| Message ID | 1524471030-3527-1-git-send-email-shawn.lin@rock-chips.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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
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
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
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
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 --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"
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(+)