| Message ID | 20230122144749.87597-1-newbyte@postmarketos.org |
|---|---|
| Headers | show |
| Series | Add samsung-matisselte and common matisse dtsi | expand |
On 22/01/2023 15:47, Stefan Hansson wrote: > MSM8926 (also known as Snapdragon 400) is very similar to MSM8226 and > APQ8026 with the primary difference being that it features an LTE modem > unlike the former two which feature a 3G modem and a GPS-only modem, > respectively. > > This also documents Samsung Galaxy Tab 4 10.1 LTE (samsung,matisselte) > which is a tablet by Samsung based on the MSM8926 SoC. > > Signed-off-by: Stefan Hansson <newbyte@postmarketos.org> > --- > Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml > index 47913a8e3eea..7a0b2088ead9 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -35,6 +35,7 @@ description: | > mdm9615 > msm8226 > msm8916 > + msm8926 > msm8953 > msm8956 > msm8974 > @@ -219,6 +220,11 @@ properties: > - const: qcom,msm8916-v1-qrd/9-v1 > - const: qcom,msm8916 > > + - items: > + - enum: > + - samsung,matisselte 1. matisse is the code name, lte is version/suffix. I don't think they should be together, because then it looks like "matisselte" is a name. It actually sounds like one word. 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... Best regards, Krzysztof
On 23/01/2023 18:10, Krzysztof Kozlowski wrote: > On 22/01/2023 15:47, Stefan Hansson wrote: >> MSM8926 (also known as Snapdragon 400) is very similar to MSM8226 and >> APQ8026 with the primary difference being that it features an LTE modem >> unlike the former two which feature a 3G modem and a GPS-only modem, >> respectively. >> >> This also documents Samsung Galaxy Tab 4 10.1 LTE (samsung,matisselte) >> which is a tablet by Samsung based on the MSM8926 SoC. >> >> Signed-off-by: Stefan Hansson <newbyte@postmarketos.org> >> --- >> Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >> index 47913a8e3eea..7a0b2088ead9 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >> @@ -35,6 +35,7 @@ description: | >> mdm9615 >> msm8226 >> msm8916 >> + msm8926 >> msm8953 >> msm8956 >> msm8974 >> @@ -219,6 +220,11 @@ properties: >> - const: qcom,msm8916-v1-qrd/9-v1 >> - const: qcom,msm8916 >> >> + - items: >> + - enum: >> + - samsung,matisselte > > 1. matisse is the code name, lte is version/suffix. I don't think they > should be together, because then it looks like "matisselte" is a name. > It actually sounds like one word. Update: there is already matisse-wifi, so please follow the same naming convention. Version suffix should be separated with hyphen. > > 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... Best regards, Krzysztof
On 22/01/2023 15:47, Stefan Hansson wrote: > According to the dts from the kernel source code released by Samsung, > matissewifi and matisselte only have minor differences in hardware, so > use a shared dtsi to reduce duplicated code. Additionally, this should > make adding support for matisse3g easier should someone want to do that > at a later point. > > As such, add a common device tree for all matisse devices by Samsung > based on the matissewifi dts. Support for matisselte will be introduced > in a later patch in this series and will use the common dtsi as well. > > Signed-off-by: Stefan Hansson <newbyte@postmarketos.org> > --- Decompiled DTB is the same, so: Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> (although not on a device...) Best regards, Krzysztof
On 2023-01-23 18:11, Krzysztof Kozlowski wrote: > On 23/01/2023 18:10, Krzysztof Kozlowski wrote: >> On 22/01/2023 15:47, Stefan Hansson wrote: >>> MSM8926 (also known as Snapdragon 400) is very similar to MSM8226 and >>> APQ8026 with the primary difference being that it features an LTE modem >>> unlike the former two which feature a 3G modem and a GPS-only modem, >>> respectively. >>> >>> This also documents Samsung Galaxy Tab 4 10.1 LTE (samsung,matisselte) >>> which is a tablet by Samsung based on the MSM8926 SoC. >>> >>> Signed-off-by: Stefan Hansson <newbyte@postmarketos.org> >>> --- >>> Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++++++ >>> 1 file changed, 6 insertions(+) >>> >>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >>> index 47913a8e3eea..7a0b2088ead9 100644 >>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >>> @@ -35,6 +35,7 @@ description: | >>> mdm9615 >>> msm8226 >>> msm8916 >>> + msm8926 >>> msm8953 >>> msm8956 >>> msm8974 >>> @@ -219,6 +220,11 @@ properties: >>> - const: qcom,msm8916-v1-qrd/9-v1 >>> - const: qcom,msm8916 >>> >>> + - items: >>> + - enum: >>> + - samsung,matisselte >> >> 1. matisse is the code name, lte is version/suffix. I don't think they >> should be together, because then it looks like "matisselte" is a name. >> It actually sounds like one word. > > Update: there is already matisse-wifi, so please follow the same naming > convention. Version suffix should be separated with hyphen. > I'm aware, and I've been in contact with the matisse-wifi dts author who told me that he went with this name because you suggested it (he had originally sent it in as matissewifi). However I don't think diverging from how the rest of the community refers to it is a good idea. Codenames often sound nonsensical, but they have effectively become the de-facto universal identifier for devices in the community and so I think retaining that consistency is more beneficial than making it sound nice. Additionally, while matisse-wifi has the hyphen added before the suffix, many other Samsung devices do not (klte, jackpotlte, s3ve3g). As such, I think the name matisse-wifi is the outlier here rather than matisselte (but yes, I do understand that they are more related to each other than the other devices mentioned). Does that sound sensible? >> >> 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 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? > > Best regards, > Krzysztof > Thanks for the review, Stefan Hansson
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. > > 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
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
This series adds a common samsung-matisse dtsi and reworks samsung-matisse-wifi to use it, and introduces samsung-matisselte. I choose matisselte over matisse-lte as this is how most other devices (klte, s3ve3g) do it and it is the codename that Samsung gave the device. See individual commits for more information. Stefan Hansson (3): ARM: dts: qcom: samsung-matisse-common: Add initial common device tree dt-bindings: arm: qcom: Add MSM8926 and Samsung Galaxy Tab 4 10.1 LTE ARM: dts: qcom: Add support for Samsung Galaxy Tab 4 10.1 LTE (SM-T535) .../devicetree/bindings/arm/qcom.yaml | 6 + arch/arm/boot/dts/Makefile | 1 + .../dts/qcom-apq8026-samsung-matisse-wifi.dts | 511 +----------------- .../qcom-msm8226-samsung-matisse-common.dtsi | 510 +++++++++++++++++ .../dts/qcom-msm8926-samsung-matisselte.dts | 39 ++ 5 files changed, 568 insertions(+), 499 deletions(-) create mode 100644 arch/arm/boot/dts/qcom-msm8226-samsung-matisse-common.dtsi create mode 100644 arch/arm/boot/dts/qcom-msm8926-samsung-matisselte.dts