Message-ID: <8b3ed680-bc14-42a3-92d2-2167213954a5@phytec.de>
Date: Mon, 16 Dec 2024 05:14:39 +0100
From: Wadim Egorov <w.egorov@...tec.de>
To: Bryan Brattlof <bb@...com>, Francesco Dolcini <francesco@...cini.it>
Cc: Nishanth Menon <nm@...com>, Vignesh Raghavendra <vigneshr@...com>,
 Tero Kristo <kristo@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, linux-arm-kernel@...ts.infradead.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: ti: k3-am62l: add initial infrastructure

Am 14.12.24 um 22:56 schrieb Bryan Brattlof:
> On December 14, 2024 thus sayeth Francesco Dolcini:
>> On Sun, Nov 17, 2024 at 11:34:07PM -0600, Bryan Brattlof wrote:
>>> From: Vignesh Raghavendra <vigneshr@...com>
>>>
>>> Add the initial infrastructure needed for the AM62L. All of which can be
>>> found in the Technical Reference Manual (TRM) located here:
>>>
>>>      https://www.ti.com/lit/ug/sprujb4/sprujb4.pdf
>>>
>>> Signed-off-by: Vignesh Raghavendra <vigneshr@...com>
>>> Signed-off-by: Bryan Brattlof <bb@...com>
>>> ---
>>>   Documentation/devicetree/bindings/arm/ti/k3.yaml |  6 ++
>>>   arch/arm64/boot/dts/ti/Makefile                  |  3 +
>>>   arch/arm64/boot/dts/ti/k3-am62l-main.dtsi        | 52 ++++++++++++++
>>>   arch/arm64/boot/dts/ti/k3-am62l-wakeup.dtsi      | 33 +++++++++
>>>   arch/arm64/boot/dts/ti/k3-am62l.dtsi             | 89 ++++++++++++++++++++++++
>>>   arch/arm64/boot/dts/ti/k3-am62l3.dtsi            | 67 ++++++++++++++++++
>>>   arch/arm64/boot/dts/ti/k3-pinctrl.h              |  2 +
>>>   7 files changed, 252 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
>>> index 18f155cd06c84..b109e854879cb 100644
>>> --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
>>> +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
>>> @@ -31,6 +31,12 @@ properties:
>>>             - const: phytec,am62a-phycore-som
>>>             - const: ti,am62a7
>>>   
>>> +      - description: K3 AM62L3 SoC and Boards
>>> +        items:
>>> +          - enum:
>>> +              - ti,am62l3-evm
>>> +          - const: ti,am62l3
>>> +
>>
>> can you clarify the differences between AM62L and AM62L3? you have a mix of names in this series. I assume that
>> AM62L is the SOC family / product name, while AM62L3 is a specific
>> part number.
>>
> 
> Absolutely! I found the naming a bit confusing myself.
> 
> We (the baseport teams) have kinda coalesced into using less digits as a
> way to describe all devices included in the subgroup. So for example AM6
> would be all Sitara class MPUs in the K3 generation. AM62L would be all
> parts in K3 in the 'lite' derivative. AM62L32 would be all AM62L parts
> with display and dual cores.
> 
> But I should probably decode everything as these part numbers are really
> opaque in my eye if you don't see them every day.
> 
> The full orderable part number for this part is the XAM62L32AOGHAANB
> 
>      'X' is the production status. If you see an 'X' here it just means
>      it's a pre-production sample that hasn't gone through validation.
>      Most of the time (outside of TI) this will be blank
> 
>      'AM' is the prefix which indicates a Sitara class of SoC. The AM68
>      and AM69 being originally a Jacinto class part kinda makes this more
>      confusing but back in the day i think it used to stand for ARM
>      Microprocessors so that's what I've been telling people.
> 
>      '62' is the generation and family of the part. So this example the 6
>      indicates the K3 generation of SoCs and the 2 means it's an MPU
>      family with 2k display or 2k camera support among other things.
> 
>      'L' is the derivative of the family. This is mostly a marketing
>      thing to indicate the target market for the SoC:
> 
>        AM62  (or blank) would be the general base class
>        AM62A is for the analytics derivative
>        AM62D is for DSP
>        AM62P is for Plus
>        AM62L is for Lite
> 
>      '3' is the configuration. This really depends on what the business
>      teams find feasible. Some of the family/derivative combinations
>      don't make sense to have. For example an AM62L9 which would just be
>      the base AM62 derivative, so some configurations may not exist.
> 
>        0 = No Display / No ISP
>        1 = No Display with ISP
>        2 = No Display with ISP and Analytics
>        3 = Display / No ISP
>        4 = Display / No ISP with Analytics
>        5 = Display / No ISP with GPU
>        6 = Display with ISP
>        7 = Display with ISP and Analytics
>        8 = Display with ISP and GPU
>        9 = includes everything
> 
>      '2' is the core count. AM62L32 would be the dual core option.
> 
> The rest of the digits get into stuff we try to do automatically via our
> bootloaders so you wont see any mention of them in Linux, but I kinda
> wanted to continue decoding this :)
> 
>      'A' is the silicon revision. A = SR 1.0
> 
>      'O' is the speed grade. (there is a table somewhere with all the
>      speed grades we support. The two I know about are.
> 
>        O = 1.25GHz
>        E = 833MHz
> 
>      'G' is the feature set. Because the derivative is 'L' (or lite) we
>      probably won't have options other than G which is the baseline
> 
>      'H' is the security & functional safety value
> 
>        'G' is non secure no functional safety. (like the beagleplay)
>        '1-9' are dummy key devices with no functional safety
>        'H-R' are production key HS devices with no function safety
>        'S-Z' are production key HS devices with function safety
>          
> 'H-Z' is probably the most common security you will see TI make now.
> There are ways (by talking to sales) you can purchase other variants for
> special use cases (like aviation) but I think these are all special use
> cases with unique regulatory or security issues.
> 
>      'A' is the temperature rating
>       
>        'A' = -40C to 105C
>        'I' = -40C to 125C
> 
>      'ANB' is the package: 11.9mm x 11.9mm with 0.5 BGA
> 
> There can be a total of 18 digits which can vary when decoding the
> family (AM65, AM64) but generally this decoding scheme will hold. I only
> really see those weird parts with our vertically integrated customers
> with their own sales teams.
> 
> Sorry for the essay. I went though our catalog one day and had the very
> same question you did so I wanted to dump as much as I could.

Thank you for this write up! Will save this mail for future reference.



> 
> ~Bryan
> 

Powered by blists - more mailing lists