* Andreas Kemnade <andreas@xxxxxxxxxxxx> [181101 21:33]:
> well, having the gpio active there should prevent deeper
> idle states? Well, not that I want that...
Well I guess it should but currently does not unless a PM QoS
limit is set by a GPIO consumer driver. Things should work
just fine for retention idle, but if the PMIC is configured
to enter off mode with ti,twl4030-power-idle-osc-off then
presumably the board maintainers have configured things
properly :)
> 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.
Yes for the duration of runtime_suspend being configured,
both the IO interrupt and the wakeirq are both active.
> 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.
Nope, the pinctrl irq can be active any time. For wakeirqs,
we only enable it for runtime suspend to avoid extra
overhead.
> Maybe I am wrong. Do you have a cite from the trm?
Hmm I don't think there's much in the TRM about that.
You should be able to verify it yourself easily with
grep wake /proc/interrupts though.
> > > > 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
Yup that's all there really is to it for other devices. So I
guess the only difference is that you also need to change
to sdio 1-bit mode here?
> Now it is tested on several devices. So it is not my device
> somehow strange.
OK
> > And do you see interrupts with grep wake /proc/interrupts?
> >
> The additional interrupt is there, but count stays at 1-2.
Hmm that's interesting. Maybe check the 16-bit padconf
register at offset 0x12e and see if what value it has?
Also maybe add a printk to the sdio runtime idle path to
make sure it's idling and waking properly at that point?
Regards,
Tony
