U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
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



  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