[PATCH v1 0/4] Enable shared SE support over I2C

[PATCH v1 0/4] Enable shared SE support over I2C

[Mukesh Kumar Savaliya]

This Series adds support to share QUP based I2C SE between subsystems.
Each subsystem should have its own GPII which interacts between SE and
GSI DMA HW engine.

Subsystem must acquire Lock over the SE on GPII channel so that it
gets uninterrupted control till it unlocks the SE. It also makes sure
the commonly shared TLMM GPIOs are not touched which can impact other
subsystem or cause any interruption. Generally, GPIOs are being
unconfigured during suspend time. 

GSI DMA engine is capable to perform requested transfer operations
from any of the SE in a seamless way and its transparent to the
subsystems. Make sure to enable “qcom,shared-se” flag only while
enabling this feature. I2C client should add in its respective parent
node.

---
Mukesh Kumar Savaliya (4):
  dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
  dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
  soc: qcom: geni-se: Export function geni_se_clks_off()
  i2c: i2c-qcom-geni: Enable i2c controller sharing between two
    subsystems

 .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
 drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
 drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
 drivers/soc/qcom/qcom-geni-se.c               |  4 +-
 include/linux/dma/qcom-gpi-dma.h              |  6 +++
 include/linux/soc/qcom/geni-se.h              |  3 ++
 6 files changed, 74 insertions(+), 9 deletions(-)

-- 
2.25.1

[PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

Adds qcom,shared-se flag usage. Use this when particular I2C serial
controller needs to be shared between two subsystems.

Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
---
 Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
index 9f66a3bb1f80..ae423127f736 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
@@ -60,6 +60,10 @@ properties:
   power-domains:
     maxItems: 1
 
+  qcom,shared-se:
+    description: True if I2C needs to be shared between two or more subsystems.
+    type: boolean
+
   reg:
     maxItems: 1
 
-- 
2.25.1

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Bryan O'Donoghue]

On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
> Adds qcom,shared-se flag usage. Use this when particular I2C serial
> controller needs to be shared between two subsystems.
> 
> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
> ---
>   Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> index 9f66a3bb1f80..ae423127f736 100644
> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
> @@ -60,6 +60,10 @@ properties:
>     power-domains:
>       maxItems: 1
>   
> +  qcom,shared-se:
> +    description: True if I2C needs to be shared between two or more subsystems.
> +    type: boolean
> +
>     reg:
>       maxItems: 1
>   

SE = shared execution ?

---
bod

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Bryan O'Donoghue]

On 29/08/2024 10:58, Bryan O'Donoghue wrote:
> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>> Adds qcom,shared-se flag usage. Use this when particular I2C serial
>> controller needs to be shared between two subsystems.
>>
>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml 
>> b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> index 9f66a3bb1f80..ae423127f736 100644
>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> @@ -60,6 +60,10 @@ properties:
>>     power-domains:
>>       maxItems: 1
>> +  qcom,shared-se:
>> +    description: True if I2C needs to be shared between two or more 
>> subsystems.
>> +    type: boolean
>> +
>>     reg:
>>       maxItems: 1
> 
> SE = shared execution ?
> 
> ---
> bod
> 

Serial Engines

This is a good example of defining TLAs

commit eddac5af06546d2e7a0730e3dc02dde3dc91098a
Author: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
Date:   Fri Mar 30 11:08:17 2018 -0600

     soc: qcom: Add GENI based QUP Wrapper driver

     This driver manages the Generic Interface (GENI) firmware based
     Qualcomm Universal Peripheral (QUP) Wrapper. GENI based QUP is the
     next generation programmable module composed of multiple Serial
     Engines (SE)

...

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

On 8/29/2024 3:31 PM, Bryan O'Donoghue wrote:
> On 29/08/2024 10:58, Bryan O'Donoghue wrote:
>> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>>> Adds qcom,shared-se flag usage. Use this when particular I2C serial
>>> controller needs to be shared between two subsystems.
>>>
>>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
>>> ---
>>>   Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
>>>   1 file changed, 4 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml 
>>> b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>>> index 9f66a3bb1f80..ae423127f736 100644
>>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>>> @@ -60,6 +60,10 @@ properties:
>>>     power-domains:
>>>       maxItems: 1
>>> +  qcom,shared-se:
>>> +    description: True if I2C needs to be shared between two or more 
>>> subsystems.
>>> +    type: boolean
>>> +
>>>     reg:
>>>       maxItems: 1
>>
>> SE = shared execution ?
>>
>> ---
>> bod
>>
> 
> Serial Engines
> 
Sorry for short name. yes, SE = Serial Engine. I shall mention in 
brackets in next patch. Noted below TLAs too.
> This is a good example of defining TLAs
> 
> commit eddac5af06546d2e7a0730e3dc02dde3dc91098a
> Author: Karthikeyan Ramasubramanian <kramasub@codeaurora.org>
> Date:   Fri Mar 30 11:08:17 2018 -0600
> 
>      soc: qcom: Add GENI based QUP Wrapper driver
> 
>      This driver manages the Generic Interface (GENI) firmware based
>      Qualcomm Universal Peripheral (QUP) Wrapper. GENI based QUP is the
>      next generation programmable module composed of multiple Serial
>      Engines (SE)
> 
> ...

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

Thanks Bryan For reviewing.

On 8/29/2024 3:28 PM, Bryan O'Donoghue wrote:
> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>> Adds qcom,shared-se flag usage. Use this when particular I2C serial
>> controller needs to be shared between two subsystems.
>>
>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git 
>> a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml 
>> b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> index 9f66a3bb1f80..ae423127f736 100644
>> --- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> +++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
>> @@ -60,6 +60,10 @@ properties:
>>     power-domains:
>>       maxItems: 1
>> +  qcom,shared-se:
>> +    description: True if I2C needs to be shared between two or more 
>> subsystems.
>> +    type: boolean
>> +
>>     reg:
>>       maxItems: 1
> 
> SE = shared execution ?
> 
Sorry for short name. SE = Serial Engine. I shall mention in bracket in 
next step.
> ---
> bod

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Krzysztof Kozlowski]

On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
> Adds qcom,shared-se flag usage. Use this when particular I2C serial
> controller needs to be shared between two subsystems.
> 
> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
> ---
>  Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
>  1 file changed, 4 insertions(+)

<form letter>
Please use scripts/get_maintainers.pl to get a list of necessary people
and lists to CC. It might happen, that command when run on an older
kernel, gives you outdated entries. Therefore please be sure you base
your patches on recent Linux kernel.

Tools like b4 or scripts/get_maintainer.pl provide you proper list of
people, so fix your workflow. Tools might also fail if you work on some
ancient tree (don't, instead use mainline) or work on fork of kernel
(don't, instead use mainline). Just use b4 and everything should be
fine, although remember about `b4 prep --auto-to-cc` if you added new
patches to the patchset.

You missed at least devicetree list (maybe more), so this won't be
tested by automated tooling. Performing review on untested code might be
a waste of time.

Please kindly resend and include all necessary To/Cc entries.
</form letter>

Best regards,
Krzysztof

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

Thanks Krzysztof for the review.

On 8/30/2024 1:41 PM, Krzysztof Kozlowski wrote:
> On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
>> Adds qcom,shared-se flag usage. Use this when particular I2C serial
>> controller needs to be shared between two subsystems.
>>
>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
>> ---
>>   Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml | 4 ++++
>>   1 file changed, 4 insertions(+)
> 
> <form letter>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC. It might happen, that command when run on an older
> kernel, gives you outdated entries. Therefore please be sure you base
> your patches on recent Linux kernel.
> 
Sorry, i forgot to add list for different SS. I am adding all 
maintainers and list after running maintainers scripts on each patch.

> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
> people, so fix your workflow. Tools might also fail if you work on some
> ancient tree (don't, instead use mainline) or work on fork of kernel
> (don't, instead use mainline). Just use b4 and everything should be
> fine, although remember about `b4 prep --auto-to-cc` if you added new
> patches to the patchset.
> 
> You missed at least devicetree list (maybe more), so this won't be
> tested by automated tooling. Performing review on untested code might be
> a waste of time.
> 

You mean flag addition into DTSI file ? If yes, then the intention was 
to just enable feature support but not into mainline because it should 
happen per board or usecase. Please suggest if i can enable particular 
node with DTSI feature flag.
Please correct me if my understanding on your ask went wrong.
> Please kindly resend and include all necessary To/Cc entries.
> </form letter>
> 
> Best regards,
> Krzysztof
> 
> 

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Krzysztof Kozlowski]

On 04/09/2024 20:12, Mukesh Kumar Savaliya wrote:
>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>> people, so fix your workflow. Tools might also fail if you work on some
>> ancient tree (don't, instead use mainline) or work on fork of kernel
>> (don't, instead use mainline). Just use b4 and everything should be
>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>> patches to the patchset.
>>
>> You missed at least devicetree list (maybe more), so this won't be
>> tested by automated tooling. Performing review on untested code might be
>> a waste of time.
>>
> 
> You mean flag addition into DTSI file ? If yes, then the intention was 
> to just enable feature support but not into mainline because it should 
> happen per board or usecase. Please suggest if i can enable particular 
> node with DTSI feature flag.
> Please correct me if my understanding on your ask went wrong.

How is this related?

Best regards,
Krzysztof

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

On 9/4/2024 11:50 PM, Krzysztof Kozlowski wrote:
> On 04/09/2024 20:12, Mukesh Kumar Savaliya wrote:
>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>>> people, so fix your workflow. Tools might also fail if you work on some
>>> ancient tree (don't, instead use mainline) or work on fork of kernel
>>> (don't, instead use mainline). Just use b4 and everything should be
>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>>> patches to the patchset.
>>>
>>> You missed at least devicetree list (maybe more), so this won't be
>>> tested by automated tooling. Performing review on untested code might be
>>> a waste of time.
>>>
>>
>> You mean flag addition into DTSI file ? If yes, then the intention was
>> to just enable feature support but not into mainline because it should
>> happen per board or usecase. Please suggest if i can enable particular
>> node with DTSI feature flag.
>> Please correct me if my understanding on your ask went wrong.
> 
> How is this related?
"You missed at least devicetree list (maybe more)" - Do you mean to say 
i missed to add DTSI changes OR maintainers for DTSI ? seeking clarity 
to avoid confusion.
> 
> Best regards,
> Krzysztof
> 
> 

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Krzysztof Kozlowski]

On 05/09/2024 07:43, Mukesh Kumar Savaliya wrote:
> 
> 
> On 9/4/2024 11:50 PM, Krzysztof Kozlowski wrote:
>> On 04/09/2024 20:12, Mukesh Kumar Savaliya wrote:
>>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>>>> people, so fix your workflow. Tools might also fail if you work on some
>>>> ancient tree (don't, instead use mainline) or work on fork of kernel
>>>> (don't, instead use mainline). Just use b4 and everything should be
>>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>>>> patches to the patchset.
>>>>
>>>> You missed at least devicetree list (maybe more), so this won't be
>>>> tested by automated tooling. Performing review on untested code might be
>>>> a waste of time.
>>>>
>>>
>>> You mean flag addition into DTSI file ? If yes, then the intention was
>>> to just enable feature support but not into mainline because it should
>>> happen per board or usecase. Please suggest if i can enable particular
>>> node with DTSI feature flag.
>>> Please correct me if my understanding on your ask went wrong.
>>
>> How is this related?
> "You missed at least devicetree list (maybe more)" - Do you mean to say 
> i missed to add DTSI changes OR maintainers for DTSI ? seeking clarity 
> to avoid confusion.

You did not CC maintainers and necessary list. I wrote nothing about
DTSI. You are expected to use tools, not manually come with some address
list.

Best regards,
Krzysztof

Re: [PATCH v1 1/4] dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag

[Mukesh Kumar Savaliya]

On 9/5/2024 11:51 AM, Krzysztof Kozlowski wrote:
> On 05/09/2024 07:43, Mukesh Kumar Savaliya wrote:
>>
>>
>> On 9/4/2024 11:50 PM, Krzysztof Kozlowski wrote:
>>> On 04/09/2024 20:12, Mukesh Kumar Savaliya wrote:
>>>>> Tools like b4 or scripts/get_maintainer.pl provide you proper list of
>>>>> people, so fix your workflow. Tools might also fail if you work on some
>>>>> ancient tree (don't, instead use mainline) or work on fork of kernel
>>>>> (don't, instead use mainline). Just use b4 and everything should be
>>>>> fine, although remember about `b4 prep --auto-to-cc` if you added new
>>>>> patches to the patchset.
>>>>>
>>>>> You missed at least devicetree list (maybe more), so this won't be
>>>>> tested by automated tooling. Performing review on untested code might be
>>>>> a waste of time.
>>>>>
>>>>
>>>> You mean flag addition into DTSI file ? If yes, then the intention was
>>>> to just enable feature support but not into mainline because it should
>>>> happen per board or usecase. Please suggest if i can enable particular
>>>> node with DTSI feature flag.
>>>> Please correct me if my understanding on your ask went wrong.
>>>
>>> How is this related?
>> "You missed at least devicetree list (maybe more)" - Do you mean to say
>> i missed to add DTSI changes OR maintainers for DTSI ? seeking clarity
>> to avoid confusion.
> 
> You did not CC maintainers and necessary list. I wrote nothing about
> DTSI. You are expected to use tools, not manually come with some address
> list.
> 
Got it, yes, i missed to add necessary list subsystem wise, sorry. 
Thanks Krzysztof.
> Best regards,
> Krzysztof
> 

[PATCH v1 2/4] dma: gpi: Add Lock and Unlock TRE support to access SE exclusively

[Mukesh Kumar Savaliya]

GSI DMA provides specific TREs namely Lock and Unlock TRE, which
provides mutual exclusive access to SE from any of the subsystem
(E.g. Apps, TZ, ADSP etc). Lock prevents other subsystems from
concurrently performing DMA transfers and avoids disturbance to
data path. Basically lock the SE for particular subsystem, complete
the transfer, unlock the SE.

Apply Lock TRE for the first transfer of shared SE and Apply Unlock
TRE for the last transfer.

Also change MAX_TRE macro to 5 from 3 because of the two additional TREs.

Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
---
 drivers/dma/qcom/gpi.c           | 37 +++++++++++++++++++++++++++++++-
 include/linux/dma/qcom-gpi-dma.h |  6 ++++++
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
index e6ebd688d746..ba11b2641ab6 100644
--- a/drivers/dma/qcom/gpi.c
+++ b/drivers/dma/qcom/gpi.c
@@ -2,6 +2,7 @@
 /*
  * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
  * Copyright (c) 2020, Linaro Limited
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
  */
 
 #include <dt-bindings/dma/qcom-gpi.h>
@@ -65,6 +66,14 @@
 /* DMA TRE */
 #define TRE_DMA_LEN		GENMASK(23, 0)
 
+/* Lock TRE */
+#define TRE_I2C_LOCK		BIT(0)
+#define TRE_MINOR_TYPE		GENMASK(19, 16)
+#define TRE_MAJOR_TYPE		GENMASK(23, 20)
+
+/* Unlock TRE */
+#define TRE_I2C_UNLOCK		BIT(8)
+
 /* Register offsets from gpi-top */
 #define GPII_n_CH_k_CNTXT_0_OFFS(n, k)	(0x20000 + (0x4000 * (n)) + (0x80 * (k)))
 #define GPII_n_CH_k_CNTXT_0_EL_SIZE	GENMASK(31, 24)
@@ -516,7 +525,7 @@ struct gpii {
 	bool ieob_set;
 };
 
-#define MAX_TRE 3
+#define MAX_TRE 5
 
 struct gpi_desc {
 	struct virt_dma_desc vd;
@@ -1637,6 +1646,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc,
 	struct gpi_tre *tre;
 	unsigned int i;
 
+	/* create lock tre for first tranfser */
+	if (i2c->shared_se && i2c->first_msg) {
+		tre = &desc->tre[tre_idx];
+		tre_idx++;
+
+		tre->dword[0] = 0;
+		tre->dword[1] = 0;
+		tre->dword[2] = 0;
+		tre->dword[3] = u32_encode_bits(1, TRE_I2C_LOCK);
+		tre->dword[3] |= u32_encode_bits(0, TRE_MINOR_TYPE);
+		tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
+	}
+
 	/* first create config tre if applicable */
 	if (i2c->set_config) {
 		tre = &desc->tre[tre_idx];
@@ -1695,6 +1717,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc,
 		tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_IEOT);
 	}
 
+	/* Unlock tre for last transfer */
+	if (i2c->shared_se && i2c->last_msg && i2c->op != I2C_READ) {
+		tre = &desc->tre[tre_idx];
+		tre_idx++;
+
+		tre->dword[0] = 0;
+		tre->dword[1] = 0;
+		tre->dword[2] = 0;
+		tre->dword[3] = u32_encode_bits(1, TRE_I2C_UNLOCK);
+		tre->dword[3] |= u32_encode_bits(1, TRE_MINOR_TYPE);
+		tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
+	}
+
 	for (i = 0; i < tre_idx; i++)
 		dev_dbg(dev, "TRE:%d %x:%x:%x:%x\n", i, desc->tre[i].dword[0],
 			desc->tre[i].dword[1], desc->tre[i].dword[2], desc->tre[i].dword[3]);
diff --git a/include/linux/dma/qcom-gpi-dma.h b/include/linux/dma/qcom-gpi-dma.h
index 6680dd1a43c6..8589c711afae 100644
--- a/include/linux/dma/qcom-gpi-dma.h
+++ b/include/linux/dma/qcom-gpi-dma.h
@@ -65,6 +65,9 @@ enum i2c_op {
  * @rx_len: receive length for buffer
  * @op: i2c cmd
  * @muli-msg: is part of multi i2c r-w msgs
+ * @shared_se: bus is shared between subsystems
+ * @bool first_msg: use it for tracking multimessage xfer
+ * @bool last_msg: use it for tracking multimessage xfer
  */
 struct gpi_i2c_config {
 	u8 set_config;
@@ -78,6 +81,9 @@ struct gpi_i2c_config {
 	u32 rx_len;
 	enum i2c_op op;
 	bool multi_msg;
+	bool shared_se;
+	bool first_msg;
+	bool last_msg;
 };
 
 #endif /* QCOM_GPI_DMA_H */
-- 
2.25.1

Re: [PATCH v1 2/4] dma: gpi: Add Lock and Unlock TRE support to access SE exclusively

[Bryan O'Donoghue]

On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
> GSI DMA provides specific TREs namely Lock and Unlock TRE, which
> provides mutual exclusive access to SE from any of the subsystem
> (E.g. Apps, TZ, ADSP etc). Lock prevents other subsystems from
> concurrently performing DMA transfers and avoids disturbance to
> data path. Basically lock the SE for particular subsystem, complete
> the transfer, unlock the SE.
> 
> Apply Lock TRE for the first transfer of shared SE and Apply Unlock
> TRE for the last transfer.
> 
> Also change MAX_TRE macro to 5 from 3 because of the two additional TREs.
> 
> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
> ---
>   drivers/dma/qcom/gpi.c           | 37 +++++++++++++++++++++++++++++++-
>   include/linux/dma/qcom-gpi-dma.h |  6 ++++++
>   2 files changed, 42 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
> index e6ebd688d746..ba11b2641ab6 100644
> --- a/drivers/dma/qcom/gpi.c
> +++ b/drivers/dma/qcom/gpi.c
> @@ -2,6 +2,7 @@
>   /*
>    * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
>    * Copyright (c) 2020, Linaro Limited
> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>    */
>   
>   #include <dt-bindings/dma/qcom-gpi.h>
> @@ -65,6 +66,14 @@
>   /* DMA TRE */
>   #define TRE_DMA_LEN		GENMASK(23, 0)
>   
> +/* Lock TRE */
> +#define TRE_I2C_LOCK		BIT(0)
> +#define TRE_MINOR_TYPE		GENMASK(19, 16)
> +#define TRE_MAJOR_TYPE		GENMASK(23, 20)
> +
> +/* Unlock TRE */
> +#define TRE_I2C_UNLOCK		BIT(8)
> +
>   /* Register offsets from gpi-top */
>   #define GPII_n_CH_k_CNTXT_0_OFFS(n, k)	(0x20000 + (0x4000 * (n)) + (0x80 * (k)))
>   #define GPII_n_CH_k_CNTXT_0_EL_SIZE	GENMASK(31, 24)
> @@ -516,7 +525,7 @@ struct gpii {
>   	bool ieob_set;
>   };
>   
> -#define MAX_TRE 3
> +#define MAX_TRE 5
>   
>   struct gpi_desc {
>   	struct virt_dma_desc vd;
> @@ -1637,6 +1646,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc,
>   	struct gpi_tre *tre;
>   	unsigned int i;
>   
> +	/* create lock tre for first tranfser */
> +	if (i2c->shared_se && i2c->first_msg) {
> +		tre = &desc->tre[tre_idx];
> +		tre_idx++;
> +
> +		tre->dword[0] = 0;
> +		tre->dword[1] = 0;
> +		tre->dword[2] = 0;
> +		tre->dword[3] = u32_encode_bits(1, TRE_I2C_LOCK);
> +		tre->dword[3] |= u32_encode_bits(0, TRE_MINOR_TYPE);
> +		tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
> +	}
> +
>   	/* first create config tre if applicable */
>   	if (i2c->set_config) {
>   		tre = &desc->tre[tre_idx];
> @@ -1695,6 +1717,19 @@ static int gpi_create_i2c_tre(struct gchan *chan, struct gpi_desc *desc,
>   		tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_IEOT);
>   	}
>   
> +	/* Unlock tre for last transfer */
> +	if (i2c->shared_se && i2c->last_msg && i2c->op != I2C_READ) {
> +		tre = &desc->tre[tre_idx];
> +		tre_idx++;
> +
> +		tre->dword[0] = 0;
> +		tre->dword[1] = 0;
> +		tre->dword[2] = 0;
> +		tre->dword[3] = u32_encode_bits(1, TRE_I2C_UNLOCK);
> +		tre->dword[3] |= u32_encode_bits(1, TRE_MINOR_TYPE);
> +		tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
> +	}
> +

What happens if the first transfer succeeds => bus lock but the last 
transfer fails => !unlock ?

Is the SE left in a locked state ?

---
bod

Re: [PATCH v1 2/4] dma: gpi: Add Lock and Unlock TRE support to access SE exclusively

[Mukesh Kumar Savaliya]

On 8/29/2024 3:35 PM, Bryan O'Donoghue wrote:
> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>> GSI DMA provides specific TREs namely Lock and Unlock TRE, which
>> provides mutual exclusive access to SE from any of the subsystem
>> (E.g. Apps, TZ, ADSP etc). Lock prevents other subsystems from
>> concurrently performing DMA transfers and avoids disturbance to
>> data path. Basically lock the SE for particular subsystem, complete
>> the transfer, unlock the SE.
>>
>> Apply Lock TRE for the first transfer of shared SE and Apply Unlock
>> TRE for the last transfer.
>>
>> Also change MAX_TRE macro to 5 from 3 because of the two additional TREs.
>>
>> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
>> ---
>>   drivers/dma/qcom/gpi.c           | 37 +++++++++++++++++++++++++++++++-
>>   include/linux/dma/qcom-gpi-dma.h |  6 ++++++
>>   2 files changed, 42 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/dma/qcom/gpi.c b/drivers/dma/qcom/gpi.c
>> index e6ebd688d746..ba11b2641ab6 100644
>> --- a/drivers/dma/qcom/gpi.c
>> +++ b/drivers/dma/qcom/gpi.c
>> @@ -2,6 +2,7 @@
>>   /*
>>    * Copyright (c) 2017-2020, The Linux Foundation. All rights reserved.
>>    * Copyright (c) 2020, Linaro Limited
>> + * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights 
>> reserved.
>>    */
>>   #include <dt-bindings/dma/qcom-gpi.h>
>> @@ -65,6 +66,14 @@
>>   /* DMA TRE */
>>   #define TRE_DMA_LEN        GENMASK(23, 0)
>> +/* Lock TRE */
>> +#define TRE_I2C_LOCK        BIT(0)
>> +#define TRE_MINOR_TYPE        GENMASK(19, 16)
>> +#define TRE_MAJOR_TYPE        GENMASK(23, 20)
>> +
>> +/* Unlock TRE */
>> +#define TRE_I2C_UNLOCK        BIT(8)
>> +
>>   /* Register offsets from gpi-top */
>>   #define GPII_n_CH_k_CNTXT_0_OFFS(n, k)    (0x20000 + (0x4000 * (n)) 
>> + (0x80 * (k)))
>>   #define GPII_n_CH_k_CNTXT_0_EL_SIZE    GENMASK(31, 24)
>> @@ -516,7 +525,7 @@ struct gpii {
>>       bool ieob_set;
>>   };
>> -#define MAX_TRE 3
>> +#define MAX_TRE 5
>>   struct gpi_desc {
>>       struct virt_dma_desc vd;
>> @@ -1637,6 +1646,19 @@ static int gpi_create_i2c_tre(struct gchan 
>> *chan, struct gpi_desc *desc,
>>       struct gpi_tre *tre;
>>       unsigned int i;
>> +    /* create lock tre for first tranfser */
>> +    if (i2c->shared_se && i2c->first_msg) {
>> +        tre = &desc->tre[tre_idx];
>> +        tre_idx++;
>> +
>> +        tre->dword[0] = 0;
>> +        tre->dword[1] = 0;
>> +        tre->dword[2] = 0;
>> +        tre->dword[3] = u32_encode_bits(1, TRE_I2C_LOCK);
>> +        tre->dword[3] |= u32_encode_bits(0, TRE_MINOR_TYPE);
>> +        tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
>> +    }
>> +
>>       /* first create config tre if applicable */
>>       if (i2c->set_config) {
>>           tre = &desc->tre[tre_idx];
>> @@ -1695,6 +1717,19 @@ static int gpi_create_i2c_tre(struct gchan 
>> *chan, struct gpi_desc *desc,
>>           tre->dword[3] |= u32_encode_bits(1, TRE_FLAGS_IEOT);
>>       }
>> +    /* Unlock tre for last transfer */
>> +    if (i2c->shared_se && i2c->last_msg && i2c->op != I2C_READ) {
>> +        tre = &desc->tre[tre_idx];
>> +        tre_idx++;
>> +
>> +        tre->dword[0] = 0;
>> +        tre->dword[1] = 0;
>> +        tre->dword[2] = 0;
>> +        tre->dword[3] = u32_encode_bits(1, TRE_I2C_UNLOCK);
>> +        tre->dword[3] |= u32_encode_bits(1, TRE_MINOR_TYPE);
>> +        tre->dword[3] |= u32_encode_bits(3, TRE_MAJOR_TYPE);
>> +    }
>> +
> 
> What happens if the first transfer succeeds => bus lock but the last 
> transfer fails => !unlock ?
> 
> Is the SE left in a locked state ?
> 
Here, it's GSI running the transfer descriptors and if it fails, we do 
dmaengine_terminate_sync() at i2c client side. It clears the descriptors 
and unmaps the buffer. SE remains in unlocked like initial state.
> ---
> bod

[PATCH v1 3/4] soc: qcom: geni-se: Export function geni_se_clks_off()

[Mukesh Kumar Savaliya]

Currently driver provides geni_se_resources_off() function to turn
off SE resources like clocks, pinctrl. But we don't have function to
control clock separately, hence export function geni_se_clks_off()
to turn off clocks separately without disturbing GPIO.

The client drivers like i2c requires this function for use case where
i2c SE is shared between two subsystems.

Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
---
 drivers/soc/qcom/qcom-geni-se.c  | 4 +++-
 include/linux/soc/qcom/geni-se.h | 3 +++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
index 2e8f24d5da80..20166c8fc919 100644
--- a/drivers/soc/qcom/qcom-geni-se.c
+++ b/drivers/soc/qcom/qcom-geni-se.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+// Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
 
 /* Disable MMIO tracing to prevent excessive logging of unwanted MMIO traces */
 #define __DISABLE_TRACE_MMIO__
@@ -482,13 +483,14 @@ void geni_se_config_packing(struct geni_se *se, int bpw, int pack_words,
 }
 EXPORT_SYMBOL_GPL(geni_se_config_packing);
 
-static void geni_se_clks_off(struct geni_se *se)
+void geni_se_clks_off(struct geni_se *se)
 {
 	struct geni_wrapper *wrapper = se->wrapper;
 
 	clk_disable_unprepare(se->clk);
 	clk_bulk_disable_unprepare(wrapper->num_clks, wrapper->clks);
 }
+EXPORT_SYMBOL_GPL(geni_se_clks_off);
 
 /**
  * geni_se_resources_off() - Turn off resources associated with the serial
diff --git a/include/linux/soc/qcom/geni-se.h b/include/linux/soc/qcom/geni-se.h
index 0f038a1a0330..caf2c0c4505b 100644
--- a/include/linux/soc/qcom/geni-se.h
+++ b/include/linux/soc/qcom/geni-se.h
@@ -1,6 +1,7 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
  * Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
  */
 
 #ifndef _LINUX_QCOM_GENI_SE
@@ -494,6 +495,8 @@ int geni_se_resources_off(struct geni_se *se);
 
 int geni_se_resources_on(struct geni_se *se);
 
+void geni_se_clks_off(struct geni_se *se);
+
 int geni_se_clk_tbl_get(struct geni_se *se, unsigned long **tbl);
 
 int geni_se_clk_freq_match(struct geni_se *se, unsigned long req_freq,
-- 
2.25.1

Re: [PATCH v1 3/4] soc: qcom: geni-se: Export function geni_se_clks_off()

[Bryan O'Donoghue]

On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
> Currently driver provides geni_se_resources_off() function to turn
> off SE resources like clocks, pinctrl. But we don't have function to
> control clock separately, hence export function geni_se_clks_off()
> to turn off clocks separately without disturbing GPIO.
> 
> The client drivers like i2c requires this function for use case where
> i2c SE is shared between two subsystems.
> 
> Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>

Suggest:

Currently the driver provides a function called 
geni_serial_resources_off() to turn off resources like clocks and 
pinctrl. We don't have a function to control clocks separately hence, 
export the function geni_se_clks_off() to turn off clocks separately 
without disturbing GPIO.

Client drivers like I2C require this function for use-cases where the 
I2C SE is shared between two subsystems.

> ---
>   drivers/soc/qcom/qcom-geni-se.c  | 4 +++-
>   include/linux/soc/qcom/geni-se.h | 3 +++
>   2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/soc/qcom/qcom-geni-se.c b/drivers/soc/qcom/qcom-geni-se.c
> index 2e8f24d5da80..20166c8fc919 100644
> --- a/drivers/soc/qcom/qcom-geni-se.c
> +++ b/drivers/soc/qcom/qcom-geni-se.c
> @@ -1,5 +1,6 @@
>   // SPDX-License-Identifier: GPL-2.0
>   // Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
> +// Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>   
>   /* Disable MMIO tracing to prevent excessive logging of unwanted MMIO traces */
>   #define __DISABLE_TRACE_MMIO__
> @@ -482,13 +483,14 @@ void geni_se_config_packing(struct geni_se *se, int bpw, int pack_words,
>   }
>   EXPORT_SYMBOL_GPL(geni_se_config_packing);
>   
> -static void geni_se_clks_off(struct geni_se *se)
> +void geni_se_clks_off(struct geni_se *se)
>   {
>   	struct geni_wrapper *wrapper = se->wrapper;
>   
>   	clk_disable_unprepare(se->clk);
>   	clk_bulk_disable_unprepare(wrapper->num_clks, wrapper->clks);
>   }
> +EXPORT_SYMBOL_GPL(geni_se_clks_off);
>

Does it make sense to have geni_se_clks_off() exported without having 
geni_se_clks_on() similarly exported ?

Two exported functions already appear to wrapper this functionality for you.

geni_se_resources_off -> gensi_se_clks_off
geni_se_resources_on -> gensi_se_clks_on

Seems like a usage violation to have geni_se_resources_on() switch the 
clocks on but then have something else directly call gensi_se_clks_off() 
without going through geni_se_resources_off();

?

---
bod

Re: [PATCH v1 3/4] soc: qcom: geni-se: Export function geni_se_clks_off()

[Mukesh Kumar Savaliya]

On 8/29/2024 3:49 PM, Bryan O'Donoghue wrote:
> Suggest:
> 
> Currently the driver provides a function called 
> geni_serial_resources_off() to turn off resources like clocks and 
> pinctrl. We don't have a function to control clocks separately hence, 
> export the function geni_se_clks_off() to turn off clocks separately 
> without disturbing GPIO.
> 
> Client drivers like I2C require this function for use-cases where the 
> I2C SE is shared between two subsystems.
ACKed.

[PATCH v1 4/4] i2c: i2c-qcom-geni: Enable i2c controller sharing between two subsystems

[Mukesh Kumar Savaliya]

Add support to share I2C SE by two Subsystems in a mutually exclusive way.
Use  "qcom,shared-se" flag in a particular i2c instance node if the
usecase requires i2c controller to be shared.

I2C driver just need to mark first_msg and last_msg flag to help indicate
GPI driver to  take lock and unlock TRE there by protecting from concurrent
access from other EE or Subsystem.

gpi_create_i2c_tre() function at gpi.c will take care of adding Lock and
Unlock TRE for the respective transfer operations.

Since the GPIOs are also shared for the i2c bus between two SS, do not
touch GPIO configuration during runtime suspend and only turn off the
clocks. This will allow other SS to continue to transfer the data
without any disturbance over the IO lines.

Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
---
 drivers/i2c/busses/i2c-qcom-geni.c | 29 ++++++++++++++++++++++-------
 1 file changed, 22 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index eebb0cbb6ca4..ee2e431601a6 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -1,5 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 // Copyright (c) 2017-2018, The Linux Foundation. All rights reserved.
+// Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
 
 #include <linux/acpi.h>
 #include <linux/clk.h>
@@ -99,6 +100,7 @@ struct geni_i2c_dev {
 	struct dma_chan *rx_c;
 	bool gpi_mode;
 	bool abort_done;
+	bool is_shared;
 };
 
 struct geni_i2c_desc {
@@ -602,6 +604,7 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
 	peripheral.clk_div = itr->clk_div;
 	peripheral.set_config = 1;
 	peripheral.multi_msg = false;
+	peripheral.shared_se = gi2c->is_shared;
 
 	for (i = 0; i < num; i++) {
 		gi2c->cur = &msgs[i];
@@ -612,6 +615,8 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
 		if (i < num - 1)
 			peripheral.stretch = 1;
 
+		peripheral.first_msg = (i == 0);
+		peripheral.last_msg = (i == num - 1);
 		peripheral.addr = msgs[i].addr;
 
 		ret =  geni_i2c_gpi(gi2c, &msgs[i], &config,
@@ -631,8 +636,11 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, struct i2c_msg msgs[], i
 		dma_async_issue_pending(gi2c->tx_c);
 
 		time_left = wait_for_completion_timeout(&gi2c->done, XFER_TIMEOUT);
-		if (!time_left)
+		if (!time_left) {
+			dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d addr:0x%x\n",
+						gi2c->cur->flags, gi2c->cur->addr);
 			gi2c->err = -ETIMEDOUT;
+		}
 
 		if (gi2c->err) {
 			ret = gi2c->err;
@@ -800,6 +808,11 @@ static int geni_i2c_probe(struct platform_device *pdev)
 		gi2c->clk_freq_out = KHZ(100);
 	}
 
+	if (of_property_read_bool(pdev->dev.of_node, "qcom,shared-se")) {
+		gi2c->is_shared = true;
+		dev_dbg(&pdev->dev, "Shared SE Usecase\n");
+	}
+
 	if (has_acpi_companion(dev))
 		ACPI_COMPANION_SET(&gi2c->adap.dev, ACPI_COMPANION(dev));
 
@@ -962,14 +975,16 @@ static int __maybe_unused geni_i2c_runtime_suspend(struct device *dev)
 	struct geni_i2c_dev *gi2c = dev_get_drvdata(dev);
 
 	disable_irq(gi2c->irq);
-	ret = geni_se_resources_off(&gi2c->se);
-	if (ret) {
-		enable_irq(gi2c->irq);
-		return ret;
-
+	if (gi2c->is_shared) {
+		geni_se_clks_off(&gi2c->se);
 	} else {
-		gi2c->suspended = 1;
+		ret = geni_se_resources_off(&gi2c->se);
+		if (ret) {
+			enable_irq(gi2c->irq);
+			return ret;
+		}
 	}
+	gi2c->suspended = 1;
 
 	clk_disable_unprepare(gi2c->core_clk);
 
-- 
2.25.1

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Bryan O'Donoghue]

On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
> This Series adds support to share QUP based I2C SE between subsystems.
> Each subsystem should have its own GPII which interacts between SE and
> GSI DMA HW engine.

What is SE ?

GPII - general purpose interrupt ... ?

You have too many acronyms here, which makes reading and understanding 
your cover letter a bit hard.

Please define at least the term SE in your cover letter and in your patch.

In the patch you use the term TRE which without diving into the code I 
vaguely remember is a register..

- GPII
- GSI
- SE
- TRE

Need to be defined to make what's going on in this series more "grokable".

A cover letter should assume a reviewer is familiar with the basics of a 
system - no need to define what I2C is but, similarly shouldn't assume a 
reviewer is numerate in the taxonomy of vendor specific architecture 
e.g. whats SE ?

---
bod

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Mukesh Kumar Savaliya]

On 8/29/2024 3:26 PM, Bryan O'Donoghue wrote:
> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>> This Series adds support to share QUP based I2C SE between subsystems.
>> Each subsystem should have its own GPII which interacts between SE and
>> GSI DMA HW engine.
> 
> What is SE ?
> 
> GPII - general purpose interrupt ... ?
> 
> You have too many acronyms here, which makes reading and understanding 
> your cover letter a bit hard.
> 
> Please define at least the term SE in your cover letter and in your patch.
> 
> In the patch you use the term TRE which without diving into the code I 
> vaguely remember is a register..
> 
> - GPII
> - GSI
> - SE
> - TRE
> 
> Need to be defined to make what's going on in this series more "grokable".
> 
> A cover letter should assume a reviewer is familiar with the basics of a 
> system - no need to define what I2C is but, similarly shouldn't assume a 
> reviewer is numerate in the taxonomy of vendor specific architecture 
> e.g. whats SE ?
> 
> ---
Sure,  Understood what to mention instead of short names. Let me have 
cover letter and upload next patch.
> bod

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Bryan O'Donoghue]

On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
> This Series adds support to share QUP based I2C SE between subsystems.
> Each subsystem should have its own GPII which interacts between SE and
> GSI DMA HW engine.
> 
> Subsystem must acquire Lock over the SE on GPII channel so that it
> gets uninterrupted control till it unlocks the SE. It also makes sure
> the commonly shared TLMM GPIOs are not touched which can impact other
> subsystem or cause any interruption. Generally, GPIOs are being
> unconfigured during suspend time.
> 
> GSI DMA engine is capable to perform requested transfer operations
> from any of the SE in a seamless way and its transparent to the
> subsystems. Make sure to enable “qcom,shared-se” flag only while
> enabling this feature. I2C client should add in its respective parent
> node.
> 
> ---
> Mukesh Kumar Savaliya (4):
>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>    soc: qcom: geni-se: Export function geni_se_clks_off()
>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>      subsystems
> 
>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>   drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>   include/linux/soc/qcom/geni-se.h              |  3 ++
>   6 files changed, 74 insertions(+), 9 deletions(-)
> 

In the cover letter please give an example of Serial Engine sharing.

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Mukesh Kumar Savaliya]

On 8/29/2024 3:40 PM, Bryan O'Donoghue wrote:
> On 29/08/2024 10:24, Mukesh Kumar Savaliya wrote:
>> This Series adds support to share QUP based I2C SE between subsystems.
>> Each subsystem should have its own GPII which interacts between SE and
>> GSI DMA HW engine.
>>
>> Subsystem must acquire Lock over the SE on GPII channel so that it
>> gets uninterrupted control till it unlocks the SE. It also makes sure
>> the commonly shared TLMM GPIOs are not touched which can impact other
>> subsystem or cause any interruption. Generally, GPIOs are being
>> unconfigured during suspend time.
>>
>> GSI DMA engine is capable to perform requested transfer operations
>> from any of the SE in a seamless way and its transparent to the
>> subsystems. Make sure to enable “qcom,shared-se” flag only while
>> enabling this feature. I2C client should add in its respective parent
>> node.
>>
>> ---
>> Mukesh Kumar Savaliya (4):
>>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>>    soc: qcom: geni-se: Export function geni_se_clks_off()
>>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>>      subsystems
>>
>>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>>   drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>>   include/linux/soc/qcom/geni-se.h              |  3 ++
>>   6 files changed, 74 insertions(+), 9 deletions(-)
>>
> 
> In the cover letter please give an example of Serial Engine sharing.
> 
Sure Bryan, Noted. In next patch will update in cover letter.
> 
> 

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Vinod Koul]

On 29-08-24, 14:54, Mukesh Kumar Savaliya wrote:
> This Series adds support to share QUP based I2C SE between subsystems.
> Each subsystem should have its own GPII which interacts between SE and
> GSI DMA HW engine.
> 
> Subsystem must acquire Lock over the SE on GPII channel so that it
> gets uninterrupted control till it unlocks the SE. It also makes sure
> the commonly shared TLMM GPIOs are not touched which can impact other
> subsystem or cause any interruption. Generally, GPIOs are being
> unconfigured during suspend time. 

Most of the use case it is either I2C using it or some other peripheral
using it, so who are you protecting the channel with this locking
mechanism?

> GSI DMA engine is capable to perform requested transfer operations
> from any of the SE in a seamless way and its transparent to the
> subsystems. Make sure to enable “qcom,shared-se” flag only while
> enabling this feature. I2C client should add in its respective parent
> node.

Why should this be expose to peripheral drivers and not handled
internally inside dma driver, you lock, submit the txn to engine and
then unlock when txn is processed, why should this be exposed to
clients?

> 
> ---
> Mukesh Kumar Savaliya (4):
>   dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>   dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>   soc: qcom: geni-se: Export function geni_se_clks_off()
>   i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>     subsystems
> 
>  .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>  drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>  drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>  drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>  include/linux/dma/qcom-gpi-dma.h              |  6 +++
>  include/linux/soc/qcom/geni-se.h              |  3 ++
>  6 files changed, 74 insertions(+), 9 deletions(-)
> 
> -- 
> 2.25.1
> 

-- 
~Vinod

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[neil.armstrong]

Hi,

On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
> This Series adds support to share QUP based I2C SE between subsystems.
> Each subsystem should have its own GPII which interacts between SE and
> GSI DMA HW engine.
> 
> Subsystem must acquire Lock over the SE on GPII channel so that it
> gets uninterrupted control till it unlocks the SE. It also makes sure
> the commonly shared TLMM GPIOs are not touched which can impact other
> subsystem or cause any interruption. Generally, GPIOs are being
> unconfigured during suspend time.
> 
> GSI DMA engine is capable to perform requested transfer operations
> from any of the SE in a seamless way and its transparent to the
> subsystems. Make sure to enable “qcom,shared-se” flag only while
> enabling this feature. I2C client should add in its respective parent
> node.
> 
> ---
> Mukesh Kumar Savaliya (4):
>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>    soc: qcom: geni-se: Export function geni_se_clks_off()
>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>      subsystems
> 
>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>   drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>   include/linux/soc/qcom/geni-se.h              |  3 ++
>   6 files changed, 74 insertions(+), 9 deletions(-)
> 

I see in downstream that this flag is used on the SM8650 qupv3_se6_i2c,
and that on the SM8650-HDK this i2c is shared between the aDSP battmgr and
the linux to access the HDMI controller.

Is this is the target use-case ?

We have some issues on this platform that crashes the system when Linux
does some I2C transfers while battmgr does some access at the same time,
the problem is that on the Linux side the i2c uses the SE DMA and not GPI
because fifo_disable=0 so by default this bypasses GPI.

A temporary fix has been merged:
https://lore.kernel.org/all/20240605-topic-sm8650-upstream-hdk-iommu-fix-v1-1-9fd7233725fa@linaro.org/
but it's clearly not a real solution

What would be the solution to use the shared i2c with on one side battmgr
using GPI and the kernel using SE DMA ?

In this case, shouldn't we force using GPI on linux with:
==============><=====================================================================
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
index ee2e431601a6..a15825ea56de 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -885,7 +885,7 @@ static int geni_i2c_probe(struct platform_device *pdev)
         else
                 fifo_disable = readl_relaxed(gi2c->se.base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;

-       if (fifo_disable) {
+       if (gi2c->is_shared || fifo_disable) {
                 /* FIFO is disabled, so we can only use GPI DMA */
                 gi2c->gpi_mode = true;
                 ret = setup_gpi_dma(gi2c);
==============><=====================================================================

Neil

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Mukesh Kumar Savaliya]

Thanks Neil !

On 8/30/2024 1:17 PM, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
>> This Series adds support to share QUP based I2C SE between subsystems.
>> Each subsystem should have its own GPII which interacts between SE and
>> GSI DMA HW engine.
>>
>> Subsystem must acquire Lock over the SE on GPII channel so that it
>> gets uninterrupted control till it unlocks the SE. It also makes sure
>> the commonly shared TLMM GPIOs are not touched which can impact other
>> subsystem or cause any interruption. Generally, GPIOs are being
>> unconfigured during suspend time.
>>
>> GSI DMA engine is capable to perform requested transfer operations
>> from any of the SE in a seamless way and its transparent to the
>> subsystems. Make sure to enable “qcom,shared-se” flag only while
>> enabling this feature. I2C client should add in its respective parent
>> node.
>>
>> ---
>> Mukesh Kumar Savaliya (4):
>>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>>    soc: qcom: geni-se: Export function geni_se_clks_off()
>>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>>      subsystems
>>
>>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>>   drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>>   include/linux/soc/qcom/geni-se.h              |  3 ++
>>   6 files changed, 74 insertions(+), 9 deletions(-)
>>
> 
> I see in downstream that this flag is used on the SM8650 qupv3_se6_i2c,
> and that on the SM8650-HDK this i2c is shared between the aDSP battmgr and
> the linux to access the HDMI controller.
> 
> Is this is the target use-case ?
Not exactly that usecase. Here making it generic in a way to transfer 
data which is pushed from two subsystems independently. Consider for 
example one is ADSP i2c client and another is Linux i2c client. Not sure 
in what manner battmgr and HDMI sends traffic. we can debug it 
separately over that email.
> 
> We have some issues on this platform that crashes the system when Linux
> does some I2C transfers while battmgr does some access at the same time,
> the problem is that on the Linux side the i2c uses the SE DMA and not GPI
> because fifo_disable=0 so by default this bypasses GPI.
> 
> A temporary fix has been merged:
> https://lore.kernel.org/all/20240605-topic-sm8650-upstream-hdk-iommu-fix-v1-1-9fd7233725fa@linaro.org/
> but it's clearly not a real solution
> 
Seems you have added SID for the GPII being used from linux side. Need 
to know why you have added it and is it helping ? I have sent an email 
to know more about this issue before 2 weeks.

> What would be the solution to use the shared i2c with on one side battmgr
> using GPI and the kernel using SE DMA ?
> 
I have already sent an email on this issue, please respond on it. We 
shall debug it separately since this feature about sharing is still 
under implementation as you know about this patch series.

> In this case, shouldn't we force using GPI on linux with:
> ==============><=====================================================================
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index ee2e431601a6..a15825ea56de 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -885,7 +885,7 @@ static int geni_i2c_probe(struct platform_device *pdev)
>          else
>                  fifo_disable = readl_relaxed(gi2c->se.base + 
> GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
> 
> -       if (fifo_disable) {
> +       if (gi2c->is_shared || fifo_disable) {
>                  /* FIFO is disabled, so we can only use GPI DMA */
>                  gi2c->gpi_mode = true;
>                  ret = setup_gpi_dma(gi2c);
> ==============><=====================================================================
> 
> Neil

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[neil.armstrong]

Hi,

On 04/09/2024 20:07, Mukesh Kumar Savaliya wrote:
> Thanks Neil !
> 
> On 8/30/2024 1:17 PM, neil.armstrong@linaro.org wrote:
>> Hi,
>>
>> On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
>>> This Series adds support to share QUP based I2C SE between subsystems.
>>> Each subsystem should have its own GPII which interacts between SE and
>>> GSI DMA HW engine.
>>>
>>> Subsystem must acquire Lock over the SE on GPII channel so that it
>>> gets uninterrupted control till it unlocks the SE. It also makes sure
>>> the commonly shared TLMM GPIOs are not touched which can impact other
>>> subsystem or cause any interruption. Generally, GPIOs are being
>>> unconfigured during suspend time.
>>>
>>> GSI DMA engine is capable to perform requested transfer operations
>>> from any of the SE in a seamless way and its transparent to the
>>> subsystems. Make sure to enable “qcom,shared-se” flag only while
>>> enabling this feature. I2C client should add in its respective parent
>>> node.
>>>
>>> ---
>>> Mukesh Kumar Savaliya (4):
>>>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>>>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>>>    soc: qcom: geni-se: Export function geni_se_clks_off()
>>>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>>>      subsystems
>>>
>>>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>>>   drivers/dma/qcom/gpi.c                        | 37 ++++++++++++++++++-
>>>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>>>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>>>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>>>   include/linux/soc/qcom/geni-se.h              |  3 ++
>>>   6 files changed, 74 insertions(+), 9 deletions(-)
>>>
>>
>> I see in downstream that this flag is used on the SM8650 qupv3_se6_i2c,
>> and that on the SM8650-HDK this i2c is shared between the aDSP battmgr and
>> the linux to access the HDMI controller.
>>
>> Is this is the target use-case ?
> Not exactly that usecase. Here making it generic in a way to transfer data which is pushed from two subsystems independently. Consider for example one is ADSP i2c client and another is Linux i2c client. Not sure in what manner battmgr and HDMI sends traffic. we can debug it separately over that email.

Considering battmgr runs in ADSP, it matches this use-case, no ?

>>
>> We have some issues on this platform that crashes the system when Linux
>> does some I2C transfers while battmgr does some access at the same time,
>> the problem is that on the Linux side the i2c uses the SE DMA and not GPI
>> because fifo_disable=0 so by default this bypasses GPI.
>>
>> A temporary fix has been merged:
>> https://lore.kernel.org/all/20240605-topic-sm8650-upstream-hdk-iommu-fix-v1-1-9fd7233725fa@linaro.org/
>> but it's clearly not a real solution
>>
> Seems you have added SID for the GPII being used from linux side. Need to know why you have added it and is it helping ? I have sent an email to know more about this issue before 2 weeks.

I've added this because it actually avoids crashing when doing I2C6 transactions over SE DMA, now we need to understand why.

> 
>> What would be the solution to use the shared i2c with on one side battmgr
>> using GPI and the kernel using SE DMA ?
>>
> I have already sent an email on this issue, please respond on it. We shall debug it separately since this feature about sharing is still under implementation as you know about this patch series.

Sorry for the delay, I was technically unable to answer, let me resume it now that I'm able again.

Thanks,
Neil

> 
>> In this case, shouldn't we force using GPI on linux with:
>> ==============><=====================================================================
>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c b/drivers/i2c/busses/i2c-qcom-geni.c
>> index ee2e431601a6..a15825ea56de 100644
>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>> @@ -885,7 +885,7 @@ static int geni_i2c_probe(struct platform_device *pdev)
>>          else
>>                  fifo_disable = readl_relaxed(gi2c->se.base + GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
>>
>> -       if (fifo_disable) {
>> +       if (gi2c->is_shared || fifo_disable) {
>>                  /* FIFO is disabled, so we can only use GPI DMA */
>>                  gi2c->gpi_mode = true;
>>                  ret = setup_gpi_dma(gi2c);
>> ==============><=====================================================================
>>
>> Neil

Re: [PATCH v1 0/4] Enable shared SE support over I2C

[Mukesh Kumar Savaliya]

Thanks Neil !

On 9/5/2024 12:39 PM, neil.armstrong@linaro.org wrote:
> Hi,
> 
> On 04/09/2024 20:07, Mukesh Kumar Savaliya wrote:
>> Thanks Neil !
>>
>> On 8/30/2024 1:17 PM, neil.armstrong@linaro.org wrote:
>>> Hi,
>>>
>>> On 29/08/2024 11:24, Mukesh Kumar Savaliya wrote:
>>>> This Series adds support to share QUP based I2C SE between subsystems.
>>>> Each subsystem should have its own GPII which interacts between SE and
>>>> GSI DMA HW engine.
>>>>
>>>> Subsystem must acquire Lock over the SE on GPII channel so that it
>>>> gets uninterrupted control till it unlocks the SE. It also makes sure
>>>> the commonly shared TLMM GPIOs are not touched which can impact other
>>>> subsystem or cause any interruption. Generally, GPIOs are being
>>>> unconfigured during suspend time.
>>>>
>>>> GSI DMA engine is capable to perform requested transfer operations
>>>> from any of the SE in a seamless way and its transparent to the
>>>> subsystems. Make sure to enable “qcom,shared-se” flag only while
>>>> enabling this feature. I2C client should add in its respective parent
>>>> node.
>>>>
>>>> ---
>>>> Mukesh Kumar Savaliya (4):
>>>>    dt-bindindgs: i2c: qcom,i2c-geni: Document shared flag
>>>>    dma: gpi: Add Lock and Unlock TRE support to access SE exclusively
>>>>    soc: qcom: geni-se: Export function geni_se_clks_off()
>>>>    i2c: i2c-qcom-geni: Enable i2c controller sharing between two
>>>>      subsystems
>>>>
>>>>   .../bindings/i2c/qcom,i2c-geni-qcom.yaml      |  4 ++
>>>>   drivers/dma/qcom/gpi.c                        | 37 
>>>> ++++++++++++++++++-
>>>>   drivers/i2c/busses/i2c-qcom-geni.c            | 29 +++++++++++----
>>>>   drivers/soc/qcom/qcom-geni-se.c               |  4 +-
>>>>   include/linux/dma/qcom-gpi-dma.h              |  6 +++
>>>>   include/linux/soc/qcom/geni-se.h              |  3 ++
>>>>   6 files changed, 74 insertions(+), 9 deletions(-)
>>>>
>>>
>>> I see in downstream that this flag is used on the SM8650 qupv3_se6_i2c,
>>> and that on the SM8650-HDK this i2c is shared between the aDSP 
>>> battmgr and
>>> the linux to access the HDMI controller.
>>>
>>> Is this is the target use-case ?
>> Not exactly that usecase. Here making it generic in a way to transfer 
>> data which is pushed from two subsystems independently. Consider for 
>> example one is ADSP i2c client and another is Linux i2c client. Not 
>> sure in what manner battmgr and HDMI sends traffic. we can debug it 
>> separately over that email.
> 
> Considering battmgr runs in ADSP, it matches this use-case, no ?
> 
is your issue 100% ? I have received your email, so will debug over that 
email.
>>>
>>> We have some issues on this platform that crashes the system when Linux
>>> does some I2C transfers while battmgr does some access at the same time,
>>> the problem is that on the Linux side the i2c uses the SE DMA and not 
>>> GPI
>>> because fifo_disable=0 so by default this bypasses GPI.
>>>
>>> A temporary fix has been merged:
>>> https://lore.kernel.org/all/20240605-topic-sm8650-upstream-hdk-iommu-fix-v1-1-9fd7233725fa@linaro.org/
>>> but it's clearly not a real solution
>>>
>> Seems you have added SID for the GPII being used from linux side. Need 
>> to know why you have added it and is it helping ? I have sent an email 
>> to know more about this issue before 2 weeks.
> 
> I've added this because it actually avoids crashing when doing I2C6 
> transactions over SE DMA, now we need to understand why.
> 
Seems stream IS (SID) is corrected and points to the potential wrong 
device tree configuration. Its required for DMA transactions.
>>
>>> What would be the solution to use the shared i2c with on one side 
>>> battmgr
>>> using GPI and the kernel using SE DMA ?
>>>
>> I have already sent an email on this issue, please respond on it. We 
>> shall debug it separately since this feature about sharing is still 
>> under implementation as you know about this patch series.
> 
> Sorry for the delay, I was technically unable to answer, let me resume 
> it now that I'm able again.
> 
Sure, lets discuss there.
> Thanks,
> Neil
> 
>>
>>> In this case, shouldn't we force using GPI on linux with:
>>> ==============><=====================================================================
>>> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
>>> b/drivers/i2c/busses/i2c-qcom-geni.c
>>> index ee2e431601a6..a15825ea56de 100644
>>> --- a/drivers/i2c/busses/i2c-qcom-geni.c
>>> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
>>> @@ -885,7 +885,7 @@ static int geni_i2c_probe(struct platform_device 
>>> *pdev)
>>>          else
>>>                  fifo_disable = readl_relaxed(gi2c->se.base + 
>>> GENI_IF_DISABLE_RO) & FIFO_IF_DISABLE;
>>>
>>> -       if (fifo_disable) {
>>> +       if (gi2c->is_shared || fifo_disable) {
>>>                  /* FIFO is disabled, so we can only use GPI DMA */
>>>                  gi2c->gpi_mode = true;
>>>                  ret = setup_gpi_dma(gi2c);
>>> ==============><=====================================================================
>>>
>>> Neil
>