[PATCH 1/2] arm64: dts: ti: k3-am62l: add initial infrastructure
Wadim Egorov
w.egorov at phytec.de
Sun Dec 15 20:14:39 PST 2024
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 at ti.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 at ti.com>
>>> Signed-off-by: Bryan Brattlof <bb at ti.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
>
More information about the linux-arm-kernel
mailing list