Hi, > -----Original Message----- > From: Richard Leitner [mailto:richard.leitner@xxxxxxxxxxx] > Sent: Wednesday, June 14, 2017 9:25 AM > To: Ulf Hansson <ulf.hansson@xxxxxxxxxx>; Linus Walleij > <linus.walleij@xxxxxxxxxx> > Cc: Bart Van Assche <bart.vanassche@xxxxxxxxxxx>; Luca Porzio (lporzio) > <lporzio@xxxxxxxxxx>; Rob Herring <robh+dt@xxxxxxxxxx>; Mark Rutland > <mark.rutland@xxxxxxx>; Shawn Lin <shawn.lin@xxxxxxxxxxxxxx>; Adrian > Hunter <adrian.hunter@xxxxxxxxx>; Jaehoon Chung > <jh80.chung@xxxxxxxxxxx>; linux-mmc@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; devicetree@xxxxxxxxxxxxxxx; Richard Leitner > <dev@xxxxxxxxxx> > Subject: [EXT] Re: [PATCH v2] mmc: core: add mmc-card hardware reset > enable support > > On 04/11/2017 12:43 PM, Ulf Hansson wrote: > > On 11 April 2017 at 10:17, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote: > >> On Tue, Apr 11, 2017 at 9:31 AM, Richard Leitner > >> <richard.leitner@xxxxxxxxxxx> wrote: > >> > >>> Some eMMCs disable their hardware reset line (RST_N) by default. To > >>> enable it the host must set the corresponding bit in ECSD. An > >>> example for such a device is the Micron MTFCxGACAANA-4M. > >>> This behavior is not Micron specific but instead it is enforced by the Jedec Specification. All eMMC must have HW reset disabled by default. > >>> This patch adds a new mmc-card devicetree property to let the host > >>> enable this feature during card initialization. > >>> > >>> Signed-off-by: Richard Leitner <richard.leitner@xxxxxxxxxxx> > >> > >> Do we know *WHY* these cards disable their hardware reset lines? > > > > Allow me to make a guess. In case the reset isn't enabled, the > > internal eMMC card firmware don't monitor the pin for the reset. I > > guess that could makes sense if SoC vendors has failed to properly > > connect the pin, avoiding the eMMC card to be reset when it shouldn't. > > > >> If it is just some random over-cautious panic thing we might consider > >> just force re-enableing it, maybe with a warning in the dmesg, so we > >> can always reset the card. No DT property needed. > > This specification (as Ulf correctly hinted) originated from badly connected HW Reset pins which caused unnecessary eMMC reset glitches. Disabling this feature is a good option to contain glitches and avoid system level bugs. > > There is actually already a DT property "cap-mmc-hw-reset" > > (MMC_CAP_HW_RESET), which tells whether the eMMC reset is > supported by > > the host. > > > > Perhaps we can consider to force-enabling it for the eMMC card, when > > this property is set for the mmc host!? At least, inventing yet > > another binding doesn't make sense to me. > > IMHO setting this (permanent) configuration bit should be done explicitly > and not within another DT property. Otherwise somebody may accidentally > set this configuration by (for example) including a dtsi which has cap-mmc- > hw-reset configured. > > Nonetheless if the majority agrees to implicitly set it when "cap-mmc-hw- > reset" is configured I'm fine with that too. > > Another possibility is to don't include it in the kernel at all and therefore > require the mmc userspace program to configure it...? > > > > >> Putting some people who work for eMMC vendors in the To: line so they > >> can say if they know about this. > > > > Yes, let's see what they say about it. Here I am :-) > > Any news/comments? > IMHO mmc-util is where the patch really stands: the enabling is OTP, the programmer have to use mmc-util only once and the kernel will behave accordingly. Any platform vendor must check that the HW Reset pin is actually Connected BEFORE enabling this feature otherwise the system may be unstable. A DT Binding may be dangerous if this condition is not met as well as the code execution at each MMC init is honestly redundant for an OTP location of the extCSD. Cheers, Luca > kind regards, > Richard.L ��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
