All of lore.kernel.org
 help / color / mirror / Atom feed
From: Georgi Djakov <gdjakov@mm-sol.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: "linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	"cjb@laptop.org" <cjb@laptop.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"grant.likely@linaro.org" <grant.likely@linaro.org>,
	"rob.herring@calxeda.com" <rob.herring@calxeda.com>,
	Pawel Moll <Pawel.Moll@arm.com>,
	"swarren@wwwdotorg.org" <swarren@wwwdotorg.org>,
	"ijc+devicetree@hellion.org.uk" <ijc+devicetree@hellion.org.uk>,
	"galak@codeaurora.org" <galak@codeaurora.org>,
	"rob@landley.net" <rob@landley.net>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	"subhashj@codeaurora.org" <subhashj@codeaurora.org>
Subject: Re: [PATCH v7 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation
Date: Thu, 30 Jan 2014 19:07:25 +0200	[thread overview]
Message-ID: <52EA86CD.3080609@mm-sol.com> (raw)
In-Reply-To: <20131209093843.GB28379@e106331-lin.cambridge.arm.com>

Hi,

Apologies for the delayed reply.

On 12/09/2013 11:38 AM, Mark Rutland wrote:
> On Fri, Dec 06, 2013 at 11:59:46AM +0000, Georgi Djakov wrote:
>> On 12/05/2013 11:52 AM, Mark Rutland wrote:
[...]
>
>>>> +
>>>> +- qcom,{vdd,vdd-io}-lpm-sup - specifies whether the supply can be kept in low power mode.
>>>
>>> Boolean? Please specify types on properties.
>>
>> Yes, it is boolean. I'll note it in the documentation. Thanks!
>>
>>>
>>> Can you elaborate on what this means? When can a supply not be kept in
>>> low power mode?
>>
>> The vdd-io for example is a regulator that is always-on and may be
>> shared with multiple other peripherals as well. It should not be
>> disabled by the driver, but instead put in low power mode when unused.
>
> The fact that the regulator is driving other peripherals doesn't seem
> like a property of the SDHCI to me. What are these other peripherals?
>

Agree! I'll drop this property.

> When you say should not be disabled by the driver, do you mean that
> another peripheral's driver shouldn't be able to disable the regulator
> feeding the SDHCI, or the SDHCI driver shouldn't be able to disable a
> regulator in use by another peripheral?
>

The regulator will not be disabled in any case as it will be marked as 
always-on.

> When in low power mode, is the SDHCI functional?
>
>>>
>>>> +- qcom,{vdd,vdd-io}-voltage-level - specifies voltage levels for the supply.
>>>> +	Should be specified in pairs (min, max), units uV.
>>>> +- qcom,{vdd,vdd-io}-current-level - specifies load levels for the supply in lpm
>>>> +	or high power mode (hpm). Should be specified in pairs (lpm, hpm), units uA.
>>>
>>> Can you not query these from the regulator framework?
>>>
>>> If these are configuration, why are they necessary?
>>>
>>
>> As some regulators are shared and can have multiple consumers, these
>> properties can be used for voltage and load current aggregation.
>> The voltage-level is the "supported voltage" by the controller, that
>> also (at least on my platform) matches the corresponding regulator
>> voltage. I probably can drop the voltage-level property and get voltage
>> via the regulator framework helper functions, but the load current
>> values are different for each sdhc.
>>   From the very limited documentation that i have, i think this is
>> describing the hardware configuration and should be in the device-tree.
>
> If these are the voltages / currents supported by the SDHCI, then that
> seems like it makes sense to have in DT, if they're likely to be
> variable in practice. How variable do you expect these to be?
>

The voltages vary depending on the function. For example the vdd-io for 
eMMC is 1.2 - 1.8v, for SD cards 1.8 - 2.95v and for SDIO 1.8v.
So, one way is using -min/-max suffixes and the other can be introducing 
a for ex. "function" property (emmc/card/sdio) and moving the voltage 
range definitions into the driver.

> Also, I'd recommend splitting them in to separate -min and -max
> properties, it makes it far clearer what they're actually for.
>

Thanks,
Georgi

  reply	other threads:[~2014-01-30 17:11 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-06 15:56 [PATCH v7 0/2] mmc: sdhci-msm: Add support for MSM chipsets Georgi Djakov
2013-11-06 15:56 ` [PATCH v7 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation Georgi Djakov
2013-12-05  9:52   ` Mark Rutland
2013-12-06 11:59     ` Georgi Djakov
2013-12-09  9:38       ` Mark Rutland
2014-01-30 17:07         ` Georgi Djakov [this message]
2013-11-06 15:56 ` [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets Georgi Djakov
2013-12-05 10:27   ` Mark Rutland
2013-12-06 12:02     ` Georgi Djakov
2013-12-09  9:46       ` Mark Rutland
2014-01-30 17:13         ` Georgi Djakov
2013-12-09 17:00   ` Courtney Cavin
2014-01-30 17:21     ` Georgi Djakov
2014-01-31 17:31       ` Courtney Cavin
2013-11-14 10:18 ` [PATCH v7 0/2] mmc: sdhci-msm: Add " Ivan T. Ivanov

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=52EA86CD.3080609@mm-sol.com \
    --to=gdjakov@mm-sol.com \
    --cc=Pawel.Moll@arm.com \
    --cc=cjb@laptop.org \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=grant.likely@linaro.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=subhashj@codeaurora.org \
    --cc=swarren@wwwdotorg.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.