questions about runtime pm

questions about runtime pm

[Ludovic Desroches]

Hi guys,

I have recently added PM support for my driver but I don't have the
behavior I was expecting. I am wondering if I didn't do something wrong.

I have implemented runtime_suspend in a very simple way, I call
sdhci_runtime_suspend_host() and I disable the clocks. It works pretty
well with the eMMC which is non removable but with a SD card... If I
have my SD card present on boot time, it is detected but
insertion/removal is not detected.

Having a look to sdhci_runtime_suspend_host() internal, all the
interruptions are disabled expecting the card interrupt if it has been
set earlier.

>From my understanding, it means that if there is no activity on sdhci,
we will go to suspend and then we could wake up only on a software event
(or a sdio interrupt). How to manage card insertion/removal in this
case? My problem is so huge, I have probably missed something...

Moreover, to avoid system PM, I have used pm_runtime_force_suspend but I
could not wake up on card insertion/removal too. Do I have to use system
PM if I want to manage this case?

Thanks for your advices.

Regards

Ludovic

Re: questions about runtime pm

[Ludovic Desroches]

On Tue, Dec 22, 2015 at 02:24:53PM +0100, Ludovic Desroches wrote:
> Hi guys,
> 
> I have recently added PM support for my driver but I don't have the
> behavior I was expecting. I am wondering if I didn't do something wrong.
> 
> I have implemented runtime_suspend in a very simple way, I call
> sdhci_runtime_suspend_host() and I disable the clocks. It works pretty
> well with the eMMC which is non removable but with a SD card... If I
> have my SD card present on boot time, it is detected but
> insertion/removal is not detected.
> 
> Having a look to sdhci_runtime_suspend_host() internal, all the
> interruptions are disabled expecting the card interrupt if it has been
> set earlier.
> 
> From my understanding, it means that if there is no activity on sdhci,
> we will go to suspend and then we could wake up only on a software event
> (or a sdio interrupt). How to manage card insertion/removal in this
> case? My problem is so huge, I have probably missed something...
> 
> Moreover, to avoid system PM, I have used pm_runtime_force_suspend but I
> could not wake up on card insertion/removal too. Do I have to use system
> PM if I want to manage this case?
> 
> Thanks for your advices.
> 
> Regards
> 
> Ludovic


Any feedback?


Ludovic

Re: questions about runtime pm

[Jaehoon Chung]

Hi,

On 01/16/2016 12:01 AM, Ludovic Desroches wrote:
> On Tue, Dec 22, 2015 at 02:24:53PM +0100, Ludovic Desroches wrote:
>> Hi guys,
>>
>> I have recently added PM support for my driver but I don't have the
>> behavior I was expecting. I am wondering if I didn't do something wrong.
>>
>> I have implemented runtime_suspend in a very simple way, I call
>> sdhci_runtime_suspend_host() and I disable the clocks. It works pretty
>> well with the eMMC which is non removable but with a SD card... If I
>> have my SD card present on boot time, it is detected but
>> insertion/removal is not detected.
>>
>> Having a look to sdhci_runtime_suspend_host() internal, all the
>> interruptions are disabled expecting the card interrupt if it has been
>> set earlier.
>>
>> From my understanding, it means that if there is no activity on sdhci,
>> we will go to suspend and then we could wake up only on a software event
>> (or a sdio interrupt). How to manage card insertion/removal in this
>> case? My problem is so huge, I have probably missed something...

Is there any detection method for SD-card(removable card)?
Doesn't use Card-detect pin or Polling..?

Best Regards,
Jaehoon Chung

>>
>> Moreover, to avoid system PM, I have used pm_runtime_force_suspend but I
>> could not wake up on card insertion/removal too. Do I have to use system
>> PM if I want to manage this case?
>>
>> Thanks for your advices.
>>
>> Regards
>>
>> Ludovic
> 
> 
> Any feedback?
> 
> 
> Ludovic
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
>