[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1938307.usQuhbGJ8B@g550jk>
Date: Sat, 28 Jan 2023 22:43:11 +0100
From: Luca Weiss <luca@...tu.xyz>
To: Stefan Hansson <newbyte@...tmarketos.org>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
soc@...nel.org, linux-arm-msm@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
~postmarketos/upstreaming@...ts.sr.ht
Cc: ~postmarketos/upstreaming@...ts.sr.ht, phone-devel@...r.kernel.org,
matti.lehtimaki@...il.com,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH 2/3] dt-bindings: arm: qcom: Add MSM8926 and Samsung Galaxy Tab 4
10.1 LTE
On Montag, 23. Jänner 2023 19:08:03 CET Krzysztof Kozlowski wrote:
> On 23/01/2023 18:41, Stefan Hansson wrote:
> >>> 2. You base on other SoC but you do not include its compatibles. Why? Is
> >>> it intended? None of the properties applicable to other SoC will match
> >>> here, thus I actually wonder if you run dtbs_check...
> >
> > Sorry, I forgot about running dtbs_check. However, I'm not sure I
> > understand the question. What do you mean by that I don't include its
> > compatibles?
>
> I understood you include the msm8226.dtsi which is a different SoC. If
> you include it, you get all of its content. We do it only for compatible
> devices, but your device does not indicate compatibility with msm8226.
Hi Krzysztof,
the way the earlier Qualcomm SoCs work, especially regarding naming scheme is
the following.
There's for example the msm8x74 family which includes msm8974, msm8674,
msm8274, and the a bit differently named apq8074 where the significant
different are the RF capabilities, I think with those only 8974 had LTE, 8674
and 8274 only 3G but different band support, and the apq8074 has no mobile
radio.
The same exists for sure also for 8x16 and 8x26, probably a bunch of other
SoCs as well.
So from software side (apart from modem firmware of course) it can be treated
in practise as the same SoC so that's why we included the dtsi in this case in
msm8226 but also msm8926 and apq8026.
But the compatible on board-level is in practise (to my knowledge) not really
used for anything important other than having a nice string in the dts file. I
know some software uses compatible from user space but there for
differentiating between different devices and ignoring the SoC compatibles.
But while they are software-compatible for the most part, they *are* distinct
SoCs with different capabilities and I just don't see the point in trying to
establish some kinds of relationships between different SoCs that are somewhat
or very similar (msm8226 and msm8974 also share many components but are
obviously different SoCs).
And also e.g. (nearly) all apq* dts files we already have in mainline only
have apq compatible and not the corresponding msm* compatible. And I think
that's totally legitimate.
Regards
Luca
>
> > I ran `$ make dtbs_check DT_SCHEMA_FILES=qcom.yaml` locally just now,
> > and it only gave me errors from the qcom-msm8974pro-oneplus-bacon dtb.
> > Maybe I'm running it wrong?
>
> No clue, I cannot test because your patches do not apply cleanly.
>
> Best regards,
> Krzysztof
Powered by blists - more mailing lists