[PATCH v8 0/4] Add I2C support for Tegra264

[PATCH v8 0/4] Add I2C support for Tegra264

[Kartik Rajput]

Following series of patches add support for Tegra264 and High Speed (HS)
Mode in i2c-tegra.c driver.

Akhil R (2):
  i2c: tegra: Add HS mode support
  i2c: tegra: Add Tegra264 support

Kartik Rajput (2):
  i2c: tegra: Do not configure DMA if not supported
  i2c: tegra: Add support for SW mutex register

 drivers/i2c/busses/i2c-tegra.c | 159 +++++++++++++++++++++++++++++++++
 1 file changed, 159 insertions(+)

-- 
2.43.0

[PATCH v8 1/4] i2c: tegra: Do not configure DMA if not supported

[Kartik Rajput]

On Tegra264, not all I2C controllers have the necessary interface to
GPC DMA, this causes failures when function tegra_i2c_init_dma()
is called.

Ensure that "dmas" device-tree property is present before initializing
DMA in function tegra_i2c_init_dma().

Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
v2 -> v4:
	* Add debug print if DMA is not supported by the I2C controller.
v1 -> v2:
	* Update commit message to clarify that some I2C controllers may
	  not have the necessary interface to GPC DMA.
---
 drivers/i2c/busses/i2c-tegra.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index e533460bccc3..d908e5e3f0af 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -446,6 +446,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
 	u32 *dma_buf;
 	int err;
 
+	if (!of_property_present(i2c_dev->dev->of_node, "dmas")) {
+		dev_dbg(i2c_dev->dev, "DMA not available, falling back to PIO\n");
+		return 0;
+	}
+
 	if (IS_VI(i2c_dev))
 		return 0;
 
-- 
2.43.0

Re: [PATCH v8 1/4] i2c: tegra: Do not configure DMA if not supported

[Jon Hunter]

On 17/09/2025 09:56, Kartik Rajput wrote:
> On Tegra264, not all I2C controllers have the necessary interface to
> GPC DMA, this causes failures when function tegra_i2c_init_dma()
> is called.
> 
> Ensure that "dmas" device-tree property is present before initializing
> DMA in function tegra_i2c_init_dma().
> 
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> ---
> v2 -> v4:
> 	* Add debug print if DMA is not supported by the I2C controller.
> v1 -> v2:
> 	* Update commit message to clarify that some I2C controllers may
> 	  not have the necessary interface to GPC DMA.
> ---
>   drivers/i2c/busses/i2c-tegra.c | 5 +++++
>   1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index e533460bccc3..d908e5e3f0af 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -446,6 +446,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>   	u32 *dma_buf;
>   	int err;
>   
> +	if (!of_property_present(i2c_dev->dev->of_node, "dmas")) {
> +		dev_dbg(i2c_dev->dev, "DMA not available, falling back to PIO\n");
> +		return 0;
> +	}
> +
>   	if (IS_VI(i2c_dev))
>   		return 0;
>   

No issue with this change, but we have a few checks for DMA support in 
this function and so it would be nice to have them altogether.

Jon

-- 
nvpublic

Re: [PATCH v8 1/4] i2c: tegra: Do not configure DMA if not supported

[Kartik Rajput]

On 17/09/25 19:38, Jon Hunter wrote:
> 
> On 17/09/2025 09:56, Kartik Rajput wrote:
>> On Tegra264, not all I2C controllers have the necessary interface to
>> GPC DMA, this causes failures when function tegra_i2c_init_dma()
>> is called.
>>
>> Ensure that "dmas" device-tree property is present before initializing
>> DMA in function tegra_i2c_init_dma().
>>
>> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
>> ---
>> v2 -> v4:
>>     * Add debug print if DMA is not supported by the I2C controller.
>> v1 -> v2:
>>     * Update commit message to clarify that some I2C controllers may
>>       not have the necessary interface to GPC DMA.
>> ---
>>   drivers/i2c/busses/i2c-tegra.c | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>> index e533460bccc3..d908e5e3f0af 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -446,6 +446,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>       u32 *dma_buf;
>>       int err;
>> +    if (!of_property_present(i2c_dev->dev->of_node, "dmas")) {
>> +        dev_dbg(i2c_dev->dev, "DMA not available, falling back to PIO\n");
>> +        return 0;
>> +    }
>> +
>>       if (IS_VI(i2c_dev))
>>           return 0;
> 
> No issue with this change, but we have a few checks for DMA support in this function and so it would be nice to have them altogether.
> 
> Jon
> 

Ack.

Thanks,
Kartik

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

[Kartik Rajput]

From: Akhil R <akhilrajeev@nvidia.com>

Add support for HS (High Speed) mode transfers, which is supported by
Tegra194 onwards.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.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;
+	}
+
 	clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
 
 	err = clk_set_rate(i2c_dev->div_clk,
@@ -1214,6 +1235,9 @@ static void tegra_i2c_push_packet_header(struct tegra_i2c_dev *i2c_dev,
 	if (msg->flags & I2C_M_RD)
 		packet_header |= I2C_HEADER_READ;
 
+	if (i2c_dev->timings.bus_freq_hz > I2C_MAX_FAST_MODE_PLUS_FREQ)
+		packet_header |= I2C_HEADER_HS_MODE;
+
 	if (i2c_dev->dma_mode && !i2c_dev->msg_read)
 		*dma_buf++ = packet_header;
 	else
@@ -1502,6 +1526,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0x0,
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
@@ -1527,6 +1552,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0x0,
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
@@ -1552,6 +1578,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0x0,
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
@@ -1577,6 +1604,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0x0,
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = true,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
@@ -1602,6 +1630,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0,
 	.setup_hold_time_hs_mode = 0,
 	.has_interface_timing_reg = true,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
@@ -1627,6 +1656,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
 	.setup_hold_time_fast_fast_plus_mode = 0,
 	.setup_hold_time_hs_mode = 0,
 	.has_interface_timing_reg = true,
+	.has_hs_mode_support = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
@@ -1648,10 +1678,13 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
 	.thigh_std_mode = 0x7,
 	.tlow_fast_fastplus_mode = 0x2,
 	.thigh_fast_fastplus_mode = 0x2,
+	.tlow_hs_mode = 0x8,
+	.thigh_hs_mode = 0x3,
 	.setup_hold_time_std_mode = 0x08080808,
 	.setup_hold_time_fast_fast_plus_mode = 0x02020202,
 	.setup_hold_time_hs_mode = 0x090909,
 	.has_interface_timing_reg = true,
+	.has_hs_mode_support = true,
 };
 
 static const struct tegra_i2c_hw_feature tegra256_i2c_hw = {
-- 
2.43.0

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

[Jon Hunter]

On 17/09/2025 09:56, Kartik Rajput wrote:
> From: Akhil R <akhilrajeev@nvidia.com>
> 
> Add support for HS (High Speed) mode transfers, which is supported by
> Tegra194 onwards.
> 
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Signed-off-by: Kartik Rajput <kkartik@nvidia.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?

> +	}
> +
>   	clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
>   
>   	err = clk_set_rate(i2c_dev->div_clk,
> @@ -1214,6 +1235,9 @@ static void tegra_i2c_push_packet_header(struct tegra_i2c_dev *i2c_dev,
>   	if (msg->flags & I2C_M_RD)
>   		packet_header |= I2C_HEADER_READ;
>   
> +	if (i2c_dev->timings.bus_freq_hz > I2C_MAX_FAST_MODE_PLUS_FREQ)
> +		packet_header |= I2C_HEADER_HS_MODE;
> +
>   	if (i2c_dev->dma_mode && !i2c_dev->msg_read)
>   		*dma_buf++ = packet_header;
>   	else
> @@ -1502,6 +1526,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0x0,
>   	.setup_hold_time_hs_mode = 0x0,
>   	.has_interface_timing_reg = false,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
> @@ -1527,6 +1552,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0x0,
>   	.setup_hold_time_hs_mode = 0x0,
>   	.has_interface_timing_reg = false,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
> @@ -1552,6 +1578,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0x0,
>   	.setup_hold_time_hs_mode = 0x0,
>   	.has_interface_timing_reg = false,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
> @@ -1577,6 +1604,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0x0,
>   	.setup_hold_time_hs_mode = 0x0,
>   	.has_interface_timing_reg = true,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
> @@ -1602,6 +1630,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0,
>   	.setup_hold_time_hs_mode = 0,
>   	.has_interface_timing_reg = true,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
> @@ -1627,6 +1656,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
>   	.setup_hold_time_fast_fast_plus_mode = 0,
>   	.setup_hold_time_hs_mode = 0,
>   	.has_interface_timing_reg = true,
> +	.has_hs_mode_support = false,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
> @@ -1648,10 +1678,13 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
>   	.thigh_std_mode = 0x7,
>   	.tlow_fast_fastplus_mode = 0x2,
>   	.thigh_fast_fastplus_mode = 0x2,
> +	.tlow_hs_mode = 0x8,
> +	.thigh_hs_mode = 0x3,
>   	.setup_hold_time_std_mode = 0x08080808,
>   	.setup_hold_time_fast_fast_plus_mode = 0x02020202,
>   	.setup_hold_time_hs_mode = 0x090909,
>   	.has_interface_timing_reg = true,
> +	.has_hs_mode_support = true,
>   };
>   
>   static const struct tegra_i2c_hw_feature tegra256_i2c_hw = {

-- 
nvpublic

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

[Akhil R]

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@nvidia.com>
>> 
>> Add support for HS (High Speed) mode transfers, which is supported by
>> Tegra194 onwards.
>> 
>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>> Signed-off-by: Kartik Rajput <kkartik@nvidia.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.


Regards,
Akhil

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

[Jon Hunter]

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@nvidia.com>
>>>
>>> Add support for HS (High Speed) mode transfers, which is supported by
>>> Tegra194 onwards.
>>>
>>> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
>>> Signed-off-by: Kartik Rajput <kkartik@nvidia.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

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

[Akhil R]

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.

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.

Regards,
Akhil

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

[Jon Hunter]

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

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

[Akhil R]

On Thu, 18 Sep 2025 13:55:48 +0100 Jon Hunter wrote:  
> 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.

Yes. That makes sense. If you agree, we can remove the else part because
we weren't doing this before when HS mode support was not there. It is not 
directly related to the HS mode support as well. We can add this at a later
point in a separate patch if found required.

Regards,
Akhil

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

[Jon Hunter]

On 18/09/2025 18:12, Akhil R wrote:

...

>> 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.
> 
> Yes. That makes sense. If you agree, we can remove the else part because
> we weren't doing this before when HS mode support was not there. It is not
> directly related to the HS mode support as well. We can add this at a later
> point in a separate patch if found required.

Hmmm ... I am not sure because then we could potentially program the 
packet header incorrectly later on. May be that will never happen? 
However, I think it would be better to not make any assumptions here and 
make the code as robust as possible.

Jon

-- 
nvpublic

[PATCH v8 3/4] i2c: tegra: Add support for SW mutex register

[Kartik Rajput]

Add support for SW mutex register introduced in Tegra264 to provide
an option to share the interface between multiple firmwares and/or
VMs. This involves following steps:

 - A firmware/OS writes its unique ID to the mutex REQUEST field.
 - Ownership is established when reading the GRANT field returns the
   same ID.
 - If GRANT shows a different non-zero ID, the firmware/OS retries
   until timeout.
 - After completing access, it releases the mutex by writing 0.

However, the hardware does not ensure any protection based on the
values. The driver/firmware should honor the peer who already holds
the mutex.

Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
---
v7 -> v8:
	* Use `bool` instead of `int` for `locked` variable in
	  tegra_i2c_mutex_lock() function.
v6 -> v7:
	* Return bool from tegra_i2c_mutex_acquired() and
	  tegra_i2c_mutex_trylock() functions.
	* Move `has_mutex` check inside tegra_i2c_mutex_lock/unlock
	  functions.
	* Remove redundant empty line added in tegra_i2c_xfer() in v6.
	* Fix pm_runtime_put() not getting called if mutex unlock fails.
	* In tegra_i2c_mutex_lock() simplify the logic to check if the
	  mutex is acquired or not by checking the value of `ret`
	  variable.
	* Update commit message to describe the functioning of SW mutex
	  feature.
v4 -> v6:
	* Guard tegra_i2c_mutex_lock() and tegra_i2c_mutex_unlock() to
	  ensure that they are called on platforms which support SW
	  mutex. 
v3 -> v4:
	* Update timeout logic of tegra_i2c_mutex_lock() to use
	  read_poll_timeout APIs for improving timeout logic.
	* Add tegra_i2c_mutex_acquired() to check if mutex is acquired
	  or not.
	* Rename I2C_SW_MUTEX_ID as I2C_SW_MUTEX_ID_CCPLEX.
	* Function tegra_i2c_poll_register() was moved unnecessarily, it
	  has now been moved to its original location.
	* Use tegra_i2c_mutex_lock/unlock APIs in the tegra_i2c_xfer()
	  function. This ensures proper propagation of error in case
	  mutex lock fails.
	  Please note that as the function tegra_i2c_xfer() is
	  already guarded by the bus lock operation there is no need of
	  additional lock for the tegra_i2c_mutex_lock/unlock APIs.
v2 -> v3:
	* Update tegra_i2c_mutex_trylock and tegra_i2c_mutex_unlock to
	  use readl and writel APIs instead of i2c_readl and i2c_writel
	  which use relaxed APIs.
	* Use dev_warn instead of WARN_ON if mutex lock/unlock fails.
v1 -> v2:
	* Fixed typos.
	* Fix tegra_i2c_mutex_lock() logic.
	* Add a timeout in tegra_i2c_mutex_lock() instead of polling for
	  mutex indefinitely.
---
 drivers/i2c/busses/i2c-tegra.c | 92 ++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 6f816de8b3af..a2119b8bcc1d 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -137,6 +137,14 @@
 
 #define I2C_MASTER_RESET_CNTRL			0x0a8
 
+#define I2C_SW_MUTEX				0x0ec
+#define I2C_SW_MUTEX_REQUEST			GENMASK(3, 0)
+#define I2C_SW_MUTEX_GRANT			GENMASK(7, 4)
+#define I2C_SW_MUTEX_ID_CCPLEX			9
+
+/* SW mutex acquire timeout value in microseconds. */
+#define I2C_SW_MUTEX_TIMEOUT_US			(25 * USEC_PER_MSEC)
+
 /* configuration load timeout in microseconds */
 #define I2C_CONFIG_LOAD_TIMEOUT			1000000
 
@@ -210,6 +218,7 @@ enum msg_end_type {
  * @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.
+ * @has_mutex: Has mutex register for mutual exclusion with other firmwares or VMs.
  */
 struct tegra_i2c_hw_feature {
 	bool has_continue_xfer_support;
@@ -237,6 +246,7 @@ struct tegra_i2c_hw_feature {
 	u32 setup_hold_time_hs_mode;
 	bool has_interface_timing_reg;
 	bool has_hs_mode_support;
+	bool has_mutex;
 };
 
 /**
@@ -381,6 +391,76 @@ static void i2c_readsl(struct tegra_i2c_dev *i2c_dev, void *data,
 	readsl(i2c_dev->base + tegra_i2c_reg_addr(i2c_dev, reg), data, len);
 }
 
+static bool tegra_i2c_mutex_acquired(struct tegra_i2c_dev *i2c_dev)
+{
+	unsigned int reg = tegra_i2c_reg_addr(i2c_dev, I2C_SW_MUTEX);
+	u32 val, id;
+
+	val = readl(i2c_dev->base + reg);
+	id = FIELD_GET(I2C_SW_MUTEX_GRANT, val);
+
+	return id == I2C_SW_MUTEX_ID_CCPLEX;
+}
+
+static bool tegra_i2c_mutex_trylock(struct tegra_i2c_dev *i2c_dev)
+{
+	unsigned int reg = tegra_i2c_reg_addr(i2c_dev, I2C_SW_MUTEX);
+	u32 val, id;
+
+	val = readl(i2c_dev->base + reg);
+	id = FIELD_GET(I2C_SW_MUTEX_GRANT, val);
+	if (id != 0 && id != I2C_SW_MUTEX_ID_CCPLEX)
+		return false;
+
+	val = FIELD_PREP(I2C_SW_MUTEX_REQUEST, I2C_SW_MUTEX_ID_CCPLEX);
+	writel(val, i2c_dev->base + reg);
+
+	return tegra_i2c_mutex_acquired(i2c_dev);
+}
+
+static int tegra_i2c_mutex_lock(struct tegra_i2c_dev *i2c_dev)
+{
+	bool locked;
+	int ret;
+
+	if (!i2c_dev->hw->has_mutex)
+		return 0;
+
+	if (i2c_dev->atomic_mode)
+		ret = read_poll_timeout_atomic(tegra_i2c_mutex_trylock, locked, locked,
+					       USEC_PER_MSEC, I2C_SW_MUTEX_TIMEOUT_US,
+					       false, i2c_dev);
+	else
+		ret = read_poll_timeout(tegra_i2c_mutex_trylock, locked, locked, USEC_PER_MSEC,
+					I2C_SW_MUTEX_TIMEOUT_US, false, i2c_dev);
+
+	if (ret)
+		dev_warn(i2c_dev->dev, "failed to acquire mutex\n");
+
+	return ret;
+}
+
+static int tegra_i2c_mutex_unlock(struct tegra_i2c_dev *i2c_dev)
+{
+	unsigned int reg = tegra_i2c_reg_addr(i2c_dev, I2C_SW_MUTEX);
+	u32 val, id;
+
+	if (!i2c_dev->hw->has_mutex)
+		return 0;
+
+	val = readl(i2c_dev->base + reg);
+
+	id = FIELD_GET(I2C_SW_MUTEX_GRANT, val);
+	if (id && id != I2C_SW_MUTEX_ID_CCPLEX) {
+		dev_warn(i2c_dev->dev, "unable to unlock mutex, mutex is owned by: %u\n", id);
+		return -EPERM;
+	}
+
+	writel(0, i2c_dev->base + reg);
+
+	return 0;
+}
+
 static void tegra_i2c_mask_irq(struct tegra_i2c_dev *i2c_dev, u32 mask)
 {
 	u32 int_mask;
@@ -1422,6 +1502,10 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 		return ret;
 	}
 
+	ret = tegra_i2c_mutex_lock(i2c_dev);
+	if (ret)
+		return ret;
+
 	for (i = 0; i < num; i++) {
 		enum msg_end_type end_type = MSG_END_STOP;
 
@@ -1451,6 +1535,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msgs[],
 			break;
 	}
 
+	ret = tegra_i2c_mutex_unlock(i2c_dev);
 	pm_runtime_put(i2c_dev->dev);
 
 	return ret ?: i;
@@ -1527,6 +1612,7 @@ static const struct tegra_i2c_hw_feature tegra20_i2c_hw = {
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
@@ -1553,6 +1639,7 @@ static const struct tegra_i2c_hw_feature tegra30_i2c_hw = {
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
@@ -1579,6 +1666,7 @@ static const struct tegra_i2c_hw_feature tegra114_i2c_hw = {
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = false,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
@@ -1605,6 +1693,7 @@ static const struct tegra_i2c_hw_feature tegra124_i2c_hw = {
 	.setup_hold_time_hs_mode = 0x0,
 	.has_interface_timing_reg = true,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
@@ -1631,6 +1720,7 @@ static const struct tegra_i2c_hw_feature tegra210_i2c_hw = {
 	.setup_hold_time_hs_mode = 0,
 	.has_interface_timing_reg = true,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
@@ -1657,6 +1747,7 @@ static const struct tegra_i2c_hw_feature tegra186_i2c_hw = {
 	.setup_hold_time_hs_mode = 0,
 	.has_interface_timing_reg = true,
 	.has_hs_mode_support = false,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
@@ -1685,6 +1776,7 @@ static const struct tegra_i2c_hw_feature tegra194_i2c_hw = {
 	.setup_hold_time_hs_mode = 0x090909,
 	.has_interface_timing_reg = true,
 	.has_hs_mode_support = true,
+	.has_mutex = false,
 };
 
 static const struct tegra_i2c_hw_feature tegra256_i2c_hw = {
-- 
2.43.0

[PATCH v8 4/4] i2c: tegra: Add Tegra264 support

[Kartik Rajput]

From: Akhil R <akhilrajeev@nvidia.com>

Add support for Tegra264 SoC which supports 17 generic I2C controllers,
two of which are in the AON (always-on) partition of the SoC. In
addition to the features supported by Tegra194 it also supports a
SW mutex register to allow sharing the same I2C instance across
multiple firmware.

Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
v1 -> v4:
	* Update commit message to mention the SW mutex feature
	  available on Tegra264.
---
 drivers/i2c/busses/i2c-tegra.c | 29 +++++++++++++++++++++++++++++
 1 file changed, 29 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index a2119b8bcc1d..cc9aa7f008eb 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1804,7 +1804,36 @@ static const struct tegra_i2c_hw_feature tegra256_i2c_hw = {
 	.has_interface_timing_reg = true,
 };
 
+static const struct tegra_i2c_hw_feature tegra264_i2c_hw = {
+	.has_continue_xfer_support = true,
+	.has_per_pkt_xfer_complete_irq = true,
+	.clk_divisor_hs_mode = 1,
+	.clk_divisor_std_mode = 0x1d,
+	.clk_divisor_fast_mode = 0x15,
+	.clk_divisor_fast_plus_mode = 0x8,
+	.has_config_load_reg = true,
+	.has_multi_master_mode = true,
+	.has_slcg_override_reg = true,
+	.has_mst_fifo = true,
+	.quirks = &tegra194_i2c_quirks,
+	.supports_bus_clear = true,
+	.has_apb_dma = false,
+	.tlow_std_mode = 0x8,
+	.thigh_std_mode = 0x7,
+	.tlow_fast_fastplus_mode = 0x2,
+	.thigh_fast_fastplus_mode = 0x2,
+	.tlow_hs_mode = 0x4,
+	.thigh_hs_mode = 0x2,
+	.setup_hold_time_std_mode = 0x08080808,
+	.setup_hold_time_fast_fast_plus_mode = 0x02020202,
+	.setup_hold_time_hs_mode = 0x090909,
+	.has_interface_timing_reg = true,
+	.has_hs_mode_support = true,
+	.has_mutex = true,
+};
+
 static const struct of_device_id tegra_i2c_of_match[] = {
+	{ .compatible = "nvidia,tegra264-i2c", .data = &tegra264_i2c_hw, },
 	{ .compatible = "nvidia,tegra256-i2c", .data = &tegra256_i2c_hw, },
 	{ .compatible = "nvidia,tegra194-i2c", .data = &tegra194_i2c_hw, },
 	{ .compatible = "nvidia,tegra186-i2c", .data = &tegra186_i2c_hw, },
-- 
2.43.0