From: Per Forlin <per.lkml@gmail.com>
To: Sujit Reddy Thumma <sthumma@codeaurora.org>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Per Forlin <per.friden@stericsson.com>,
linux-mmc@vger.kernel.org, cjb@laptop.org
Subject: Re: [PATCH] mmc: core: Ensure clocks are always enabled before host interaction
Date: Mon, 30 Jan 2012 13:48:43 +0100 [thread overview]
Message-ID: <CAFEEs1=SoPvTSoBFybVLVC8ZHi8fuUNy0ZLAjXn2jYV0T5Lv3g@mail.gmail.com> (raw)
In-Reply-To: <4F1E2933.8030708@codeaurora.org>
On Tue, Jan 24, 2012 at 4:44 AM, Sujit Reddy Thumma
<sthumma@codeaurora.org> wrote:
> Hi Linus Walleij,
>
>
> On 12/30/2011 7:44 AM, Linus Walleij wrote:
>>
>> On Mon, Dec 12, 2011 at 9:21 AM, Sujit Reddy Thumma
>> <sthumma@codeaurora.org> wrote:
>>
>>> Ensure clocks are always enabled before any interaction with the
>>> host controller driver. This makes sure that there is no race
>>> between host execution and the core layer turning off clocks
>>> in different context with clock gating framework.
>>>
>>> Signed-off-by: Sujit Reddy Thumma<sthumma@codeaurora.org>
>>
>>
>> I guess Per Förlin may not be available, but would have preferred to
>> have his view on this as well, since he knows the semantics of
>> pre/post-req.
>
>
> I have checked the implementation for pre-req and post-req in mmc host
> drivers. There is no interaction to the controller or card registers in
> these functions, but in future if drivers appeal to configure their
> controller in these functions then we must have clocks enabled.
>
> Per, if you are available can you comment on this?
>
I just got back from 2 months of leave so I apologize for not being up to date.
It makes sense to ensure clocking in pre-req() and post-req()
implemented by this patch.
My only concern from a throughput point of view is if the clocking
adds an overhead, but AFAIK the clocking doesn't add an overhead (that
would increase the prepare time).
Currently the pre-req() and post-req() only prepares DMA for next
transfer without interacting with the controller. The intention is to
increase throughput by minimizing start latency for the next transfer.
It's perfectly ok to do other useful preparations in these hooks as
well. The hooks are generic. It should be possible to do clock
dependent stuff in these hooks too, it's up to the host driver to do
what's best.
Acked-by: Per Forlin <per.forlin@stericsson.com>
Thanks,
Per
next prev parent reply other threads:[~2012-01-30 12:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-12 8:21 [PATCH] mmc: core: Ensure clocks are always enabled before host interaction Sujit Reddy Thumma
2011-12-12 9:12 ` Subhash Jadavani
2011-12-27 4:53 ` Sujit Reddy Thumma
2011-12-30 2:14 ` Linus Walleij
2012-01-24 3:44 ` Sujit Reddy Thumma
2012-01-30 12:48 ` Per Forlin [this message]
2012-01-30 19:33 ` Linus Walleij
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='CAFEEs1=SoPvTSoBFybVLVC8ZHi8fuUNy0ZLAjXn2jYV0T5Lv3g@mail.gmail.com' \
--to=per.lkml@gmail.com \
--cc=cjb@laptop.org \
--cc=linus.walleij@linaro.org \
--cc=linux-mmc@vger.kernel.org \
--cc=per.friden@stericsson.com \
--cc=sthumma@codeaurora.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).