All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shawn Lin <shawn.lin@rock-chips.com>
To: Ulf Hansson <ulf.hansson@linaro.org>, Rob Herring <robh@kernel.org>
Cc: shawn.lin@rock-chips.com, Jaehoon Chung <jh80.chung@samsung.com>,
	Wolfram Sang <wsa+renesas@sang-engineering.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	"linux-mmc@vger.kernel.org" <linux-mmc@vger.kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCH v2 1/2] Documentation: mmc: add description for power-delay-ms
Date: Thu, 3 May 2018 15:26:40 +0800	[thread overview]
Message-ID: <4e6952d7-4896-71d3-9522-fe4c67f03ed2@rock-chips.com> (raw)
In-Reply-To: <CAPDyKFrYyaRASpAx7c6BvJ_5LP4whNeRUv-ZrveLftnV6ywO3w@mail.gmail.com>

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


  reply	other threads:[~2018-05-03  7:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-23  8:10 [PATCH v2 1/2] Documentation: mmc: add description for power-delay-ms Shawn Lin
2018-04-23  8:10 ` [PATCH v2 2/2] mmc: core: add tunable delay waiting for power to be stable Shawn Lin
2018-04-23  8:36   ` Adrian Hunter
2018-04-27 18:54 ` [PATCH v2 1/2] Documentation: mmc: add description for power-delay-ms Rob Herring
2018-04-28  1:11   ` Shawn Lin
2018-05-02 12:46     ` Ulf Hansson
2018-05-03  7:26       ` Shawn Lin [this message]
2018-05-07 13:46         ` Rob Herring

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=4e6952d7-4896-71d3-9522-fe4c67f03ed2@rock-chips.com \
    --to=shawn.lin@rock-chips.com \
    --cc=adrian.hunter@intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jh80.chung@samsung.com \
    --cc=linux-mmc@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa+renesas@sang-engineering.com \
    /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.