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@xxxxxxxxxx]
> Sent: Tuesday, January 11, 2011 7:20 AM
> To: Dong, Chuanxiao
> Cc: linux-mmc@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx;
> akpm@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxx>   <http://printf.net/>
> One Laptop Per Child
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/