From: Adrian Hunter <adrian.hunter@intel.com>
To: Shawn Lin <shawn.lin@rock-chips.com>,
Rob Herring <robh@kernel.org>,
Stefan Wahren <stefan.wahren@i2se.com>
Cc: Dong Aisheng <aisheng.dong@nxp.com>,
Mark Rutland <mark.rutland@arm.com>,
Ulf Hansson <ulf.hansson@linaro.org>, Marek Vasut <marex@denx.de>,
Otavio Salvador <otavio@ossystems.com.br>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Holger Schurig <holgerschurig@gmail.com>,
"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
Sascha Hauer <kernel@pengutronix.de>,
Fabio Estevam <fabio.estevam@nxp.com>,
Shawn Guo <shawnguo@kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH RFC 1/3] DT: bindings: mmc: Add property for 3.3V only support
Date: Thu, 18 Aug 2016 15:25:35 +0300 [thread overview]
Message-ID: <8f87c885-3c55-cac8-a9f5-e121ae031f90@intel.com> (raw)
In-Reply-To: <468a6704-a9f0-1715-ff64-9e331a6a80b1@rock-chips.com>
On 11/08/16 03:48, Shawn Lin wrote:
> + Adrian
>
> Let's queue Adrian here who now maintains SDHCI stuff.
SDHCI drivers may not implement no-1-8-v in a consistent manner, but as far
as I can see, the meaning is still clear: 1.8V will not be used for either
supply or signaling.
SDHCI is complicated because the SDHCI specification does not cover eMMC.
>From the perspective of SDHCI, the only 1.8V modes are the UHS-I modes, so
support for 1.8V signaling is the same as support for one of those modes
(the spec even says as much). But what happens is that the host controller
can support those modes but the board can't supply 1.8V so the drivers
remove capability for the modes. Support for 1.8V supply has a capability
bit which drivers can override if necessary but removable SD cards don't
support 1.8V supply anyway, so the issue doesn't arise if the host
controller is only used for uSD cards.
>
> On 2016/8/11 5:39, Rob Herring wrote:
>> On Wed, Aug 10, 2016 at 3:27 PM, Stefan Wahren <stefan.wahren@i2se.com>
>> wrote:
>>> Hi,
>>>
>>>> Rob Herring <robh@kernel.org> hat am 10. August 2016 um 20:44 geschrieben:
>>>>
>>>>
>>>> On Sat, Aug 06, 2016 at 12:55:38PM +0000, Stefan Wahren wrote:
>>>>> Currently there is no proper way to define that a MMC host supports
>>>>> only 3.3V. The property no-1-8-v is broken and has different meanings
>>>>> for different sdhci variants. So add a new property for 3.3V only
>>>>> support and mark no-1-8-v as deprecated.
>>>>
>>>> Why is it broken?
>>>
>>> i want to quote Ulf Hansson here [1]:
>>>
>>> The problem with the "no-1-8-v" binding is that it's describing what
>>> the hardware *can't* do. It thus becomes easy to abuse it.
>>
>> Sounds like a quirk which is perfectly normal for a property. I'd
>> agree it should be what the h/w *can* do if h/w didn't have capability
>> bit that does that.
>>
>>> I suggest we stop using it, we should mark it deprecated.
>>>
>>> [1] - http://www.spinics.net/lists/linux-mmc/msg34604.html
>>>
>>>> How would I override a controller saying 1.8V is
>>>> supported and it is not?
>>>
>>> Sorry, i'm not sure that i understand your question. In case a board or a
>>> MMC
>>> controller doesn't support 1.8V, it usually supports only 3.3V which is the
>>> intension of this patch.
>>
>> Some controllers have capability bits saying what voltages they
>> support, right? And those bits can be wrong (unless firmware sets them
>> I'd expect that is the common case) which as I read it is what
>> "no-1-8-v" was for. So with the "mmc-ddr-*v" properties, what does not
>> present mean and how do they relate to controller capability bits? I
>> assume they would override the controller bits, but you can only
>> override the capability bit not set case. I would think the property
>> not present means use the capability bit, not that that voltage is not
>> supported. I think you probably need tri-state properties here where
>> value 1 means supported, 0 means not supported, and not present means
>> use capability bit (or other method).
>>
>> Rob
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>
>
next prev parent reply other threads:[~2016-08-18 12:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-06 12:55 [PATCH RFC 0/3] mmc: mxs-mmc: Implement DDR support Stefan Wahren
2016-08-06 12:55 ` [PATCH RFC 1/3] DT: bindings: mmc: Add property for 3.3V only support Stefan Wahren
2016-08-10 18:44 ` Rob Herring
2016-08-10 20:27 ` Stefan Wahren
[not found] ` <853617027.179290.63a6f478-ad48-40c8-82ca-760dd1afc040.open-xchange-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
2016-08-10 21:39 ` Rob Herring
[not found] ` <CAL_JsqJ09hXYrp_pgAw9FXrBv+=grkm_zip6qB9XefujPECTxQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-08-11 0:48 ` Shawn Lin
2016-08-18 12:25 ` Adrian Hunter [this message]
2016-08-30 9:26 ` Ulf Hansson
2016-09-02 18:50 ` Stefan Wahren
[not found] ` <1736517218.106027.c3e46c0d-6759-48dd-92a9-ce98ef74d48a.open-xchange-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
2016-09-08 16:44 ` Rob Herring
2016-08-06 12:55 ` [PATCH RFC 2/3] mmc: core: add new cap for 3.3V only DDR MMCs Stefan Wahren
2016-08-06 13:14 ` Marek Vasut
2016-08-06 14:18 ` Stefan Wahren
2016-08-06 14:42 ` Marek Vasut
[not found] ` <16443443.114784.752d0f22-93a7-46e8-bb14-c884787aaea3.open-xchange-7tX72C7vayboQLBSYMtkGA@public.gmane.org>
2016-08-07 2:07 ` Shawn Lin
[not found] ` <7284d9a4-164d-dd2d-b9a0-dd1de6c76274-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
2016-08-07 8:09 ` Stefan Wahren
2016-08-11 11:12 ` Jaehoon Chung
2016-08-11 11:57 ` Stefan Wahren
2016-08-06 12:55 ` [PATCH RFC 3/3] mmc: mxs-mmc: Implement DDR support Stefan Wahren
2016-08-06 13:13 ` Marek Vasut
2016-08-06 14:08 ` Stefan Wahren
2016-08-06 13:10 ` [PATCH RFC 0/3] " Marek Vasut
2016-08-06 13:48 ` Stefan Wahren
2016-08-07 11:37 ` Stefan Wahren
[not found] ` <1470488140-10104-1-git-send-email-stefan.wahren-eS4NqCHxEME@public.gmane.org>
2016-08-27 19:15 ` Stefan Wahren
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=8f87c885-3c55-cac8-a9f5-e121ae031f90@intel.com \
--to=adrian.hunter@intel.com \
--cc=aisheng.dong@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=fabio.estevam@nxp.com \
--cc=holgerschurig@gmail.com \
--cc=kernel@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-mmc@vger.kernel.org \
--cc=marex@denx.de \
--cc=mark.rutland@arm.com \
--cc=otavio@ossystems.com.br \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=shawnguo@kernel.org \
--cc=stefan.wahren@i2se.com \
--cc=ulf.hansson@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).