| Message ID | 20230331163159.17145-1-thierry.reding@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] dt-bindings: Document additional Jetson Orin NX SKUs | expand |
On 31/03/2023 18:31, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > Beyond the original 16 GiB SKU (0), additional SKUs exist, such as the 8 > GiB SKU (1) and an internal-only SKU (2) that comes with an equipeed SD typo: equipped > card slot. Is there a point in documenting all of them if there is no DTS? Also, size of storage (eMMC?) pretty often is runtime-detectable, so you do no need a new DTS and new compatible. Best regards, Krzysztof
On Fri, Mar 31, 2023 at 10:19:00PM +0200, Krzysztof Kozlowski wrote: > On 31/03/2023 18:31, Thierry Reding wrote: > > From: Thierry Reding <treding@nvidia.com> > > > > Beyond the original 16 GiB SKU (0), additional SKUs exist, such as the 8 > > GiB SKU (1) and an internal-only SKU (2) that comes with an equipeed SD > > typo: equipped > > > card slot. > > Is there a point in documenting all of them if there is no DTS? Also, > size of storage (eMMC?) pretty often is runtime-detectable, so you do no > need a new DTS and new compatible. This is for the sake of completeness since these compatible strings correspond to the part numbers that will show up on stickers on these modules. In practice, yes, most of the differences will be runtime- detected and the DT updated to reflect the SKU differences by UEFI. As far as I know, UEFI doesn't actually do anything with the compatible strings themselves, but that's potentially something that could happen at some point. The SKU numbers also show up in EEPROMs, so I think having one place where these are documented might be helpful to people. The 16 GiB in this case is actually DRAM, but it's also detected at runtime. We don't actually plan on upstreaming DTS files for all of these, since we don't expect all SKUs to be widely used (the internal one, for example) so we should be able to cover pretty much all variants with just two DTS files. Thierry
On 04/04/2023 12:49, Thierry Reding wrote: > On Fri, Mar 31, 2023 at 10:19:00PM +0200, Krzysztof Kozlowski wrote: >> On 31/03/2023 18:31, Thierry Reding wrote: >>> From: Thierry Reding <treding@nvidia.com> >>> >>> Beyond the original 16 GiB SKU (0), additional SKUs exist, such as the 8 >>> GiB SKU (1) and an internal-only SKU (2) that comes with an equipeed SD >> >> typo: equipped >> >>> card slot. >> >> Is there a point in documenting all of them if there is no DTS? Also, >> size of storage (eMMC?) pretty often is runtime-detectable, so you do no >> need a new DTS and new compatible. > > This is for the sake of completeness since these compatible strings > correspond to the part numbers that will show up on stickers on these > modules. In practice, yes, most of the differences will be runtime- > detected and the DT updated to reflect the SKU differences by UEFI. Just because there is some sticker, it does not mean we need a compatible. We actually omit dozen of versions per device - all PMICs, I2C IIO and others have some packaging bins and revision numbers. Although here if I understand correctly, UEFI firmware will add these compatibles? > > As far as I know, UEFI doesn't actually do anything with the compatible > strings themselves, but that's potentially something that could happen > at some point. The SKU numbers also show up in EEPROMs, so I think > having one place where these are documented might be helpful to people. Just like bins, revision numbers etc, the DT would be overwhelmed if we decided to document all this just because it exists somewhere. > > The 16 GiB in this case is actually DRAM, but it's also detected at > runtime. Which in many cases is filled by bootloader (/memory node) and we do not create any new compatibles. > We don't actually plan on upstreaming DTS files for all of > these, since we don't expect all SKUs to be widely used (the internal > one, for example) so we should be able to cover pretty much all variants > with just two DTS files. That's one more argument of not having these compatibles at all. Best regards, Krzysztof
On Fri, Apr 07, 2023 at 10:52:58AM +0200, Krzysztof Kozlowski wrote: > On 04/04/2023 12:49, Thierry Reding wrote: > > On Fri, Mar 31, 2023 at 10:19:00PM +0200, Krzysztof Kozlowski wrote: > >> On 31/03/2023 18:31, Thierry Reding wrote: > >>> From: Thierry Reding <treding@nvidia.com> > >>> > >>> Beyond the original 16 GiB SKU (0), additional SKUs exist, such as the 8 > >>> GiB SKU (1) and an internal-only SKU (2) that comes with an equipeed SD > >> > >> typo: equipped > >> > >>> card slot. > >> > >> Is there a point in documenting all of them if there is no DTS? Also, > >> size of storage (eMMC?) pretty often is runtime-detectable, so you do no > >> need a new DTS and new compatible. > > > > This is for the sake of completeness since these compatible strings > > correspond to the part numbers that will show up on stickers on these > > modules. In practice, yes, most of the differences will be runtime- > > detected and the DT updated to reflect the SKU differences by UEFI. > > Just because there is some sticker, it does not mean we need a > compatible. We actually omit dozen of versions per device - all PMICs, > I2C IIO and others have some packaging bins and revision numbers. > > Although here if I understand correctly, UEFI firmware will add these > compatibles? That's the idea. UEFI does some probing of the hardware and currently writes information about the detected SKUs into the /chosen node. I think we could achieve the same effect in a more standard way by writing out the compatible strings instead. So while we likely won't have these compatible strings in the DTS files, we may very well end up having these in the DTB that is passed to the kernel. So we don't need these to be documented for validation within the kernel repository, but I'm concerned it could lead to confusion if people end up with undocumented compatible strings in the DTB. Perhaps that's not as big a deal as I think it is, so I'll drop this for now. We'll go with the "standard" SKU compatible strings for now and can revisit if this becomes an actual problem. Sorry for the delay, I hadn't seen your replies before. Thierry
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml index aa71236f93ce..61e638c9cad7 100644 --- a/Documentation/devicetree/bindings/arm/tegra.yaml +++ b/Documentation/devicetree/bindings/arm/tegra.yaml @@ -215,7 +215,10 @@ properties: - const: nvidia,tegra234 - description: Jetson Orin NX items: - - const: nvidia,p3767-0000 + - enum: + - nvidia,p3767-0000 + - nvidia,p3767-0001 + - nvidia,p3767-0002 - const: nvidia,tegra234 - description: Jetson Orin NX Engineering Reference Developer Kit items: