Re: [PATCH v8 2/4] i2c: tegra: Add HS mode support

[Jon Hunter <jonathanh@nvidia.com>]

On 18/09/2025 12:16, Akhil R wrote:
> On Thu, 18 Sep 2025 11:21:14 +0100, Jon Hunter wrote:
>> On 18/09/2025 11:04, Akhil R wrote:
>>> On Wed, 17 Sep 2025 14:59:54 +0100, Jon Hunter wrote:
>>>> On 17/09/2025 09:56, Kartik Rajput wrote:
> ...
> ...
> 
>>>> No mention in the changelog about this part. Looks like this is a fallback.
>>>>
>>>> Should all of this be handled in the case statement for t->bus_freq_hz?
>>>>
>>>
>>> HS mode timing parameters are programmed in registers different from the other
>>> speed modes. These registers does not affect the timing in other speed modes.
>>> HS mode registers being used or not is determined by the packet header.
>>>
>>> We may also want to program the regular timing registers, because it will be
>>> used for the master code byte to transition to HS mode.
>>>
>>> So, I guess, even if we move this to the switch statement, we might end up
>>> doing something similar outside it.
>>
>>
>> The 'tlow', 'thigh' and 'tsu_thd' are configured under the case
>> statement and so seems logical to also configure these for HS mode under
>> this too. I see that there are different timing registers for HS mode,
> 
> We are just reusing the variables since the fields are similar. If required,
> we can define separate variables with _hs suffix. Do you suggest it that way?
> 
>> but right now looks like we are programming both the normal ones and HS
>> ones. Do both need to be programmed for HS mode?
> 
> Yes. As mentioned in my previous comment, the normal timing registers will
> be used for the 'master code' byte sent to transition to HS mode. We need
> to program both for HS mode.

OK, I see now. So we need to program the normal timings first and then 
we are re-using the variables to then program the HS timings. And 
because of that we cannot setup the HS timing values in the existing 
case statement?

> So, I am not sure if moving this section to the switch block will add
> any benefit. We might end up making it more complicated that it is now.

Yes that's true. It was really this else part that caught my eye ...

  } else if (t->bus_freq_hz > I2C_MAX_FAST_MODE_PLUS_FREQ) {
   	t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
  }

It feels like at least this part should be handled as part of the case 
statement.

Jon

-- 
nvpublic