[PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

[PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

[Chuanxiao Dong]

Hi all,
   This is the version 6 of hardware reset feature implementation. When eMMC
   card cannot response any command, signal RST_n can help to reset eMMC
   card.

   patch1: enable HW reset capability if card supports.
   patch2: do hardware reset if card occurs read/write/erase timeout
   patch3: implement hwreset_emmc and reinit_emmc callbacks. In this patch,
   hwreset_emmc callback will pull up/down the corresponded GPIO line number
   to trigger RST_n signal.

   change log:
   1. Move hardware_reset callback to mmc_bus_ops so that all kinds of host
   controller can use hardware_reset callback to trigger RST_n signal.
   Different host controller only needs to provide a GPIO line number to
   this callback.
   2. Add GPIO pull up/down part in hardware_reset callback.
   3. Remove reset_emmc callback in sdhci_ops.

Thanks
Chuanxiao

RE: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

[Dong, Chuanxiao]

Hi Chris,
The HW ware reset patches have been pending for several weeks. The first version was sent at Oct.25th, and now I have updated them to be the version 6. So Chris, would you help me on this?. I want to know whether they are acceptable. And I am ready to fix all the comments from the community. Thanks a lot.

-Chuanxiao

> -----Original Message-----
> From: linux-mmc-owner@vger.kernel.org
> [mailto:linux-mmc-owner@vger.kernel.org] On Behalf Of Chuanxiao Dong
> Sent: Monday, December 27, 2010 6:13 PM
> To: linux-mmc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; cjb@laptop.org; akpm@linux-foundation.org
> Subject: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature
> 
> Hi all,
>    This is the version 6 of hardware reset feature implementation. When eMMC
>    card cannot response any command, signal RST_n can help to reset eMMC
>    card.
> 
>    patch1: enable HW reset capability if card supports.
>    patch2: do hardware reset if card occurs read/write/erase timeout
>    patch3: implement hwreset_emmc and reinit_emmc callbacks. In this patch,
>    hwreset_emmc callback will pull up/down the corresponded GPIO line number
>    to trigger RST_n signal.
> 
>    change log:
>    1. Move hardware_reset callback to mmc_bus_ops so that all kinds of host
>    controller can use hardware_reset callback to trigger RST_n signal.
>    Different host controller only needs to provide a GPIO line number to
>    this callback.
>    2. Add GPIO pull up/down part in hardware_reset callback.
>    3. Remove reset_emmc callback in sdhci_ops.
> 
> Thanks
> Chuanxiao
> --
> 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

Re: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

[Chris Ball]

Hi Chuanxiao,

On Mon, Dec 27, 2010 at 06:13:05PM +0800, Chuanxiao Dong wrote:
> Hi all,
>    This is the version 6 of hardware reset feature implementation. When eMMC
>    card cannot response any command, signal RST_n can help to reset eMMC
>    card.
> 
>    patch1: enable HW reset capability if card supports.
>    patch2: do hardware reset if card occurs read/write/erase timeout
>    patch3: implement hwreset_emmc and reinit_emmc callbacks. In this patch,
>    hwreset_emmc callback will pull up/down the corresponded GPIO line number
>    to trigger RST_n signal.

Sorry for the very late reply.  I'm simply not sure what to do about
this patchset -- I'm extremely reluctant to touch the once-only
programmable bits on the eMMC, and especially to do so silently by
default.

Also, where exactly do you assign host->rst_gpio?  It isn't assigned
to in this patch, so where will it be set?  It looks like you could
end up strobing GPIO0 if a gpio isn't passed in at all.

I haven't seen any other reports of -ETIMEDOUT from eMMC controllers
not responding to CMD0; I wonder if only your controller has this
problem, and if that should change how we handle it.

Does anyone else on the list have feedback on how best to proceed?

Thanks,

-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

RE: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature

[Dong, Chuanxiao]

Hi Chris, Thanks for your review! Below is my answer about your concerns.

> -----Original Message-----
> From: Chris Ball [mailto:cjb@laptop.org]
> Sent: Tuesday, January 11, 2011 7:20 AM
> To: Dong, Chuanxiao
> Cc: linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org;
> akpm@linux-foundation.org
> Subject: Re: [PATCH v6 0/3]mmc: implement eMMC4.4 standard HW reset feature
> 
> Hi Chuanxiao,
> 
> On Mon, Dec 27, 2010 at 06:13:05PM +0800, Chuanxiao Dong wrote:
> > Hi all,
> >    This is the version 6 of hardware reset feature implementation. When eMMC
> >    card cannot response any command, signal RST_n can help to reset eMMC
> >    card.
> >
> >    patch1: enable HW reset capability if card supports.
> >    patch2: do hardware reset if card occurs read/write/erase timeout
> >    patch3: implement hwreset_emmc and reinit_emmc callbacks. In this patch,
> >    hwreset_emmc callback will pull up/down the corresponded GPIO line
> number
> >    to trigger RST_n signal.
> 
> Sorry for the very late reply.  I'm simply not sure what to do about
> this patchset -- I'm extremely reluctant to touch the once-only
> programmable bits on the eMMC, and especially to do so silently by
> default.
Some eMMC4.4 or later new features need to touch the once-only programmable bits...If we support such features, we cannot avoid doing this. So do you think it is better for driver only read such once-only programmable bits? Writing such bits can leave to the manufactory line?
Or using a Kconfig option to notice user is better?

> 
> Also, where exactly do you assign host->rst_gpio?  It isn't assigned
> to in this patch, so where will it be set?  It looks like you could
Yes. host->rst_gpio was planned to put in host controller driver. But there is a dependence for getting the reset gpio number since different platform may use different gpios. I will send it out with my host controller support in the next submission for your review.

> end up strobing GPIO0 if a gpio isn't passed in at all.
Yes. If the rst_gpio was initialized by -ENODEV during host probing by default, this problem will be gone.

> 
> I haven't seen any other reports of -ETIMEDOUT from eMMC controllers
> not responding to CMD0; I wonder if only your controller has this
> problem, and if that should change how we handle it.
My host controller can also responding to CMD0. I am not sure if there will happen such scenario: eMMC card is in some error state and cannot respond any command in case during read/write/erase, host controller can still have another way to reset card and make it back to a normal working state. If such scenario occurs, HW reset feature can be used.

> 
> Does anyone else on the list have feedback on how best to proceed?
> 
> Thanks,
> 
> --
> Chris Ball   <cjb@laptop.org>   <http://printf.net/>
> One Laptop Per Child