Re: [PATCH v2 2/8] dt-bindings: i2c: qcom,i2c-geni: Add support for selecting data transfer mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 1/24/2025 8:33 PM, Dmitry Baryshkov wrote:
On Fri, Jan 24, 2025 at 05:52:24PM +0530, Viken Dadhaniya wrote:


On 1/24/2025 4:48 PM, Dmitry Baryshkov wrote:
On Fri, Jan 24, 2025 at 04:23:03PM +0530, Viken Dadhaniya wrote:
Data transfer mode is fixed by TrustZone (TZ), which currently restricts
developers from modifying the transfer mode from the APPS side.

Document the 'qcom,xfer-mode' properties to select the data transfer mode,
either GPI DMA (Generic Packet Interface) or non-GPI mode (PIO/CPU DMA).

I2C controller can operate in one of two modes based on the
'qcom,xfer-mode' property, and the firmware is loaded accordingly.

Is it possible to load the firmware after it being loaded by TZ? Is it
possible to change the mode at runtime too?

No, firmware can be loaded either from the TZ side or APPS side.

You answer actually reads as "No, yes" (excuse me, non-native here).
Most likely you mean that it can not be reloaded once either TZ or APPS
has loaded it.

Yes correct. it can not be reloaded once either TZ or APPS has loaded it.


In non-GPI mode, the transfer mode will change runtime between PIO and CPU
DMA based on the data length.

We need to update the device tree property(qcom,xfer-mode) to change the
mode between non-GPI and GPI.

So, is it actually possible to change the mode? E.g. if the TZ has
loaded the firmware and configured SE for PIO/SE DMA, is it possible to
change it to GPI DMA?

No, if the TZ has loaded the firmware, it is not possible to switch from non-GPI (PIO/SE DMA) to GPI DMA mode.





Co-developed-by: Mukesh Kumar Savaliya <quic_msavaliy@xxxxxxxxxxx>
Signed-off-by: Mukesh Kumar Savaliya <quic_msavaliy@xxxxxxxxxxx>
Signed-off-by: Viken Dadhaniya <quic_vdadhani@xxxxxxxxxxx>
---

v1 -> v2:

- Drop 'qcom,load-firmware' property and add 'firmware-name' property in
    qup common driver.
- Update commit log.

v1 Link: https://lore.kernel.org/linux-kernel/20241204150326.1470749-2-quic_vdadhani@xxxxxxxxxxx/
---
---
   .../devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml        | 7 +++++++
   1 file changed, 7 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..68e4bf0c84d1 100644
--- a/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
+++ b/Documentation/devicetree/bindings/i2c/qcom,i2c-geni-qcom.yaml
@@ -66,6 +66,12 @@ properties:
     required-opps:
       maxItems: 1
+  qcom,xfer-mode:
+    description: Set the value to 1 for non-GPI (FIFO/CPU DMA) mode and 3 for GPI DMA mode.
+      The default mode is FIFO.
+    $ref: /schemas/types.yaml#/definitions/uint32
+    enum: [1, 3]
+
   required:
     - compatible
     - interrupts
@@ -142,5 +148,6 @@ examples:
           interconnect-names = "qup-core", "qup-config", "qup-memory";
           power-domains = <&rpmhpd SC7180_CX>;
           required-opps = <&rpmhpd_opp_low_svs>;
+        qcom,xfer-mode = <1>;

What does <1> mean? Please provide corresponding defines.

Do we need to add a string instead of a number, like
include/dt-bindings/dma/qcom-gpi.h?

You need to '#define FOO_BAR 1', then another one for 3. String is a
"string", it's not required here (in my opinion).


Sure, I will update it in the next patch.





[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux