From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933284AbcCIQil (ORCPT ); Wed, 9 Mar 2016 11:38:41 -0500 Received: from eusmtp01.atmel.com ([212.144.249.243]:2528 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753712AbcCIQib (ORCPT ); Wed, 9 Mar 2016 11:38:31 -0500 Date: Wed, 9 Mar 2016 17:38:09 +0100 From: Ludovic Desroches To: Ulf Hansson CC: Ludovic Desroches , "linux-kernel@vger.kernel.org" , linux-mmc , Adrian Hunter , Nicolas Ferre , , , Subject: Re: [PATCH] mmc: sdhci-of-at91: fix wakeup issue when using runtime pm Message-ID: <20160309163809.GM2690@odux.rfo.atmel.com> Mail-Followup-To: Ulf Hansson , "linux-kernel@vger.kernel.org" , linux-mmc , Adrian Hunter , Nicolas Ferre , linux-pm@vger.kernel.org, rjw@rjwysocki.net, khilman@kernel.org References: <20160212120415.GJ14937@odux.rfo.atmel.com> <1455357400-32145-1-git-send-email-ludovic.desroches@atmel.com> <20160216152204.GE2607@odux.rfo.atmel.com> <20160217103515.GM2607@odux.rfo.atmel.com> <20160304134830.GG2690@odux.rfo.atmel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org + 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 wrote: > > On 4 March 2016 at 14:48, Ludovic Desroches 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