[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110110232020.GA7920@void.printf.net>
Date: Mon, 10 Jan 2011 23:20:20 +0000
From: Chris Ball <cjb@...top.org>
To: Chuanxiao Dong <chuanxiao.dong@...el.com>
Cc: linux-mmc@...r.kernel.org, linux-kernel@...r.kernel.org,
akpm@...ux-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.
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@...top.org> <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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists