From: Jassi Brar <jaswinder.singh@linaro.org>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: linux-kernel@vger.kernel.org, lrg@ti.com
Subject: Re: [PATCH] regulator: Provide a check for dummy regulator
Date: Fri, 20 Apr 2012 23:55:22 +0530 [thread overview]
Message-ID: <CAJe_ZhdzuHo8P5WHguKMaikht8aN4RU-j_Q9FB+xOSw=roFZ=w@mail.gmail.com> (raw)
In-Reply-To: <20120420144256.GA6828@opensource.wolfsonmicro.com>
On 20 April 2012 20:12, Mark Brown <broonie@opensource.wolfsonmicro.com> wrote:
>
>> > No. You're failing to understand what dummy regulators are for.
>
>> I think I do understand what dummy regulators are for and also that
>> they are meant to go away some time in future.
>
> No, they're here to stay - people will always be bringing up new boards
> after all - but they're not supposed to be used on platforms.
>
"some time in future" means utopia.... whenever that be. The longer that is
to more important is it for dummy support to be 'complete'.
>
> In any case, as I've said it's not the fact that you've got a dummy
> supply that's an issue for most of the cases you mention - it's the fact
> that the supply is always on.
>
I am not sure anymore you read my posts :(
I am more bothered by the case where the supply is always off i.e,
physically absent.
> Even in the case where a supply might genuinely be missing (which are
> very unusual, it's more effort in silicon to cope with missing supplies)
>
It's not that unusual. See vcc_aux at line 150 of omap_hsmmc.c
See how dummy fools the driver throughout into stuff like toggling vcc
even for platforms that don't really provide vcc_aux.
In practice, see how dummy affects (negatively because of unnecessary
toggles) the vcc too. Not every platform with omap_hsmmc might afford
having dummy disabled (I don't know all to tell for sure).
Best Regards,
-Jassi
next prev parent reply other threads:[~2012-04-20 18:25 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-19 9:51 [PATCH] regulator: Provide a check for dummy regulator Jassi Brar
2012-04-19 12:42 ` Mark Brown
2012-04-19 14:05 ` Jassi Brar
2012-04-19 16:29 ` Mark Brown
2012-04-20 7:32 ` Jassi Brar
2012-04-20 11:46 ` Mark Brown
2012-04-20 12:29 ` Jassi Brar
2012-04-20 13:01 ` Mark Brown
2012-04-20 13:48 ` Jassi Brar
2012-04-20 14:13 ` Jassi Brar
2012-04-20 14:42 ` Mark Brown
2012-04-20 18:25 ` Jassi Brar [this message]
2012-04-20 18:48 ` Mark Brown
2012-04-20 19:11 ` Jassi Brar
2012-04-20 22:04 ` Mark Brown
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='CAJe_ZhdzuHo8P5WHguKMaikht8aN4RU-j_Q9FB+xOSw=roFZ=w@mail.gmail.com' \
--to=jaswinder.singh@linaro.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lrg@ti.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.