[Letux-kernel] omap_hsmmc + gta04 + sdio irq + runtime_suspend + 4 bit = trouble

Andreas Kemnade andreas at kemnade.info
Thu Oct 11 22:07:13 CEST 2018


Hi Tony,

I think this is really a topic where sitting down and think alot
of what was already tried and what might have gone wrong. So it is
probably
not good to test something hastily. 
And do not feel pressed to answer quickly. 

On Thu, 4 Oct 2018 08:02:25 -0700
Tony Lindgren <tony at atomide.com> wrote:

> Hi,
> 
> * Andreas Kemnade <andreas at kemnade.info> [180926 21:16]:
> > With the dirty letux patch (enabling SDIO_IRQ and adding a pair of
> > pm_runtime_get_sync()/put() in omap_hsmmc_enable_sdio_irq()),
> > the values are 30mA and > 1000KByte/s.
> > The wifi chip (with libertas driver) just behaves better with low
> > latency sdio irq.  
> 
> Hmm so what is this sdio patch? We've had omap_hsmmc working for
> years with sdio dat1 interrupt and waking to interrupts from off
> idle as long as the wakeirq is configured with interrupts-extended
> in the dts file. For omap3, there should not be any remuxing to
> gpio needed, only am335x needs that. Maybe I just don't follow
> you here :)
> 

I am citing myself:
> Just for clarification: If I force-enable runtime here via
> echo on >/sys/bus/platform/devices/480b4000.mmc/power/control
> or this dirty hack
> http://git.goldelico.com/?p=letux-kernel.git;a=commit;h=72e47cfbef51e0f1cdb771d5ca59032fd489876b
> sdio irq works even with 4 bit.

I just mean sdio irq works for lower latency compared to polling what is
used when sdio is not enabled. And the wifi chip also needs that low
latency for properly handling 802.11 ps mode. Of course it is not a good
idea to have wifi on all the time if it is the only blocker for lower
power states.
And before  my clk patches regarding hdq are not through, I cannot
easily measure my success.


> > On Fri, 7 Sep 2018 10:08:50 -0700
> > Tony Lindgren <tony at atomide.com> wrote:
> >   
> > > * Andreas Kemnade <andreas at kemnade.info> [180907 16:52]:  
> > > > sdio irq + wakeirq via remapped dat1 as gpio + 4 bit -(=reverted)
> > > > generic_wakeirq_patch = does not work    
> 
> Sounds like you're unnecessarily remapping dat1 to gpio for wake.
> With omap3 just configure the dat1 padconf irq as the "wakeup".
> 
Is there anything bad with it, so that it does not work (besides
being not optimal)? I just trust that gpio level interrupt more.
To my understanding, pinctrl irq is an edge irq. So we detect level
changes for that pad. To my understanding, that does not work during
normal operation, but when the module behind that pad is off.
So what about the gap in omap_hsmmc_runtime_suspend() between
switching off IRQs and switching off the module finally?
Are there chances that we loose an irq?


> Care to try something like this in the in omap3-gta04.dtsi:
> 
> &mmc2 {
>       interrupts-extended = <&intc 86 &omap3_pmx_core 0x12e>;
>       interrupt-names = "irq", "wakeup";
>       vmmc-supply = <&vaux4>;
>       bus-width = <4>;
>       ti,non-removable;
>       cap-power-off-card;
>       mmc-pwrseq = <&wifi_pwrseq>;
> };
> 
> Untested.. 
No, tested, 
see my previous mails in the thread.

But I retested it in case of some PEBCAK issues.
plain 4.19.0-rc6 + dt patches

> And I just hastily looked up that the the sdmmc2_dat1
> is at 0x4800215C + 2 making the padconf interrupt then
> 0x4800215C + 2 - 0x48002030 = 0x12e. But I know a similar setup
> works just fine with omap3 and mwifiex_sdio and off idle.
> 
> Please leave out all remuxing initially, then if the sdio
> needs some pins with pull up/down configured for idle you
> can add a pinctrl idle or sleep mode with PULL | MUX_MODE7.
> 

Ok, that is really something I did not test yet.
                pinctrl-single,pins = <
                        /* sdmmc2_clk.sdmmc2_clk */
                        OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP |
MUX_MODE0)

                        /* sdmmc2_cmd.sdmmc2_cmd */
                        OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP |
                        MUX_MODE0)

                        /* sdmmc2_dat0.sdmmc2_dat0 */
                        OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP |
                        MUX_MODE0)

                        /* sdmmc2_dat0.sdmmc2_dat1 */
                        OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP |
                        MUX_MODE0)

                        /* sdmmc2_dat2.sdmmc2_dat2 */
                        OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP |
                        MUX_MODE0)

                        /* sdmmc2_dat2.sdmmc2_dat3 */
                        OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP |
                        MUX_MODE0)

                        /* sdmmc2_dat4.sdmmc2_dir_dat0 */
                        OMAP3_CORE1_IOPAD(0x2164, PIN_INPUT_PULLUP |
                        MUX_MODE1)

                        /* sdmmc2_dat4.sdmmc2_dir_dat1 */
                        OMAP3_CORE1_IOPAD(0x2166,
                                          PIN_INPUT_PULLDOWN |
                        MUX_MODE1)

                        /* sdmmc2_dat6.sdmmc2_dir_cmd */
                        OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP |
                        MUX_MODE1)

                        /* sdmmc2_dat6.sdmmc2_clkin */
                        OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP |
                        MUX_MODE1) >;  
        };

        mmc2_idle_pins: pinmux_mmc2_idle_pins {
                pinctrl-single,pins = <
                        /* sdmmc2_clk.sdmmc2_clk */
                        OMAP3_CORE1_IOPAD(0x2158, PIN_INPUT_PULLUP |
        MUX_MODE7)

                        /* sdmmc2_cmd.sdmmc2_cmd */
                        OMAP3_CORE1_IOPAD(0x215a, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat0.sdmmc2_dat0 */
                        OMAP3_CORE1_IOPAD(0x215c, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat0.gpio133 */
                        OMAP3_CORE1_IOPAD(0x215e, PIN_INPUT_PULLUP |
                        MUX_MODE7) 
			/* sdmmc2_dat2.sdmmc2_dat2 */
                        OMAP3_CORE1_IOPAD(0x2160, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat2.sdmmc2_dat3 */
                        OMAP3_CORE1_IOPAD(0x2162, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat4.sdmmc2_dir_dat0 */
                        OMAP3_CORE1_IOPAD(0x2164, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat4.sdmmc2_dir_dat1 */
                        OMAP3_CORE1_IOPAD(0x2166,
                                          PIN_INPUT_PULLDOWN |
                        MUX_MODE7)

                        /* sdmmc2_dat6.sdmmc2_dir_cmd */
                        OMAP3_CORE1_IOPAD(0x2168, PIN_INPUT_PULLUP |
                        MUX_MODE7)

                        /* sdmmc2_dat6.sdmmc2_clkin */
                        OMAP3_CORE1_IOPAD(0x216a, PIN_INPUT_PULLUP |
                        MUX_MODE7) >;  
        };

does not give any advantages.

Regards,
Andreas
PS: with the gta04a5 things are a lot easier: wlcore + oob irq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20181011/f0a8d4cb/attachment.asc>


More information about the Letux-kernel mailing list