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?
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.
[...]