linux-kernel - Re: [PATCH v8 2/4] i2c: tegra: Add HS mode 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: <af2462af-5b6e-4eb1-b1a3-59ec5f96f1d6@nvidia.com>
Date: Thu, 18 Sep 2025 11:21: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, kkartik@...dia.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
Subject: Re: [PATCH v8 2/4] i2c: tegra: Add HS mode support


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:
>>> From: Akhil R <akhilrajeev@...dia.com>
>>>
>>> Add support for HS (High Speed) mode transfers, which is supported by
>>> Tegra194 onwards.
>>>
>>> Signed-off-by: Akhil R <akhilrajeev@...dia.com>
>>> Signed-off-by: Kartik Rajput <kkartik@...dia.com>
>>> ---
>>> v3 -> v5:
>>> 	* Set has_hs_mode_support to false for unsupported SoCs.
>>> v2 -> v3:
>>> 	* Document tlow_hs_mode and thigh_hs_mode.
>>> v1 -> v2:
>>> 	* Document has_hs_mode_support.
>>> 	* Add a check to set the frequency to fastmode+ if the device
>>> 	  does not support HS mode but the requested frequency is more
>>> 	  than fastmode+.
>>> ---
>>>    drivers/i2c/busses/i2c-tegra.c | 33 +++++++++++++++++++++++++++++++++
>>>    1 file changed, 33 insertions(+)
>>>
>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>> index d908e5e3f0af..6f816de8b3af 100644
>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>> @@ -91,6 +91,7 @@
>>>    #define I2C_HEADER_IE_ENABLE			BIT(17)
>>>    #define I2C_HEADER_REPEAT_START			BIT(16)
>>>    #define I2C_HEADER_CONTINUE_XFER		BIT(15)
>>> +#define I2C_HEADER_HS_MODE			BIT(22)
>>>    #define I2C_HEADER_SLAVE_ADDR_SHIFT		1
>>>    
>>>    #define I2C_BUS_CLEAR_CNFG			0x084
>>> @@ -198,6 +199,8 @@ enum msg_end_type {
>>>     * @thigh_std_mode: High period of the clock in standard mode.
>>>     * @tlow_fast_fastplus_mode: Low period of the clock in fast/fast-plus modes.
>>>     * @thigh_fast_fastplus_mode: High period of the clock in fast/fast-plus modes.
>>> + * @tlow_hs_mode: Low period of the clock in HS mode.
>>> + * @thigh_hs_mode: High period of the clock in HS mode.
>>>     * @setup_hold_time_std_mode: Setup and hold time for start and stop conditions
>>>     *		in standard mode.
>>>     * @setup_hold_time_fast_fast_plus_mode: Setup and hold time for start and stop
>>> @@ -206,6 +209,7 @@ enum msg_end_type {
>>>     *		in HS mode.
>>>     * @has_interface_timing_reg: Has interface timing register to program the tuned
>>>     *		timing settings.
>>> + * @has_hs_mode_support: Has support for high speed (HS) mode transfers.
>>>     */
>>>    struct tegra_i2c_hw_feature {
>>>    	bool has_continue_xfer_support;
>>> @@ -226,10 +230,13 @@ struct tegra_i2c_hw_feature {
>>>    	u32 thigh_std_mode;
>>>    	u32 tlow_fast_fastplus_mode;
>>>    	u32 thigh_fast_fastplus_mode;
>>> +	u32 tlow_hs_mode;
>>> +	u32 thigh_hs_mode;
>>>    	u32 setup_hold_time_std_mode;
>>>    	u32 setup_hold_time_fast_fast_plus_mode;
>>>    	u32 setup_hold_time_hs_mode;
>>>    	bool has_interface_timing_reg;
>>> +	bool has_hs_mode_support;
>>>    };
>>>    
>>>    /**
>>> @@ -717,6 +724,20 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
>>>    	if (i2c_dev->hw->has_interface_timing_reg && tsu_thd)
>>>    		i2c_writel(i2c_dev, tsu_thd, I2C_INTERFACE_TIMING_1);
>>>    
>>> +	/* Write HS mode registers. These will get used only for HS mode*/
>>> +	if (i2c_dev->hw->has_hs_mode_support) {
>>> +		tlow = i2c_dev->hw->tlow_hs_mode;
>>> +		thigh = i2c_dev->hw->thigh_hs_mode;
>>> +		tsu_thd = i2c_dev->hw->setup_hold_time_hs_mode;
>>> +
>>> +		val = FIELD_PREP(I2C_HS_INTERFACE_TIMING_THIGH, thigh) |
>>> +			FIELD_PREP(I2C_HS_INTERFACE_TIMING_TLOW, tlow);
>>> +		i2c_writel(i2c_dev, val, I2C_HS_INTERFACE_TIMING_0);
>>> +		i2c_writel(i2c_dev, tsu_thd, I2C_HS_INTERFACE_TIMING_1);
>>> +	} else if (t->bus_freq_hz > I2C_MAX_FAST_MODE_PLUS_FREQ) {
>>> +		t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
>>
>> 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, 
but right now looks like we are programming both the normal ones and HS 
ones. Do both need to be programmed for HS mode?

Jon

-- 
nvpublic