From: Tomasz Figa <t.figa@samsung.com>
To: Chris Ball <cjb@laptop.org>
Cc: kgene.kim@samsung.com, jy0922.shim@samsung.com,
linux-mmc@vger.kernel.org, kyungmin.park@samsung.com,
linux-samsung-soc@vger.kernel.org, thomas.abraham@linaro.org,
Ben Dooks <ben-linux@fluff.org>,
linux-arm-kernel@lists.infradead.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 12:34:31 +0200 [thread overview]
Message-ID: <1907099.4JSZthrgh2@amdc1227> (raw)
In-Reply-To: <m3a9wmgvip.fsf@pullcord.laptop.org>
Hi Chris,
On Wednesday 19 of September 2012 06:24:46 Chris Ball wrote:
> 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.
We could just check if the regulator provides the capability to change the
voltage.
I don't see any direct way of querying the regulator for provided
capabilities (correct me if I'm just blind), but calling
regulator_count_voltages() on the regulator and checking if the returned
value is 1 should be enough to assume that the regulator is fixed.
What do you think?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
WARNING: multiple messages have this Message-ID (diff)
From: t.figa@samsung.com (Tomasz Figa)
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 12:34:31 +0200 [thread overview]
Message-ID: <1907099.4JSZthrgh2@amdc1227> (raw)
In-Reply-To: <m3a9wmgvip.fsf@pullcord.laptop.org>
Hi Chris,
On Wednesday 19 of September 2012 06:24:46 Chris Ball wrote:
> 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.
We could just check if the regulator provides the capability to change the
voltage.
I don't see any direct way of querying the regulator for provided
capabilities (correct me if I'm just blind), but calling
regulator_count_voltages() on the regulator and checking if the returned
value is 1 should be enough to assume that the regulator is fixed.
What do you think?
Best regards,
--
Tomasz Figa
Samsung Poland R&D Center
next prev parent reply other threads:[~2012-09-19 10:34 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
2012-09-19 10:24 ` Chris Ball
2012-09-19 10:34 ` Tomasz Figa [this message]
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=1907099.4JSZthrgh2@amdc1227 \
--to=t.figa@samsung.com \
--cc=ben-linux@fluff.org \
--cc=cjb@laptop.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=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.