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-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
