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

[Andreas Kemnade]

On Thu, 18 Oct 2018 10:45:07 -0700
Tony Lindgren <tony at atomide.com> wrote:

> Hi,
> 
> * Andreas Kemnade <andreas at kemnade.info> [181011 20:07]:
> > Tony Lindgren <tony at atomide.com> wrote:  
> > > 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.  
> 
> Well using gpio works only anything in the gpio bank1
> that is always powered for deeper idle states. The other
> gpio banks still need to rely on padconf wake-up events,
> which is the dat1 padconf irq.
> 
well, having the gpio active there should prevent deeper
idle states? Well, not that I want that...

> The gpio here is the sdmmc2_dat1/gpio_133, right?
> 
yes,
> Leaving out the unnecessary muxing will also prevent
> possible glitches, not sure if that could be an issue
> here, probably not.
> 
> > 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.  
> 
> Correct, it gets enabled for runtime suspend only to
> prevent extra load with duplicate interrupts on the dat
> lines.
> 
> Note that when the padconf interrupt gets a wake-up event,
> the sdio_dat1 interrupt is still there on wake as it's a
> level interrupt.
> 
> > 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?  
> 
> No, we enable the padconf irq first before runtime suspend
> for the device.
> 
If I understand the code correctly, wakeirq gets enabled before
the omap_hsmmc_runtime_suspend() function is called.
Then there is 
 OMAP_HSMMC_WRITE(host->base, ISE, 0);
 OMAP_HSMMC_WRITE(host->base, IE, 0);
and the mmc irq is turned off.
But if I understand the trm correcly, the pinctl irq only
works when the corresponding hwmod is off.
But the hsmmc hwmod is turned off *after* that.

Maybe I am wrong. Do you have a cite from the trm? 

> > > 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  
> 
> Hmm it should just work(TM). Care to post your patch for that?
> 
https://misc.andi.de1.cc/0001-arm-omap-dts-add-wakeirq-for-mmc2-of-gta04.patch
defconfig used:
https://misc.andi.de1.cc/ml-defconfig
on top of
next-20181031 (where all the latest dtb patches are in,
 didn't want to wait for 4.20-rc1), to rule out that I did funny things
while applying dt patches.

Now it is tested on several devices. So it is not my device
somehow strange.


> And do you see interrupts with grep wake /proc/interrupts?
> 
The additional interrupt is there, but count stays at 1-2.

Regards,
Andreas
-------------- 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/20181101/cb972dab/attachment.asc>