* [PATCH 0/2] Add board-id support for multiple DT selection @ 2024-01-20 11:20 Amrit Anand 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand ` (3 more replies) 0 siblings, 4 replies; 29+ messages in thread From: Amrit Anand @ 2024-01-20 11:20 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Amrit Anand Device manufacturers frequently ship multiple boards or SKUs under a single software package. These software packages will ship multiple devicetree blobs and require some mechanism to pick the correct DTB for the board the software package was deployed. Introduce a common definition for adding board identifiers to device trees. board-id provides a mechanism for bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. Isn't that what the compatible property is for? ----------------------------------------------- The compatible property can be used for board matching, but requires bootloaders and/or firmware to maintain a database of possible strings to match against or have complex compatible string matching. Compatible string matching becomes complicated when there are multiple versions of board: the device tree selector should recognize a DTB that cares to distinguish between v1/v2 and a DTB that doesn't make the distinction. An eeprom either needs to store the compatible strings that could match against the board or the bootloader needs to have vendor-specific decoding logic for the compatible string. Neither increasing eeprom storage nor adding vendor-specific decoding logic is desirable. The solution proposed here is simpler to implement and doesn't require updating firmware or bootloader for every new board. How is this better than Qualcomm's qcom,msm-id/qcom,board-id? ------------------------------------------------------------- The selection process for devicetrees was Qualcomm-specific and not useful for other devices and bootloaders that were not developed by Qualcomm because a complex algorithm was used to implement. Board-ids provide a matching solution that can be implemented by bootloaders without introducing vendor-specific code. Qualcomm uses three devicetree properties: msm-id (interchangeably: soc-id), board-id, and pmic-id. This does not scale well for use casese which use identifiers, for example, to distinguish between a display panel. For a display panel, an approach could be to add a new property: display-id, but now bootloaders need to be updated to also read this property. We want to avoid requiring to update bootloaders with new hardware identifiers: a bootloader need only recognize the identifiers it can handle. Amrit Anand (1): dt-bindings: hwinfo: Add Qualcomm's board-id types Elliot Berman (1): dt-bindings: hwinfo: Introduce board-id .../devicetree/bindings/hwinfo/board-id.yaml | 53 +++++++++++++ .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- 3 files changed, 199 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml -- 2.7.4 ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand @ 2024-01-20 11:20 ` Amrit Anand 2024-01-20 12:36 ` Rob Herring ` (3 more replies) 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand ` (2 subsequent siblings) 3 siblings, 4 replies; 29+ messages in thread From: Amrit Anand @ 2024-01-20 11:20 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman, Amrit Anand From: Elliot Berman <quic_eberman@quicinc.com> Device manufacturers frequently ship multiple boards or SKUs under a single software package. These software packages will ship multiple devicetree blobs and require some mechanism to pick the correct DTB for the board the software package was deployed. Introduce a common definition for adding board identifiers to device trees. board-id provides a mechanism for bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. Isn't that what the compatible property is for? ----------------------------------------------- The compatible property can be used for board matching, but requires bootloaders and/or firmware to maintain a database of possible strings to match against or have complex compatible string matching. Compatible string matching becomes complicated when there are multiple versions of board: the device tree selector should recognize a DTB that cares to distinguish between v1/v2 and a DTB that doesn't make the distinction. An eeprom either needs to store the compatible strings that could match against the board or the bootloader needs to have vendor-specific decoding logic for the compatible string. Neither increasing eeprom storage nor adding vendor-specific decoding logic is desirable. The solution proposed here is simpler to implement and doesn't require updating firmware or bootloader for every new board. How is this better than Qualcomm's qcom,msm-id/qcom,board-id? ------------------------------------------------------------- The selection process for devicetrees was Qualcomm-specific and not useful for other devices and bootloaders that were not developed by Qualcomm because a complex algorithm was used to implement. Board-ids provide a matching solution that can be implemented by bootloaders without introducing vendor-specific code. Qualcomm uses three devicetree properties: msm-id (interchangeably: soc-id), board-id, and pmic-id. This does not scale well for use casese which use identifiers, for example, to distinguish between a display panel. For a display panel, an approach could be to add a new property: display-id, but now bootloaders need to be updated to also read this property. We want to avoid requiring to update bootloaders with new hardware identifiers: a bootloader need only recognize the identifiers it can handle. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> --- .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ 1 file changed, 53 insertions(+) create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml diff --git a/Documentation/devicetree/bindings/hwinfo/board-id.yaml b/Documentation/devicetree/bindings/hwinfo/board-id.yaml new file mode 100644 index 0000000..82d5ff7 --- /dev/null +++ b/Documentation/devicetree/bindings/hwinfo/board-id.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwinfo/board-id.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Board Identifier for Devicetree Selection + +maintainers: + - Amrit Anand <quic_amrianan@quicinc.com> + - Elliot Berman <quic_eberman@quicinc.com> + +description: | + Device manufacturers frequently ship multiple boards under a single + software package. These software packages will ship multiple devicetree + blobs and require some mechanism to pick the correct DTB for the board + the software package was deployed. board-id provides a mechanism for + bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. + +select: + anyOf: + - required: + - 'board-id' + - required: + - 'board-id-types' + - required: + - '#board-id-cells' + +properties: + $nodename: + const: "/" + board-id: + $ref: /schemas/types.yaml#/definitions/uint32-matrix + description: | + A list of identifiers that can be used to match with this devicetree. + The interpretatation of each cell can be matched with the + board-id-type at the same index. + + board-id-types: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + Defines the type of each cell, indicating to the DeviceTree selection + mechanism how to parse the board-id. + + '#board-id-cells': + minimum: 1 + +required: + - board-id + - board-id-types + - '#board-id-cells' + +additionalProperties: true -- 2.7.4 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand @ 2024-01-20 12:36 ` Rob Herring 2024-01-20 19:10 ` Trilok Soni ` (2 subsequent siblings) 3 siblings, 0 replies; 29+ messages in thread From: Rob Herring @ 2024-01-20 12:36 UTC (permalink / raw) To: Amrit Anand Cc: linux-arm-msm, conor+dt, robh+dt, andersson, linux-kernel, agross, krzysztof.kozlowski+dt, devicetree, kernel, konrad.dybcio, Elliot Berman On Sat, 20 Jan 2024 16:50:48 +0530, Amrit Anand wrote: > From: Elliot Berman <quic_eberman@quicinc.com> > > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. > > Isn't that what the compatible property is for? > ----------------------------------------------- > The compatible property can be used for board matching, but requires > bootloaders and/or firmware to maintain a database of possible strings > to match against or have complex compatible string matching. Compatible > string matching becomes complicated when there are multiple versions of > board: the device tree selector should recognize a DTB that cares to > distinguish between v1/v2 and a DTB that doesn't make the distinction. > An eeprom either needs to store the compatible strings that could match > against the board or the bootloader needs to have vendor-specific > decoding logic for the compatible string. Neither increasing eeprom > storage nor adding vendor-specific decoding logic is desirable. > > The solution proposed here is simpler to implement and doesn't require > updating firmware or bootloader for every new board. > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, > but now bootloaders need to be updated to also read this property. We > want to avoid requiring to update bootloaders with new hardware > identifiers: a bootloader need only recognize the identifiers it can > handle. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/hwinfo/board-id.yaml:23:11: [error] string value is redundantly quoted with any quotes (quoted-strings) ./Documentation/devicetree/bindings/hwinfo/board-id.yaml:25:11: [error] string value is redundantly quoted with any quotes (quoted-strings) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1705749649-4708-2-git-send-email-quic_amrianan@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand 2024-01-20 12:36 ` Rob Herring @ 2024-01-20 19:10 ` Trilok Soni 2024-01-22 10:10 ` Amrit Anand 2024-01-23 12:09 ` Krzysztof Kozlowski 2024-01-24 15:00 ` Rob Herring 3 siblings, 1 reply; 29+ messages in thread From: Trilok Soni @ 2024-01-20 19:10 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 1/20/2024 3:20 AM, Amrit Anand wrote: > From: Elliot Berman <quic_eberman@quicinc.com> > > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since the proposal below is not specific to ARM but any architecture is using the devicetree. -- ---Trilok Soni ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 19:10 ` Trilok Soni @ 2024-01-22 10:10 ` Amrit Anand 2024-01-23 11:50 ` Krzysztof Kozlowski 0 siblings, 1 reply; 29+ messages in thread From: Amrit Anand @ 2024-01-22 10:10 UTC (permalink / raw) To: Trilok Soni, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 1/21/2024 12:40 AM, Trilok Soni wrote: > On 1/20/2024 3:20 AM, Amrit Anand wrote: >> From: Elliot Berman <quic_eberman@quicinc.com> >> >> Device manufacturers frequently ship multiple boards or SKUs under a >> single software package. These software packages will ship multiple >> devicetree blobs and require some mechanism to pick the correct DTB for >> the board the software package was deployed. Introduce a common >> definition for adding board identifiers to device trees. board-id >> provides a mechanism for bootloaders to select the appropriate DTB which >> is vendor/OEM-agnostic. > Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since > the proposal below is not specific to ARM but any architecture is using the > devicetree. Wouldn't devicetree@vger.kernel.org will have concern folks from all the architectures? Please correct me. Thanks, Amrit. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-22 10:10 ` Amrit Anand @ 2024-01-23 11:50 ` Krzysztof Kozlowski 2024-01-23 17:18 ` Conor Dooley 0 siblings, 1 reply; 29+ messages in thread From: Krzysztof Kozlowski @ 2024-01-23 11:50 UTC (permalink / raw) To: Amrit Anand, Trilok Soni, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 22/01/2024 11:10, Amrit Anand wrote: > > On 1/21/2024 12:40 AM, Trilok Soni wrote: >> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>> From: Elliot Berman <quic_eberman@quicinc.com> >>> >>> Device manufacturers frequently ship multiple boards or SKUs under a >>> single software package. These software packages will ship multiple >>> devicetree blobs and require some mechanism to pick the correct DTB for >>> the board the software package was deployed. Introduce a common >>> definition for adding board identifiers to device trees. board-id >>> provides a mechanism for bootloaders to select the appropriate DTB which >>> is vendor/OEM-agnostic. >> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >> the proposal below is not specific to ARM but any architecture is using the >> devicetree. > Wouldn't devicetree@vger.kernel.org will have concern folks from all the > architectures? > Please correct me. No. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-23 11:50 ` Krzysztof Kozlowski @ 2024-01-23 17:18 ` Conor Dooley 2024-01-23 18:51 ` Elliot Berman 0 siblings, 1 reply; 29+ messages in thread From: Conor Dooley @ 2024-01-23 17:18 UTC (permalink / raw) To: Krzysztof Kozlowski Cc: Amrit Anand, Trilok Soni, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman [-- Attachment #1: Type: text/plain, Size: 1363 bytes --] On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: > On 22/01/2024 11:10, Amrit Anand wrote: > > > > On 1/21/2024 12:40 AM, Trilok Soni wrote: > >> On 1/20/2024 3:20 AM, Amrit Anand wrote: > >>> From: Elliot Berman <quic_eberman@quicinc.com> > >>> > >>> Device manufacturers frequently ship multiple boards or SKUs under a > >>> single software package. These software packages will ship multiple > >>> devicetree blobs and require some mechanism to pick the correct DTB for > >>> the board the software package was deployed. Introduce a common > >>> definition for adding board identifiers to device trees. board-id > >>> provides a mechanism for bootloaders to select the appropriate DTB which > >>> is vendor/OEM-agnostic. > >> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since > >> the proposal below is not specific to ARM but any architecture is using the > >> devicetree. > > Wouldn't devicetree@vger.kernel.org will have concern folks from all the > > architectures? > > Please correct me. > > No. The chromium guys should get a CC on future versions of this stuff, since they like doing wacky things with compatible strings in their bootloader and this problem is one they also face. Doug Anderson and the mediatek chromebook folks would be a good start. Thanks, Conor. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-23 17:18 ` Conor Dooley @ 2024-01-23 18:51 ` Elliot Berman 2024-01-23 20:05 ` Trilok Soni 0 siblings, 1 reply; 29+ messages in thread From: Elliot Berman @ 2024-01-23 18:51 UTC (permalink / raw) To: Amrit Anand Cc: Trilok Soni, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel, Conor Dooley, andersson, Krzysztof Kozlowski On 1/23/2024 9:18 AM, Conor Dooley wrote: > On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >> On 22/01/2024 11:10, Amrit Anand wrote: >>> >>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>> >>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>> single software package. These software packages will ship multiple >>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>> the board the software package was deployed. Introduce a common >>>>> definition for adding board identifiers to device trees. board-id >>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>> is vendor/OEM-agnostic. >>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>> the proposal below is not specific to ARM but any architecture is using the >>>> devicetree. >>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>> architectures? >>> Please correct me. >> >> No. > > The chromium guys should get a CC on future versions of this stuff, > since they like doing wacky things with compatible strings in their > bootloader and this problem is one they also face. Doug Anderson and the > mediatek chromebook folks would be a good start. > Please CC Peter Griffin from Linaro as he helped restart this discussion at Plumbers. Peter Griffin <peter.griffin@linaro.org> Also, for the oneplus boards: Caleb Connolly <caleb.connolly@linaro.org> ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-23 18:51 ` Elliot Berman @ 2024-01-23 20:05 ` Trilok Soni 2024-01-24 12:44 ` Amrit Anand 0 siblings, 1 reply; 29+ messages in thread From: Trilok Soni @ 2024-01-23 20:05 UTC (permalink / raw) To: Elliot Berman, Amrit Anand Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel, Conor Dooley, andersson, Krzysztof Kozlowski On 1/23/2024 10:51 AM, Elliot Berman wrote: > > > On 1/23/2024 9:18 AM, Conor Dooley wrote: >> On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >>> On 22/01/2024 11:10, Amrit Anand wrote: >>>> >>>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>>> >>>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>>> single software package. These software packages will ship multiple >>>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>>> the board the software package was deployed. Introduce a common >>>>>> definition for adding board identifiers to device trees. board-id >>>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>>> is vendor/OEM-agnostic. >>>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>>> the proposal below is not specific to ARM but any architecture is using the >>>>> devicetree. >>>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>>> architectures? >>>> Please correct me. >>> >>> No. >> >> The chromium guys should get a CC on future versions of this stuff, >> since they like doing wacky things with compatible strings in their >> bootloader and this problem is one they also face. Doug Anderson and the >> mediatek chromebook folks would be a good start. >> > > Please CC Peter Griffin from Linaro as he helped restart this > discussion at Plumbers. > > Peter Griffin <peter.griffin@linaro.org> > > Also, for the oneplus boards: > Caleb Connolly <caleb.connolly@linaro.org> Thank you everyone. Amrit - please take care of above comments when you post next revision and as suggested please add other architecture mailing lists using the devicetree. Thank you. -- ---Trilok Soni ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-23 20:05 ` Trilok Soni @ 2024-01-24 12:44 ` Amrit Anand 0 siblings, 0 replies; 29+ messages in thread From: Amrit Anand @ 2024-01-24 12:44 UTC (permalink / raw) To: Trilok Soni, Elliot Berman Cc: robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel, Conor Dooley, andersson, Krzysztof Kozlowski On 1/24/2024 1:35 AM, Trilok Soni wrote: > On 1/23/2024 10:51 AM, Elliot Berman wrote: >> >> On 1/23/2024 9:18 AM, Conor Dooley wrote: >>> On Tue, Jan 23, 2024 at 12:50:07PM +0100, Krzysztof Kozlowski wrote: >>>> On 22/01/2024 11:10, Amrit Anand wrote: >>>>> On 1/21/2024 12:40 AM, Trilok Soni wrote: >>>>>> On 1/20/2024 3:20 AM, Amrit Anand wrote: >>>>>>> From: Elliot Berman <quic_eberman@quicinc.com> >>>>>>> >>>>>>> Device manufacturers frequently ship multiple boards or SKUs under a >>>>>>> single software package. These software packages will ship multiple >>>>>>> devicetree blobs and require some mechanism to pick the correct DTB for >>>>>>> the board the software package was deployed. Introduce a common >>>>>>> definition for adding board identifiers to device trees. board-id >>>>>>> provides a mechanism for bootloaders to select the appropriate DTB which >>>>>>> is vendor/OEM-agnostic. >>>>>> Please extend CC list to more architectures? linux-arm-kernel, risc-v etc; since >>>>>> the proposal below is not specific to ARM but any architecture is using the >>>>>> devicetree. >>>>> Wouldn't devicetree@vger.kernel.org will have concern folks from all the >>>>> architectures? >>>>> Please correct me. >>>> No. >>> The chromium guys should get a CC on future versions of this stuff, >>> since they like doing wacky things with compatible strings in their >>> bootloader and this problem is one they also face. Doug Anderson and the >>> mediatek chromebook folks would be a good start. >>> >> Please CC Peter Griffin from Linaro as he helped restart this >> discussion at Plumbers. >> >> Peter Griffin <peter.griffin@linaro.org> >> >> Also, for the oneplus boards: >> Caleb Connolly <caleb.connolly@linaro.org> > Thank you everyone. Amrit - please take care of above comments > when you post next revision and as suggested please add other > architecture mailing lists using the devicetree. Thank you. Sure, will keep this in mind when sending next version. Thanks for pointing out. Thanks, Amrit. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand 2024-01-20 12:36 ` Rob Herring 2024-01-20 19:10 ` Trilok Soni @ 2024-01-23 12:09 ` Krzysztof Kozlowski 2024-01-24 12:42 ` Amrit Anand 2024-01-24 15:00 ` Rob Herring 3 siblings, 1 reply; 29+ messages in thread From: Krzysztof Kozlowski @ 2024-01-23 12:09 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 20/01/2024 12:20, Amrit Anand wrote: > From: Elliot Berman <quic_eberman@quicinc.com> > > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, > but now bootloaders need to be updated to also read this property. We > want to avoid requiring to update bootloaders with new hardware Some mis-indentation in two lines above. > identifiers: a bootloader need only recognize the identifiers it can > handle. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml > > diff --git a/Documentation/devicetree/bindings/hwinfo/board-id.yaml b/Documentation/devicetree/bindings/hwinfo/board-id.yaml I think we should add it to dtschema, because bootloaders are using these. > new file mode 100644 > index 0000000..82d5ff7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwinfo/board-id.yaml > @@ -0,0 +1,53 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwinfo/board-id.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Board Identifier for Devicetree Selection > + > +maintainers: > + - Amrit Anand <quic_amrianan@quicinc.com> > + - Elliot Berman <quic_eberman@quicinc.com> > + > +description: | Do not need '|' unless you need to preserve formatting. > + Device manufacturers frequently ship multiple boards under a single > + software package. These software packages will ship multiple devicetree > + blobs and require some mechanism to pick the correct DTB for the board > + the software package was deployed. board-id provides a mechanism for > + bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. > + > +select: > + anyOf: > + - required: > + - 'board-id' > + - required: > + - 'board-id-types' > + - required: > + - '#board-id-cells' I don't fully get why do you need this select. Isn't the schema selected by nodename? Or maybe it is for the final required: but then this could be just set of dependencies. > + > +properties: > + $nodename: > + const: "/" Blank line. > + board-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + description: | Do not need '|' unless you need to preserve formatting. > + A list of identifiers that can be used to match with this devicetree. s/devicetree/Devicetree/ ? > + The interpretatation of each cell can be matched with the Typo: interpretation > + board-id-type at the same index. > + > + board-id-types: > + $ref: /schemas/types.yaml#/definitions/non-unique-string-array > + description: > + Defines the type of each cell, indicating to the DeviceTree selection s/DeviceTree/Devicetree/ ? > + mechanism how to parse the board-id. > + > + '#board-id-cells': What are the cells for? > + minimum: 1 > + > +required: > + - board-id > + - board-id-types > + - '#board-id-cells' > + > +additionalProperties: true Best regards, Krzysztof ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-23 12:09 ` Krzysztof Kozlowski @ 2024-01-24 12:42 ` Amrit Anand 2024-01-25 10:40 ` Krzysztof Kozlowski 0 siblings, 1 reply; 29+ messages in thread From: Amrit Anand @ 2024-01-24 12:42 UTC (permalink / raw) To: Krzysztof Kozlowski, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 1/23/2024 5:39 PM, Krzysztof Kozlowski wrote: > On 20/01/2024 12:20, Amrit Anand wrote: >> From: Elliot Berman <quic_eberman@quicinc.com> >> > > >> How is this better than Qualcomm's qcom,msm-id/qcom,board-id? >> ------------------------------------------------------------- >> The selection process for devicetrees was Qualcomm-specific and not >> useful for other devices and bootloaders that were not developed by >> Qualcomm because a complex algorithm was used to implement. Board-ids >> provide a matching solution that can be implemented by bootloaders >> without introducing vendor-specific code. Qualcomm uses three >> devicetree properties: msm-id (interchangeably: soc-id), board-id, and >> pmic-id. This does not scale well for use casese which use identifiers, >> for example, to distinguish between a display panel. For a display >> panel, an approach could be to add a new property: display-id, >> but now bootloaders need to be updated to also read this property. We >> want to avoid requiring to update bootloaders with new hardware > Some mis-indentation in two lines above. Sure will take care of this. > >> identifiers: a bootloader need only recognize the identifiers it can >> handle. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> >> --- >> .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ >> 1 file changed, 53 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml >> >> diff --git a/Documentation/devicetree/bindings/hwinfo/board-id.yaml b/Documentation/devicetree/bindings/hwinfo/board-id.yaml > I think we should add it to dtschema, because bootloaders are using these. Do you want us to move this file completely to the below mentioned repo and under which directory? https://github.com/devicetree-org/dt-schema > >> new file mode 100644 >> index 0000000..82d5ff7 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/hwinfo/board-id.yaml >> @@ -0,0 +1,53 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/hwinfo/board-id.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Board Identifier for Devicetree Selection >> + >> +maintainers: >> + - Amrit Anand <quic_amrianan@quicinc.com> >> + - Elliot Berman <quic_eberman@quicinc.com> >> + >> +description: | > Do not need '|' unless you need to preserve formatting. Will drop it. > >> + Device manufacturers frequently ship multiple boards under a single >> + software package. These software packages will ship multiple devicetree >> + blobs and require some mechanism to pick the correct DTB for the board >> + the software package was deployed. board-id provides a mechanism for >> + bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. >> + >> +select: >> + anyOf: >> + - required: >> + - 'board-id' >> + - required: >> + - 'board-id-types' >> + - required: >> + - '#board-id-cells' > I don't fully get why do you need this select. Isn't the schema selected > by nodename? Or maybe it is for the final required: but then this could > be just set of dependencies. The nodename here would be "/". So it will be applied to all the DTs, right? Here, we wanted this to apply only if the above mentioned properties are present. Do you suggest moving this to qcom,board-id.yaml and the required: as well. So that vendor specific yaml could be applied? >> + >> +properties: >> + $nodename: >> + const: "/" > Blank line. Will add it. >> + board-id: >> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >> + description: | > Do not need '|' unless you need to preserve formatting. Ack >> + A list of identifiers that can be used to match with this devicetree. > s/devicetree/Devicetree/ ? Will update >> + The interpretatation of each cell can be matched with the > Typo: interpretation Will update >> + board-id-type at the same index. >> + >> + board-id-types: >> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array >> + description: >> + Defines the type of each cell, indicating to the DeviceTree selection > s/DeviceTree/Devicetree/ ? Will update > >> + mechanism how to parse the board-id. >> + >> + '#board-id-cells': > What are the cells for? Bootloader will use this to check the number of entries in a tuple of board-id. Vendors can have different logic in bootloader to specify the number So wanted to make it flexible. Thanks, Amrit. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-24 12:42 ` Amrit Anand @ 2024-01-25 10:40 ` Krzysztof Kozlowski 0 siblings, 0 replies; 29+ messages in thread From: Krzysztof Kozlowski @ 2024-01-25 10:40 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 24/01/2024 13:42, Amrit Anand wrote: >>> +select: >>> + anyOf: >>> + - required: >>> + - 'board-id' >>> + - required: >>> + - 'board-id-types' >>> + - required: >>> + - '#board-id-cells' >> I don't fully get why do you need this select. Isn't the schema selected >> by nodename? Or maybe it is for the final required: but then this could >> be just set of dependencies. > The nodename here would be "/". So it will be applied to all the DTs, right? > Here, we wanted this to apply only if the above mentioned properties are > present. The nodename will select it. > Do you suggest moving this to qcom,board-id.yaml and the required: as well. > So that vendor specific yaml could be applied? I suggest dropping the select. Different topic is that we cannot even test it because you did not provide any user of this binding. >>> + >>> +properties: >>> + $nodename: >>> + const: "/" >> Blank line. > Will add it. >>> + board-id: >>> + $ref: /schemas/types.yaml#/definitions/uint32-matrix >>> + description: | >> Do not need '|' unless you need to preserve formatting. > Ack >>> + A list of identifiers that can be used to match with this devicetree. >> s/devicetree/Devicetree/ ? > Will update >>> + The interpretatation of each cell can be matched with the >> Typo: interpretation > Will update >>> + board-id-type at the same index. >>> + >>> + board-id-types: >>> + $ref: /schemas/types.yaml#/definitions/non-unique-string-array >>> + description: >>> + Defines the type of each cell, indicating to the DeviceTree selection >> s/DeviceTree/Devicetree/ ? > Will update >> >>> + mechanism how to parse the board-id. >>> + >>> + '#board-id-cells': >> What are the cells for? > Bootloader will use this to check the number of entries in a tuple of > board-id. Doesn't the board-id-type define number of cells? How could you have the same board-id-type with different number of elements on board A and board B? Best regards, Krzysztof ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand ` (2 preceding siblings ...) 2024-01-23 12:09 ` Krzysztof Kozlowski @ 2024-01-24 15:00 ` Rob Herring 3 siblings, 0 replies; 29+ messages in thread From: Rob Herring @ 2024-01-24 15:00 UTC (permalink / raw) To: Amrit Anand Cc: krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On Sat, Jan 20, 2024 at 04:50:48PM +0530, Amrit Anand wrote: > From: Elliot Berman <quic_eberman@quicinc.com> > > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. > > Isn't that what the compatible property is for? > ----------------------------------------------- > The compatible property can be used for board matching, but requires > bootloaders and/or firmware to maintain a database of possible strings > to match against or have complex compatible string matching. Compatible > string matching becomes complicated when there are multiple versions of > board: the device tree selector should recognize a DTB that cares to > distinguish between v1/v2 and a DTB that doesn't make the distinction. > An eeprom either needs to store the compatible strings that could match > against the board or the bootloader needs to have vendor-specific > decoding logic for the compatible string. Neither increasing eeprom > storage nor adding vendor-specific decoding logic is desirable. > > The solution proposed here is simpler to implement and doesn't require > updating firmware or bootloader for every new board. > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, > but now bootloaders need to be updated to also read this property. We > want to avoid requiring to update bootloaders with new hardware > identifiers: a bootloader need only recognize the identifiers it can > handle. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/board-id.yaml | 53 ++++++++++++++++++++++ > 1 file changed, 53 insertions(+) > create mode 100644 Documentation/devicetree/bindings/hwinfo/board-id.yaml > > diff --git a/Documentation/devicetree/bindings/hwinfo/board-id.yaml b/Documentation/devicetree/bindings/hwinfo/board-id.yaml > new file mode 100644 > index 0000000..82d5ff7 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwinfo/board-id.yaml > @@ -0,0 +1,53 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwinfo/board-id.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Board Identifier for Devicetree Selection > + > +maintainers: > + - Amrit Anand <quic_amrianan@quicinc.com> > + - Elliot Berman <quic_eberman@quicinc.com> > + > +description: | > + Device manufacturers frequently ship multiple boards under a single > + software package. These software packages will ship multiple devicetree > + blobs and require some mechanism to pick the correct DTB for the board > + the software package was deployed. board-id provides a mechanism for > + bootloaders to select the appropriate DTB which is vendor/OEM-agnostic. > + > +select: > + anyOf: > + - required: > + - 'board-id' > + - required: > + - 'board-id-types' > + - required: > + - '#board-id-cells' > + > +properties: > + $nodename: > + const: "/" > + board-id: > + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + description: | > + A list of identifiers that can be used to match with this devicetree. > + The interpretatation of each cell can be matched with the > + board-id-type at the same index. > + > + board-id-types: > + $ref: /schemas/types.yaml#/definitions/non-unique-string-array > + description: > + Defines the type of each cell, indicating to the DeviceTree selection > + mechanism how to parse the board-id. > + > + '#board-id-cells': > + minimum: 1 This is not how #foo-cells works. It is for provider/consumer style bindings. Rob ^ permalink raw reply [flat|nested] 29+ messages in thread
* [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand @ 2024-01-20 11:20 ` Amrit Anand 2024-01-20 12:36 ` Rob Herring ` (3 more replies) 2024-01-20 13:04 ` [PATCH 0/2] Add board-id support for multiple DT selection Konrad Dybcio 2024-01-24 14:56 ` Rob Herring 3 siblings, 4 replies; 29+ messages in thread From: Amrit Anand @ 2024-01-20 11:20 UTC (permalink / raw) To: robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Amrit Anand, Elliot Berman Qualcomm based DT uses two or three different identifiers. The SoC based idenfier which signifies chipset and the revision for those chipsets. The board based identifier is used to distinguish different boards (e.g. IDP, MTP) along with the different types of same boards. The PMIC attached to the board can also be used as a identifier for device tree. Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> --- .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- 2 files changed, 146 insertions(+), 8 deletions(-) create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml new file mode 100644 index 0000000..807f134 --- /dev/null +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QCOM Board Identifier for Devicetree Selection + +maintainers: + - Amrit Anand <quic_amrianan@quicinc.com> + - Elliot Berman <quic_eberman@quicinc.com> + +description: | + Qualcomm uses two and sometimes three hardware identifiers to describe + its boards + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) + - a board identifier is used to match board form factor (e.g. MTP, QRD, + ADP, CRD) + - a PMIC identifier is occasionally used when different PMICs are used + for a given board/SoC combination. + Each field and helper macros are defined at:: + - include/dt-bindings/arm/qcom,ids.h + + For example, + / { + #board-id-cells = <2>; + board-id = <456 0>, <457 0>, <10 0>; + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; + } + +allOf: + - $ref: board-id.yaml# + +properties: + board-id: + minItems: 2 + + board-id-types: + minItems: 2 + items: + oneOf: + - const: qcom,soc-id + description: | + Matches Qualcomm Technologies, Inc. boards with the specified SoC. + 2 integers are needed to describe a soc-id. The first integer is the + SoC ID and the second integer is the SoC revision. + qcom,soc-id = <soc-id soc-revision> + - const: qcom,board-id + description: | + Matches Qualcomm Technologies, Inc. boards with the specified board. + 2 integers are needed to describe a board-id. The first integer is the + board ID. The second integer is the board-subtype. + qcom,board-id = <board-id board-subtype> + - const: qcom,pmic-id + description: | + QUALCOMM boards can be atached to mutliple PMICs where slave-id (SID) + indicates the address of the bus on which the PMIC is attached. It can be + any number. The model for a PMIC indicates the PMIC name attached to bus + described by SID along with major and minor version. 2 integers are needed + to describe qcom,pmic-id. The first integer is the slave-id and the second integer + is the pmic model. + qcom,pmic-id = <pmic-sid pmic-model> + + '#board-id-cells': + minimum: 2 + +additionalProperties: true + +examples: + - | + #include <dt-bindings/arm/qcom,ids.h> + / { + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; + + #board-id-cells = <2>; + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; + board-id-types = "qcom,soc-id", + "qcom,soc-id", + "qcom,board-id"; + + #address-cells = <2>; + #size-cells = <2>; + }; diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h index f724834..c4cd440 100644 --- a/include/dt-bindings/arm/qcom,ids.h +++ b/include/dt-bindings/arm/qcom,ids.h @@ -8,9 +8,12 @@ #define _DT_BINDINGS_ARM_QCOM_IDS_H /* - * The MSM chipset and hardware revision used by Qualcomm bootloaders, DTS for - * older chipsets (qcom,msm-id) and in socinfo driver: + * The MSM chipset ID used by Qualcomm bootloaders, DTS for + * older chipsets (soc-id) and in socinfo driver: */ + +#define QCOM_SOC_ID(a) ((QCOM_ID_##a) && 0xffff) + #define QCOM_ID_MSM8260 70 #define QCOM_ID_MSM8660 71 #define QCOM_ID_APQ8060 86 @@ -266,16 +269,65 @@ #define QCOM_ID_IPQ5302 595 #define QCOM_ID_IPQ5300 624 + /* The SOC revision used by Qualcomm bootloaders (soc-revision) */ + +#define QCOM_SOC_REVISION(a) (a & 0xff) + /* * The board type and revision information, used by Qualcomm bootloaders and - * DTS for older chipsets (qcom,board-id): + * DTS for older chipsets (board-id) */ + #define QCOM_BOARD_ID(a, major, minor) \ - (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | ((QCOM_BOARD_ID_##a) & 0xff)) + +#define QCOM_BOARD_ID_MTP 0x8 +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 +#define QCOM_BOARD_ID_QRD 0x11 +#define QCOM_BOARD_ID_HDK 0x1F +#define QCOM_BOARD_ID_ATP 0x21 +#define QCOM_BOARD_ID_IDP 0x22 +#define QCOM_BOARD_ID_SBC 0x24 +#define QCOM_BOARD_ID_QXR 0x26 +#define QCOM_BOARD_ID_CRD 0x28 + +/* + * The platform subtype is used by Qualcomm bootloaders and + * DTS (board-subtype) + */ +#define QCOM_BOARD_SUBTYPE(a, b, SUBTYPE) \ + (((QCOM_BOARD_BOOT_##a & 0xf) << 16) | ((QCOM_BOARD_DDRTYPE_##b & 0x7) << 8) | \ + (SUBTYPE & 0xff)) + +/* Board DDR Type where each value indicates higher limit */ +#define QCOM_BOARD_DDRTYPE_ANY 0x0 +#define QCOM_BOARD_DDRTYPE_128M 0x1 +#define QCOM_BOARD_DDRTYPE_256M 0x2 +#define QCOM_BOARD_DDRTYPE_512M 0x3 +#define QCOM_BOARD_DDRTYPE_1024M 0x4 +#define QCOM_BOARD_DDRTYPE_2048M 0x5 +#define QCOM_BOARD_DDRTYPE_3072M 0x6 +#define QCOM_BOARD_DDRTYPE_4096M 0x7 + +/* Board Boot Device Type */ +#define QCOM_BOARD_BOOT_EMMC 0x0 +#define QCOM_BOARD_BOOT_UFS 0x1 +#define QCOM_BOARD_BOOT_NAND 0x2 +#define QCOM_BOARD_BOOT_OTHER 0x3 + +/* + * The PMIC slave id is used by Qualcomm bootloaders to + * indicates which PMIC is attached (pmic-sid) + */ + +#define QCOM_PMIC_SID(a) (a & 0xff) + +/* + * The PMIC ID is used by Qualcomm bootloaders to describe the ID + * of PMIC attached to bus described by SID (pmic-model) + */ -#define QCOM_BOARD_ID_MTP 8 -#define QCOM_BOARD_ID_DRAGONBOARD 10 -#define QCOM_BOARD_ID_QRD 11 -#define QCOM_BOARD_ID_SBC 24 +#define QCOM_PMIC_MODEL(ID, major, minor) \ + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | (ID & 0xff)) #endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ -- 2.7.4 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand @ 2024-01-20 12:36 ` Rob Herring 2024-01-20 13:32 ` Konrad Dybcio ` (2 subsequent siblings) 3 siblings, 0 replies; 29+ messages in thread From: Rob Herring @ 2024-01-20 12:36 UTC (permalink / raw) To: Amrit Anand Cc: linux-kernel, linux-arm-msm, kernel, devicetree, konrad.dybcio, andersson, robh+dt, Elliot Berman, agross, krzysztof.kozlowski+dt, conor+dt On Sat, 20 Jan 2024 16:50:49 +0530, Amrit Anand wrote: > Qualcomm based DT uses two or three different identifiers. The SoC > based idenfier which signifies chipset and the revision for those > chipsets. The board based identifier is used to distinguish different > boards (e.g. IDP, MTP) along with the different types of same boards. > The PMIC attached to the board can also be used as a identifier for > device tree. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ > include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- > 2 files changed, 146 insertions(+), 8 deletions(-) > create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check' on your patch (DT_CHECKER_FLAGS is new in v5.13): yamllint warnings/errors: ./Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml:70:4: [warning] wrong indentation: expected 2 but found 3 (indentation) dtschema/dtc warnings/errors: doc reference errors (make refcheckdocs): See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/1705749649-4708-3-git-send-email-quic_amrianan@quicinc.com The base for the series is generally the latest rc1. A different dependency should be noted in *this* patch. If you already ran 'make dt_binding_check' and didn't see the above error(s), then make sure 'yamllint' is installed and dt-schema is up to date: pip3 install dtschema --upgrade Please check and re-submit after running the above command yourself. Note that DT_SCHEMA_FILES can be set to your schema file to speed up checking your schema. However, it must be unset to test all examples with your schema. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand 2024-01-20 12:36 ` Rob Herring @ 2024-01-20 13:32 ` Konrad Dybcio 2024-01-22 10:07 ` Amrit Anand 2024-01-21 2:05 ` kernel test robot 2024-01-22 18:12 ` Elliot Berman 3 siblings, 1 reply; 29+ messages in thread From: Konrad Dybcio @ 2024-01-20 13:32 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 20.01.2024 12:20, Amrit Anand wrote: > Qualcomm based DT uses two or three different identifiers. The SoC > based idenfier which signifies chipset and the revision for those > chipsets. The board based identifier is used to distinguish different > boards (e.g. IDP, MTP) along with the different types of same boards. > The PMIC attached to the board can also be used as a identifier for > device tree. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ > include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- > 2 files changed, 146 insertions(+), 8 deletions(-) > create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > > diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > new file mode 100644 > index 0000000..807f134 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > @@ -0,0 +1,86 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: QCOM Board Identifier for Devicetree Selection > + > +maintainers: > + - Amrit Anand <quic_amrianan@quicinc.com> > + - Elliot Berman <quic_eberman@quicinc.com> > + > +description: | The '|'s are unnecessary in both commits, IIRC they're used for preserving formatting which we don't really need for non-styled plaintext > + Qualcomm uses two and sometimes three hardware identifiers to describe > + its boards > + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) > + - a board identifier is used to match board form factor (e.g. MTP, QRD, > + ADP, CRD) > + - a PMIC identifier is occasionally used when different PMICs are used > + for a given board/SoC combination. > + Each field and helper macros are defined at:: > + - include/dt-bindings/arm/qcom,ids.h > + > + For example, > + / { > + #board-id-cells = <2>; > + board-id = <456 0>, <457 0>, <10 0>; > + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; > + } > + > +allOf: > + - $ref: board-id.yaml# > + > +properties: > + board-id: > + minItems: 2 I believe some older platforms match exclusively based on socid, so perhaps 1 would be okay as well. [...] > +examples: > + - | > + #include <dt-bindings/arm/qcom,ids.h> > + / { > + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; > + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; > + > + #board-id-cells = <2>; > + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, > + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, > + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; > + board-id-types = "qcom,soc-id", > + "qcom,soc-id", > + "qcom,board-id"; So, would the matching here would be: loop over disctinct board-id-types check if there's at least 1 match for all of them use this dtb if that's the case stop booting / "best guess match" ? [...] > +#define QCOM_BOARD_ID_MTP 0x8 > +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 > +#define QCOM_BOARD_ID_QRD 0x11 > +#define QCOM_BOARD_ID_HDK 0x1F > +#define QCOM_BOARD_ID_ATP 0x21 > +#define QCOM_BOARD_ID_IDP 0x22 > +#define QCOM_BOARD_ID_SBC 0x24 > +#define QCOM_BOARD_ID_QXR 0x26 > +#define QCOM_BOARD_ID_CRD 0x28 Missing ADP/QCP/Ride (if they're separate) Konrad ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 13:32 ` Konrad Dybcio @ 2024-01-22 10:07 ` Amrit Anand 2024-01-22 18:10 ` Elliot Berman 0 siblings, 1 reply; 29+ messages in thread From: Amrit Anand @ 2024-01-22 10:07 UTC (permalink / raw) To: Konrad Dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel, Elliot Berman On 1/20/2024 7:02 PM, Konrad Dybcio wrote: > On 20.01.2024 12:20, Amrit Anand wrote: >> Qualcomm based DT uses two or three different identifiers. The SoC >> based idenfier which signifies chipset and the revision for those >> chipsets. The board based identifier is used to distinguish different >> boards (e.g. IDP, MTP) along with the different types of same boards. >> The PMIC attached to the board can also be used as a identifier for >> device tree. >> >> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> >> --- >> .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ >> include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- >> 2 files changed, 146 insertions(+), 8 deletions(-) >> create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >> >> diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >> new file mode 100644 >> index 0000000..807f134 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >> @@ -0,0 +1,86 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: QCOM Board Identifier for Devicetree Selection >> + >> +maintainers: >> + - Amrit Anand <quic_amrianan@quicinc.com> >> + - Elliot Berman <quic_eberman@quicinc.com> >> + >> +description: | > The '|'s are unnecessary in both commits, IIRC they're used for > preserving formatting which we don't really need for non-styled > plaintext Sure, will do. >> + Qualcomm uses two and sometimes three hardware identifiers to describe >> + its boards >> + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) >> + - a board identifier is used to match board form factor (e.g. MTP, QRD, >> + ADP, CRD) >> + - a PMIC identifier is occasionally used when different PMICs are used >> + for a given board/SoC combination. >> + Each field and helper macros are defined at:: >> + - include/dt-bindings/arm/qcom,ids.h >> + >> + For example, >> + / { >> + #board-id-cells = <2>; >> + board-id = <456 0>, <457 0>, <10 0>; >> + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; >> + } >> + >> +allOf: >> + - $ref: board-id.yaml# >> + >> +properties: >> + board-id: >> + minItems: 2 > I believe some older platforms match exclusively based on socid, so > perhaps 1 would be okay as well. > > [...] Ok, considering legacy targets we can make it 1. But i think ideally it should always be recommended to have a board ID associated with a SoC ID, correct me if my understanding is wrong. >> +examples: >> + - | >> + #include <dt-bindings/arm/qcom,ids.h> >> + / { >> + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; >> + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; >> + >> + #board-id-cells = <2>; >> + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, >> + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, >> + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; >> + board-id-types = "qcom,soc-id", >> + "qcom,soc-id", >> + "qcom,board-id"; > So, would the matching here would be: > > loop over disctinct board-id-types > check if there's at least 1 match for all of them > use this dtb if that's the case > > stop booting / "best guess match" > > ? > > [...] Yes, But the "if" checking would have preference in place. The preference logic would look something like this, First will check for SoC-ID, if we have an exact match for SoC-ID then will proceed for board-ID match. Otherwise the DT would be discarded. Once (exact) board-ID found, will proceed for subtype , pmic and so on. Exact match and best match logic is used. Parameters like SoC-ID, board-ID are required to be best matched. Other few fields follow best match logic and best of the DT can be picked. >> +#define QCOM_BOARD_ID_MTP 0x8 >> +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 >> +#define QCOM_BOARD_ID_QRD 0x11 >> +#define QCOM_BOARD_ID_HDK 0x1F >> +#define QCOM_BOARD_ID_ATP 0x21 >> +#define QCOM_BOARD_ID_IDP 0x22 >> +#define QCOM_BOARD_ID_SBC 0x24 >> +#define QCOM_BOARD_ID_QXR 0x26 >> +#define QCOM_BOARD_ID_CRD 0x28 > Missing ADP/QCP/Ride (if they're separate) Sure, will update. Would need to work with teams. Thanks, Amrit. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-22 10:07 ` Amrit Anand @ 2024-01-22 18:10 ` Elliot Berman 2024-01-22 19:27 ` Dmitry Baryshkov 2024-01-24 12:47 ` Amrit Anand 0 siblings, 2 replies; 29+ messages in thread From: Elliot Berman @ 2024-01-22 18:10 UTC (permalink / raw) To: Amrit Anand, Konrad Dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel On 1/22/2024 2:07 AM, Amrit Anand wrote: > > On 1/20/2024 7:02 PM, Konrad Dybcio wrote: >> On 20.01.2024 12:20, Amrit Anand wrote: >>> Qualcomm based DT uses two or three different identifiers. The SoC >>> based idenfier which signifies chipset and the revision for those >>> chipsets. The board based identifier is used to distinguish different >>> boards (e.g. IDP, MTP) along with the different types of same boards. >>> The PMIC attached to the board can also be used as a identifier for >>> device tree. >>> >>> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >>> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> >>> --- >>> .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ >>> include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- >>> 2 files changed, 146 insertions(+), 8 deletions(-) >>> create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>> >>> diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>> new file mode 100644 >>> index 0000000..807f134 >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>> @@ -0,0 +1,86 @@ >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>> +%YAML 1.2 >>> +--- >>> +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>> + >>> +title: QCOM Board Identifier for Devicetree Selection >>> + >>> +maintainers: >>> + - Amrit Anand <quic_amrianan@quicinc.com> >>> + - Elliot Berman <quic_eberman@quicinc.com> >>> + >>> +description: | >> The '|'s are unnecessary in both commits, IIRC they're used for >> preserving formatting which we don't really need for non-styled >> plaintext > Sure, will do. >>> + Qualcomm uses two and sometimes three hardware identifiers to describe >>> + its boards >>> + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) >>> + - a board identifier is used to match board form factor (e.g. MTP, QRD, >>> + ADP, CRD) >>> + - a PMIC identifier is occasionally used when different PMICs are used >>> + for a given board/SoC combination. >>> + Each field and helper macros are defined at:: >>> + - include/dt-bindings/arm/qcom,ids.h >>> + >>> + For example, >>> + / { >>> + #board-id-cells = <2>; >>> + board-id = <456 0>, <457 0>, <10 0>; >>> + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; >>> + } >>> + >>> +allOf: >>> + - $ref: board-id.yaml# >>> + >>> +properties: >>> + board-id: >>> + minItems: 2 >> I believe some older platforms match exclusively based on socid, so >> perhaps 1 would be okay as well. >> >> [...] > > Ok, considering legacy targets we can make it 1. > > But i think ideally it should always be recommended to have a board ID associated with a SoC ID, correct me if my understanding is wrong. > There is no "legacy" support needed here: Qualcomm's bootloaders need to be updated to adhere to the new proposed spec. I suppose we need to consider whether we have targets that only need SoC to differentiate? >>> +examples: >>> + - | >>> + #include <dt-bindings/arm/qcom,ids.h> >>> + / { >>> + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; >>> + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; >>> + >>> + #board-id-cells = <2>; >>> + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, >>> + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, >>> + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; >>> + board-id-types = "qcom,soc-id", >>> + "qcom,soc-id", >>> + "qcom,board-id"; >> So, would the matching here would be: >> >> loop over disctinct board-id-types >> check if there's at least 1 match for all of them >> use this dtb if that's the case >> >> stop booting / "best guess match" >> >> ? >> >> [...] > > Yes, But the "if" checking would have preference in place. > The preference logic would look something like this, > > First will check for SoC-ID, if we have an exact match for SoC-ID then will proceed for board-ID match. Otherwise the DT would be discarded. > Once (exact) board-ID found, will proceed for subtype , pmic and so on. > Exact match and best match logic is used. Parameters like SoC-ID, board-ID are required to be best matched. Other few fields follow best match logic and best of the DT can be picked. > >>> +#define QCOM_BOARD_ID_MTP 0x8 >>> +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 >>> +#define QCOM_BOARD_ID_QRD 0x11 >>> +#define QCOM_BOARD_ID_HDK 0x1F >>> +#define QCOM_BOARD_ID_ATP 0x21 >>> +#define QCOM_BOARD_ID_IDP 0x22 >>> +#define QCOM_BOARD_ID_SBC 0x24 >>> +#define QCOM_BOARD_ID_QXR 0x26 >>> +#define QCOM_BOARD_ID_CRD 0x28 >> Missing ADP/QCP/Ride (if they're separate) > > Sure, will update. Would need to work with teams. There are probably more boards that we aren't aware of. Amrit, please add board IDs for all the boards that are in kernel.org. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-22 18:10 ` Elliot Berman @ 2024-01-22 19:27 ` Dmitry Baryshkov 2024-01-24 12:47 ` Amrit Anand 1 sibling, 0 replies; 29+ messages in thread From: Dmitry Baryshkov @ 2024-01-22 19:27 UTC (permalink / raw) To: Elliot Berman Cc: Amrit Anand, Konrad Dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, devicetree, linux-kernel, linux-arm-msm, kernel On Mon, 22 Jan 2024 at 20:46, Elliot Berman <quic_eberman@quicinc.com> wrote: > > > > On 1/22/2024 2:07 AM, Amrit Anand wrote: > > > > On 1/20/2024 7:02 PM, Konrad Dybcio wrote: > >> On 20.01.2024 12:20, Amrit Anand wrote: > >>> Qualcomm based DT uses two or three different identifiers. The SoC > >>> based idenfier which signifies chipset and the revision for those > >>> chipsets. The board based identifier is used to distinguish different > >>> boards (e.g. IDP, MTP) along with the different types of same boards. > >>> The PMIC attached to the board can also be used as a identifier for > >>> device tree. > >>> > >>> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > >>> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > >>> --- > >>> .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ > >>> include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- > >>> 2 files changed, 146 insertions(+), 8 deletions(-) > >>> create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > >>> > >>> diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > >>> new file mode 100644 > >>> index 0000000..807f134 > >>> --- /dev/null > >>> +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > >>> @@ -0,0 +1,86 @@ > >>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > >>> +%YAML 1.2 > >>> +--- > >>> +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# > >>> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >>> + > >>> +title: QCOM Board Identifier for Devicetree Selection > >>> + > >>> +maintainers: > >>> + - Amrit Anand <quic_amrianan@quicinc.com> > >>> + - Elliot Berman <quic_eberman@quicinc.com> > >>> + > >>> +description: | > >> The '|'s are unnecessary in both commits, IIRC they're used for > >> preserving formatting which we don't really need for non-styled > >> plaintext > > Sure, will do. > >>> + Qualcomm uses two and sometimes three hardware identifiers to describe > >>> + its boards > >>> + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) > >>> + - a board identifier is used to match board form factor (e.g. MTP, QRD, > >>> + ADP, CRD) > >>> + - a PMIC identifier is occasionally used when different PMICs are used > >>> + for a given board/SoC combination. > >>> + Each field and helper macros are defined at:: > >>> + - include/dt-bindings/arm/qcom,ids.h > >>> + > >>> + For example, > >>> + / { > >>> + #board-id-cells = <2>; > >>> + board-id = <456 0>, <457 0>, <10 0>; > >>> + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; > >>> + } > >>> + > >>> +allOf: > >>> + - $ref: board-id.yaml# > >>> + > >>> +properties: > >>> + board-id: > >>> + minItems: 2 > >> I believe some older platforms match exclusively based on socid, so > >> perhaps 1 would be okay as well. > >> > >> [...] > > > > Ok, considering legacy targets we can make it 1. > > > > But i think ideally it should always be recommended to have a board ID associated with a SoC ID, correct me if my understanding is wrong. > > > > There is no "legacy" support needed here: Qualcomm's bootloaders > need to be updated to adhere to the new proposed spec. I suppose > we need to consider whether we have targets that only need SoC to > differentiate? What is the chance of updating the bootloader for the N year device? -- With best wishes Dmitry ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-22 18:10 ` Elliot Berman 2024-01-22 19:27 ` Dmitry Baryshkov @ 2024-01-24 12:47 ` Amrit Anand 1 sibling, 0 replies; 29+ messages in thread From: Amrit Anand @ 2024-01-24 12:47 UTC (permalink / raw) To: Elliot Berman, Konrad Dybcio, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel On 1/22/2024 11:40 PM, Elliot Berman wrote: > > On 1/22/2024 2:07 AM, Amrit Anand wrote: >> On 1/20/2024 7:02 PM, Konrad Dybcio wrote: >>> On 20.01.2024 12:20, Amrit Anand wrote: >>>> Qualcomm based DT uses two or three different identifiers. The SoC >>>> based idenfier which signifies chipset and the revision for those >>>> chipsets. The board based identifier is used to distinguish different >>>> boards (e.g. IDP, MTP) along with the different types of same boards. >>>> The PMIC attached to the board can also be used as a identifier for >>>> device tree. >>>> >>>> Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> >>>> Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> >>>> --- >>>> .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ >>>> include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- >>>> 2 files changed, 146 insertions(+), 8 deletions(-) >>>> create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>>> >>>> diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>>> new file mode 100644 >>>> index 0000000..807f134 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml >>>> @@ -0,0 +1,86 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: QCOM Board Identifier for Devicetree Selection >>>> + >>>> +maintainers: >>>> + - Amrit Anand <quic_amrianan@quicinc.com> >>>> + - Elliot Berman <quic_eberman@quicinc.com> >>>> + >>>> +description: | >>> The '|'s are unnecessary in both commits, IIRC they're used for >>> preserving formatting which we don't really need for non-styled >>> plaintext >> Sure, will do. >>>> + Qualcomm uses two and sometimes three hardware identifiers to describe >>>> + its boards >>>> + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) >>>> + - a board identifier is used to match board form factor (e.g. MTP, QRD, >>>> + ADP, CRD) >>>> + - a PMIC identifier is occasionally used when different PMICs are used >>>> + for a given board/SoC combination. >>>> + Each field and helper macros are defined at:: >>>> + - include/dt-bindings/arm/qcom,ids.h >>>> + >>>> + For example, >>>> + / { >>>> + #board-id-cells = <2>; >>>> + board-id = <456 0>, <457 0>, <10 0>; >>>> + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; >>>> + } >>>> + >>>> +allOf: >>>> + - $ref: board-id.yaml# >>>> + >>>> +properties: >>>> + board-id: >>>> + minItems: 2 >>> I believe some older platforms match exclusively based on socid, so >>> perhaps 1 would be okay as well. >>> >>> [...] >> Ok, considering legacy targets we can make it 1. >> >> But i think ideally it should always be recommended to have a board ID associated with a SoC ID, correct me if my understanding is wrong. >> > There is no "legacy" support needed here: Qualcomm's bootloaders > need to be updated to adhere to the new proposed spec. I suppose > we need to consider whether we have targets that only need SoC to > differentiate? > >>>> +examples: >>>> + - | >>>> + #include <dt-bindings/arm/qcom,ids.h> >>>> + / { >>>> + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; >>>> + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; >>>> + >>>> + #board-id-cells = <2>; >>>> + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, >>>> + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, >>>> + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; >>>> + board-id-types = "qcom,soc-id", >>>> + "qcom,soc-id", >>>> + "qcom,board-id"; >>> So, would the matching here would be: >>> >>> loop over disctinct board-id-types >>> check if there's at least 1 match for all of them >>> use this dtb if that's the case >>> >>> stop booting / "best guess match" >>> >>> ? >>> >>> [...] >> Yes, But the "if" checking would have preference in place. >> The preference logic would look something like this, >> >> First will check for SoC-ID, if we have an exact match for SoC-ID then will proceed for board-ID match. Otherwise the DT would be discarded. >> Once (exact) board-ID found, will proceed for subtype , pmic and so on. >> Exact match and best match logic is used. Parameters like SoC-ID, board-ID are required to be best matched. Other few fields follow best match logic and best of the DT can be picked. >> >>>> +#define QCOM_BOARD_ID_MTP 0x8 >>>> +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 >>>> +#define QCOM_BOARD_ID_QRD 0x11 >>>> +#define QCOM_BOARD_ID_HDK 0x1F >>>> +#define QCOM_BOARD_ID_ATP 0x21 >>>> +#define QCOM_BOARD_ID_IDP 0x22 >>>> +#define QCOM_BOARD_ID_SBC 0x24 >>>> +#define QCOM_BOARD_ID_QXR 0x26 >>>> +#define QCOM_BOARD_ID_CRD 0x28 >>> Missing ADP/QCP/Ride (if they're separate) >> Sure, will update. Would need to work with teams. > There are probably more boards that we aren't aware of. > > Amrit, please add board IDs for all the boards that are > in kernel.org. Sure, will do that. Thanks, Amrit ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand 2024-01-20 12:36 ` Rob Herring 2024-01-20 13:32 ` Konrad Dybcio @ 2024-01-21 2:05 ` kernel test robot 2024-01-22 18:12 ` Elliot Berman 3 siblings, 0 replies; 29+ messages in thread From: kernel test robot @ 2024-01-21 2:05 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: oe-kbuild-all, devicetree, linux-kernel, linux-arm-msm, kernel, Amrit Anand, Elliot Berman Hi Amrit, kernel test robot noticed the following build warnings: [auto build test WARNING on robh/for-next] [also build test WARNING on linus/master v6.7 next-20240119] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Amrit-Anand/dt-bindings-hwinfo-Introduce-board-id/20240120-192358 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next patch link: https://lore.kernel.org/r/1705749649-4708-3-git-send-email-quic_amrianan%40quicinc.com patch subject: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types compiler: loongarch64-linux-gcc (GCC) 13.2.0 reproduce: (https://download.01.org/0day-ci/archive/20240121/202401210920.aPy2DJwj-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202401210920.aPy2DJwj-lkp@intel.com/ dtcheck warnings: (new ones prefixed by >>) >> Documentation/devicetree/bindings/hwinfo/board-id.yaml:23:11: [error] string value is redundantly quoted with any quotes (quoted-strings) Documentation/devicetree/bindings/hwinfo/board-id.yaml:25:11: [error] string value is redundantly quoted with any quotes (quoted-strings) >> Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml:70:4: [warning] wrong indentation: expected 2 but found 3 (indentation) vim +70 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml 68 69 examples: > 70 - | -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand ` (2 preceding siblings ...) 2024-01-21 2:05 ` kernel test robot @ 2024-01-22 18:12 ` Elliot Berman 3 siblings, 0 replies; 29+ messages in thread From: Elliot Berman @ 2024-01-22 18:12 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio Cc: devicetree, linux-kernel, linux-arm-msm, kernel On 1/20/2024 3:20 AM, Amrit Anand wrote: > Qualcomm based DT uses two or three different identifiers. The SoC > based idenfier which signifies chipset and the revision for those > chipsets. The board based identifier is used to distinguish different > boards (e.g. IDP, MTP) along with the different types of same boards. > The PMIC attached to the board can also be used as a identifier for > device tree. > > Signed-off-by: Elliot Berman <quic_eberman@quicinc.com> > Signed-off-by: Amrit Anand <quic_amrianan@quicinc.com> > --- > .../devicetree/bindings/hwinfo/qcom,board-id.yaml | 86 ++++++++++++++++++++++ > include/dt-bindings/arm/qcom,ids.h | 68 +++++++++++++++-- > 2 files changed, 146 insertions(+), 8 deletions(-) > create mode 100644 Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > > diff --git a/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > new file mode 100644 > index 0000000..807f134 > --- /dev/null > +++ b/Documentation/devicetree/bindings/hwinfo/qcom,board-id.yaml > @@ -0,0 +1,86 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/hwinfo/qcom,board-id.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: QCOM Board Identifier for Devicetree Selection > + > +maintainers: > + - Amrit Anand <quic_amrianan@quicinc.com> > + - Elliot Berman <quic_eberman@quicinc.com> > + > +description: | > + Qualcomm uses two and sometimes three hardware identifiers to describe > + its boards > + - a SoC identifier is used to match chipsets (e.g. sm8550 vs sm8450) > + - a board identifier is used to match board form factor (e.g. MTP, QRD, > + ADP, CRD) > + - a PMIC identifier is occasionally used when different PMICs are used > + for a given board/SoC combination. > + Each field and helper macros are defined at:: > + - include/dt-bindings/arm/qcom,ids.h > + > + For example, > + / { > + #board-id-cells = <2>; > + board-id = <456 0>, <457 0>, <10 0>; > + board-id-types = "qcom,soc-id", "qcom,soc-id", "qcom,board-id"; > + } > + > +allOf: > + - $ref: board-id.yaml# > + There's nothing to cause this binding to be selected. Please add a select clause. I guess we can make it based off whether the board's compatible contains "qcom,". > +properties: > + board-id: > + minItems: 2 > + > + board-id-types: > + minItems: 2 > + items: > + oneOf: > + - const: qcom,soc-id > + description: | > + Matches Qualcomm Technologies, Inc. boards with the specified SoC. > + 2 integers are needed to describe a soc-id. The first integer is the > + SoC ID and the second integer is the SoC revision. > + qcom,soc-id = <soc-id soc-revision> > + - const: qcom,board-id > + description: | > + Matches Qualcomm Technologies, Inc. boards with the specified board. > + 2 integers are needed to describe a board-id. The first integer is the > + board ID. The second integer is the board-subtype. > + qcom,board-id = <board-id board-subtype> > + - const: qcom,pmic-id > + description: | > + QUALCOMM boards can be atached to mutliple PMICs where slave-id (SID) > + indicates the address of the bus on which the PMIC is attached. It can be > + any number. The model for a PMIC indicates the PMIC name attached to bus > + described by SID along with major and minor version. 2 integers are needed > + to describe qcom,pmic-id. The first integer is the slave-id and the second integer > + is the pmic model. > + qcom,pmic-id = <pmic-sid pmic-model> > + > + '#board-id-cells': > + minimum: 2 > + > +additionalProperties: true > + > +examples: > + - | > + #include <dt-bindings/arm/qcom,ids.h> > + / { > + model = "Qualcomm Technologies, Inc. sc7280 IDP SKU1 platform"; > + compatible = "qcom,sc7280-idp", "google,senor", "qcom,sc7280"; > + > + #board-id-cells = <2>; > + board-id = <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(1)>, > + <QCOM_SOC_ID(SC7280) QCOM_SOC_REVISION(2)>, > + <QCOM_BOARD_ID(IDP, 1, 0) QCOM_BOARD_SUBTYPE(UFS, ANY, 1)>; > + board-id-types = "qcom,soc-id", > + "qcom,soc-id", > + "qcom,board-id"; > + > + #address-cells = <2>; > + #size-cells = <2>; > + }; > diff --git a/include/dt-bindings/arm/qcom,ids.h b/include/dt-bindings/arm/qcom,ids.h > index f724834..c4cd440 100644 > --- a/include/dt-bindings/arm/qcom,ids.h > +++ b/include/dt-bindings/arm/qcom,ids.h > @@ -8,9 +8,12 @@ > #define _DT_BINDINGS_ARM_QCOM_IDS_H > > /* > - * The MSM chipset and hardware revision used by Qualcomm bootloaders, DTS for > - * older chipsets (qcom,msm-id) and in socinfo driver: > + * The MSM chipset ID used by Qualcomm bootloaders, DTS for > + * older chipsets (soc-id) and in socinfo driver: > */ > + > +#define QCOM_SOC_ID(a) ((QCOM_ID_##a) && 0xffff) > + > #define QCOM_ID_MSM8260 70 > #define QCOM_ID_MSM8660 71 > #define QCOM_ID_APQ8060 86 > @@ -266,16 +269,65 @@ > #define QCOM_ID_IPQ5302 595 > #define QCOM_ID_IPQ5300 624 > > + /* The SOC revision used by Qualcomm bootloaders (soc-revision) */ > + > +#define QCOM_SOC_REVISION(a) (a & 0xff) > + > /* > * The board type and revision information, used by Qualcomm bootloaders and > - * DTS for older chipsets (qcom,board-id): > + * DTS for older chipsets (board-id) > */ > + > #define QCOM_BOARD_ID(a, major, minor) \ > - (((major & 0xff) << 16) | ((minor & 0xff) << 8) | QCOM_BOARD_ID_##a) > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | ((QCOM_BOARD_ID_##a) & 0xff)) > + > +#define QCOM_BOARD_ID_MTP 0x8 > +#define QCOM_BOARD_ID_DRAGONBOARD 0x10 > +#define QCOM_BOARD_ID_QRD 0x11 > +#define QCOM_BOARD_ID_HDK 0x1F > +#define QCOM_BOARD_ID_ATP 0x21 > +#define QCOM_BOARD_ID_IDP 0x22 > +#define QCOM_BOARD_ID_SBC 0x24 > +#define QCOM_BOARD_ID_QXR 0x26 > +#define QCOM_BOARD_ID_CRD 0x28 > + > +/* > + * The platform subtype is used by Qualcomm bootloaders and > + * DTS (board-subtype) > + */ > +#define QCOM_BOARD_SUBTYPE(a, b, SUBTYPE) \ > + (((QCOM_BOARD_BOOT_##a & 0xf) << 16) | ((QCOM_BOARD_DDRTYPE_##b & 0x7) << 8) | \ > + (SUBTYPE & 0xff)) > + > +/* Board DDR Type where each value indicates higher limit */ > +#define QCOM_BOARD_DDRTYPE_ANY 0x0 > +#define QCOM_BOARD_DDRTYPE_128M 0x1 > +#define QCOM_BOARD_DDRTYPE_256M 0x2 > +#define QCOM_BOARD_DDRTYPE_512M 0x3 > +#define QCOM_BOARD_DDRTYPE_1024M 0x4 > +#define QCOM_BOARD_DDRTYPE_2048M 0x5 > +#define QCOM_BOARD_DDRTYPE_3072M 0x6 > +#define QCOM_BOARD_DDRTYPE_4096M 0x7 > + > +/* Board Boot Device Type */ > +#define QCOM_BOARD_BOOT_EMMC 0x0 > +#define QCOM_BOARD_BOOT_UFS 0x1 > +#define QCOM_BOARD_BOOT_NAND 0x2 > +#define QCOM_BOARD_BOOT_OTHER 0x3 > + > +/* > + * The PMIC slave id is used by Qualcomm bootloaders to > + * indicates which PMIC is attached (pmic-sid) > + */ > + > +#define QCOM_PMIC_SID(a) (a & 0xff) > + > +/* > + * The PMIC ID is used by Qualcomm bootloaders to describe the ID > + * of PMIC attached to bus described by SID (pmic-model) > + */ > > -#define QCOM_BOARD_ID_MTP 8 > -#define QCOM_BOARD_ID_DRAGONBOARD 10 > -#define QCOM_BOARD_ID_QRD 11 > -#define QCOM_BOARD_ID_SBC 24 > +#define QCOM_PMIC_MODEL(ID, major, minor) \ > + (((major & 0xff) << 16) | ((minor & 0xff) << 8) | (ID & 0xff)) > > #endif /* _DT_BINDINGS_ARM_QCOM_IDS_H */ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand @ 2024-01-20 13:04 ` Konrad Dybcio 2024-01-22 17:50 ` Elliot Berman 2024-01-24 14:56 ` Rob Herring 3 siblings, 1 reply; 29+ messages in thread From: Konrad Dybcio @ 2024-01-20 13:04 UTC (permalink / raw) To: Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel On 20.01.2024 12:20, Amrit Anand wrote: > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. Maybe it'd be a good idea to add it to the base spec! https://github.com/devicetree-org/devicetree-specification Konrad ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-01-20 13:04 ` [PATCH 0/2] Add board-id support for multiple DT selection Konrad Dybcio @ 2024-01-22 17:50 ` Elliot Berman 0 siblings, 0 replies; 29+ messages in thread From: Elliot Berman @ 2024-01-22 17:50 UTC (permalink / raw) To: Konrad Dybcio, Amrit Anand, robh+dt, krzysztof.kozlowski+dt, conor+dt, agross, andersson Cc: devicetree, linux-kernel, linux-arm-msm, kernel, devicetree-spec +devicetree-spec On 1/20/2024 5:04 AM, Konrad Dybcio wrote: > On 20.01.2024 12:20, Amrit Anand wrote: >> Device manufacturers frequently ship multiple boards or SKUs under a >> single software package. These software packages will ship multiple >> devicetree blobs and require some mechanism to pick the correct DTB for >> the board the software package was deployed. Introduce a common >> definition for adding board identifiers to device trees. board-id >> provides a mechanism for bootloaders to select the appropriate DTB which >> is vendor/OEM-agnostic. > > Maybe it'd be a good idea to add it to the base spec! > > https://github.com/devicetree-org/devicetree-specification > I agree. Rob, what do you think? ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand ` (2 preceding siblings ...) 2024-01-20 13:04 ` [PATCH 0/2] Add board-id support for multiple DT selection Konrad Dybcio @ 2024-01-24 14:56 ` Rob Herring 2024-02-02 5:00 ` Amrit Anand 3 siblings, 1 reply; 29+ messages in thread From: Rob Herring @ 2024-01-24 14:56 UTC (permalink / raw) To: Amrit Anand Cc: krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel On Sat, Jan 20, 2024 at 04:50:47PM +0530, Amrit Anand wrote: > Device manufacturers frequently ship multiple boards or SKUs under a > single software package. These software packages will ship multiple > devicetree blobs and require some mechanism to pick the correct DTB for > the board the software package was deployed. Introduce a common > definition for adding board identifiers to device trees. board-id > provides a mechanism for bootloaders to select the appropriate DTB which > is vendor/OEM-agnostic. Show me a 2nd user. Or does vendor/OEM-agnostic just mean vendors of QCom devices? Multiple SoC families using this would help your case. I'm not inclined to take it into the DTSpec without that. > > Isn't that what the compatible property is for? > ----------------------------------------------- > The compatible property can be used for board matching, but requires > bootloaders and/or firmware to maintain a database of possible strings > to match against or have complex compatible string matching. Compatible > string matching becomes complicated when there are multiple versions of > board: the device tree selector should recognize a DTB that cares to > distinguish between v1/v2 and a DTB that doesn't make the distinction. > An eeprom either needs to store the compatible strings that could match > against the board or the bootloader needs to have vendor-specific > decoding logic for the compatible string. Neither increasing eeprom > storage nor adding vendor-specific decoding logic is desirable. You could hash the compatible strings if it was just a size issue. > The solution proposed here is simpler to implement and doesn't require > updating firmware or bootloader for every new board. > > How is this better than Qualcomm's qcom,msm-id/qcom,board-id? > ------------------------------------------------------------- > The selection process for devicetrees was Qualcomm-specific and not > useful for other devices and bootloaders that were not developed by > Qualcomm because a complex algorithm was used to implement. Board-ids > provide a matching solution that can be implemented by bootloaders > without introducing vendor-specific code. Qualcomm uses three > devicetree properties: msm-id (interchangeably: soc-id), board-id, and > pmic-id. This does not scale well for use casese which use identifiers, > for example, to distinguish between a display panel. For a display > panel, an approach could be to add a new property: display-id, but now > bootloaders need to be updated to also read this property. We want to > avoid requiring to update bootloaders with new hardware identifiers: a > bootloader need only recognize the identifiers it can handle. So the id list will be always expanding list for every last component that is 2nd sourced? The ChromeOS folks are also trying to solve that problem. There's a similar issue for EFI boot with how to select an OS installed DTB[1]. You might not care now, but users may later on (like we have already with QCom devices with fixed bootloaders). If you do this board-id route, then no doubt that compatible values won't be specific enough or have suitable fallbacks to be used. Then EFI boot can't use compatible either and needs to use this QCom specific logic. It may be a common property name, but all the types you defined are QCom specific and the matching logic is pretty much undocumented. I'm not saying we have to use compatible. There wasn't even agreement to use it for EFI boot case. This does need to work for multiple vendors and multiple boot scenarios. Rob [1] https://lore.kernel.org/u-boot/20231114232012.GD6601@bill-the-cat/#r ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-01-24 14:56 ` Rob Herring @ 2024-02-02 5:00 ` Amrit Anand 2024-02-14 12:56 ` Amrit Anand 0 siblings, 1 reply; 29+ messages in thread From: Amrit Anand @ 2024-02-02 5:00 UTC (permalink / raw) To: Rob Herring Cc: krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel Sorry for the spam, earlier mail had some formatting issue. On 1/24/2024 8:26 PM, Rob Herring wrote: > On Sat, Jan 20, 2024 at 04:50:47PM +0530, Amrit Anand wrote: >> Device manufacturers frequently ship multiple boards or SKUs under a >> single software package. These software packages will ship multiple >> devicetree blobs and require some mechanism to pick the correct DTB for >> the board the software package was deployed. Introduce a common >> definition for adding board identifiers to device trees. board-id >> provides a mechanism for bootloaders to select the appropriate DTB which >> is vendor/OEM-agnostic. > Show me a 2nd user. Or does vendor/OEM-agnostic just mean vendors of > QCom devices? Multiple SoC families using this would help your case. I'm > not inclined to take it into the DTSpec without that. Agree; since the DT selection identifiers and algorithm used by various DT users has been largely undocumented, we were trying to reach a generic solution based on our known use-cases. >> Isn't that what the compatible property is for? >> ----------------------------------------------- >> The compatible property can be used for board matching, but requires >> bootloaders and/or firmware to maintain a database of possible strings >> to match against or have complex compatible string matching. Compatible >> string matching becomes complicated when there are multiple versions of >> board: the device tree selector should recognize a DTB that cares to >> distinguish between v1/v2 and a DTB that doesn't make the distinction. >> An eeprom either needs to store the compatible strings that could match >> against the board or the bootloader needs to have vendor-specific >> decoding logic for the compatible string. Neither increasing eeprom >> storage nor adding vendor-specific decoding logic is desirable. > You could hash the compatible strings if it was just a size issue. > >> The solution proposed here is simpler to implement and doesn't require >> updating firmware or bootloader for every new board. >> >> How is this better than Qualcomm's qcom,msm-id/qcom,board-id? >> ------------------------------------------------------------- >> The selection process for devicetrees was Qualcomm-specific and not >> useful for other devices and bootloaders that were not developed by >> Qualcomm because a complex algorithm was used to implement. Board-ids >> provide a matching solution that can be implemented by bootloaders >> without introducing vendor-specific code. Qualcomm uses three >> devicetree properties: msm-id (interchangeably: soc-id), board-id, and >> pmic-id. This does not scale well for use casese which use identifiers, >> for example, to distinguish between a display panel. For a display >> panel, an approach could be to add a new property: display-id, but now >> bootloaders need to be updated to also read this property. We want to >> avoid requiring to update bootloaders with new hardware identifiers: a >> bootloader need only recognize the identifiers it can handle. > So the id list will be always expanding list for every last component > that is 2nd sourced? The ChromeOS folks are also trying to solve that > problem. Agree, this could be an expanding list as and when any new hardware identifiers for DT selection become pertinent in future. > > There's a similar issue for EFI boot with how to select an OS installed > DTB[1]. You might not care now, but users may later on (like we have > already with QCom devices with fixed bootloaders). If you do this > board-id route, then no doubt that compatible values won't be specific > enough or have suitable fallbacks to be used. Then EFI boot can't use > compatible either and needs to use this QCom specific logic. It may be a > common property name, but all the types you defined are QCom specific > and the matching logic is pretty much undocumented. I'm not saying we > have to use compatible. There wasn't even agreement to use it for EFI > boot case. This does need to work for multiple vendors and multiple boot > scenarios. > Agree, given so many hardware identifiers Qcom uses to find the DT based on a best and exact match algorithm, it may not work as is for other vendors/users outside the scope of Qcom. Since we have none to very limited visibility into complete set of DT selection identifiers being used by other users or into their selection algorithms since it is mostly undocumented, designing a perfectly generic solution (one-size-fits-all) could be far-fetched. The number of board files in Qcom DT selection software package often reaches over 100 DT files due to multiple SoCs and board types being supported out of a single software package and these multiple hardware identifiers helps to pick the closest best match DT within a very large pool of DTs. Not to affect other users/vendors who would be using their own set of identifiers and an entirely different algorithm for DT selection, would it make more sense to define these Qcom specific identifiers within Qcom specific bindings (qcom.yaml), along with detailed documentation on our DT selection algorithm? Thanks, Amrit > > Rob > > [1] https://lore.kernel.org/u-boot/20231114232012.GD6601@bill-the-cat/#r ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-02-02 5:00 ` Amrit Anand @ 2024-02-14 12:56 ` Amrit Anand 2024-02-14 13:12 ` Krzysztof Kozlowski 0 siblings, 1 reply; 29+ messages in thread From: Amrit Anand @ 2024-02-14 12:56 UTC (permalink / raw) To: Rob Herring Cc: krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel On 2/2/2024 10:30 AM, Amrit Anand wrote: <snip> >> There's a similar issue for EFI boot with how to select an OS installed >> DTB[1]. You might not care now, but users may later on (like we have >> already with QCom devices with fixed bootloaders). If you do this >> board-id route, then no doubt that compatible values won't be specific >> enough or have suitable fallbacks to be used. Then EFI boot can't use >> compatible either and needs to use this QCom specific logic. It may be a >> common property name, but all the types you defined are QCom specific >> and the matching logic is pretty much undocumented. I'm not saying we >> have to use compatible. There wasn't even agreement to use it for EFI >> boot case. This does need to work for multiple vendors and multiple boot >> scenarios. >> > Agree, given so many hardware identifiers Qcom uses to find the DT > based on a best and exact match algorithm, it may not work as is for > other vendors/users outside the scope of Qcom. > Since we have none to very limited visibility into complete set of DT > selection identifiers being used by other users or into their > selection algorithms since it is mostly undocumented, > designing a perfectly generic solution (one-size-fits-all) could be > far-fetched. The number of board files in Qcom DT selection software > package often reaches over 100 DT files due to multiple SoCs and > board types being supported out of a single software package and these > multiple hardware identifiers helps to pick the closest best match DT > within a very large pool of DTs. > Not to affect other users/vendors who would be using their own set of > identifiers and an entirely different algorithm for DT selection, > would it make more sense to define these Qcom specific > identifiers within Qcom specific bindings (qcom.yaml), along with > detailed documentation on our DT selection algorithm? I have written a patch for defining Qcom specific identifiers within Qcom specific bindings (qcom.yaml) along with documentation on DT selection algorithm, would it be okay to send for review? > > Thanks, > Amrit > >> >> Rob >> >> [1] https://lore.kernel.org/u-boot/20231114232012.GD6601@bill-the-cat/#r ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH 0/2] Add board-id support for multiple DT selection 2024-02-14 12:56 ` Amrit Anand @ 2024-02-14 13:12 ` Krzysztof Kozlowski 0 siblings, 0 replies; 29+ messages in thread From: Krzysztof Kozlowski @ 2024-02-14 13:12 UTC (permalink / raw) To: Amrit Anand, Rob Herring Cc: krzysztof.kozlowski+dt, conor+dt, agross, andersson, konrad.dybcio, devicetree, linux-kernel, linux-arm-msm, kernel On 14/02/2024 13:56, Amrit Anand wrote: > On 2/2/2024 10:30 AM, Amrit Anand wrote: > <snip> >>> There's a similar issue for EFI boot with how to select an OS installed >>> DTB[1]. You might not care now, but users may later on (like we have >>> already with QCom devices with fixed bootloaders). If you do this >>> board-id route, then no doubt that compatible values won't be specific >>> enough or have suitable fallbacks to be used. Then EFI boot can't use >>> compatible either and needs to use this QCom specific logic. It may be a >>> common property name, but all the types you defined are QCom specific >>> and the matching logic is pretty much undocumented. I'm not saying we >>> have to use compatible. There wasn't even agreement to use it for EFI >>> boot case. This does need to work for multiple vendors and multiple boot >>> scenarios. >>> >> Agree, given so many hardware identifiers Qcom uses to find the DT >> based on a best and exact match algorithm, it may not work as is for >> other vendors/users outside the scope of Qcom. >> Since we have none to very limited visibility into complete set of DT >> selection identifiers being used by other users or into their >> selection algorithms since it is mostly undocumented, >> designing a perfectly generic solution (one-size-fits-all) could be >> far-fetched. The number of board files in Qcom DT selection software >> package often reaches over 100 DT files due to multiple SoCs and >> board types being supported out of a single software package and these >> multiple hardware identifiers helps to pick the closest best match DT >> within a very large pool of DTs. >> Not to affect other users/vendors who would be using their own set of >> identifiers and an entirely different algorithm for DT selection, >> would it make more sense to define these Qcom specific >> identifiers within Qcom specific bindings (qcom.yaml), along with >> detailed documentation on our DT selection algorithm? > > > I have written a patch for defining Qcom specific identifiers within > Qcom specific bindings (qcom.yaml) along with documentation on DT > selection algorithm, would it be okay to send for review? New ideas and patches in good-faith are always welcomed for review, so go ahead. What's still missing here is involvement of other SoC vendors: at least their maintainers and mailing lists. Best regards, Krzysztof ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2024-02-14 13:12 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2024-01-20 11:20 [PATCH 0/2] Add board-id support for multiple DT selection Amrit Anand 2024-01-20 11:20 ` [PATCH 1/2] dt-bindings: hwinfo: Introduce board-id Amrit Anand 2024-01-20 12:36 ` Rob Herring 2024-01-20 19:10 ` Trilok Soni 2024-01-22 10:10 ` Amrit Anand 2024-01-23 11:50 ` Krzysztof Kozlowski 2024-01-23 17:18 ` Conor Dooley 2024-01-23 18:51 ` Elliot Berman 2024-01-23 20:05 ` Trilok Soni 2024-01-24 12:44 ` Amrit Anand 2024-01-23 12:09 ` Krzysztof Kozlowski 2024-01-24 12:42 ` Amrit Anand 2024-01-25 10:40 ` Krzysztof Kozlowski 2024-01-24 15:00 ` Rob Herring 2024-01-20 11:20 ` [PATCH 2/2] dt-bindings: hwinfo: Add Qualcomm's board-id types Amrit Anand 2024-01-20 12:36 ` Rob Herring 2024-01-20 13:32 ` Konrad Dybcio 2024-01-22 10:07 ` Amrit Anand 2024-01-22 18:10 ` Elliot Berman 2024-01-22 19:27 ` Dmitry Baryshkov 2024-01-24 12:47 ` Amrit Anand 2024-01-21 2:05 ` kernel test robot 2024-01-22 18:12 ` Elliot Berman 2024-01-20 13:04 ` [PATCH 0/2] Add board-id support for multiple DT selection Konrad Dybcio 2024-01-22 17:50 ` Elliot Berman 2024-01-24 14:56 ` Rob Herring 2024-02-02 5:00 ` Amrit Anand 2024-02-14 12:56 ` Amrit Anand 2024-02-14 13:12 ` Krzysztof Kozlowski
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).