[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a83aaf52-7fa4-d9dc-a058-8bfe387731b4@ti.com>
Date: Thu, 14 Sep 2023 09:35:31 +0530
From: Neha Malcom Francis <n-francis@...com>
To: Nishanth Menon <nm@...com>
CC: Thejasvi Konduru <t-konduru@...com>,
<linux-kernel@...r.kernel.org>,
<linux-arm-kernel@...ts.infradead.org>,
Santosh Shilimkar <ssantosh@...nel.org>,
Tero Kristo <t-kristo@...com>,
Grygorii Strashko <grygorii.strashko@...com>,
Lokesh Vutla <lokeshvutla@...com>,
Apurva Nandan <a-nandan@...com>, Udit Kumar <u-kumar1@...com>
Subject: Re: [PATCH] soc: ti: k3-socinfo: Fix the silicon revision misprint
Hi Nishanth
On 13/09/23 16:58, Nishanth Menon wrote:
> On 12:07-20230912, Neha Malcom Francis wrote:
>
> [...]
>
>>>> +void
>>>> +k3_chipinfo_silicon_rev(unsigned int variant,
>>>> + struct soc_device_attribute *soc_dev_attr)
>>>> +{
>>>> + const char *family_name = soc_dev_attr->family;
>>>> + int j721e_lookup_arr_size = ARRAY_SIZE(soc_revision_j721e);
>>>> +
>>>> + if (!strcmp(family_name, "J721E") && variant < j721e_lookup_arr_size) {
>>>> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s", soc_revision_j721e[variant]);
>>>> + } else {
>>>> + variant++;
>>>> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%x.0", variant);
>>>> + }
>>>
>>> I am not comfortable with if else here. Why not extend k3_soc_id
>>> structure to include the variant LuT? Are there exceptions to this rule
>>> (Say AM65x?), those would make sense to handle with a compare against
>>> the partno?
>>>
>>
>> Trying to revive this patch, I see what you are saying is similar to the way
>> detection has already been implemented in U-Boot (drivers/soc/soc_ti_k3.c)
>> if I'm not mistaken.
>
> Yes.
>
>>
>> But I can't find any existing exception to this "family --> version" rule
>> that forces us to use "partno --> version". Checked through all AM65x device
>> TRMs available in ti.com; all seem to use common partno. So maybe I am not
>> on the same page, did you mean something else?
>
> https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf
> CTRLMMR_WKUP_JTAGID:: VARIANT field: SR2.0: 1h SR1.0: 0h
> Latest data sheet: https://www.ti.com/lit/ds/symlink/am6548.pdf
> indicates SR 2.1
>
> How is this detected?
Detection of the ".x" bit is still a WIP and needs some alignment internally
before I can add that patch. So for now, working on cleaning up the known issues
of the driver.
>
> What I indicated is a LUT table similar to
> https://git.ti.com/cgit/k3conf/k3conf/tree/common/socinfo.c#n382
>
> This allows a switch statement to handle custom SR handling schemes or
> use LUT with variants that use VARIANT field to handle things properly.
>
This makes sense, will work on the patch accordingly. Thanks!
> [...]
--
Thanking You
Neha Malcom Francis
Powered by blists - more mailing lists