From: Chris Ball <cjb@laptop.org>
To: Tomasz Figa <t.figa@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kyungmin.park@samsung.com,
jy0922.shim@samsung.com, kgene.kim@samsung.com,
thomas.abraham@linaro.org, Ben Dooks <ben-linux@fluff.org>,
linux-mmc@vger.kernel.org
Subject: Re: [PATCH v2 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Date: Wed, 19 Sep 2012 06:24:46 -0400 [thread overview]
Message-ID: <m3a9wmgvip.fsf@pullcord.laptop.org> (raw)
In-Reply-To: <1587150.uFGRdL0s8e@amdc1227> (Tomasz Figa's message of "Wed, 19 Sep 2012 12:13:14 +0200")
Hi Tomasz,
On Wed, Sep 19 2012, Tomasz Figa wrote:
> Hi Chris,
>
> On Wednesday 19 of September 2012 01:42:01 Chris Ball wrote:
>> On Tue, Sep 04 2012, Tomasz Figa wrote:
>> > Some boards use fixed voltage regulator for vmmc supply (e.g. for eMMC
>> > memories). MMC_CAP2_BROKEN_VOLTAGE must be enabled for them to operate
>> > correctly.
>>>
>> Is there a reason we can't make this a property on the regulator instead?
>
> Is there a reason we can't make this a property of the mmc subsystem? ;)
>
> Now, seriously, could you elaborate on this a bit more? Do you mean that a
> regulator should provide a dummy set voltage operation that would accept
> any voltage?
Sorry for the terseness.
It seems like we're encoding exactly the same information twice in two
different subsystems -- I don't see the point, so I'd like to think
about how we could do better.
For example, if we're only concerned about fixed regulators, could we
just detect a fixed regulator in the driver and avoid the failing call
to regulator_set_voltage() directly, without needing to go via this
capability? Seems like the capability doesn't tell us anything we
couldn't already have known.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
WARNING: multiple messages have this Message-ID (diff)
From: cjb@laptop.org (Chris Ball)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk
Date: Wed, 19 Sep 2012 06:24:46 -0400 [thread overview]
Message-ID: <m3a9wmgvip.fsf@pullcord.laptop.org> (raw)
In-Reply-To: <1587150.uFGRdL0s8e@amdc1227> (Tomasz Figa's message of "Wed, 19 Sep 2012 12:13:14 +0200")
Hi Tomasz,
On Wed, Sep 19 2012, Tomasz Figa wrote:
> Hi Chris,
>
> On Wednesday 19 of September 2012 01:42:01 Chris Ball wrote:
>> On Tue, Sep 04 2012, Tomasz Figa wrote:
>> > Some boards use fixed voltage regulator for vmmc supply (e.g. for eMMC
>> > memories). MMC_CAP2_BROKEN_VOLTAGE must be enabled for them to operate
>> > correctly.
>>>
>> Is there a reason we can't make this a property on the regulator instead?
>
> Is there a reason we can't make this a property of the mmc subsystem? ;)
>
> Now, seriously, could you elaborate on this a bit more? Do you mean that a
> regulator should provide a dummy set voltage operation that would accept
> any voltage?
Sorry for the terseness.
It seems like we're encoding exactly the same information twice in two
different subsystems -- I don't see the point, so I'd like to think
about how we could do better.
For example, if we're only concerned about fixed regulators, could we
just detect a fixed regulator in the driver and avoid the failing call
to regulator_set_voltage() directly, without needing to go via this
capability? Seems like the capability doesn't tell us anything we
couldn't already have known.
Thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
next prev parent reply other threads:[~2012-09-19 10:24 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-04 8:50 [PATCH v2 0/5] ARM: EXYNOS: Add support for Trats board using device tree Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-04 8:50 ` [PATCH v2 1/5] mmc: host: sdhci-s3c: Add broken-voltage DT property for broken voltage quirk Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-05 8:36 ` Jaehoon Chung
2012-09-05 8:36 ` Jaehoon Chung
2012-09-19 5:42 ` Chris Ball
2012-09-19 5:42 ` Chris Ball
2012-09-19 10:13 ` Tomasz Figa
2012-09-19 10:13 ` Tomasz Figa
2012-09-19 10:24 ` Chris Ball [this message]
2012-09-19 10:24 ` Chris Ball
2012-09-19 10:34 ` Tomasz Figa
2012-09-19 10:34 ` Tomasz Figa
2012-09-19 10:47 ` Chris Ball
2012-09-19 10:47 ` Chris Ball
2012-09-19 10:49 ` Tomasz Figa
2012-09-19 10:49 ` Tomasz Figa
2012-09-19 11:02 ` Jaehoon Chung
2012-09-19 11:02 ` Jaehoon Chung
2012-09-19 14:39 ` Chris Ball
2012-09-19 14:39 ` Chris Ball
2012-09-20 5:57 ` Jaehoon Chung
2012-09-20 5:57 ` Jaehoon Chung
2012-09-04 8:50 ` [PATCH v2 2/5] ARM: Exynos4: dts: Specify address and size cells for i2c controllers Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-05 3:58 ` Thomas Abraham
2012-09-05 3:58 ` Thomas Abraham
2012-09-08 2:37 ` Kukjin Kim
2012-09-08 2:37 ` Kukjin Kim
2012-09-04 8:50 ` [PATCH v2 3/5] ARM: Exynos4: Add OF compatibility lookups for Exynos4 i2c adapters Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-05 3:59 ` Thomas Abraham
2012-09-05 3:59 ` Thomas Abraham
2012-09-08 2:38 ` Kukjin Kim
2012-09-08 2:38 ` Kukjin Kim
2012-09-04 8:50 ` [PATCH v2 4/5] ARM: EXYNOS: Increase maximum possible memory bank size to 512MiB Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-08 2:41 ` Kukjin Kim
2012-09-08 2:41 ` Kukjin Kim
2012-09-08 8:15 ` Tomasz Figa
2012-09-08 8:15 ` Tomasz Figa
2012-09-04 8:50 ` [PATCH v2 5/5] ARM: Exynos: Add basic dts file for Samsung Trats board Tomasz Figa
2012-09-04 8:50 ` Tomasz Figa
2012-09-05 4:05 ` Thomas Abraham
2012-09-05 4:05 ` Thomas Abraham
2012-09-05 5:53 ` Tomasz Figa
2012-09-05 5:53 ` Tomasz Figa
2012-09-08 2:47 ` Kukjin Kim
2012-09-08 2:47 ` Kukjin Kim
2012-09-08 8:21 ` Tomasz Figa
2012-09-08 8:21 ` Tomasz Figa
2012-09-19 23:49 ` Kukjin Kim
2012-09-19 23:49 ` Kukjin Kim
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=m3a9wmgvip.fsf@pullcord.laptop.org \
--to=cjb@laptop.org \
--cc=ben-linux@fluff.org \
--cc=jy0922.shim@samsung.com \
--cc=kgene.kim@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=t.figa@samsung.com \
--cc=thomas.abraham@linaro.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 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.