Thread (16 messages) 16 messages, 2 authors, 2021-08-25

Re: [PATCH 3/6] dt-bindings: mmc: fsl-imx-esdhc: add fsl,sdio-async-interrupt-enabled binding

From: Ulf Hansson <hidden>
Date: 2021-08-17 07:37:40
Also in: linux-devicetree, linux-mmc

On Tue, 17 Aug 2021 at 08:41, Bough Chen [off-list ref] wrote:
quoted
-----Original Message-----
From: Ulf Hansson [mailto:ulf.hansson@linaro.org]
Sent: 2021年8月16日 21:43
To: Bough Chen <haibo.chen@nxp.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>; Shawn Guo
[off-list ref]; Rob Herring [off-list ref]; Sascha Hauer
[off-list ref]; Sascha Hauer [off-list ref]; Fabio
Estevam [off-list ref]; linux-mmc [off-list ref];
dl-linux-imx [off-list ref]; DTML [off-list ref]; Linux
ARM [off-list ref]
Subject: Re: [PATCH 3/6] dt-bindings: mmc: fsl-imx-esdhc: add
fsl,sdio-async-interrupt-enabled binding

On Mon, 16 Aug 2021 at 15:00, [off-list ref] wrote:
quoted
From: Haibo Chen <haibo.chen@nxp.com>

Add a new fsl,sdio-async-interrupt-enabled binding for sdio devices
which enable the async interrupt function. When get this property,
driver will avoid to use DAT[1] for hardware auto tuning check.

Signed-off-by: Haibo Chen <haibo.chen@nxp.com>
---
 .../devicetree/bindings/mmc/fsl-imx-esdhc.yaml         | 10
++++++++++
quoted
 1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
index b5baf439fbac..8a9f1775b0e2 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml
@@ -122,6 +122,16 @@ properties:
       - const: state_200mhz
       - const: sleep

+  fsl,sdio-async-interrupt-enabled:
+    description: |
+      Recommend for SDIO cards that enables SDIO async interrupt for
SDR104 and SDR50
quoted
+      operating modes. SDIO async interrupt uses DAT[1] to signal the
card's interrupt.
quoted
+      uSDHC tuning mechanism must use DAT[0] and CMD signals to avoid
a possible
quoted
+      conflict and incorrect delay line calculated by the uSDHC auto tuning
mechanism.
quoted
+      Enabling this device tree property is only recommended for layouts
that are
quoted
+      matching the SD interface length.
+    type: boolean
We already have a common mmc property, "cap-sdio-irq", that tells whether
the controller supports SDIO irqs (which is delivered on DAT1).

Can't you use this instead?
Hi Ulf,

Thanks for your quick reply!

According to our WiFi team reply, the sdio-irq has two types. Sync interrupt and Async interrupt.
When WiFi send out the interrupt signal during the interrupt period, if it sync with clock pad(just as
when send out data), then this is sync interrupt. When this interrupt not sync with clock, it is async
interrupt. Async interrupt has a better overall performance than sync interrupt.
The async interrupt is what we refer to as SDIO irqs, which is being
delivered on DAT1.
Logically, auto tuning circuit should only take care of the data and cmd line, and ignore interrupt signal.
But unfortunately current i.mx-usdhc IP do not ignore interrupt signal. So it detect the interrupt signal,
and take this signal as a data signal, and adjust the delay cell accordingly. For sync interrupt, due to it
sync with clock, so no affect, but for async interrupt, it will involve wrong delay cell change randomly.
Okay.
I involve a new property here, because in sdhci.c, we default use this "cap-sdio-irq" for all sdio/sd/mmc.
I guess it's the similar variant of the controller for all slots then.

It can be debated whether the proper thing is to set "cap-sdio-irq"
only for the SDIO card slot. I think so, (and it's already being used
like that) if there is an embedded SDIO card attached, because
cap-sdio-irq would not make sense otherwise.
I need one property which can use only for sdio device, and only when sdio device enable async-interrupt.
If you really need a new DT property (let's discuss that more in patch
4/6), I suggest you add something along the lines of a
"broken-auto-tuning" DT property instead, because that is in principle
what this should be about, isn't it?

Kind regards
Uffe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help