diff mbox

[v2,1/2] Documentation: mmc: add description for power-delay-ms

Message ID 1524471030-3527-1-git-send-email-shawn.lin@rock-chips.com (mailing list archive)
State New, archived
Headers show

Commit Message

Shawn Lin April 23, 2018, 8:10 a.m. UTC
power-delay-ms woule be used to substitute the hard-coded 10ms
delay waiting for power supply to be stable, specificed by individual
platform/board. Default to 10ms as before, if no available.

Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
---

Changes in v2: None

 Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
 1 file changed, 2 insertions(+)

Comments

Rob Herring (Arm) April 27, 2018, 6:54 p.m. UTC | #1
On Mon, Apr 23, 2018 at 04:10:29PM +0800, Shawn Lin wrote:
> power-delay-ms woule be used to substitute the hard-coded 10ms
> delay waiting for power supply to be stable, specificed by individual
> platform/board. Default to 10ms as before, if no available.
> 
> Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
> ---
> 
> Changes in v2: None
> 
>  Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
> index 467cd7b..8db2ba0 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc.txt
> +++ b/Documentation/devicetree/bindings/mmc/mmc.txt
> @@ -56,6 +56,8 @@ Optional properties:
>  - fixed-emmc-driver-type: for non-removable eMMC, enforce this driver type.
>    The value <n> is the driver type as specified in the eMMC specification
>    (table 206 in spec version 5.1).
> +- power-delay-ms: Tunable delay waiting for I/O signalling and card power supply
> +  to be stable. Default to 10ms if no available.

How long do you need? Would changing the default to say 20ms work and 
still be short enough others don't care?

Can we use the same property as the mmc pwrseq binding defines: 
post-power-on-delay-ms

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
Shawn Lin April 28, 2018, 1:11 a.m. UTC | #2
Hi Rob and Ulf,

On 2018/4/28 2:54, Rob Herring wrote:
> On Mon, Apr 23, 2018 at 04:10:29PM +0800, Shawn Lin wrote:

...

>> +- power-delay-ms: Tunable delay waiting for I/O signalling and card power supply
>> +  to be stable. Default to 10ms if no available.
> 
> How long do you need? Would changing the default to say 20ms work and
> still be short enough others don't care?

It varies from board-2-board, but my boards only need 2ms or less. The
hard-coded 10ms was increased from 2ms since 2009, just for fixing one
board. And nobody complained 10ms is too short(including me), so it's
fine for everybody probably. However, nobody complained it's toooo long
as well, expect me, so my best guess is either others don't care it at
all, or haven't noticed it. So the intention for this patch, is to save
the unnecessary waste for the boot-time sensitive environment, by
reducing the delay but don't break anything else.


> 
> Can we use the same property as the mmc pwrseq binding defines:
> post-power-on-delay-ms

I'm fine with using post-power-on-delay-ms, but it depends on whether
using pwrseq_simple. So I need add parsing it in two places for
different prupose. Is it ok, or better idea?


> 
> 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
Ulf Hansson May 2, 2018, 12:46 p.m. UTC | #3
On 28 April 2018 at 03:11, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> Hi Rob and Ulf,
>
> On 2018/4/28 2:54, Rob Herring wrote:
>>
>> On Mon, Apr 23, 2018 at 04:10:29PM +0800, Shawn Lin wrote:
>
>
> ...
>
>>> +- power-delay-ms: Tunable delay waiting for I/O signalling and card
>>> power supply
>>> +  to be stable. Default to 10ms if no available.
>>
>>
>> How long do you need? Would changing the default to say 20ms work and
>> still be short enough others don't care?
>
>
> It varies from board-2-board, but my boards only need 2ms or less. The
> hard-coded 10ms was increased from 2ms since 2009, just for fixing one
> board. And nobody complained 10ms is too short(including me), so it's
> fine for everybody probably. However, nobody complained it's toooo long
> as well, expect me, so my best guess is either others don't care it at
> all, or haven't noticed it. So the intention for this patch, is to save
> the unnecessary waste for the boot-time sensitive environment, by
> reducing the delay but don't break anything else.
>
>
>>
>> Can we use the same property as the mmc pwrseq binding defines:
>> post-power-on-delay-ms
>
>
> I'm fine with using post-power-on-delay-ms, but it depends on whether
> using pwrseq_simple. So I need add parsing it in two places for
> different prupose. Is it ok, or better idea?

I don't think the parsing is an issue, but that we need to allow two
different descriptions of the same property name may be a bit
confusing.

I would rather keep them separate, but I have no strong onion.

Kind regards
Uffe
--
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
Shawn Lin May 3, 2018, 7:26 a.m. UTC | #4
On 2018/5/2 20:46, Ulf Hansson wrote:
> On 28 April 2018 at 03:11, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>> Hi Rob and Ulf,
>>
>> On 2018/4/28 2:54, Rob Herring wrote:
>>>
>>> On Mon, Apr 23, 2018 at 04:10:29PM +0800, Shawn Lin wrote:
>>
>>
>> ...
>>
>>>> +- power-delay-ms: Tunable delay waiting for I/O signalling and card
>>>> power supply
>>>> +  to be stable. Default to 10ms if no available.
>>>
>>>
>>> How long do you need? Would changing the default to say 20ms work and
>>> still be short enough others don't care?
>>
>>
>> It varies from board-2-board, but my boards only need 2ms or less. The
>> hard-coded 10ms was increased from 2ms since 2009, just for fixing one
>> board. And nobody complained 10ms is too short(including me), so it's
>> fine for everybody probably. However, nobody complained it's toooo long
>> as well, expect me, so my best guess is either others don't care it at
>> all, or haven't noticed it. So the intention for this patch, is to save
>> the unnecessary waste for the boot-time sensitive environment, by
>> reducing the delay but don't break anything else.
>>
>>
>>>
>>> Can we use the same property as the mmc pwrseq binding defines:
>>> post-power-on-delay-ms
>>
>>
>> I'm fine with using post-power-on-delay-ms, but it depends on whether
>> using pwrseq_simple. So I need add parsing it in two places for
>> different prupose. Is it ok, or better idea?
> 
> I don't think the parsing is an issue, but that we need to allow two
> different descriptions of the same property name may be a bit
> confusing.

> I would rather keep them separate, but I have no strong onion.
> 

I also would like to keep the separate. Rob, any suggestion? :)

> Kind regards
> Uffe
> 
> 
> 

--
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
Rob Herring (Arm) May 7, 2018, 1:46 p.m. UTC | #5
On Thu, May 3, 2018 at 2:26 AM, Shawn Lin <shawn.lin@rock-chips.com> wrote:
> On 2018/5/2 20:46, Ulf Hansson wrote:
>>
>> On 28 April 2018 at 03:11, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>>>
>>> Hi Rob and Ulf,
>>>
>>> On 2018/4/28 2:54, Rob Herring wrote:
>>>>
>>>>
>>>> On Mon, Apr 23, 2018 at 04:10:29PM +0800, Shawn Lin wrote:
>>>
>>>
>>>
>>> ...
>>>
>>>>> +- power-delay-ms: Tunable delay waiting for I/O signalling and card
>>>>> power supply
>>>>> +  to be stable. Default to 10ms if no available.
>>>>
>>>>
>>>>
>>>> How long do you need? Would changing the default to say 20ms work and
>>>> still be short enough others don't care?
>>>
>>>
>>>
>>> It varies from board-2-board, but my boards only need 2ms or less. The
>>> hard-coded 10ms was increased from 2ms since 2009, just for fixing one
>>> board. And nobody complained 10ms is too short(including me), so it's
>>> fine for everybody probably. However, nobody complained it's toooo long
>>> as well, expect me, so my best guess is either others don't care it at
>>> all, or haven't noticed it. So the intention for this patch, is to save
>>> the unnecessary waste for the boot-time sensitive environment, by
>>> reducing the delay but don't break anything else.
>>>
>>>
>>>>
>>>> Can we use the same property as the mmc pwrseq binding defines:
>>>> post-power-on-delay-ms
>>>
>>>
>>>
>>> I'm fine with using post-power-on-delay-ms, but it depends on whether
>>> using pwrseq_simple. So I need add parsing it in two places for
>>> different prupose. Is it ok, or better idea?
>>
>>
>> I don't think the parsing is an issue, but that we need to allow two
>> different descriptions of the same property name may be a bit
>> confusing.
>
>
>> I would rather keep them separate, but I have no strong onion.
>>
>
> I also would like to keep the separate. Rob, any suggestion? :)

I think it is fine to describe it in 2 places. It just needs to have
the same definition in terms of what happens before and after it.

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
diff mbox

Patch

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 467cd7b..8db2ba0 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -56,6 +56,8 @@  Optional properties:
 - fixed-emmc-driver-type: for non-removable eMMC, enforce this driver type.
   The value <n> is the driver type as specified in the eMMC specification
   (table 206 in spec version 5.1).
+- power-delay-ms: Tunable delay waiting for I/O signalling and card power supply
+  to be stable. Default to 10ms if no available.
 
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"