[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z4dMRjK5I8s2lT3k@hu-wasimn-hyd.qualcomm.com>
Date: Wed, 15 Jan 2025 11:18:54 +0530
From: Wasim Nazir <quic_wasimn@...cinc.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
CC: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
Bjorn Andersson
<andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring
<robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley
<conor+dt@...nel.org>, <linux-arm-msm@...r.kernel.org>,
<devicetree@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<kernel@...cinc.com>
Subject: Re: [PATCH v5 5/6] arm64: dts: qcom: Add support for QCS9075 Ride &
Ride-r3
On Thu, Jan 09, 2025 at 05:16:25PM +0100, Krzysztof Kozlowski wrote:
> On 09/01/2025 15:47, Wasim Nazir wrote:
> > On Wed, Jan 08, 2025 at 03:09:09PM +0100, Krzysztof Kozlowski wrote:
> >> On 03/01/2025 20:58, Dmitry Baryshkov wrote:
> >>>>>>>> Initially, we included the DTS [1] file to avoid duplication. However,
> >>>>>>>> based on Krzysztof's previous suggestion [2], we change to this format.
> >>>>>>>>
> >>>>>>>> Please let us know how to proceed further on this.
> >>>>>>>
> >>>>>>> Krzysztof asked you to include DTSI files instead of including DTS
> >>>>>>> files. Hope this helps.
> >>>>>>
> >>>>>> Are you suggesting that we should also modify the 9100-ride files to
> >>>>>> include DTSI instead of DTS for consistency between QCS9100 and QCS9075?
> >>>>>> However, this would result in the duplication of Ethernet nodes in all
> >>>>>> the ride board files. Would that be acceptable?
> >>>>>
> >>>>> git mv foo.dts foo.dtsi
> >>>>> echo '#include "foo.dtsi"' > foo.dts
> >>>>> git add foo.dts
> >>>>> git commit
> >>>>>
> >>>>
> >>>> We cannot convert sa8775p-ride-r3.dts and sa8775p-ride.dts to .dtsi as
> >>>> they represent different platforms. In patch [1], we included these DTS
> >>>> files to reuse the common hardware nodes.
> >>>>
> >>>> Could you please advise on how we should proceed with the following
> >>>> approaches?
> >>>>
> >>>> a) Previous approach [1]:
> >>>> Include sa8775p-ride-r3.dts and sa8775p-ride.dts in the qcs9075-ride
> >>>> platform DTS, similar to the qcs9100-ride platform DTS. This approach
> >>>> avoids duplicating Ethernet nodes and maintains uniformity. However, it
> >>>> involves including the DTS file directly.
> >>>>
> >>>> b) Current suggestion:
> >>>> Include sa8775p-ride.dtsi in the qcs9075-ride platform DTS and also
> >>>> modify the qcs9100-ride platform DTS files to maintain uniformity. This
> >>>> approach results in duplicating Ethernet nodes.
> >>>>
> >>>> Please let us know your recommendation to finalize the DT structure.
> >>>
> >>> sa8775p.dtsi
> >>> `__sa8775p-ride.dtsi
> >>> `__sa8775p-ride-r2.dtsi
> >>> `__sa8775p-ride.dts
> >>> `__qcs9100-ride.dts
> >>> `__qcs9075-ride.dts
> >>> `__sa8775p-ride-r3.dtsi
> >>> `__sa8775p-ride-r3.dts
> >>> `__qcs9100-ride-r3.dts
> >>> `__qcs9075-ride-r3.dts
> >>>
> >> Wasim and all other copy-pasters of sa8775p-ride,
> >>
> >> Just to recap, qcs9100 contributions started this terrible pattern of
> >> board including a board. Unfortunately qcs9100 was merged, so that ship
> >> has sailed.
> >>
> >> This patchset was going the same way, because poor choices like to keep
> >> spreading, but at one of previous versions I noticed it and objected.
> >>
> >> This v5 however solves above problem by duplicating the nodes.
> >>
> >> Apparently all these designs - sa8755p, qcs9100 and qcs9075 - use the
> >> same board, but none of this was communicated. I checked all the commit
> >> msgs in this patchset and nothing explained about it. What annoys me is
> >> that you do not communicate your design forcing us to accept poor DTS or
> >> forcing us to guess and make poor judgments.
> >>
> >> Come with proper hardware description and split out shared parts, like
> >> motherboard. Look how other vendors are doing it, e.g. NXP or Renesas.
> >> But assuming there are shared parts because I am pretty sure you will
> >> pick my comments when it suits you without actually following them fully
> >> and without understanding and explaining to us your own hardware.
> >>
> >
> > Hi Krzysztof,
> >
> > Here is the pictorial flow showing how SoCs are derived and what all boards
> > are supported.
> >
> > +---------------------------------------------------------------------+
> > | |
> > | sa8775p |
> > | | |
> > | +-----------------------+-----------------------+ |
> > | | | | |
> > | v | v |
> > | qcs9100 | qcs9075 |
> > | | | | |
> > | v v v |
> > | (IOT) (AUTO) (IOT) |
> > | qcs9100-ride.dts sa8775p-ride.dts qcs9075-ride.dts |
> > | qcs9100-ride-r3.dts sa8775p-ride-r3.dts qcs9075-ride-r3.dts |
> > | qcs9075-rb8.dts |
> > | |
> > +---------------------------------------------------------------------+
>
> The the SoC, I am asking about the board. Why each of them is for
> example r3?
>
> So this is not sufficient explanation, nothing about the board, and
> again just look Renesas and NXP.
>
Hi Krzysztof,
sa8775p(AUTO), qcs9100(IOT), qcs9075(IOT) are different SoCs based on
safety capabilities and memory map, serving different purpose.
Ride & Ride-r3 are different boards based on ethernet capabilities and
are compatible with all the SoCs mentioned.
With the combination of these 3 SoCs and 2 boards, we have 6 platforms,
all of which we need.
- sa8775p-ride.dts is auto grade Ride platform with safety feature.
- qcs9100-ride.dts is IOT grade Ride platform with safety feature.
- qcs9075-ride.dts is IOT grade Ride platform without safety feature.
Since the Ride-r3 boards are essentially Ride boards with Ethernet
modifications, we can convert the Ride-r3 DTS to overlays.
Please let me know if this solution works for you.
>
> Best regards,
> Krzysztof
Thanks & Regards,
Wasim
Powered by blists - more mailing lists