linux-kernel - Re: [PATCH RESEND 2/2] i2c: tegra: Add Tegra256 support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f954b162-f9bc-4693-92a5-8ac73b3a788e@nvidia.com>
Date: Wed, 8 Oct 2025 10:52:14 +0100
From: Jon Hunter <jonathanh@...dia.com>
To: Akhil R <akhilrajeev@...dia.com>
Cc: andi.shyti@...nel.org, conor+dt@...nel.org, devicetree@...r.kernel.org,
 digetx@...il.com, krzk+dt@...nel.org, ldewangan@...dia.com,
 linux-i2c@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-tegra@...r.kernel.org, robh@...nel.org, thierry.reding@...il.com,
 treding@...dia.com
Subject: Re: [PATCH RESEND 2/2] i2c: tegra: Add Tegra256 support


On 08/10/2025 10:33, Jon Hunter wrote:
> Hi Akhil,
> 
> On 08/10/2025 06:35, Akhil R wrote:
>> Hi Jon,
>>
>> On Tue, 7 Oct 2025 15:50:56 +0100, Jon Hunter wrote:
>>> On 18/08/2025 05:33, Akhil R wrote:
>>>> Add compatible and the hardware struct for Tegra256. Tegra256 
>>>> controllers
>>>> use a different parent clock. Hence the timing parameters are different
>>>> from the previous generations to meet the expected frequencies.
>>>>
>>>> Signed-off-by: Akhil R <akhilrajeev@...dia.com>
>>>> Acked-by: Thierry Reding <treding@...dia.com>
>>>>
>>>> ---
>>>>    drivers/i2c/busses/i2c-tegra.c | 26 ++++++++++++++++++++++++++
>>>>    1 file changed, 26 insertions(+)
>>>>
>>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/ 
>>>> i2c-tegra.c
>>>> index 4eb31b913c1a..e533460bccc3 100644
>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>> @@ -1649,7 +1649,33 @@ static const struct tegra_i2c_hw_feature 
>>>> tegra194_i2c_hw = {
>>>>         .has_interface_timing_reg = true,
>>>>    };
>>>> +static const struct tegra_i2c_hw_feature tegra256_i2c_hw = {
>>>> +     .has_continue_xfer_support = true,
>>>> +     .has_per_pkt_xfer_complete_irq = true,
>>>> +     .clk_divisor_hs_mode = 7,
>>>> +     .clk_divisor_std_mode = 0x7a,
>>>> +     .clk_divisor_fast_mode = 0x40,
>>>> +     .clk_divisor_fast_plus_mode = 0x19,
>>>
>>>
>>> Can you check this divisor value? I see we have been using a value of
>>> 0x14 for this which does not align with what we have here. Can you
>>> confirm if this should be 0x19 or 0x14?
>>
>> If you happen to notice, we are using a different tlow, thigh and hold
>> time values as well internally. We are also using separate variables
>> (tlow, thigh) for fast and fastplus modes, whereas this driver currently
>> uses the same variable (and value) for both fast and fastplus mode. With
>> that limitation, these are the closest timing values we can use now to
>> get the required frequency.
> 
> Yes I did see that we have been re-working these variables and separated 
> some of the variables. However, this parameter itself has not changed 
> and now we have a different value in upstream. So regardless of the 
> changes being planned, I don't see why we are not using the same value 
> for this variable everywhere.

Or are you saying that this divisor value is correct per the other 
settings we have here? And when we push the other changes to separate 
the settings for fast mode and fast plus mode, we will then update this 
accordingly? If so, then that is fine.

Jon

-- 
nvpublic