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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxx>
>>>
>>> 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




[Index of Archives]     [ARM Kernel]     [Linux ARM]     [Linux ARM MSM]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux