[1/4] dt-bindings: Document additional Jetson Orin NX SKUs

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
card slot.

Signed-off-by: Thierry Reding <treding@nvidia.com>
---
 Documentation/devicetree/bindings/arm/tegra.yaml | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

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 04/04/2023 12:59, Thierry Reding wrote:
> On Fri, Mar 31, 2023 at 10:20:16PM +0200, Krzysztof Kozlowski wrote:
>> On 31/03/2023 18:31, Thierry Reding wrote:
>>> From: Thierry Reding <treding@nvidia.com>
>>>
>>> The Jetson Orin Nano is the little sibling of the Jetson Orin NX.
>>> Document the corresponding compatible strings for these devices.
>>>
>>> Signed-off-by: Thierry Reding <treding@nvidia.com>
>>> ---
>>>  Documentation/devicetree/bindings/arm/tegra.yaml | 7 +++++++
>>>  1 file changed, 7 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
>>> index 61e638c9cad7..60c151da5e06 100644
>>> --- a/Documentation/devicetree/bindings/arm/tegra.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
>>> @@ -220,6 +220,13 @@ properties:
>>>                - nvidia,p3767-0001
>>>                - nvidia,p3767-0002
>>>            - const: nvidia,tegra234
>>> +      - description: Jetson Orin Nano
>>> +        items:
>>> +          - enum:
>>> +              - nvidia,p3767-0003
>>> +              - nvidia,p3767-0004
>>> +              - nvidia,p3767-0005
>>
>> Similar questions as for patch #1. Where are the DTSes? Where are the
>> differences? If we keep documenting every SKU which is the same from
>> user/OS perspective, this list would grow crazy.
> 
> Most of the differences will be user-noticeable, even if they can be
> runtime detected. Besides the mentioned differences in DRAM size, things
> like the number of CPUs, 

You need different DTS for different number of CPUs. It's not the case
we talk here.

> GPU compute units or video encoders/decoders

I would argue that for these as well you will have different DTS.

> can vary depending on the SKU. While the OS should certainly be able to
> abstract all of that away as best as possible, on user may still end up
> with SKU 3 and another with SKU 5 and it's important for people to know
> what they have.

Depends. They know what do they have. If the DTS is the same, then it is
apparently not important to know what do they have because it is all
"the same" (in a compatible meaning).

> 
> So I think we have to find a way to both keep things simple from a DTS
> point of view (as I said, we should be able to make do with one DTS file
> for the Jetson Orin NX and one for the Jetson Orin Nano with UEFI taking
> care of fixing up the DTS per SKU), and not lying to users. If users get
> a SKU 3, then that's what we should report instead of 3 (or whatever
> ends up being the SKU that we use in the DTS).
> 
> So I want to be as complete as possible in documenting these so that
> when people go look for the part numbers, they can at least find some
> reference to them.

To Chromium guys I need to spend effort to ask to document at least
something, as they claim any board compatible bindings are useless for
them. It's one border case.

Here, I need to bring it to the middle from another side and border case
- documenting many unneeded compatibles which do not exist in DTS.

It would be much easier if you folks get together and exchange
arguments, not through me. :)

Let me be clear then for this case:
We do not document compatibles for stuff somewhere out-of-tree, just
because it is there or you want it to be there. We document the stuff in
the kernel or other SW projects.

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