On Thu, 18 Oct 2018 10:45:07 -0700
Tony Lindgren <tony@xxxxxxxxxxx> wrote:
> Hi,
>
> * Andreas Kemnade <andreas@xxxxxxxxxxxx> [181011 20:07]:
> > Tony Lindgren <tony@xxxxxxxxxxx> 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
Attachment:
pgpgAnAOCJ43f.pgp
Description: OpenPGP digital signature
