On Friday 18 October 2013 11:50 AM, NeilBrown wrote:
On Sat,  5 Oct 2013 13:17:09 +0200 Andreas Fenkart <afenk...@gmail.com> wrote:

The am335x can't detect pending cirq in PM runtime suspend.
This patch reconfigures dat1 as a GPIO before going to suspend.
SDIO interrupts are detected with the GPIO, while in runtime
suspend, standard detection of the module block otherwise.

Signed-off-by: Andreas Fenkart <afenk...@gmail.com>

diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 1136e6b..146f3ad 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -21,8 +21,11 @@ ti,non-removable: non-removable slot (like eMMC)
  ti,needs-special-reset: Requires a special softreset sequence
  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
High Speed
  ti,quirk-swakup-missing: SOC missing the swakeup line, will not detect
-SDIO irq while in suspend. Fallback to polling. Affected chips are
-am335x,
+SDIO irq while in suspend. The workaround is to reconfigure the dat1 line as a
+GPIO upon suspend. Beyond this option and the GPIO config, you also need to set
+named pinctrl states "default", "active" and "idle ", see example below.  The
+MMC driver will then then toggle between default and idle during the runtime
+Affected chips are am335x,

                              ------
                              | PRCM |
@@ -49,3 +52,24 @@ Example:
                vmmc-supply = <&vmmc>; /* phandle to regulator node */
                ti,non-removable;
        };
+
+[am335x with with gpio for sdio irq]
+
+       mmc1_cirq_pin: pinmux_cirq_pin {
+               pinctrl-single,pins = <
+                       0x0f8 0x3f      /* MMC0_DAT1 as GPIO2_28 */
+               >;
+       };
+
+       mmc1: mmc@48060000 {
+               ti,non-removable;
+               bus-width = <4>;
+               vmmc-supply = <&ldo2_reg>;
+               vmmc_aux-supply = <&vmmc>;
+               ti,quirk-swakeup-missing;
+               pinctrl-names = "default", "active", "idle";
+               pinctrl-0 = <&mmc1_pins>;
+               pinctrl-1 = <&mmc1_pins>;
+               pinctrl-2 = <&mmc1_cirq_pin>;
+               ti,cirq-gpio = <&gpio3 28 0>;
+       };


hi,
  I've been trying to get SD irq to work on my  OMAP3 DM3730.
I seems to need the magic to catch interrupts while FCLK is off, as
the only way I can get it to work at the moment is to keep FCLK on.

I discovered your patch and tried it out, but it doesn't seem to work for me.

I have a Libertas WIFI chip attached to the second mmc (which is sometimes
called mmc1, and sometimes mmc2 - very confusing!).
I added:
        mmc2_cirq_pin: pinmux_cirq_pin {
                pinctrl-single,pins = <
                        0x012e (PIN_INPUT_PULLUP | MUX_MODE4)   /* MMC2_DAT1 as 
GPIO5_5 */
                >;
        };

and

&mmc2 {
        ti,quirk-swakeup-missing;
        pinctrl-names = "default", "active", "idle";
        pinctrl-0 = <&mmc2_pins>;
        pinctrl-1 = <&mmc2_pins>;
        pinctrl-2 = <&mmc2_cirq_pin>;
        ti,cirq-gpio = <&gpio5 5 0>; /* GPIO133 = 128+5 */
};

to my dts file but it doesn't make any apparent difference.

Any idea what I might be doing wrong?
(the base kernel I am applying patches to is from 8th Oct,
  commit 0e7a3ed04f0cd4311096d691888f88569310ee6c)

BTW,
  - with the default polling, I get about 1Mb/sec with iperf
  - with sd-irq enabled and FCLK kept on the whole time, I get 4Mb/sec
  - with sd-irq enable, FCLK kept on, and the 5ms polling also
    running, I get over 5Mb/sec!
Still much less than the 40Mb/sec that I would like to get...

(removing svenk...@ti.com)

Hi,

Can you check if you have bus-width property set ?
        bus-width = <4>;

Thanks and Regards,
Balaji T K

Thanks,
NeilBrown


--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to