linux-mmc.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sujit Reddy Thumma <sthumma@codeaurora.org>
To: Chris Ball <cjb@laptop.org>
Cc: linux-mmc@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH V3] mmc: core: Use delayed work in clock gating framework
Date: Tue, 15 Nov 2011 10:42:46 +0530	[thread overview]
Message-ID: <4EC1F4CE.90706@codeaurora.org> (raw)
In-Reply-To: <87ehxaluam.fsf@laptop.org>

Hi Chris,

On 11/14/2011 6:45 PM, Chris Ball wrote:
> Hi Sujit,
>
> On Mon, Nov 14 2011, Sujit Reddy Thumma 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 8MCLK
>> 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.
>>
>> Also if the host controller driver decides to disable the host clock too
>> when mmc_set_ios function is called with ios.clock=0, it adds additional
>> delay and it is highly possible that the next request had already arrived
>> and unnecessarily blocked in enabling the clocks. This is seen frequently
>> when the processor is executing at high speeds and in multi-core platforms
>> thus reduces the overall throughput compared to if clock gating is
>> disabled.
>>
>> 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.
>>
>> sysfs entry is provided to tune the delay as needed, default
>> value set to 200ms.
>>
>> Signed-off-by: Sujit Reddy Thumma<sthumma@codeaurora.org>
>> Acked-by: Linus Walleij<linus.walleij@linaro.org>
>
> error: patch failed: drivers/mmc/core/host.c:53
> error: drivers/mmc/core/host.c: patch does not apply
> error: patch failed: include/linux/mmc/host.h:253
> error: include/linux/mmc/host.h: patch does not apply
>
> Please could you resend against current mmc-next?

I see that the patch is already applied on mmc-next, hence the conflicts.

http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=0987075c3c285ba92f93464f7a882515d4a054d1

Can we rebase the tree and apply V3?

>
> Thanks,
>
> - Chris.


-- 
Thanks,
Sujit

  reply	other threads:[~2011-11-15  5:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-14  8:23 [PATCH V3] mmc: core: Use delayed work in clock gating framework Sujit Reddy Thumma
2011-11-14 13:15 ` Chris Ball
2011-11-15  5:12   ` Sujit Reddy Thumma [this message]
2011-11-15 13:12     ` Chris Ball
2011-11-15 18:51 ` Stephen Boyd
2011-12-05 18:28   ` [PATCH-next] mmc: core: Fixup delayed work clock gating patch Stephen Boyd
2011-12-06  8:52     ` Sujit Reddy Thumma
2011-12-08  3:58     ` Chris Ball

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4EC1F4CE.90706@codeaurora.org \
    --to=sthumma@codeaurora.org \
    --cc=cjb@laptop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).