From: Judith Mendez <jm@ti.com>
To: Andrew Davis <afd@ti.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Ulf Hansson <ulf.hansson@linaro.org>, Nishanth Menon <nm@ti.com>,
Santosh Shilimkar <ssantosh@kernel.org>
Cc: <linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 1/2] soc: ti: k3-socinfo: Add support for AM62P variants
Date: Fri, 8 Aug 2025 09:51:43 -0500 [thread overview]
Message-ID: <4fdd0d2a-dbbc-43bb-9a31-18f5f1da3193@ti.com> (raw)
In-Reply-To: <bac04814-ed8a-4dad-b5a3-72d0a2fc5d76@ti.com>
Hi Andrew,
On 8/8/25 8:50 AM, Andrew Davis wrote:
> On 8/7/25 5:51 PM, Judith Mendez wrote:
>> This adds a support for detecting AM62P SR1.0, SR1.1, SR1.2.
>>
>> On AM62P, silicon revision is discovered with GP_SW1 instead of JTAGID
>> register, so read GP_SW1 to determine SoC revision only on AM62P.
>>
>> Signed-off-by: Judith Mendez <jm@ti.com>
>> ---
>> drivers/soc/ti/k3-socinfo.c | 27 +++++++++++++++++++++++++--
>> 1 file changed, 25 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/soc/ti/k3-socinfo.c b/drivers/soc/ti/k3-socinfo.c
>> index d716be113c84..81d078f15cd2 100644
>> --- a/drivers/soc/ti/k3-socinfo.c
>> +++ b/drivers/soc/ti/k3-socinfo.c
>> @@ -15,6 +15,9 @@
>> #include <linux/sys_soc.h>
>> #define CTRLMMR_WKUP_JTAGID_REG 0
>> +#define CTRLMMR_WKUP_GP_SW1_OFFSET 544
>> +#define GP_SW1_MOD_OPR 16
>> +
>> /*
>> * Bits:
>> * 31-28 VARIANT Device variant
>> @@ -66,6 +69,10 @@ static const char * const j721e_rev_string_map[] = {
>> "1.0", "1.1", "2.0",
>> };
>> +static const char * const am62p_gpsw_rev_string_map[] = {
>> + "1.0", "1.1", "1.2",
>> +};
>> +
>> static int
>> k3_chipinfo_partno_to_names(unsigned int partno,
>> struct soc_device_attribute *soc_dev_attr)
>> @@ -83,7 +90,7 @@ k3_chipinfo_partno_to_names(unsigned int partno,
>> static int
>> k3_chipinfo_variant_to_sr(unsigned int partno, unsigned int variant,
>> - struct soc_device_attribute *soc_dev_attr)
>> + struct soc_device_attribute *soc_dev_attr, u32 gp_sw1)
>> {
>> switch (partno) {
>> case JTAG_ID_PARTNO_J721E:
>> @@ -92,6 +99,14 @@ k3_chipinfo_variant_to_sr(unsigned int partno,
>> unsigned int variant,
>> soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s",
>> j721e_rev_string_map[variant]);
>> break;
>> + case JTAG_ID_PARTNO_AM62PX:
>> + /* Always parse AM62P variant from GP_SW1 */
>> + variant = gp_sw1 % GP_SW1_MOD_OPR;
>> + if (variant >= ARRAY_SIZE(am62p_gpsw_rev_string_map))
>> + goto err_unknown_variant;
>> + soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%s",
>> + am62p_gpsw_rev_string_map[variant]);
>> + break;
>> default:
>> variant++;
>> soc_dev_attr->revision = kasprintf(GFP_KERNEL, "SR%x.0",
>> @@ -121,6 +136,7 @@ static int k3_chipinfo_probe(struct
>> platform_device *pdev)
>> struct soc_device *soc_dev;
>> struct regmap *regmap;
>> void __iomem *base;
>> + u32 gp_sw1_val = 0;
>> u32 partno_id;
>> u32 variant;
>> u32 jtag_id;
>> @@ -163,7 +179,14 @@ static int k3_chipinfo_probe(struct
>> platform_device *pdev)
>> goto err;
>> }
>> - ret = k3_chipinfo_variant_to_sr(partno_id, variant, soc_dev_attr);
>> + if (partno_id == JTAG_ID_PARTNO_AM62PX) {
>> + ret = regmap_read(regmap, CTRLMMR_WKUP_JTAGID_REG +
>> + CTRLMMR_WKUP_GP_SW1_OFFSET, &gp_sw1_val);
>
> This is wrong, you cannot read from the register GP_SW1 (offset 544). In DT
> the region is 4 bytes long (reg = <0x14 0x4>;).
>
> This only worked in your testing because the above ioremap_resource()
> has to
> map in page sized(4K) chunks and we didn't set max_register in our
> regmap_config
> so no bounds checking is done. If we fix either of the above then this read
> will stop working.
>
> So yes you'll have to make DT changes and fight it out with Krzysztof. My
> suggestion is to make a efuse region for the 3 GPSW registers and use a
> phandle from this node to fetch the extra info you need to get revision.
Sure I also believe that is the correct implementation and is actually
the way I approached the issue in v1.
But it seems like Krzysztof will not take that implementation [0]
https://lore.kernel.org/linux-mmc/736f09e0-075a-48e0-9b32-6b8805a7ee2a@kernel.org/
so what to do then....
~ Judith
next prev parent reply other threads:[~2025-08-08 14:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-07 22:51 [PATCH v2 0/2] Add support for AM62P SR1.2 Judith Mendez
2025-08-07 22:51 ` [PATCH v2 1/2] soc: ti: k3-socinfo: Add support for AM62P variants Judith Mendez
2025-08-08 13:50 ` Andrew Davis
2025-08-08 14:51 ` Judith Mendez [this message]
2025-08-07 22:51 ` [PATCH v2 2/2] mmc: sdhci_am654: Disable HS400 for AM62P SR1.0 and SR1.1 Judith Mendez
2025-08-08 13:38 ` Judith Mendez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4fdd0d2a-dbbc-43bb-9a31-18f5f1da3193@ti.com \
--to=jm@ti.com \
--cc=adrian.hunter@intel.com \
--cc=afd@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=nm@ti.com \
--cc=ssantosh@kernel.org \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox