Re: [PATCH 1/1] mmc: core: Use delayed work in clock gating framework

[Sujit Reddy Thumma <sthumma@codeaurora.org>]

On 10/24/2011 12:53 PM, Linus Walleij wrote:
> On Wed, Oct 19, 2011 at 4:48 PM, Sujit Reddy Thumma
> <sthumma@codeaurora.org>  wrote:
>
>> Current clock gating framework disables the MCI clock as soon as the
>> request is completed and enables it when a request arrives. This aggressive
>> clock gating framework when enabled cause following issues:
>>
>> When there are back-to-back requests from the Queue layer, we unnecessarily
>> end up disabling and enabling the clocks between these requests since 8 MCLK
>> clock cycles is a very short duration compared to the time delay between
>> back to back requests reaching the MMC layer. This overhead can effect the
>> overall performance depending on how long the clock enable and disable
>> calls take which is platform dependent. For example on some platforms we
>> can have clock control not on the local processor, but on a different
>> subsystem and the time taken to perform the clock enable/disable can add
>> significant overhead.
>
> OK I see the problem. At one point it was suggested to use the delayed
> disable facilities in runtime PM for avoiding this, but it never materialized.
>
>> Fix this by delaying turning off the clocks by posting request on
>> delayed workqueue. Also cancel the unscheduled pending work, if any,
>> when there is access to card.
>
> (...)
>> @@ -252,10 +252,11 @@ struct mmc_host {
>>         int                     clk_requests;   /* internal reference counter */
>>         unsigned int            clk_delay;      /* number of MCI clk hold cycles */
>>         bool                    clk_gated;      /* clock gated */
>> -       struct work_struct      clk_gate_work; /* delayed clock gate */
>> +       struct delayed_work     clk_gate_work; /* delayed clock gate */
>>         unsigned int            clk_old;        /* old clock value cache */
>>         spinlock_t              clk_lock;       /* lock for clk fields */
>>         struct mutex            clk_gate_mutex; /* mutex for clock gating */
>> +#define MMC_CLK_GATE_DELAY     50              /* in milliseconds*/
>>   #endif
>
> What's the rationale of having this in the middle of the struct
> in the .h-file?
>
> Move it inside the #ifdef in host.c instead, and also provide
> some rationale about the choice of 50 ms.

With my testing on a MSM platform, round-trip delay of 10ms to turn off 
and on the clocks is seen. So I thought 50ms is a reasonable tradeoff. 
There is no specific calculation behind this delay. We just relied on 
the empirical data which again may vary with different platforms.

If you have any suggestions I would be happy to consider that. I am 
planning to increase this to 200ms, any comments on that?

>
> Maybe we should even provide a sysfs or debugfs entry for
> tweaking that value, as has been suggested in the past.
> However that's no big deal for me...

Adding an entry in sysfs seems to be a good solution to tune the 
required delay. I will add this.

>
> Do you have a patch to your msm_sdcc.c that enables the
> gating to take effect as well? Does it solve the problems
> pointed out by Russell when I tried the same type of patch
> to mmci.c?
> http://marc.info/?l=linux-mmc&m=129146545916794&w=2

Looking at the patch that you pointed out, I don't think it is required 
for msm_sdcc.c to enable clock gating. The current code inherently takes 
care of logic that is needed to ensure that MCLK is not turned off until 
any pending register write in the host driver is completed. You might 
want to have a look at set_ios function in 
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/mmc/host/msm_sdcc.c;h=b5a08d2b58e0cd6d18a8f1041139b6866c0cdc09;hb=refs/heads/msm-3.0
Please let me know if I am still missing anything.

-- 
Thanks & Regards,
Sujit Reddy Thumma