On Thu, May 3, 2018 at 2:26 AM, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> wrote: > On 2018/5/2 20:46, Ulf Hansson wrote: >> >> On 28 April 2018 at 03:11, Shawn Lin <shawn.lin@xxxxxxxxxxxxxx> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
