* [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-01 6:47 [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
@ 2025-10-01 6:47 ` Kartik Rajput
2025-10-24 15:20 ` Jon Hunter
2025-11-06 15:51 ` Jon Hunter
2025-10-01 6:47 ` [PATCH v9 2/4] i2c: tegra: Add HS mode support Kartik Rajput
` (3 subsequent siblings)
4 siblings, 2 replies; 20+ messages in thread
From: Kartik Rajput @ 2025-10-01 6:47 UTC (permalink / raw)
To: akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, ldewangan, digetx, linux-i2c, devicetree, linux-tegra,
linux-kernel
Cc: kkartik
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>
---
v4 -> v9: Moved the condition down to have all dma checks together.
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..aa7c0d8c0941 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
if (IS_VI(i2c_dev))
return 0;
+ 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 (i2c_dev->hw->has_apb_dma) {
if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
--
2.50.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-01 6:47 ` [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported Kartik Rajput
@ 2025-10-24 15:20 ` Jon Hunter
2025-10-28 10:00 ` Akhil R
2025-11-06 15:51 ` Jon Hunter
1 sibling, 1 reply; 20+ messages in thread
From: Jon Hunter @ 2025-10-24 15:20 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, 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>
> ---
> v4 -> v9: Moved the condition down to have all dma checks together.
> 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..aa7c0d8c0941 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
> if (IS_VI(i2c_dev))
> return 0;
>
> + 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 (i2c_dev->hw->has_apb_dma) {
> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
What about ACPI based devices?
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-24 15:20 ` Jon Hunter
@ 2025-10-28 10:00 ` Akhil R
2025-10-28 10:41 ` Jon Hunter
0 siblings, 1 reply; 20+ messages in thread
From: Akhil R @ 2025-10-28 10:00 UTC (permalink / raw)
To: jonathanh
Cc: akhilrajeev, andi.shyti, conor+dt, devicetree, digetx, kkartik,
krzk+dt, ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On Fri, 24 Oct 2025 16:20:09 +0100, Jon Hunter wrote:
> On 01/10/2025 07:47, 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>
>> ---
>> v4 -> v9: Moved the condition down to have all dma checks together.
>> 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..aa7c0d8c0941 100644
>> --- a/drivers/i2c/busses/i2c-tegra.c
>> +++ b/drivers/i2c/busses/i2c-tegra.c
>> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>> if (IS_VI(i2c_dev))
>> return 0;
>>
>> + 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 (i2c_dev->hw->has_apb_dma) {
>> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
>> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
>
> What about ACPI based devices?
The of_ function returns false if using ACPI. Since these DMA drivers does
not support ACPI enumeration currently, we would not require to proceed
further anyway. But if required we can add an additional check with
acpi_dma_supported() or similar. Do you suggest adding a check for ACPI?
Regards,
Akhil
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-28 10:00 ` Akhil R
@ 2025-10-28 10:41 ` Jon Hunter
2025-10-28 13:08 ` Akhil R
0 siblings, 1 reply; 20+ messages in thread
From: Jon Hunter @ 2025-10-28 10:41 UTC (permalink / raw)
To: Akhil R
Cc: andi.shyti, conor+dt, devicetree, digetx, kkartik, krzk+dt,
ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On 28/10/2025 10:00, Akhil R wrote:
> On Fri, 24 Oct 2025 16:20:09 +0100, Jon Hunter wrote:
>> On 01/10/2025 07:47, 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>
>>> ---
>>> v4 -> v9: Moved the condition down to have all dma checks together.
>>> 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..aa7c0d8c0941 100644
>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>> if (IS_VI(i2c_dev))
>>> return 0;
>>>
>>> + 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 (i2c_dev->hw->has_apb_dma) {
>>> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
>>> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
>>
>> What about ACPI based devices?
>
> The of_ function returns false if using ACPI. Since these DMA drivers does
> not support ACPI enumeration currently, we would not require to proceed
> further anyway. But if required we can add an additional check with
> acpi_dma_supported() or similar. Do you suggest adding a check for ACPI?
I was just wondering if it is better to use fwnode_property_present()
instead.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-28 10:41 ` Jon Hunter
@ 2025-10-28 13:08 ` Akhil R
2025-10-28 16:09 ` Jon Hunter
0 siblings, 1 reply; 20+ messages in thread
From: Akhil R @ 2025-10-28 13:08 UTC (permalink / raw)
To: jonathanh
Cc: akhilrajeev, andi.shyti, conor+dt, devicetree, digetx, kkartik,
krzk+dt, ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On Tue, 28 Oct 2025 10:41:54 +0000 Jon Hunter wrote:
> On 28/10/2025 10:00, Akhil R wrote:
>> On Fri, 24 Oct 2025 16:20:09 +0100, Jon Hunter wrote:
>>> On 01/10/2025 07:47, Kartik Rajput wrote:
...
>>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>>> index e533460bccc3..aa7c0d8c0941 100644
>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>>> if (IS_VI(i2c_dev))
>>>> return 0;
>>>>
>>>> + 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 (i2c_dev->hw->has_apb_dma) {
>>>> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
>>>> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
>>>
>>> What about ACPI based devices?
>>
>> The of_ function returns false if using ACPI. Since these DMA drivers does
>> not support ACPI enumeration currently, we would not require to proceed
>> further anyway. But if required we can add an additional check with
>> acpi_dma_supported() or similar. Do you suggest adding a check for ACPI?
>
> I was just wondering if it is better to use fwnode_property_present()
> instead.
I think ACPI does not use 'dmas' property to connect a DMA resource.
It uses FixedDMA or something similar. It may not be helpful to use
fwnode_*() or device_*() check here in that case.
Regards,
Akhil
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-28 13:08 ` Akhil R
@ 2025-10-28 16:09 ` Jon Hunter
0 siblings, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-10-28 16:09 UTC (permalink / raw)
To: Akhil R
Cc: andi.shyti, conor+dt, devicetree, digetx, kkartik, krzk+dt,
ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On 28/10/2025 13:08, Akhil R wrote:
> On Tue, 28 Oct 2025 10:41:54 +0000 Jon Hunter wrote:
>> On 28/10/2025 10:00, Akhil R wrote:
>>> On Fri, 24 Oct 2025 16:20:09 +0100, Jon Hunter wrote:
>>>> On 01/10/2025 07:47, Kartik Rajput wrote:
>
> ...
>
>>>>> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
>>>>> index e533460bccc3..aa7c0d8c0941 100644
>>>>> --- a/drivers/i2c/busses/i2c-tegra.c
>>>>> +++ b/drivers/i2c/busses/i2c-tegra.c
>>>>> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
>>>>> if (IS_VI(i2c_dev))
>>>>> return 0;
>>>>>
>>>>> + 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 (i2c_dev->hw->has_apb_dma) {
>>>>> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
>>>>> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
>>>>
>>>> What about ACPI based devices?
>>>
>>> The of_ function returns false if using ACPI. Since these DMA drivers does
>>> not support ACPI enumeration currently, we would not require to proceed
>>> further anyway. But if required we can add an additional check with
>>> acpi_dma_supported() or similar. Do you suggest adding a check for ACPI?
>>
>> I was just wondering if it is better to use fwnode_property_present()
>> instead.
>
> I think ACPI does not use 'dmas' property to connect a DMA resource.
> It uses FixedDMA or something similar. It may not be helpful to use
> fwnode_*() or device_*() check here in that case.
OK. Then fine to leave this as-is.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported
2025-10-01 6:47 ` [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported Kartik Rajput
2025-10-24 15:20 ` Jon Hunter
@ 2025-11-06 15:51 ` Jon Hunter
1 sibling, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-11-06 15:51 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, 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>
> ---
> v4 -> v9: Moved the condition down to have all dma checks together.
> 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..aa7c0d8c0941 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -449,6 +449,11 @@ static int tegra_i2c_init_dma(struct tegra_i2c_dev *i2c_dev)
> if (IS_VI(i2c_dev))
> return 0;
>
> + 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 (i2c_dev->hw->has_apb_dma) {
> if (!IS_ENABLED(CONFIG_TEGRA20_APB_DMA)) {
> dev_dbg(i2c_dev->dev, "APB DMA support not enabled\n");
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Thanks!
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v9 2/4] i2c: tegra: Add HS mode support
2025-10-01 6:47 [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
2025-10-01 6:47 ` [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported Kartik Rajput
@ 2025-10-01 6:47 ` Kartik Rajput
2025-10-24 15:28 ` Jon Hunter
2025-10-01 6:47 ` [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register Kartik Rajput
` (2 subsequent siblings)
4 siblings, 1 reply; 20+ messages in thread
From: Kartik Rajput @ 2025-10-01 6:47 UTC (permalink / raw)
To: akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, ldewangan, digetx, linux-i2c, devicetree, linux-tegra,
linux-kernel
Cc: kkartik
From: Akhil R <akhilrajeev@nvidia.com>
Add support for HS (High Speed) mode transfers, which is supported by
Tegra194 onwards. Also adjust the bus frequency such that it uses the
fast plus mode when HS mode is not supported.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
---
v5 -> v9:
* In the switch block, handle the case when hs mode is not
supported. Also update it to use Fast mode for master code
byte as per the I2C spec for HS mode.
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 | 49 +++++++++++++++++++++++++++++++---
1 file changed, 46 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index aa7c0d8c0941..cc75340f6cb5 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;
};
/**
@@ -678,16 +685,28 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
tegra_i2c_vi_init(i2c_dev);
switch (t->bus_freq_hz) {
- case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
default:
+ if (!i2c_dev->hw->has_hs_mode_support)
+ t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
+ fallthrough;
+
+ case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
- if (t->bus_freq_hz > I2C_MAX_FAST_MODE_FREQ)
+ /*
+ * When HS mode is supported, the non-hs timing registers will be used for the
+ * master code byte for transition to HS mode. As per the spec, the 8 bit master
+ * code should be sent at max 400kHz. Therefore, limit the bus speed to fast mode.
+ * Whereas when HS mode is not supported, allow the highest speed mode capable.
+ */
+ if (t->bus_freq_hz > I2C_MAX_FAST_MODE_FREQ && !i2c_dev->hw->has_hs_mode_support) {
non_hs_mode = i2c_dev->hw->clk_divisor_fast_plus_mode;
- else
+ t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
+ } else {
non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
+ }
break;
case 0 ... I2C_MAX_STANDARD_MODE_FREQ:
@@ -717,6 +736,18 @@ 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);
+ }
+
clk_multiplier = (tlow + thigh + 2) * (non_hs_mode + 1);
err = clk_set_rate(i2c_dev->div_clk,
@@ -1214,6 +1245,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 +1536,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 +1562,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 +1588,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 +1614,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 +1640,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 +1666,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 +1688,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.50.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v9 2/4] i2c: tegra: Add HS mode support
2025-10-01 6:47 ` [PATCH v9 2/4] i2c: tegra: Add HS mode support Kartik Rajput
@ 2025-10-24 15:28 ` Jon Hunter
2025-11-06 6:17 ` Akhil R
0 siblings, 1 reply; 20+ messages in thread
From: Jon Hunter @ 2025-10-24 15:28 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, Kartik Rajput wrote:
> From: Akhil R <akhilrajeev@nvidia.com>
>
> Add support for HS (High Speed) mode transfers, which is supported by
> Tegra194 onwards. Also adjust the bus frequency such that it uses the
> fast plus mode when HS mode is not supported.
>
> Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> Signed-off-by: Kartik Rajput <kkartik@nvidia.com>
> ---
> v5 -> v9:
> * In the switch block, handle the case when hs mode is not
> supported. Also update it to use Fast mode for master code
> byte as per the I2C spec for HS mode.
> 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 | 49 +++++++++++++++++++++++++++++++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
> index aa7c0d8c0941..cc75340f6cb5 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;
> };
>
> /**
> @@ -678,16 +685,28 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> tegra_i2c_vi_init(i2c_dev);
>
> switch (t->bus_freq_hz) {
> - case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
> default:
> + if (!i2c_dev->hw->has_hs_mode_support)
> + t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
> + fallthrough;
> +
This looks odd. I guess this is carry over from the previous code, but
now it looks very odd to someone reviewing the code after this change
has been made. We need to make the code here more logical so that the
reader stands a chance of understanding the new logic.
> + case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
> tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
> thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
> tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
>
> - if (t->bus_freq_hz > I2C_MAX_FAST_MODE_FREQ)
> + /*
> + * When HS mode is supported, the non-hs timing registers will be used for the
> + * master code byte for transition to HS mode. As per the spec, the 8 bit master
> + * code should be sent at max 400kHz. Therefore, limit the bus speed to fast mode.
> + * Whereas when HS mode is not supported, allow the highest speed mode capable.
> + */
> + if (t->bus_freq_hz > I2C_MAX_FAST_MODE_FREQ && !i2c_dev->hw->has_hs_mode_support) {
> non_hs_mode = i2c_dev->hw->clk_divisor_fast_plus_mode;
> - else
> + t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
> + } else {
> non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
> + }
> break;
>
> case 0 ... I2C_MAX_STANDARD_MODE_FREQ:
> @@ -717,6 +736,18 @@ 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);
> + }
> +
I still think all of the above needs a bit of work.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 2/4] i2c: tegra: Add HS mode support
2025-10-24 15:28 ` Jon Hunter
@ 2025-11-06 6:17 ` Akhil R
2025-11-06 16:02 ` Jon Hunter
0 siblings, 1 reply; 20+ messages in thread
From: Akhil R @ 2025-11-06 6:17 UTC (permalink / raw)
To: jonathanh
Cc: akhilrajeev, andi.shyti, conor+dt, devicetree, digetx, kkartik,
krzk+dt, ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On Fri, 24 Oct 2025 16:28:50 +0100, Jon Hunter wrote:
> On 01/10/2025 07:47, Kartik Rajput wrote:
...
>> /**
>> @@ -678,16 +685,28 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
>> tegra_i2c_vi_init(i2c_dev);
>>
>> switch (t->bus_freq_hz) {
>> - case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
>> default:
>> + if (!i2c_dev->hw->has_hs_mode_support)
>> + t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
>> + fallthrough;
>> +
>>
> This looks odd. I guess this is carry over from the previous code, but
> now it looks very odd to someone reviewing the code after this change
> has been made. We need to make the code here more logical so that the
> reader stands a chance of understanding the new logic.
Would it look better if I update as below?
@@ -678,8 +685,26 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
tegra_i2c_vi_init(i2c_dev);
switch (t->bus_freq_hz) {
- case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
default:
+ /*
+ * When HS mode is supported, the non-hs timing registers will be used for the
+ * master code byte for transition to HS mode. As per the spec, the 8 bit master
+ * code should be sent at max 400kHz. Therefore, limit the bus speed to fast mode.
+ * Whereas when HS mode is not supported, allow the highest speed mode capable.
+ */
+ if (i2c_dev->hw->has_hs_mode_support) {
+ tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
+ thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
+ tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
+ non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
+
+ break;
+ } else {
+ t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
+ }
+ fallthrough;
+
+ case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
@@ -688,6 +713,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
...
>> @@ -717,6 +736,18 @@ 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);
>> + }
>> +
>
> I still think all of the above needs a bit of work.
I suppose the above section can be as is since HS mode registers are independent
of other speed modes. Any suggestions or thoughts?
Regards,
Akhil
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 2/4] i2c: tegra: Add HS mode support
2025-11-06 6:17 ` Akhil R
@ 2025-11-06 16:02 ` Jon Hunter
0 siblings, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-11-06 16:02 UTC (permalink / raw)
To: Akhil R
Cc: andi.shyti, conor+dt, devicetree, digetx, kkartik, krzk+dt,
ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On 06/11/2025 06:17, Akhil R wrote:
> On Fri, 24 Oct 2025 16:28:50 +0100, Jon Hunter wrote:
>> On 01/10/2025 07:47, Kartik Rajput wrote:
>
> ...
>
>>> /**
>>> @@ -678,16 +685,28 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
>>> tegra_i2c_vi_init(i2c_dev);
>>>
>>> switch (t->bus_freq_hz) {
>>> - case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
>>> default:
>>> + if (!i2c_dev->hw->has_hs_mode_support)
>>> + t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
>>> + fallthrough;
>>> +
>>>
>> This looks odd. I guess this is carry over from the previous code, but
>> now it looks very odd to someone reviewing the code after this change
>> has been made. We need to make the code here more logical so that the
>> reader stands a chance of understanding the new logic.
>
> Would it look better if I update as below?
>
> @@ -678,8 +685,26 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
> tegra_i2c_vi_init(i2c_dev);
>
> switch (t->bus_freq_hz) {
> - case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
> default:
I can't say I am a fan of this 'default' part. I don't find this very
clear at all.
> + /*
> + * When HS mode is supported, the non-hs timing registers will be used for the
> + * master code byte for transition to HS mode. As per the spec, the 8 bit master
> + * code should be sent at max 400kHz. Therefore, limit the bus speed to fast mode.
> + * Whereas when HS mode is not supported, allow the highest speed mode capable.
> + */
> + if (i2c_dev->hw->has_hs_mode_support) {
> + tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
> + thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
> + tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
> + non_hs_mode = i2c_dev->hw->clk_divisor_fast_mode;
> +
> + break;
> + } else {
> + t->bus_freq_hz = I2C_MAX_FAST_MODE_PLUS_FREQ;
> + }
> + fallthrough;
> +
> + case I2C_MAX_STANDARD_MODE_FREQ + 1 ... I2C_MAX_FAST_MODE_PLUS_FREQ:
> tlow = i2c_dev->hw->tlow_fast_fastplus_mode;
> thigh = i2c_dev->hw->thigh_fast_fastplus_mode;
> tsu_thd = i2c_dev->hw->setup_hold_time_fast_fast_plus_mode;
Looking at this code are we better off converting this to a simple
if-statement?
So we have ...
if (t->bus_freq_hz <= I2C_MAX_STANDARD_MODE_FREQ) {
tlow = i2c_dev->hw->tlow_std_mode;
thigh = i2c_dev->hw->thigh_std_mode;
tsu_thd = i2c_dev->hw->setup_hold_time_std_mode;
non_hs_mode = i2c_dev->hw->clk_divisor_std_mode;
} else {
...
}
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register
2025-10-01 6:47 [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
2025-10-01 6:47 ` [PATCH v9 1/4] i2c: tegra: Do not configure DMA if not supported Kartik Rajput
2025-10-01 6:47 ` [PATCH v9 2/4] i2c: tegra: Add HS mode support Kartik Rajput
@ 2025-10-01 6:47 ` Kartik Rajput
2025-10-24 15:42 ` Jon Hunter
2025-11-06 15:52 ` Jon Hunter
2025-10-01 6:47 ` [PATCH v9 4/4] i2c: tegra: Add Tegra264 support Kartik Rajput
2025-10-21 8:17 ` [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
4 siblings, 2 replies; 20+ messages in thread
From: Kartik Rajput @ 2025-10-01 6:47 UTC (permalink / raw)
To: akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, ldewangan, digetx, linux-i2c, devicetree, linux-tegra,
linux-kernel
Cc: kkartik
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 cc75340f6cb5..1c8c24ae54ed 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;
@@ -1432,6 +1512,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;
@@ -1461,6 +1545,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;
@@ -1537,6 +1622,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 = {
@@ -1563,6 +1649,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 = {
@@ -1589,6 +1676,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 = {
@@ -1615,6 +1703,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 = {
@@ -1641,6 +1730,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 = {
@@ -1667,6 +1757,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 = {
@@ -1695,6 +1786,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.50.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register
2025-10-01 6:47 ` [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register Kartik Rajput
@ 2025-10-24 15:42 ` Jon Hunter
2025-10-28 12:54 ` Akhil R
2025-11-06 15:52 ` Jon Hunter
1 sibling, 1 reply; 20+ messages in thread
From: Jon Hunter @ 2025-10-24 15:42 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, Kartik Rajput wrote:
> 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 cc75340f6cb5..1c8c24ae54ed 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;
> @@ -1432,6 +1512,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;
> +
I wonder if it would be better to have a wrapper function around
tegra_i2c_xfer() called tegra264_i2c_xfer() that is only used for
Tegra264 platforms and invokes these sw-mutex functions?
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register
2025-10-24 15:42 ` Jon Hunter
@ 2025-10-28 12:54 ` Akhil R
2025-10-28 16:14 ` Jon Hunter
0 siblings, 1 reply; 20+ messages in thread
From: Akhil R @ 2025-10-28 12:54 UTC (permalink / raw)
To: jonathanh
Cc: akhilrajeev, andi.shyti, conor+dt, devicetree, digetx, kkartik,
krzk+dt, ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On Fri, 24 Oct 2025 16:42:06 +0100, Jon Hunter wrote:
> On 01/10/2025 07:47, Kartik Rajput wrote:
>> static void tegra_i2c_mask_irq(struct tegra_i2c_dev *i2c_dev, u32 mask)
>> {
>> u32 int_mask;
>> @@ -1432,6 +1512,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;
>> +
>>
>> I wonder if it would be better to have a wrapper function around
>> tegra_i2c_xfer() called tegra264_i2c_xfer() that is only used for
>> Tegra264 platforms and invokes these sw-mutex functions?
Wouldn't this only add another 'if' condition to tegra_i2c_xfer()?
And probably making it more complex? Or am I missing something?
Regards,
Akhil
^ permalink raw reply [flat|nested] 20+ messages in thread* Re: [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register
2025-10-28 12:54 ` Akhil R
@ 2025-10-28 16:14 ` Jon Hunter
0 siblings, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-10-28 16:14 UTC (permalink / raw)
To: Akhil R
Cc: andi.shyti, conor+dt, devicetree, digetx, kkartik, krzk+dt,
ldewangan, linux-i2c, linux-kernel, linux-tegra, robh,
thierry.reding
On 28/10/2025 12:54, Akhil R wrote:
> On Fri, 24 Oct 2025 16:42:06 +0100, Jon Hunter wrote:
>> On 01/10/2025 07:47, Kartik Rajput wrote:
>>> static void tegra_i2c_mask_irq(struct tegra_i2c_dev *i2c_dev, u32 mask)
>>> {
>>> u32 int_mask;
>>> @@ -1432,6 +1512,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;
>>> +
>>>
>>> I wonder if it would be better to have a wrapper function around
>>> tegra_i2c_xfer() called tegra264_i2c_xfer() that is only used for
>>> Tegra264 platforms and invokes these sw-mutex functions?
>
> Wouldn't this only add another 'if' condition to tegra_i2c_xfer()?
> And probably making it more complex? Or am I missing something?
I was thinking we could define a tegra264_i2c_algo but I guess we need
another if condition at some point some where. So let's leave as-is for now.
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register
2025-10-01 6:47 ` [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register Kartik Rajput
2025-10-24 15:42 ` Jon Hunter
@ 2025-11-06 15:52 ` Jon Hunter
1 sibling, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-11-06 15:52 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, Kartik Rajput wrote:
> 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 cc75340f6cb5..1c8c24ae54ed 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;
> @@ -1432,6 +1512,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;
>
> @@ -1461,6 +1545,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;
> @@ -1537,6 +1622,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 = {
> @@ -1563,6 +1649,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 = {
> @@ -1589,6 +1676,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 = {
> @@ -1615,6 +1703,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 = {
> @@ -1641,6 +1730,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 = {
> @@ -1667,6 +1757,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 = {
> @@ -1695,6 +1786,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 = {
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Thanks!
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH v9 4/4] i2c: tegra: Add Tegra264 support
2025-10-01 6:47 [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
` (2 preceding siblings ...)
2025-10-01 6:47 ` [PATCH v9 3/4] i2c: tegra: Add support for SW mutex register Kartik Rajput
@ 2025-10-01 6:47 ` Kartik Rajput
2025-10-24 15:43 ` Jon Hunter
2025-10-21 8:17 ` [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
4 siblings, 1 reply; 20+ messages in thread
From: Kartik Rajput @ 2025-10-01 6:47 UTC (permalink / raw)
To: akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, ldewangan, digetx, linux-i2c, devicetree, linux-tegra,
linux-kernel
Cc: kkartik
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 1c8c24ae54ed..f324cf3b1f28 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -1814,7 +1814,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.50.1
^ permalink raw reply related [flat|nested] 20+ messages in thread* Re: [PATCH v9 4/4] i2c: tegra: Add Tegra264 support
2025-10-01 6:47 ` [PATCH v9 4/4] i2c: tegra: Add Tegra264 support Kartik Rajput
@ 2025-10-24 15:43 ` Jon Hunter
0 siblings, 0 replies; 20+ messages in thread
From: Jon Hunter @ 2025-10-24 15:43 UTC (permalink / raw)
To: Kartik Rajput, akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt,
thierry.reding, ldewangan, digetx, linux-i2c, devicetree,
linux-tegra, linux-kernel
On 01/10/2025 07:47, Kartik Rajput wrote:
> 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 1c8c24ae54ed..f324cf3b1f28 100644
> --- a/drivers/i2c/busses/i2c-tegra.c
> +++ b/drivers/i2c/busses/i2c-tegra.c
> @@ -1814,7 +1814,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, },
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Jon
--
nvpublic
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH v9 0/4] Add I2C support for Tegra264
2025-10-01 6:47 [PATCH v9 0/4] Add I2C support for Tegra264 Kartik Rajput
` (3 preceding siblings ...)
2025-10-01 6:47 ` [PATCH v9 4/4] i2c: tegra: Add Tegra264 support Kartik Rajput
@ 2025-10-21 8:17 ` Kartik Rajput
4 siblings, 0 replies; 20+ messages in thread
From: Kartik Rajput @ 2025-10-21 8:17 UTC (permalink / raw)
To: akhilrajeev, andi.shyti, robh, krzk+dt, conor+dt, thierry.reding,
jonathanh, ldewangan, digetx, linux-i2c, devicetree, linux-tegra,
linux-kernel
On 01/10/25 12:17, Kartik Rajput wrote:
> From: Kartik Rajput <akhilrajeev@nvidia.com>
>
> 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 | 175 ++++++++++++++++++++++++++++++++-
> 1 file changed, 172 insertions(+), 3 deletions(-)
>
Hi all,
Just sending a gentle reminder to review the "[PATCH v9 0/4] Add I2C support for Tegra264" series.
Thanks,
Kartik
^ permalink raw reply [flat|nested] 20+ messages in thread