From: Paul Mundt <lethal@linux-sh.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH] sh: ecovec: switch SDHI controllers to card polling
Date: Wed, 28 Mar 2012 15:27:53 +0900 [thread overview]
Message-ID: <20120328062753.GU26543@linux-sh.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1201281929450.27970@axis700.grange>
On Sat, Jan 28, 2012 at 07:36:24PM +0100, Guennadi Liakhovetski wrote:
> Polling for card hotplug events is a better option than using SDHI native
> hotplug interrupt, because the latter option forces the controller to stay
> permanently powered up and enabled.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> It is a kind of an RFC. We do in general prefer SDHI polling to SDHI
> native hotplug detection for the above reason, but there might well be
> other reasons, why this is not a good idea in this specific case. If there
> are such, I'd love to hear about them.
>
I've not heard any more about this one way or the other, so should I
assume you still want it applied? At least we can revert it if one of
these cases pops up, and in the interim it's always preferable to lean
towards better power management for a default.
WARNING: multiple messages have this Message-ID (diff)
From: Paul Mundt <lethal@linux-sh.org>
To: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: linux-sh@vger.kernel.org, Magnus Damm <magnus.damm@gmail.com>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH] sh: ecovec: switch SDHI controllers to card polling
Date: Wed, 28 Mar 2012 06:27:53 +0000 [thread overview]
Message-ID: <20120328062753.GU26543@linux-sh.org> (raw)
In-Reply-To: <Pine.LNX.4.64.1201281929450.27970@axis700.grange>
On Sat, Jan 28, 2012 at 07:36:24PM +0100, Guennadi Liakhovetski wrote:
> Polling for card hotplug events is a better option than using SDHI native
> hotplug interrupt, because the latter option forces the controller to stay
> permanently powered up and enabled.
>
> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>
> It is a kind of an RFC. We do in general prefer SDHI polling to SDHI
> native hotplug detection for the above reason, but there might well be
> other reasons, why this is not a good idea in this specific case. If there
> are such, I'd love to hear about them.
>
I've not heard any more about this one way or the other, so should I
assume you still want it applied? At least we can revert it if one of
these cases pops up, and in the interim it's always preferable to lean
towards better power management for a default.
next prev parent reply other threads:[~2012-03-28 6:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-28 18:36 [PATCH] sh: ecovec: switch SDHI controllers to card polling Guennadi Liakhovetski
2012-01-28 18:36 ` Guennadi Liakhovetski
2012-03-28 6:27 ` Paul Mundt [this message]
2012-03-28 6:27 ` Paul Mundt
2012-03-28 6:58 ` Guennadi Liakhovetski
2012-03-28 6:58 ` Guennadi Liakhovetski
2012-03-28 7:39 ` Paul Mundt
2012-03-28 7:39 ` Paul Mundt
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=20120328062753.GU26543@linux-sh.org \
--to=lethal@linux-sh.org \
--cc=g.liakhovetski@gmx.de \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.