Re: [PATCH] mmc: sdhci-of-at91: fix wakeup issue when using runtime pm

[Ludovic Desroches]

+ PM mailing list since the discussion is mixing PM and sdhci

On Tue, Mar 08, 2016 at 10:56:31PM +0100, Ulf Hansson wrote:
> +Ludovic
> 
> On 8 March 2016 at 22:54, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote:
> > On 4 March 2016 at 14:48, Ludovic Desroches <ludovic.desroches@xxxxxxxxx> wrote:

[snip]

> >>
> >> Coming back to the initial discussion and patch which were motivated by
> >> the fact that after runtime suspend I can't wake-up on card detect event,
> >> I have the feeling we don't have the same assumption about runtime PM.
> >>
> >> From what you and Adrian told me, I should not use runtime PM if I have
> >> no way to wake-up. In your minds, the way to wake-up is to use an
> >> externel GPIO because the controller will be 'totally' disabled, isn't it?
> >
> > I agree to the first part here.
> >
> > Although, as you also have the option to use polling for card detect,
> > this actually means you don't really *need* to have a wakeup
> > configured. Especially in the case where you don't have GPIO card
> > detect.
> >
> > In that way, *all* the clocks can gated in between the polling
> > attempts, thus you will save power even in the polling mode
> > configuration and when runtime PM is enabled.
> >

As you said, I can gate all the clocks but only between attempts.
Regularly, I will resume and suspend my controller to perform the card
detection. I don't know if it is a better solution than keeping one
clock enabled and waiting for an interrupt to enable the other ones.

> >>
> >> On my side, runtime PM allows me to save power when the sdhci controller
> >> is not used. If I can disable two clocks out of three, I should use
> >> runtime PM. Do you agree?
> >>
> >> If not, tell me how I can convince you :) Otherwise, next step is to rework
> >> my patch but I think I have no other solution that not calling
> >> sdhci_runtime_suspend_host if I expect to use the card detect irq of the
> >> controller.
> >
> > So, to summarize.
> >
> > I think the best fix is to add a clever check in ->probe() and then
> > enable polling when you can't rely on GPIO card detect IRQ.
> >
> > Moreover, to have a robust solution, you also need to clear
> > SDHCI_QUIRK_BROKEN_CARD_DETECTION for your sdhci variant, as otherwise
> > the "broken-cd" DT binding could wrongly be used for this variant.
> >
> > Does that make sense?


Well I don't agree totally because I have the feeling to use a
workaround because if sdhci_runtime_suspend_host has been called the
controlled is considered as 'disabled' then we won't deal with its IRQs.

I would like to move forward on this issue so it could be a trade-off.

Since the sdhci layer is going to be reworked, maybe it could be
interesting to have another approach of runtime PM to get more
flexibility.


Regards

Ludovic