* [PATCH v2 0/2] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id @ 2022-06-21 18:56 Krzysztof Kozlowski 2022-06-21 18:56 ` [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Krzysztof Kozlowski 2022-06-21 18:56 ` [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples Krzysztof Kozlowski 0 siblings, 2 replies; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-21 18:56 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd, Krzysztof Kozlowski Hi, Changes since v1 ================ 1. Make the qcom,board-id and qcom,msm-id properties deprecated and limited to certain SoCs (Rob). 2. Extend the qcom,board-id schema to match OnePlus variant - four elements - and drop DTS patches splitting four into two touples (Stephan). Description =========== The discussion [1] brought several arguments for keeping the qcom,board-id and qcom,msm-id properties. Keeping means we should document them, so the DT schema checks pass. I revived old patch [2] with several changes and improvements. The commit msg hopefully collects feedback from the discussion. Best regards, Krzysztof [1] https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ [2] https://lore.kernel.org/all/1425503602-24916-1-git-send-email-galak@codeaurora.org/ Krzysztof Kozlowski (2): dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ .../boot/dts/qcom/msm8992-xiaomi-libra.dts | 2 +- include/dt-bindings/arm/qcom,ids.h | 30 +++++ 3 files changed, 154 insertions(+), 1 deletion(-) create mode 100644 include/dt-bindings/arm/qcom,ids.h -- 2.34.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 18:56 [PATCH v2 0/2] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id Krzysztof Kozlowski @ 2022-06-21 18:56 ` Krzysztof Kozlowski 2022-06-21 19:26 ` Dmitry Baryshkov 2022-06-22 9:44 ` Dmitry Baryshkov 2022-06-21 18:56 ` [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples Krzysztof Kozlowski 1 sibling, 2 replies; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-21 18:56 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd, Krzysztof Kozlowski The top level qcom,msm-id and qcom,board-id properties are utilized by bootloaders on Qualcomm MSM platforms to determine which device tree should be used and passed to the kernel. The commit b32e592d3c28 ("devicetree: bindings: Document qcom board compatible format") from 2015 was a consensus during discussion about upstreaming qcom,msm-id and qcom,board-id fields. There are however still problems with that consensus: 1. It was reached 7 years ago but it turned out its implementation did not reach all possible products. 2. Initially additional tool (dtbTool) was needed for parsing these fields to create a QCDT image consisting of multiple DTBs, later the bootloaders were improved and they use these qcom,msm-id and qcom,board-id properties directly. 3. Extracting relevant information from the board compatible requires this additional tool (dtbTool), which makes the build process more complicated and not easily reproducible (DTBs are modified after the kernel build). 4. Some versions of Qualcomm bootloaders expect these properties even when booting with a single DTB. The community is stuck with these bootloaders thus they require properties in the DTBs. Since several upstreamed Qualcomm SoC-based boards require these properties to properly boot and the properties are reportedly used by bootloaders, document them. Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ Co-developed-by: Kumar Gala <galak@codeaurora.org> Signed-off-by: Kumar Gala <galak@codeaurora.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ include/dt-bindings/arm/qcom,ids.h | 30 +++++ 2 files changed, 153 insertions(+) create mode 100644 include/dt-bindings/arm/qcom,ids.h diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 6c38c1387afd..05b98cde4653 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -403,6 +403,129 @@ properties: - qcom,sm8450-qrd - const: qcom,sm8450 + # Board compatibles go above + + qcom,msm-id: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 8 + items: + items: + - description: | + MSM chipset ID - an exact match value consisting of three bitfields:: + - bits 0-15 - The unique MSM chipset ID + - bits 16-31 - Reserved; should be 0 + - description: | + Hardware revision ID - a chipset specific 32-bit ID representing + the version of the chipset. It is best a match value - the + bootloader will look for the closest possible match. + deprecated: true + description: + The MSM chipset and hardware revision use by Qualcomm bootloaders. It + can optionally be an array of these to indicate multiple hardware that + use the same device tree. It is expected that the bootloader will use + this information at boot-up to decide which device tree to use when given + multiple device trees, some of which may not be compatible with the + actual hardware. It is the bootloader's responsibility to pass the + correct device tree to the kernel. + The property is deprecated - it is not expected on newer boards + (starting with SM8350). + + qcom,board-id: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + minItems: 1 + maxItems: 8 + items: + oneOf: + - maxItems: 2 + items: + - description: | + Board ID consisting of three bitfields:: + - bits 31-24 - Unused + - bits 23-16 - Platform Version Major + - bits 15-8 - Platform Version Minor + - bits 7-0 - Platform Type + Platform Type field is an exact match value. The + Platform Major/Minor field is a best match. The bootloader will + look for the closest possible match. + - description: | + Subtype ID unique to a Platform Type/Chipset ID. For a given + Platform Type, there will typically only be a single board and the + subtype_id will be 0. However in some cases board variants may + need to be distinguished by different subtype_id values. + # OnePlus uses a variant of board-id with four elements: + - minItems: 4 + items: + - const: 8 + - const: 0 + - description: OnePlus board ID + - description: OnePlus subtype ID + deprecated: true + description: + The board type and revision information. It can optionally be an array + of these to indicate multiple boards that use the same device tree. It + is expected that the bootloader will use this information at boot-up to + decide which device tree to use when given multiple device trees, some of + which may not be compatible with the actual hardware. It is the + bootloader's responsibility to pass the correct device tree to the + kernel + The property is deprecated - it is not expected on newer boards + (starting with SM8350). + +allOf: + # Explicit allow-list for older SoCs. The legacy properties are not allowed + # on newer SoCs. + - if: + properties: + compatible: + contains: + enum: + - qcom,apq8026 + - qcom,apq8094 + - qcom,apq8096 + - qcom,msm8992 + - qcom,msm8994 + - qcom,msm8996 + - qcom,msm8998 + - qcom,sdm630 + - qcom,sdm632 + - qcom,sdm845 + - qcom,sdx55 + - qcom,sdx65 + - qcom,sm6125 + - qcom,sm6350 + - qcom,sm7225 + - qcom,sm8150 + - qcom,sm8250 + then: + properties: + qcom,board-id: true + qcom,msm-id: true + else: + properties: + qcom,board-id: false + qcom,msm-id: false + + - if: + properties: + compatible: + contains: + enum: + - oneplus,cheeseburger + - oneplus,dumpling + - oneplus,enchilada + - oneplus,fajita + then: + properties: + qcom,board-id: + items: + minItems: 4 + else: + properties: + qcom,board-id: + items: + maxItems: 2 + additionalProperties: true ... diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h new file mode 100644 index 000000000000..eaf86c18650f --- /dev/null +++ b/include/dt-bindings/arm/qcom,ids.h @@ -0,0 +1,30 @@ +/* SPDX-License-Identifier: GPL-2.0-only */ +/* + * Copyright (c) 2015, The Linux Foundation. All rights reserved. + * Copyright (c) 2022 Linaro Ltd + * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala. + */ +#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H +#define _DT_BINDINGS_ARM_QCOM_IDS_H + +/* qcom,msm-id */ +#define QCOM_ID_APQ8026 199 +#define QCOM_ID_MSM8916 206 +#define QCOM_ID_MSM8994 207 +#define QCOM_ID_MSM8996_3_0 246 +#define QCOM_ID_APQ8016 247 +#define QCOM_ID_MSM8216 248 +#define QCOM_ID_MSM8116 249 +#define QCOM_ID_MSM8616 250 +#define QCOM_ID_MSM8998 292 +#define QCOM_ID_SDM845 321 + +/* qcom,board-id */ +#define QCOM_BOARD_ID(a, major, minor) \ + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) + +#define QCOM_BOARD_ID_MTP 8 +#define QCOM_BOARD_ID_DRAGONBOARD 10 +#define QCOM_BOARD_ID_SBC 24 + +#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ -- 2.34.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 18:56 ` [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Krzysztof Kozlowski @ 2022-06-21 19:26 ` Dmitry Baryshkov 2022-06-21 19:32 ` Krzysztof Kozlowski 2022-06-22 9:44 ` Dmitry Baryshkov 1 sibling, 1 reply; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-21 19:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 21/06/2022 21:56, Krzysztof Kozlowski wrote: > The top level qcom,msm-id and qcom,board-id properties are utilized by > bootloaders on Qualcomm MSM platforms to determine which device tree > should be used and passed to the kernel. > > The commit b32e592d3c28 ("devicetree: bindings: Document qcom board > compatible format") from 2015 was a consensus during discussion about > upstreaming qcom,msm-id and qcom,board-id fields. There are however still > problems with that consensus: > 1. It was reached 7 years ago but it turned out its implementation did > not reach all possible products. > > 2. Initially additional tool (dtbTool) was needed for parsing these > fields to create a QCDT image consisting of multiple DTBs, later the > bootloaders were improved and they use these qcom,msm-id and > qcom,board-id properties directly. I might be mistaken here. I think it was expected that dtbTool would use board compat strings to generate qcom,msm-id and qcom,board-id properties. It's not that the bootloaders were improved. > > 3. Extracting relevant information from the board compatible requires > this additional tool (dtbTool), which makes the build process more > complicated and not easily reproducible (DTBs are modified after the > kernel build). > > 4. Some versions of Qualcomm bootloaders expect these properties even > when booting with a single DTB. The community is stuck with these > bootloaders thus they require properties in the DTBs. > > Since several upstreamed Qualcomm SoC-based boards require these > properties to properly boot and the properties are reportedly used by > bootloaders, document them. > > Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ > Co-developed-by: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ > include/dt-bindings/arm/qcom,ids.h | 30 +++++ > 2 files changed, 153 insertions(+) > create mode 100644 include/dt-bindings/arm/qcom,ids.h > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml > index 6c38c1387afd..05b98cde4653 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -403,6 +403,129 @@ properties: > - qcom,sm8450-qrd > - const: qcom,sm8450 > > + # Board compatibles go above > + > + qcom,msm-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + minItems: 1 > + maxItems: 8 > + items: > + items: > + - description: | > + MSM chipset ID - an exact match value consisting of three bitfields:: two bitfields > + - bits 0-15 - The unique MSM chipset ID > + - bits 16-31 - Reserved; should be 0 > + - description: | > + Hardware revision ID - a chipset specific 32-bit ID representing > + the version of the chipset. It is best a match value - the > + bootloader will look for the closest possible match. > + deprecated: true > + description: > + The MSM chipset and hardware revision use by Qualcomm bootloaders. It > + can optionally be an array of these to indicate multiple hardware that > + use the same device tree. It is expected that the bootloader will use > + this information at boot-up to decide which device tree to use when given > + multiple device trees, some of which may not be compatible with the > + actual hardware. It is the bootloader's responsibility to pass the > + correct device tree to the kernel. > + The property is deprecated - it is not expected on newer boards > + (starting with SM8350). Could you please elaborate this? If the AOSP team were to add e.g. SM8350-HDK to their single RB3+RB5 images, they would still need the qcom,board-id/qcom,msm-id properties to let the bootloader choose proper DTB. > + > + qcom,board-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + minItems: 1 > + maxItems: 8 > + items: > + oneOf: > + - maxItems: 2 > + items: > + - description: | > + Board ID consisting of three bitfields:: > + - bits 31-24 - Unused > + - bits 23-16 - Platform Version Major > + - bits 15-8 - Platform Version Minor > + - bits 7-0 - Platform Type > + Platform Type field is an exact match value. The > + Platform Major/Minor field is a best match. The bootloader will > + look for the closest possible match. > + - description: | > + Subtype ID unique to a Platform Type/Chipset ID. For a given > + Platform Type, there will typically only be a single board and the > + subtype_id will be 0. However in some cases board variants may > + need to be distinguished by different subtype_id values. > + # OnePlus uses a variant of board-id with four elements: > + - minItems: 4 > + items: > + - const: 8 > + - const: 0 > + - description: OnePlus board ID > + - description: OnePlus subtype ID > + deprecated: true > + description: > + The board type and revision information. It can optionally be an array > + of these to indicate multiple boards that use the same device tree. It > + is expected that the bootloader will use this information at boot-up to > + decide which device tree to use when given multiple device trees, some of > + which may not be compatible with the actual hardware. It is the > + bootloader's responsibility to pass the correct device tree to the > + kernel > + The property is deprecated - it is not expected on newer boards > + (starting with SM8350). > + > +allOf: > + # Explicit allow-list for older SoCs. The legacy properties are not allowed > + # on newer SoCs. > + - if: > + properties: > + compatible: > + contains: > + enum: > + - qcom,apq8026 > + - qcom,apq8094 > + - qcom,apq8096 > + - qcom,msm8992 > + - qcom,msm8994 > + - qcom,msm8996 > + - qcom,msm8998 > + - qcom,sdm630 > + - qcom,sdm632 > + - qcom,sdm845 > + - qcom,sdx55 > + - qcom,sdx65 > + - qcom,sm6125 > + - qcom,sm6350 > + - qcom,sm7225 > + - qcom,sm8150 > + - qcom,sm8250 > + then: > + properties: > + qcom,board-id: true > + qcom,msm-id: true > + else: > + properties: > + qcom,board-id: false > + qcom,msm-id: false > + > + - if: > + properties: > + compatible: > + contains: > + enum: > + - oneplus,cheeseburger > + - oneplus,dumpling > + - oneplus,enchilada > + - oneplus,fajita > + then: > + properties: > + qcom,board-id: > + items: > + minItems: 4 > + else: > + properties: > + qcom,board-id: > + items: > + maxItems: 2 > + > additionalProperties: true > > ... > diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h > new file mode 100644 > index 000000000000..eaf86c18650f > --- /dev/null > +++ b/include/dt-bindings/arm/qcom,ids.h > @@ -0,0 +1,30 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) 2015, The Linux Foundation. All rights reserved. > + * Copyright (c) 2022 Linaro Ltd > + * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala. > + */ > +#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H > +#define _DT_BINDINGS_ARM_QCOM_IDS_H > + > +/* qcom,msm-id */ > +#define QCOM_ID_APQ8026 199 > +#define QCOM_ID_MSM8916 206 > +#define QCOM_ID_MSM8994 207 > +#define QCOM_ID_MSM8996_3_0 246 2_0 too. And then (according to 3.18): 8996-pro 305 8996-pro-auto 315 8996-auto 310 > +#define QCOM_ID_APQ8016 247 > +#define QCOM_ID_MSM8216 248 > +#define QCOM_ID_MSM8116 249 > +#define QCOM_ID_MSM8616 250 > +#define QCOM_ID_MSM8998 292 > +#define QCOM_ID_SDM845 321 sdm845-v2.1-rb3.dts: qcom,msm-id = <341 0x20001>; But this might be a typo > + > +/* qcom,board-id */ > +#define QCOM_BOARD_ID(a, major, minor) \ > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) > + > +#define QCOM_BOARD_ID_MTP 8 > +#define QCOM_BOARD_ID_DRAGONBOARD 10 > +#define QCOM_BOARD_ID_SBC 24 > + > +#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 19:26 ` Dmitry Baryshkov @ 2022-06-21 19:32 ` Krzysztof Kozlowski 2022-06-21 19:49 ` Dmitry Baryshkov 0 siblings, 1 reply; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-21 19:32 UTC (permalink / raw) To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 21/06/2022 21:26, Dmitry Baryshkov wrote: > On 21/06/2022 21:56, Krzysztof Kozlowski wrote: >> The top level qcom,msm-id and qcom,board-id properties are utilized by >> bootloaders on Qualcomm MSM platforms to determine which device tree >> should be used and passed to the kernel. >> >> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >> compatible format") from 2015 was a consensus during discussion about >> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >> problems with that consensus: >> 1. It was reached 7 years ago but it turned out its implementation did >> not reach all possible products. >> >> 2. Initially additional tool (dtbTool) was needed for parsing these >> fields to create a QCDT image consisting of multiple DTBs, later the >> bootloaders were improved and they use these qcom,msm-id and >> qcom,board-id properties directly. > > I might be mistaken here. I think it was expected that dtbTool would use > board compat strings to generate qcom,msm-id and qcom,board-id > properties. It's not that the bootloaders were improved. Don't ask me, I am new to this. https://lore.kernel.org/all/02ab0276-b078-fe66-8596-fcec4378722b@somainline.org/ > >> >> 3. Extracting relevant information from the board compatible requires >> this additional tool (dtbTool), which makes the build process more >> complicated and not easily reproducible (DTBs are modified after the >> kernel build). >> >> 4. Some versions of Qualcomm bootloaders expect these properties even >> when booting with a single DTB. The community is stuck with these >> bootloaders thus they require properties in the DTBs. >> >> Since several upstreamed Qualcomm SoC-based boards require these >> properties to properly boot and the properties are reportedly used by >> bootloaders, document them. >> >> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ >> Co-developed-by: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> --- >> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ >> include/dt-bindings/arm/qcom,ids.h | 30 +++++ >> 2 files changed, 153 insertions(+) >> create mode 100644 include/dt-bindings/arm/qcom,ids.h >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >> index 6c38c1387afd..05b98cde4653 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >> @@ -403,6 +403,129 @@ properties: >> - qcom,sm8450-qrd >> - const: qcom,sm8450 >> >> + # Board compatibles go above >> + >> + qcom,msm-id: >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >> + minItems: 1 >> + maxItems: 8 >> + items: >> + items: >> + - description: | >> + MSM chipset ID - an exact match value consisting of three bitfields:: > > two bitfields Right, thanks. > >> + - bits 0-15 - The unique MSM chipset ID >> + - bits 16-31 - Reserved; should be 0 >> + - description: | >> + Hardware revision ID - a chipset specific 32-bit ID representing >> + the version of the chipset. It is best a match value - the >> + bootloader will look for the closest possible match. >> + deprecated: true >> + description: >> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It >> + can optionally be an array of these to indicate multiple hardware that >> + use the same device tree. It is expected that the bootloader will use >> + this information at boot-up to decide which device tree to use when given >> + multiple device trees, some of which may not be compatible with the >> + actual hardware. It is the bootloader's responsibility to pass the >> + correct device tree to the kernel. >> + The property is deprecated - it is not expected on newer boards >> + (starting with SM8350). > > Could you please elaborate this? Second paragraph: https://lore.kernel.org/all/20220522195138.35943-1-konrad.dybcio@somainline.org/ Plus consensus with Rob: https://lore.kernel.org/all/CAL_JsqKL-mtAQ8Q9H4vLGM8izVVzDPbUAVWSdS8AmGjN6X6kcA@mail.gmail.com/ > If the AOSP team were to add e.g. > SM8350-HDK to their single RB3+RB5 images, they would still need the > qcom,board-id/qcom,msm-id properties to let the bootloader choose proper > DTB. If you have any email addresses in mind, please Cc them to invite in discussions. Otherwise I am afraid it won't be allowed. The feedback I got before was that SM8350 and newer do not require this property. Feel free to propose other way to solve comments (see "consensus with Rob" above). > >> + >> + qcom,board-id: >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >> + minItems: 1 >> + maxItems: 8 >> + items: >> + oneOf: >> + - maxItems: 2 >> + items: >> + - description: | >> + Board ID consisting of three bitfields:: >> + - bits 31-24 - Unused >> + - bits 23-16 - Platform Version Major >> + - bits 15-8 - Platform Version Minor >> + - bits 7-0 - Platform Type >> + Platform Type field is an exact match value. The >> + Platform Major/Minor field is a best match. The bootloader will >> + look for the closest possible match. >> + - description: | >> + Subtype ID unique to a Platform Type/Chipset ID. For a given >> + Platform Type, there will typically only be a single board and the >> + subtype_id will be 0. However in some cases board variants may >> + need to be distinguished by different subtype_id values. >> + # OnePlus uses a variant of board-id with four elements: >> + - minItems: 4 >> + items: >> + - const: 8 >> + - const: 0 >> + - description: OnePlus board ID >> + - description: OnePlus subtype ID >> + deprecated: true >> + description: >> + The board type and revision information. It can optionally be an array >> + of these to indicate multiple boards that use the same device tree. It >> + is expected that the bootloader will use this information at boot-up to >> + decide which device tree to use when given multiple device trees, some of >> + which may not be compatible with the actual hardware. It is the >> + bootloader's responsibility to pass the correct device tree to the >> + kernel >> + The property is deprecated - it is not expected on newer boards >> + (starting with SM8350). >> + >> +allOf: >> + # Explicit allow-list for older SoCs. The legacy properties are not allowed >> + # on newer SoCs. >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - qcom,apq8026 >> + - qcom,apq8094 >> + - qcom,apq8096 >> + - qcom,msm8992 >> + - qcom,msm8994 >> + - qcom,msm8996 >> + - qcom,msm8998 >> + - qcom,sdm630 >> + - qcom,sdm632 >> + - qcom,sdm845 >> + - qcom,sdx55 >> + - qcom,sdx65 >> + - qcom,sm6125 >> + - qcom,sm6350 >> + - qcom,sm7225 >> + - qcom,sm8150 >> + - qcom,sm8250 >> + then: >> + properties: >> + qcom,board-id: true >> + qcom,msm-id: true >> + else: >> + properties: >> + qcom,board-id: false >> + qcom,msm-id: false >> + >> + - if: >> + properties: >> + compatible: >> + contains: >> + enum: >> + - oneplus,cheeseburger >> + - oneplus,dumpling >> + - oneplus,enchilada >> + - oneplus,fajita >> + then: >> + properties: >> + qcom,board-id: >> + items: >> + minItems: 4 >> + else: >> + properties: >> + qcom,board-id: >> + items: >> + maxItems: 2 >> + >> additionalProperties: true >> >> ... >> diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h >> new file mode 100644 >> index 000000000000..eaf86c18650f >> --- /dev/null >> +++ b/include/dt-bindings/arm/qcom,ids.h >> @@ -0,0 +1,30 @@ >> +/* SPDX-License-Identifier: GPL-2.0-only */ >> +/* >> + * Copyright (c) 2015, The Linux Foundation. All rights reserved. >> + * Copyright (c) 2022 Linaro Ltd >> + * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala. >> + */ >> +#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H >> +#define _DT_BINDINGS_ARM_QCOM_IDS_H >> + >> +/* qcom,msm-id */ >> +#define QCOM_ID_APQ8026 199 >> +#define QCOM_ID_MSM8916 206 >> +#define QCOM_ID_MSM8994 207 >> +#define QCOM_ID_MSM8996_3_0 246 > > 2_0 too. > And then (according to 3.18): > 8996-pro 305 > 8996-pro-auto 315 > 8996-auto 310 Sure, I can add these. > >> +#define QCOM_ID_APQ8016 247 >> +#define QCOM_ID_MSM8216 248 >> +#define QCOM_ID_MSM8116 249 >> +#define QCOM_ID_MSM8616 250 >> +#define QCOM_ID_MSM8998 292 >> +#define QCOM_ID_SDM845 321 > > sdm845-v2.1-rb3.dts: qcom,msm-id = <341 0x20001>; > But this might be a typo Yeah, that's an interesting one. I did not fill the list to all possible options, rather to some subset of more reasonable sources. > >> + >> +/* qcom,board-id */ >> +#define QCOM_BOARD_ID(a, major, minor) \ >> + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) >> + >> +#define QCOM_BOARD_ID_MTP 8 >> +#define QCOM_BOARD_ID_DRAGONBOARD 10 >> +#define QCOM_BOARD_ID_SBC 24 >> + >> +#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ > > Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 19:32 ` Krzysztof Kozlowski @ 2022-06-21 19:49 ` Dmitry Baryshkov 2022-06-22 7:00 ` Krzysztof Kozlowski 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-21 19:49 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On Tue, 21 Jun 2022 at 22:32, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> wrote: > > On 21/06/2022 21:26, Dmitry Baryshkov wrote: > > On 21/06/2022 21:56, Krzysztof Kozlowski wrote: > >> The top level qcom,msm-id and qcom,board-id properties are utilized by > >> bootloaders on Qualcomm MSM platforms to determine which device tree > >> should be used and passed to the kernel. > >> > >> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board > >> compatible format") from 2015 was a consensus during discussion about > >> upstreaming qcom,msm-id and qcom,board-id fields. There are however still > >> problems with that consensus: > >> 1. It was reached 7 years ago but it turned out its implementation did > >> not reach all possible products. > >> > >> 2. Initially additional tool (dtbTool) was needed for parsing these > >> fields to create a QCDT image consisting of multiple DTBs, later the > >> bootloaders were improved and they use these qcom,msm-id and > >> qcom,board-id properties directly. > > > > I might be mistaken here. I think it was expected that dtbTool would use > > board compat strings to generate qcom,msm-id and qcom,board-id > > properties. It's not that the bootloaders were improved. > > Don't ask me, I am new to this. > > https://lore.kernel.org/all/02ab0276-b078-fe66-8596-fcec4378722b@somainline.org/ > > > > >> > >> 3. Extracting relevant information from the board compatible requires > >> this additional tool (dtbTool), which makes the build process more > >> complicated and not easily reproducible (DTBs are modified after the > >> kernel build). > >> > >> 4. Some versions of Qualcomm bootloaders expect these properties even > >> when booting with a single DTB. The community is stuck with these > >> bootloaders thus they require properties in the DTBs. > >> > >> Since several upstreamed Qualcomm SoC-based boards require these > >> properties to properly boot and the properties are reportedly used by > >> bootloaders, document them. > >> > >> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ > >> Co-developed-by: Kumar Gala <galak@codeaurora.org> > >> Signed-off-by: Kumar Gala <galak@codeaurora.org> > >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > >> --- > >> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ > >> include/dt-bindings/arm/qcom,ids.h | 30 +++++ > >> 2 files changed, 153 insertions(+) > >> create mode 100644 include/dt-bindings/arm/qcom,ids.h > >> > >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml > >> index 6c38c1387afd..05b98cde4653 100644 > >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml > >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > >> @@ -403,6 +403,129 @@ properties: > >> - qcom,sm8450-qrd > >> - const: qcom,sm8450 > >> > >> + # Board compatibles go above > >> + > >> + qcom,msm-id: > >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix > >> + minItems: 1 > >> + maxItems: 8 > >> + items: > >> + items: > >> + - description: | > >> + MSM chipset ID - an exact match value consisting of three bitfields:: > > > > two bitfields > > Right, thanks. > > > > >> + - bits 0-15 - The unique MSM chipset ID > >> + - bits 16-31 - Reserved; should be 0 > >> + - description: | > >> + Hardware revision ID - a chipset specific 32-bit ID representing > >> + the version of the chipset. It is best a match value - the > >> + bootloader will look for the closest possible match. > >> + deprecated: true > >> + description: > >> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It > >> + can optionally be an array of these to indicate multiple hardware that > >> + use the same device tree. It is expected that the bootloader will use > >> + this information at boot-up to decide which device tree to use when given > >> + multiple device trees, some of which may not be compatible with the > >> + actual hardware. It is the bootloader's responsibility to pass the > >> + correct device tree to the kernel. > >> + The property is deprecated - it is not expected on newer boards > >> + (starting with SM8350). > > > > Could you please elaborate this? > > Second paragraph: > https://lore.kernel.org/all/20220522195138.35943-1-konrad.dybcio@somainline.org/ I think this is something peculiar to Sony. Public lahaina (sm8350) dts files contain both these properties: https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-hdk.dts https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-v2.1.dtsi > > Plus consensus with Rob: > https://lore.kernel.org/all/CAL_JsqKL-mtAQ8Q9H4vLGM8izVVzDPbUAVWSdS8AmGjN6X6kcA@mail.gmail.com/ I'm not sure here. But sm8350 and sm8450 dtsi files use these properties. I've linked lahaina files above. The waiptio dtsi (sm8450) are present at the same URL. > > > If the AOSP team were to add e.g. > > SM8350-HDK to their single RB3+RB5 images, they would still need the > > qcom,board-id/qcom,msm-id properties to let the bootloader choose proper > > DTB. > > If you have any email addresses in mind, please Cc them to invite in > discussions. Otherwise I am afraid it won't be allowed. The feedback I > got before was that SM8350 and newer do not require this property. Feel > free to propose other way to solve comments (see "consensus with Rob" > above). Amit is in CC list. In the past he used these properties to allow single-image booting of RB3 and RB5. In fact I might prefer adding more of these properties to the dts files, where it makes sense, to allow adding more dt files to the images we create. I'd really like to be able to boot a single image on all my boards (rb3, rb5, db410c, db820, ifc6560, etc). > > > > >> + > >> + qcom,board-id: > >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix > >> + minItems: 1 > >> + maxItems: 8 > >> + items: > >> + oneOf: > >> + - maxItems: 2 > >> + items: > >> + - description: | > >> + Board ID consisting of three bitfields:: > >> + - bits 31-24 - Unused > >> + - bits 23-16 - Platform Version Major > >> + - bits 15-8 - Platform Version Minor > >> + - bits 7-0 - Platform Type > >> + Platform Type field is an exact match value. The > >> + Platform Major/Minor field is a best match. The bootloader will > >> + look for the closest possible match. > >> + - description: | > >> + Subtype ID unique to a Platform Type/Chipset ID. For a given > >> + Platform Type, there will typically only be a single board and the > >> + subtype_id will be 0. However in some cases board variants may > >> + need to be distinguished by different subtype_id values. > >> + # OnePlus uses a variant of board-id with four elements: > >> + - minItems: 4 > >> + items: > >> + - const: 8 > >> + - const: 0 > >> + - description: OnePlus board ID > >> + - description: OnePlus subtype ID > >> + deprecated: true > >> + description: > >> + The board type and revision information. It can optionally be an array > >> + of these to indicate multiple boards that use the same device tree. It > >> + is expected that the bootloader will use this information at boot-up to > >> + decide which device tree to use when given multiple device trees, some of > >> + which may not be compatible with the actual hardware. It is the > >> + bootloader's responsibility to pass the correct device tree to the > >> + kernel > >> + The property is deprecated - it is not expected on newer boards > >> + (starting with SM8350). > >> + > >> +allOf: > >> + # Explicit allow-list for older SoCs. The legacy properties are not allowed > >> + # on newer SoCs. > >> + - if: > >> + properties: > >> + compatible: > >> + contains: > >> + enum: > >> + - qcom,apq8026 > >> + - qcom,apq8094 > >> + - qcom,apq8096 > >> + - qcom,msm8992 > >> + - qcom,msm8994 > >> + - qcom,msm8996 > >> + - qcom,msm8998 > >> + - qcom,sdm630 > >> + - qcom,sdm632 > >> + - qcom,sdm845 > >> + - qcom,sdx55 > >> + - qcom,sdx65 > >> + - qcom,sm6125 > >> + - qcom,sm6350 > >> + - qcom,sm7225 > >> + - qcom,sm8150 > >> + - qcom,sm8250 > >> + then: > >> + properties: > >> + qcom,board-id: true > >> + qcom,msm-id: true > >> + else: > >> + properties: > >> + qcom,board-id: false > >> + qcom,msm-id: false > >> + > >> + - if: > >> + properties: > >> + compatible: > >> + contains: > >> + enum: > >> + - oneplus,cheeseburger > >> + - oneplus,dumpling > >> + - oneplus,enchilada > >> + - oneplus,fajita > >> + then: > >> + properties: > >> + qcom,board-id: > >> + items: > >> + minItems: 4 > >> + else: > >> + properties: > >> + qcom,board-id: > >> + items: > >> + maxItems: 2 > >> + > >> additionalProperties: true > >> > >> ... > >> diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h > >> new file mode 100644 > >> index 000000000000..eaf86c18650f > >> --- /dev/null > >> +++ b/include/dt-bindings/arm/qcom,ids.h > >> @@ -0,0 +1,30 @@ > >> +/* SPDX-License-Identifier: GPL-2.0-only */ > >> +/* > >> + * Copyright (c) 2015, The Linux Foundation. All rights reserved. > >> + * Copyright (c) 2022 Linaro Ltd > >> + * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala. > >> + */ > >> +#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H > >> +#define _DT_BINDINGS_ARM_QCOM_IDS_H > >> + > >> +/* qcom,msm-id */ > >> +#define QCOM_ID_APQ8026 199 > >> +#define QCOM_ID_MSM8916 206 > >> +#define QCOM_ID_MSM8994 207 > >> +#define QCOM_ID_MSM8996_3_0 246 > > > > 2_0 too. > > And then (according to 3.18): > > 8996-pro 305 > > 8996-pro-auto 315 > > 8996-auto 310 > > Sure, I can add these. Nah, it was just to complete the picture. I'd just suggest dropping the _3_0 part of the define. Let's add more ids if one needs them. > > > > >> +#define QCOM_ID_APQ8016 247 > >> +#define QCOM_ID_MSM8216 248 > >> +#define QCOM_ID_MSM8116 249 > >> +#define QCOM_ID_MSM8616 250 > >> +#define QCOM_ID_MSM8998 292 > >> +#define QCOM_ID_SDM845 321 > > > > sdm845-v2.1-rb3.dts: qcom,msm-id = <341 0x20001>; > > But this might be a typo > > Yeah, that's an interesting one. I did not fill the list to all possible > options, rather to some subset of more reasonable sources. Checked the msm-4.9. sdm845 is 321, sda845 is 341. sdm845-v2.1-rb3 is 341 because it uses the SDA845 SoC. > >> + > >> +/* qcom,board-id */ > >> +#define QCOM_BOARD_ID(a, major, minor) \ > >> + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) > >> + > >> +#define QCOM_BOARD_ID_MTP 8 > >> +#define QCOM_BOARD_ID_DRAGONBOARD 10 > >> +#define QCOM_BOARD_ID_SBC 24 > >> + > >> +#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ > > > > > > > Best regards, > Krzysztof -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 19:49 ` Dmitry Baryshkov @ 2022-06-22 7:00 ` Krzysztof Kozlowski 2022-06-22 7:31 ` Dmitry Baryshkov 0 siblings, 1 reply; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-22 7:00 UTC (permalink / raw) To: Dmitry Baryshkov Cc: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 21/06/2022 21:49, Dmitry Baryshkov wrote: > On Tue, 21 Jun 2022 at 22:32, Krzysztof Kozlowski > <krzysztof.kozlowski@linaro.org> wrote: >> >> On 21/06/2022 21:26, Dmitry Baryshkov wrote: >>> On 21/06/2022 21:56, Krzysztof Kozlowski wrote: >>>> The top level qcom,msm-id and qcom,board-id properties are utilized by >>>> bootloaders on Qualcomm MSM platforms to determine which device tree >>>> should be used and passed to the kernel. >>>> >>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >>>> compatible format") from 2015 was a consensus during discussion about >>>> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >>>> problems with that consensus: >>>> 1. It was reached 7 years ago but it turned out its implementation did >>>> not reach all possible products. >>>> >>>> 2. Initially additional tool (dtbTool) was needed for parsing these >>>> fields to create a QCDT image consisting of multiple DTBs, later the >>>> bootloaders were improved and they use these qcom,msm-id and >>>> qcom,board-id properties directly. >>> >>> I might be mistaken here. I think it was expected that dtbTool would use >>> board compat strings to generate qcom,msm-id and qcom,board-id >>> properties. It's not that the bootloaders were improved. >> >> Don't ask me, I am new to this. >> >> https://lore.kernel.org/all/02ab0276-b078-fe66-8596-fcec4378722b@somainline.org/ > > > > >> >>> >>>> >>>> 3. Extracting relevant information from the board compatible requires >>>> this additional tool (dtbTool), which makes the build process more >>>> complicated and not easily reproducible (DTBs are modified after the >>>> kernel build). >>>> >>>> 4. Some versions of Qualcomm bootloaders expect these properties even >>>> when booting with a single DTB. The community is stuck with these >>>> bootloaders thus they require properties in the DTBs. >>>> >>>> Since several upstreamed Qualcomm SoC-based boards require these >>>> properties to properly boot and the properties are reportedly used by >>>> bootloaders, document them. >>>> >>>> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ >>>> Co-developed-by: Kumar Gala <galak@codeaurora.org> >>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>> --- >>>> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ >>>> include/dt-bindings/arm/qcom,ids.h | 30 +++++ >>>> 2 files changed, 153 insertions(+) >>>> create mode 100644 include/dt-bindings/arm/qcom,ids.h >>>> >>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >>>> index 6c38c1387afd..05b98cde4653 100644 >>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >>>> @@ -403,6 +403,129 @@ properties: >>>> - qcom,sm8450-qrd >>>> - const: qcom,sm8450 >>>> >>>> + # Board compatibles go above >>>> + >>>> + qcom,msm-id: >>>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >>>> + minItems: 1 >>>> + maxItems: 8 >>>> + items: >>>> + items: >>>> + - description: | >>>> + MSM chipset ID - an exact match value consisting of three bitfields:: >>> >>> two bitfields >> >> Right, thanks. >> >>> >>>> + - bits 0-15 - The unique MSM chipset ID >>>> + - bits 16-31 - Reserved; should be 0 >>>> + - description: | >>>> + Hardware revision ID - a chipset specific 32-bit ID representing >>>> + the version of the chipset. It is best a match value - the >>>> + bootloader will look for the closest possible match. >>>> + deprecated: true >>>> + description: >>>> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It >>>> + can optionally be an array of these to indicate multiple hardware that >>>> + use the same device tree. It is expected that the bootloader will use >>>> + this information at boot-up to decide which device tree to use when given >>>> + multiple device trees, some of which may not be compatible with the >>>> + actual hardware. It is the bootloader's responsibility to pass the >>>> + correct device tree to the kernel. >>>> + The property is deprecated - it is not expected on newer boards >>>> + (starting with SM8350). >>> >>> Could you please elaborate this? >> >> Second paragraph: >> https://lore.kernel.org/all/20220522195138.35943-1-konrad.dybcio@somainline.org/ > > I think this is something peculiar to Sony. Public lahaina (sm8350) > dts files contain both these properties: > > https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-hdk.dts > https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-v2.1.dtsi > >> >> Plus consensus with Rob: >> https://lore.kernel.org/all/CAL_JsqKL-mtAQ8Q9H4vLGM8izVVzDPbUAVWSdS8AmGjN6X6kcA@mail.gmail.com/ > > I'm not sure here. But sm8350 and sm8450 dtsi files use these > properties. I've linked lahaina files above. > The waiptio dtsi (sm8450) are present at the same URL. If you did not like where the consensus is going during the discussion last week, I would expect to join the discussion. Not to comment after I implement it. > >> >>> If the AOSP team were to add e.g. >>> SM8350-HDK to their single RB3+RB5 images, they would still need the >>> qcom,board-id/qcom,msm-id properties to let the bootloader choose proper >>> DTB. >> >> If you have any email addresses in mind, please Cc them to invite in >> discussions. Otherwise I am afraid it won't be allowed. The feedback I >> got before was that SM8350 and newer do not require this property. Feel >> free to propose other way to solve comments (see "consensus with Rob" >> above). > > Amit is in CC list. In the past he used these properties to allow > single-image booting of RB3 and RB5. > In fact I might prefer adding more of these properties to the dts > files, where it makes sense, to allow adding more dt files to the > images we create. > I'd really like to be able to boot a single image on all my boards > (rb3, rb5, db410c, db820, ifc6560, etc). You have several options here. Use the board-compatible-encoded-scheme, which was merged like 6 years ago or something. Bootloader could parse it, dtbTool as well. Add a generic property, like Rob wanted (and probably fix bootloader). Or find any other way to satisfy Rob's comments. These properties were not accepted 6 years ago and the board compatible approach was merged instead. If 6 years is not enough to change the bootloaders, nothing will happen here ever, so we need to make some statement. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-22 7:00 ` Krzysztof Kozlowski @ 2022-06-22 7:31 ` Dmitry Baryshkov 0 siblings, 0 replies; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-22 7:31 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 22/06/2022 10:00, Krzysztof Kozlowski wrote: > On 21/06/2022 21:49, Dmitry Baryshkov wrote: >> On Tue, 21 Jun 2022 at 22:32, Krzysztof Kozlowski >> <krzysztof.kozlowski@linaro.org> wrote: >>> >>> On 21/06/2022 21:26, Dmitry Baryshkov wrote: >>>> On 21/06/2022 21:56, Krzysztof Kozlowski wrote: >>>>> The top level qcom,msm-id and qcom,board-id properties are utilized by >>>>> bootloaders on Qualcomm MSM platforms to determine which device tree >>>>> should be used and passed to the kernel. >>>>> >>>>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >>>>> compatible format") from 2015 was a consensus during discussion about >>>>> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >>>>> problems with that consensus: >>>>> 1. It was reached 7 years ago but it turned out its implementation did >>>>> not reach all possible products. >>>>> >>>>> 2. Initially additional tool (dtbTool) was needed for parsing these >>>>> fields to create a QCDT image consisting of multiple DTBs, later the >>>>> bootloaders were improved and they use these qcom,msm-id and >>>>> qcom,board-id properties directly. >>>> >>>> I might be mistaken here. I think it was expected that dtbTool would use >>>> board compat strings to generate qcom,msm-id and qcom,board-id >>>> properties. It's not that the bootloaders were improved. >>> >>> Don't ask me, I am new to this. >>> >>> https://lore.kernel.org/all/02ab0276-b078-fe66-8596-fcec4378722b@somainline.org/ >> >> >> >> >>> >>>> >>>>> >>>>> 3. Extracting relevant information from the board compatible requires >>>>> this additional tool (dtbTool), which makes the build process more >>>>> complicated and not easily reproducible (DTBs are modified after the >>>>> kernel build). >>>>> >>>>> 4. Some versions of Qualcomm bootloaders expect these properties even >>>>> when booting with a single DTB. The community is stuck with these >>>>> bootloaders thus they require properties in the DTBs. >>>>> >>>>> Since several upstreamed Qualcomm SoC-based boards require these >>>>> properties to properly boot and the properties are reportedly used by >>>>> bootloaders, document them. >>>>> >>>>> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ >>>>> Co-developed-by: Kumar Gala <galak@codeaurora.org> >>>>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>>>> --- >>>>> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ >>>>> include/dt-bindings/arm/qcom,ids.h | 30 +++++ >>>>> 2 files changed, 153 insertions(+) >>>>> create mode 100644 include/dt-bindings/arm/qcom,ids.h >>>>> >>>>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >>>>> index 6c38c1387afd..05b98cde4653 100644 >>>>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >>>>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >>>>> @@ -403,6 +403,129 @@ properties: >>>>> - qcom,sm8450-qrd >>>>> - const: qcom,sm8450 >>>>> >>>>> + # Board compatibles go above >>>>> + >>>>> + qcom,msm-id: >>>>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >>>>> + minItems: 1 >>>>> + maxItems: 8 >>>>> + items: >>>>> + items: >>>>> + - description: | >>>>> + MSM chipset ID - an exact match value consisting of three bitfields:: >>>> >>>> two bitfields >>> >>> Right, thanks. >>> >>>> >>>>> + - bits 0-15 - The unique MSM chipset ID >>>>> + - bits 16-31 - Reserved; should be 0 >>>>> + - description: | >>>>> + Hardware revision ID - a chipset specific 32-bit ID representing >>>>> + the version of the chipset. It is best a match value - the >>>>> + bootloader will look for the closest possible match. >>>>> + deprecated: true >>>>> + description: >>>>> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It >>>>> + can optionally be an array of these to indicate multiple hardware that >>>>> + use the same device tree. It is expected that the bootloader will use >>>>> + this information at boot-up to decide which device tree to use when given >>>>> + multiple device trees, some of which may not be compatible with the >>>>> + actual hardware. It is the bootloader's responsibility to pass the >>>>> + correct device tree to the kernel. >>>>> + The property is deprecated - it is not expected on newer boards >>>>> + (starting with SM8350). >>>> >>>> Could you please elaborate this? >>> >>> Second paragraph: >>> https://lore.kernel.org/all/20220522195138.35943-1-konrad.dybcio@somainline.org/ >> >> I think this is something peculiar to Sony. Public lahaina (sm8350) >> dts files contain both these properties: >> >> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-hdk.dts >> https://github.com/MiCode/kernel_devicetree/blob/zeus-s-oss/qcom/lahaina-v2.1.dtsi >> >>> >>> Plus consensus with Rob: >>> https://lore.kernel.org/all/CAL_JsqKL-mtAQ8Q9H4vLGM8izVVzDPbUAVWSdS8AmGjN6X6kcA@mail.gmail.com/ >> >> I'm not sure here. But sm8350 and sm8450 dtsi files use these >> properties. I've linked lahaina files above. >> The waiptio dtsi (sm8450) are present at the same URL. > > If you did not like where the consensus is going during the discussion > last week, I would expect to join the discussion. Not to comment after I > implement it. Please excuse me. I probably missed that part of the discussion. Yes, it was my fault. >>>> If the AOSP team were to add e.g. >>>> SM8350-HDK to their single RB3+RB5 images, they would still need the >>>> qcom,board-id/qcom,msm-id properties to let the bootloader choose proper >>>> DTB. >>> >>> If you have any email addresses in mind, please Cc them to invite in >>> discussions. Otherwise I am afraid it won't be allowed. The feedback I >>> got before was that SM8350 and newer do not require this property. Feel >>> free to propose other way to solve comments (see "consensus with Rob" >>> above). >> >> Amit is in CC list. In the past he used these properties to allow >> single-image booting of RB3 and RB5. >> In fact I might prefer adding more of these properties to the dts >> files, where it makes sense, to allow adding more dt files to the >> images we create. >> I'd really like to be able to boot a single image on all my boards >> (rb3, rb5, db410c, db820, ifc6560, etc). > > You have several options here. Use the board-compatible-encoded-scheme, > which was merged like 6 years ago or something. Bootloader could parse > it, dtbTool as well. Add a generic property, like Rob wanted (and > probably fix bootloader). Or find any other way to satisfy Rob's > comments. These properties were not accepted 6 years ago and the board > compatible approach was merged instead. If 6 years is not enough to > change the bootloaders, nothing will happen here ever, so we need to > make some statement. Let me respond to his email. Amit, you might have something to add there too. Basically I think we should allow these properties to be used for all the Qcom boards. Marking them as 'deprecated' is fine to me, thus we would not endorse them. But we would still be able to use them when needed/wanted (like AOSP requirements for the single boot image). -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-21 18:56 ` [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Krzysztof Kozlowski 2022-06-21 19:26 ` Dmitry Baryshkov @ 2022-06-22 9:44 ` Dmitry Baryshkov 2022-06-22 9:49 ` Krzysztof Kozlowski 1 sibling, 1 reply; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-22 9:44 UTC (permalink / raw) To: Krzysztof Kozlowski, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 21/06/2022 21:56, Krzysztof Kozlowski wrote: > The top level qcom,msm-id and qcom,board-id properties are utilized by > bootloaders on Qualcomm MSM platforms to determine which device tree > should be used and passed to the kernel. > > The commit b32e592d3c28 ("devicetree: bindings: Document qcom board > compatible format") from 2015 was a consensus during discussion about > upstreaming qcom,msm-id and qcom,board-id fields. There are however still > problems with that consensus: > 1. It was reached 7 years ago but it turned out its implementation did > not reach all possible products. > > 2. Initially additional tool (dtbTool) was needed for parsing these > fields to create a QCDT image consisting of multiple DTBs, later the > bootloaders were improved and they use these qcom,msm-id and > qcom,board-id properties directly. > > 3. Extracting relevant information from the board compatible requires > this additional tool (dtbTool), which makes the build process more > complicated and not easily reproducible (DTBs are modified after the > kernel build). > > 4. Some versions of Qualcomm bootloaders expect these properties even > when booting with a single DTB. The community is stuck with these > bootloaders thus they require properties in the DTBs. > > Since several upstreamed Qualcomm SoC-based boards require these > properties to properly boot and the properties are reportedly used by > bootloaders, document them. > > Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ > Co-developed-by: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Kumar Gala <galak@codeaurora.org> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> > --- > .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ > include/dt-bindings/arm/qcom,ids.h | 30 +++++ > 2 files changed, 153 insertions(+) > create mode 100644 include/dt-bindings/arm/qcom,ids.h > > diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml > index 6c38c1387afd..05b98cde4653 100644 > --- a/Documentation/devicetree/bindings/arm/qcom.yaml > +++ b/Documentation/devicetree/bindings/arm/qcom.yaml > @@ -403,6 +403,129 @@ properties: > - qcom,sm8450-qrd > - const: qcom,sm8450 > > + # Board compatibles go above > + > + qcom,msm-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + minItems: 1 > + maxItems: 8 > + items: > + items: > + - description: | > + MSM chipset ID - an exact match value consisting of three bitfields:: > + - bits 0-15 - The unique MSM chipset ID > + - bits 16-31 - Reserved; should be 0 > + - description: | > + Hardware revision ID - a chipset specific 32-bit ID representing > + the version of the chipset. It is best a match value - the > + bootloader will look for the closest possible match. > + deprecated: true > + description: > + The MSM chipset and hardware revision use by Qualcomm bootloaders. It > + can optionally be an array of these to indicate multiple hardware that > + use the same device tree. It is expected that the bootloader will use > + this information at boot-up to decide which device tree to use when given > + multiple device trees, some of which may not be compatible with the > + actual hardware. It is the bootloader's responsibility to pass the > + correct device tree to the kernel. > + The property is deprecated - it is not expected on newer boards > + (starting with SM8350). I have been thinking about this for quite a while. I think this patch is good. With this paragraph (and the corresponding paragraph from the next item) rephrased to remove references to 'newer boards': Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > + > + qcom,board-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + minItems: 1 > + maxItems: 8 > + items: > + oneOf: > + - maxItems: 2 > + items: > + - description: | > + Board ID consisting of three bitfields:: > + - bits 31-24 - Unused > + - bits 23-16 - Platform Version Major > + - bits 15-8 - Platform Version Minor > + - bits 7-0 - Platform Type > + Platform Type field is an exact match value. The > + Platform Major/Minor field is a best match. The bootloader will > + look for the closest possible match. > + - description: | > + Subtype ID unique to a Platform Type/Chipset ID. For a given > + Platform Type, there will typically only be a single board and the > + subtype_id will be 0. However in some cases board variants may > + need to be distinguished by different subtype_id values. > + # OnePlus uses a variant of board-id with four elements: > + - minItems: 4 > + items: > + - const: 8 > + - const: 0 > + - description: OnePlus board ID > + - description: OnePlus subtype ID > + deprecated: true > + description: > + The board type and revision information. It can optionally be an array > + of these to indicate multiple boards that use the same device tree. It > + is expected that the bootloader will use this information at boot-up to > + decide which device tree to use when given multiple device trees, some of > + which may not be compatible with the actual hardware. It is the > + bootloader's responsibility to pass the correct device tree to the > + kernel > + The property is deprecated - it is not expected on newer boards > + (starting with SM8350). > + > +allOf: > + # Explicit allow-list for older SoCs. The legacy properties are not allowed > + # on newer SoCs. > + - if: > + properties: > + compatible: > + contains: > + enum: > + - qcom,apq8026 > + - qcom,apq8094 > + - qcom,apq8096 > + - qcom,msm8992 > + - qcom,msm8994 > + - qcom,msm8996 > + - qcom,msm8998 > + - qcom,sdm630 > + - qcom,sdm632 > + - qcom,sdm845 > + - qcom,sdx55 > + - qcom,sdx65 > + - qcom,sm6125 > + - qcom,sm6350 > + - qcom,sm7225 > + - qcom,sm8150 > + - qcom,sm8250 > + then: > + properties: > + qcom,board-id: true > + qcom,msm-id: true > + else: > + properties: > + qcom,board-id: false > + qcom,msm-id: false > + > + - if: > + properties: > + compatible: > + contains: > + enum: > + - oneplus,cheeseburger > + - oneplus,dumpling > + - oneplus,enchilada > + - oneplus,fajita > + then: > + properties: > + qcom,board-id: > + items: > + minItems: 4 > + else: > + properties: > + qcom,board-id: > + items: > + maxItems: 2 > + > additionalProperties: true > > ... > diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h > new file mode 100644 > index 000000000000..eaf86c18650f > --- /dev/null > +++ b/include/dt-bindings/arm/qcom,ids.h > @@ -0,0 +1,30 @@ > +/* SPDX-License-Identifier: GPL-2.0-only */ > +/* > + * Copyright (c) 2015, The Linux Foundation. All rights reserved. > + * Copyright (c) 2022 Linaro Ltd > + * Author: Krzysztof Kozlowski <krzk@kernel.org> based on previous work of Kumar Gala. > + */ > +#ifndef _DT_BINDINGS_ARM_QCOM_IDS_H > +#define _DT_BINDINGS_ARM_QCOM_IDS_H > + > +/* qcom,msm-id */ > +#define QCOM_ID_APQ8026 199 > +#define QCOM_ID_MSM8916 206 > +#define QCOM_ID_MSM8994 207 > +#define QCOM_ID_MSM8996_3_0 246 > +#define QCOM_ID_APQ8016 247 > +#define QCOM_ID_MSM8216 248 > +#define QCOM_ID_MSM8116 249 > +#define QCOM_ID_MSM8616 250 > +#define QCOM_ID_MSM8998 292 > +#define QCOM_ID_SDM845 321 > + > +/* qcom,board-id */ > +#define QCOM_BOARD_ID(a, major, minor) \ > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) > + > +#define QCOM_BOARD_ID_MTP 8 > +#define QCOM_BOARD_ID_DRAGONBOARD 10 > +#define QCOM_BOARD_ID_SBC 24 > + > +#endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-22 9:44 ` Dmitry Baryshkov @ 2022-06-22 9:49 ` Krzysztof Kozlowski 2022-06-22 9:50 ` Dmitry Baryshkov 0 siblings, 1 reply; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-22 9:49 UTC (permalink / raw) To: Dmitry Baryshkov, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 22/06/2022 11:44, Dmitry Baryshkov wrote: > On 21/06/2022 21:56, Krzysztof Kozlowski wrote: >> The top level qcom,msm-id and qcom,board-id properties are utilized by >> bootloaders on Qualcomm MSM platforms to determine which device tree >> should be used and passed to the kernel. >> >> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >> compatible format") from 2015 was a consensus during discussion about >> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >> problems with that consensus: >> 1. It was reached 7 years ago but it turned out its implementation did >> not reach all possible products. >> >> 2. Initially additional tool (dtbTool) was needed for parsing these >> fields to create a QCDT image consisting of multiple DTBs, later the >> bootloaders were improved and they use these qcom,msm-id and >> qcom,board-id properties directly. >> >> 3. Extracting relevant information from the board compatible requires >> this additional tool (dtbTool), which makes the build process more >> complicated and not easily reproducible (DTBs are modified after the >> kernel build). >> >> 4. Some versions of Qualcomm bootloaders expect these properties even >> when booting with a single DTB. The community is stuck with these >> bootloaders thus they require properties in the DTBs. >> >> Since several upstreamed Qualcomm SoC-based boards require these >> properties to properly boot and the properties are reportedly used by >> bootloaders, document them. >> >> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ >> Co-developed-by: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Kumar Gala <galak@codeaurora.org> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >> --- >> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ >> include/dt-bindings/arm/qcom,ids.h | 30 +++++ >> 2 files changed, 153 insertions(+) >> create mode 100644 include/dt-bindings/arm/qcom,ids.h >> >> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >> index 6c38c1387afd..05b98cde4653 100644 >> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >> @@ -403,6 +403,129 @@ properties: >> - qcom,sm8450-qrd >> - const: qcom,sm8450 >> >> + # Board compatibles go above >> + >> + qcom,msm-id: >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >> + minItems: 1 >> + maxItems: 8 >> + items: >> + items: >> + - description: | >> + MSM chipset ID - an exact match value consisting of three bitfields:: >> + - bits 0-15 - The unique MSM chipset ID >> + - bits 16-31 - Reserved; should be 0 >> + - description: | >> + Hardware revision ID - a chipset specific 32-bit ID representing >> + the version of the chipset. It is best a match value - the >> + bootloader will look for the closest possible match. >> + deprecated: true >> + description: >> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It >> + can optionally be an array of these to indicate multiple hardware that >> + use the same device tree. It is expected that the bootloader will use >> + this information at boot-up to decide which device tree to use when given >> + multiple device trees, some of which may not be compatible with the >> + actual hardware. It is the bootloader's responsibility to pass the >> + correct device tree to the kernel. >> + The property is deprecated - it is not expected on newer boards >> + (starting with SM8350). > > I have been thinking about this for quite a while. I think this patch is > good. > > With this paragraph (and the corresponding paragraph from the next item) > rephrased to remove references to 'newer boards': > > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Great, thanks! And thank you for responding in previous discussions. I'll remove entire "newer boards ..." part, fix the "two bitfields" and change the name of the define QCOM_ID_MSM8996. I won't add more board IDs yet, this can be in following up patches (not only my me). Best regards, Krzysztof ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id 2022-06-22 9:49 ` Krzysztof Kozlowski @ 2022-06-22 9:50 ` Dmitry Baryshkov 0 siblings, 0 replies; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-22 9:50 UTC (permalink / raw) To: Krzysztof Kozlowski, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Stephen Boyd On 22/06/2022 12:49, Krzysztof Kozlowski wrote: > On 22/06/2022 11:44, Dmitry Baryshkov wrote: >> On 21/06/2022 21:56, Krzysztof Kozlowski wrote: >>> The top level qcom,msm-id and qcom,board-id properties are utilized by >>> bootloaders on Qualcomm MSM platforms to determine which device tree >>> should be used and passed to the kernel. >>> >>> The commit b32e592d3c28 ("devicetree: bindings: Document qcom board >>> compatible format") from 2015 was a consensus during discussion about >>> upstreaming qcom,msm-id and qcom,board-id fields. There are however still >>> problems with that consensus: >>> 1. It was reached 7 years ago but it turned out its implementation did >>> not reach all possible products. >>> >>> 2. Initially additional tool (dtbTool) was needed for parsing these >>> fields to create a QCDT image consisting of multiple DTBs, later the >>> bootloaders were improved and they use these qcom,msm-id and >>> qcom,board-id properties directly. >>> >>> 3. Extracting relevant information from the board compatible requires >>> this additional tool (dtbTool), which makes the build process more >>> complicated and not easily reproducible (DTBs are modified after the >>> kernel build). >>> >>> 4. Some versions of Qualcomm bootloaders expect these properties even >>> when booting with a single DTB. The community is stuck with these >>> bootloaders thus they require properties in the DTBs. >>> >>> Since several upstreamed Qualcomm SoC-based boards require these >>> properties to properly boot and the properties are reportedly used by >>> bootloaders, document them. >>> >>> Link: https://lore.kernel.org/r/a3c932d1-a102-ce18-deea-18cbbd05ecab@linaro.org/ >>> Co-developed-by: Kumar Gala <galak@codeaurora.org> >>> Signed-off-by: Kumar Gala <galak@codeaurora.org> >>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> >>> --- >>> .../devicetree/bindings/arm/qcom.yaml | 123 ++++++++++++++++++ >>> include/dt-bindings/arm/qcom,ids.h | 30 +++++ >>> 2 files changed, 153 insertions(+) >>> create mode 100644 include/dt-bindings/arm/qcom,ids.h >>> >>> diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml >>> index 6c38c1387afd..05b98cde4653 100644 >>> --- a/Documentation/devicetree/bindings/arm/qcom.yaml >>> +++ b/Documentation/devicetree/bindings/arm/qcom.yaml >>> @@ -403,6 +403,129 @@ properties: >>> - qcom,sm8450-qrd >>> - const: qcom,sm8450 >>> >>> + # Board compatibles go above >>> + >>> + qcom,msm-id: >>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >>> + minItems: 1 >>> + maxItems: 8 >>> + items: >>> + items: >>> + - description: | >>> + MSM chipset ID - an exact match value consisting of three bitfields:: >>> + - bits 0-15 - The unique MSM chipset ID >>> + - bits 16-31 - Reserved; should be 0 >>> + - description: | >>> + Hardware revision ID - a chipset specific 32-bit ID representing >>> + the version of the chipset. It is best a match value - the >>> + bootloader will look for the closest possible match. >>> + deprecated: true >>> + description: >>> + The MSM chipset and hardware revision use by Qualcomm bootloaders. It >>> + can optionally be an array of these to indicate multiple hardware that >>> + use the same device tree. It is expected that the bootloader will use >>> + this information at boot-up to decide which device tree to use when given >>> + multiple device trees, some of which may not be compatible with the >>> + actual hardware. It is the bootloader's responsibility to pass the >>> + correct device tree to the kernel. >>> + The property is deprecated - it is not expected on newer boards >>> + (starting with SM8350). >> >> I have been thinking about this for quite a while. I think this patch is >> good. >> >> With this paragraph (and the corresponding paragraph from the next item) >> rephrased to remove references to 'newer boards': >> >> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > > Great, thanks! And thank you for responding in previous discussions. > > I'll remove entire "newer boards ..." part, fix the "two bitfields" and > change the name of the define QCOM_ID_MSM8996. I won't add more board > IDs yet, this can be in following up patches (not only my me). This sounds perfect to me. Thanks a lot for your work on sorting this out! -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples 2022-06-21 18:56 [PATCH v2 0/2] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id Krzysztof Kozlowski 2022-06-21 18:56 ` [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Krzysztof Kozlowski @ 2022-06-21 18:56 ` Krzysztof Kozlowski 2022-06-21 19:26 ` Dmitry Baryshkov 1 sibling, 1 reply; 12+ messages in thread From: Krzysztof Kozlowski @ 2022-06-21 18:56 UTC (permalink / raw) To: Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd, Krzysztof Kozlowski The qcom,msm-id is an uint32 matrix, so a list of tuples. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> --- arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts index 7748b745a5df..15467b697e94 100644 --- a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts +++ b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts @@ -17,7 +17,7 @@ / { chassis-type = "handset"; /* required for bootloader to select correct board */ - qcom,msm-id = <251 0 252 0>; + qcom,msm-id = <251 0>, <252 0>; qcom,pmic-id = <65545 65546 0 0>; qcom,board-id = <12 0>; -- 2.34.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples 2022-06-21 18:56 ` [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples Krzysztof Kozlowski @ 2022-06-21 19:26 ` Dmitry Baryshkov 0 siblings, 0 replies; 12+ messages in thread From: Dmitry Baryshkov @ 2022-06-21 19:26 UTC (permalink / raw) To: Krzysztof Kozlowski, Andy Gross, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel Cc: Konrad Dybcio, Amit Pundir, Trilok Soni, Rob Clark, Stephan Gerhold, Kumar Gala, Stephen Boyd On 21/06/2022 21:56, Krzysztof Kozlowski wrote: > The qcom,msm-id is an uint32 matrix, so a list of tuples. > > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> > --- > arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts > index 7748b745a5df..15467b697e94 100644 > --- a/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts > +++ b/arch/arm64/boot/dts/qcom/msm8992-xiaomi-libra.dts > @@ -17,7 +17,7 @@ / { > chassis-type = "handset"; > > /* required for bootloader to select correct board */ > - qcom,msm-id = <251 0 252 0>; > + qcom,msm-id = <251 0>, <252 0>; > qcom,pmic-id = <65545 65546 0 0>; > qcom,board-id = <12 0>; > -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2022-06-22 9:52 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2022-06-21 18:56 [PATCH v2 0/2] dt-bindings: arm: qcom: qcom,board-id and qcom,msm-id Krzysztof Kozlowski 2022-06-21 18:56 ` [PATCH v2 1/2] dt-bindings: arm: qcom: document qcom,msm-id and qcom,board-id Krzysztof Kozlowski 2022-06-21 19:26 ` Dmitry Baryshkov 2022-06-21 19:32 ` Krzysztof Kozlowski 2022-06-21 19:49 ` Dmitry Baryshkov 2022-06-22 7:00 ` Krzysztof Kozlowski 2022-06-22 7:31 ` Dmitry Baryshkov 2022-06-22 9:44 ` Dmitry Baryshkov 2022-06-22 9:49 ` Krzysztof Kozlowski 2022-06-22 9:50 ` Dmitry Baryshkov 2022-06-21 18:56 ` [PATCH v2 2/2] arm64: dts: qcom: msm8992-xiaomi-libra: split qcom,msm-id into tuples Krzysztof Kozlowski 2022-06-21 19:26 ` Dmitry Baryshkov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).