From: Judith Mendez <jm@ti.com>
To: Tom Rini <trini@konsulko.com>
Cc: Peng Fan <peng.fan@nxp.com>,
Jaehoon Chung <jh80.chung@samsung.com>,
Bryan Brattlof <bb@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>,
<u-boot@lists.denx.de>
Subject: Re: [PATCH v2 1/2] soc: soc_ti_k3: Add support for AM62P variants
Date: Wed, 6 Aug 2025 11:13:50 -0500 [thread overview]
Message-ID: <d075fa39-8d99-45fa-b0d2-403f7dac371c@ti.com> (raw)
In-Reply-To: <20250806154915.GP124814@bill-the-cat>
Hi Tom,
On 8/6/25 10:49 AM, Tom Rini wrote:
> On Wed, Aug 06, 2025 at 10:45:29AM -0500, Judith Mendez wrote:
>> Hi Tom,
>>
>> On 8/5/25 5:39 PM, Tom Rini wrote:
>>> On Tue, Aug 05, 2025 at 11:14:18AM -0500, 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 register instead
>>>> of JTAGID register, so introduce GP_SW register range to determine SoC
>>>> revision for AM62P.
>>>>
>>>> Signed-off-by: Judith Mendez <jm@ti.com>
>>>> ---
>>>> drivers/soc/soc_ti_k3.c | 70 ++++++++++++++++++++++++++++++++++++++---
>>>> 1 file changed, 65 insertions(+), 5 deletions(-)
>>> [snip]
>>>> @@ -130,17 +184,23 @@ static const struct soc_ops soc_ti_k3_ops = {
>>>> int soc_ti_k3_probe(struct udevice *dev)
>>>> {
>>>> struct soc_ti_k3_plat *plat = dev_get_plat(dev);
>>>> - u32 idreg;
>>>> + u32 gp_sw1_val = 0;
>>>> void *idreg_addr;
>>>> + u32 idreg;
>>>> - idreg_addr = dev_read_addr_ptr(dev);
>>>> + idreg_addr = dev_read_addr_index_ptr(dev, 0);
>>>> if (!idreg_addr)
>>>> return -EINVAL;
>>>> idreg = readl(idreg_addr);
>>>> +#if IS_ENABLED(CONFIG_SOC_K3_AM62P5)
>>>> + if (soc_ti_k3_variant_in_gp_sw(idreg))
>>>> + gp_sw1_val = soc_ti_k3_get_variant_alternate(dev, idreg);
>>>> +#endif /* CONFIG_SOC_K3_AM62P5 */
>>>
>>> This isn't quite what I meant, as it will generate warnings about unused
>>> variables for the tables, on other platforms, yes? What I was thinking
>>> was:
>>> if (IS_ENABLED(CONFIG_SOC_K3_AM62P5) && soc_ti_k3_variant_in_gp_sw(idreg))
>>> gp_sw1_val = soc_ti_k3_get_variant_alternate(dev, idreg);
>>> which shouldn't. And then can we check the other platforms similarly to
>>> save space or no? Or am I unclear with what I'm thinking (or it's not
>>> possible, I didn't dig at the rest of the code much)? Thanks.
>>>
>>
>> It is not very clear, but let me clarify:soc_ti_k3_get_variant_alternate
>> should only get called for AM62P and get_rev_string should get called
>> for all SoCs.
>>
>> So it only makes sense to do this then:
>>
>> if (IS_ENABLED(CONFIG_SOC_K3_AM62P5) && soc_ti_k3_variant_in_gp_sw(idreg))
>> gp_sw1_val = soc_ti_k3_get_variant_alternate(dev, idreg);
>>
>> plat->revision = get_rev_string(idreg, gp_sw1_val);
>
> Right, then the linker should normally be able to discard all of the
> am62p5 stuff on non-am62p5 platforms. Looking at the driver more now,
> OK, there's not anything we can save on the other cases that I was
> thinking about.
>
Understood, then will respin with the following change:
if (IS_ENABLED(CONFIG_SOC_K3_AM62P5) && soc_ti_k3_variant_in_gp_sw(idreg))
gp_sw1_val = soc_ti_k3_get_variant_alternate(dev, idreg);
plat->revision = get_rev_string(idreg, gp_sw1_val);
Thanks for reviewing (:
~ Judith
next prev parent reply other threads:[~2025-08-06 16:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-05 16:14 [PATCH v2 0/2] Add support for AM62P SR1.2 Judith Mendez
2025-08-05 16:14 ` [PATCH v2 1/2] soc: soc_ti_k3: Add support for AM62P variants Judith Mendez
2025-08-05 22:39 ` Tom Rini
2025-08-06 15:45 ` Judith Mendez
2025-08-06 15:49 ` Tom Rini
2025-08-06 16:13 ` Judith Mendez [this message]
2025-08-05 16:14 ` [PATCH v2 2/2] mmc: am654_sdhci: Disable HS400 for AM62P SR1.0 and SR1.1 Judith Mendez
2025-08-07 23:14 ` [PATCH v2 0/2] Add support for AM62P SR1.2 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=d075fa39-8d99-45fa-b0d2-403f7dac371c@ti.com \
--to=jm@ti.com \
--cc=bb@ti.com \
--cc=jh80.chung@samsung.com \
--cc=peng.fan@nxp.com \
--cc=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=vigneshr@ti.com \
/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