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@xxxxxxxxxxx> wrote: > Hi, > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [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@xxxxxxxxxxx> wrote: > > > > > * Andreas Kemnade <andreas@xxxxxxxxxxxx> [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
Attachment:
pgpwbd2T_RV4f.pgp
Description: OpenPGP digital signature
