Jens, Ulf,
I've run into a basic issue: BLK_SECDISCARD takes 15-35 minutes
perform a secure erase of ~23GB (mostly empty) partition on a 32GB
eMMC part (happens with two vendors). One of the vendors says it
should take less than 60 seconds. I've confirmed erasing 2GB takes
only ~6 seconds - so the
On Tue, 2015-09-22 at 03:56 -0500, Lu Yangbo-B47093 wrote:
> > -Original Message-
> > From: Wood Scott-B07421
> > Sent: Wednesday, September 02, 2015 8:24 AM
> > To: Lu Yangbo-B47093
> > Cc: linux-mmc@vger.kernel.org; ulf.hans...@linaro.org
> > Subject: Re: [v2, 2/3] mmc: sdhci-of-esdhc: ge
Some sdio wifi chips will not work properly if we try to start new
sdio-rw requests while the device is signalling that it is busy.
Signed-off-by: Hans de Goede
---
drivers/mmc/core/core.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/mmc/core/core.c b/drivers/mm
Add a helper function to check if an opcode is a sd-io-rw-* opcode.
Signed-off-by: Hans de Goede
---
drivers/mmc/core/sdio_ops.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/core/sdio_ops.h b/drivers/mmc/core/sdio_ops.h
index 12a4d3a..5660c7f 100644
--- a/drivers/mmc/co
Hi Ulf,
Here is a non RFC version of my patch-set to wait for card_busy before
starting sdio requests. It is the same as the RFC version of the set,
but this time it has been tested no hardware which actually needs this
and I can confirm now that this fixes wifi on that hardware.
This patch-set s
Some sdio wifi modules have not been working reliable with the sunxi-mmc
host code. This turns out to be caused by starting new io-rw commands while
the card signals that it is still busy processing a previous command.
This commit adds card-busy detection to the sunxi-mmc driver which together
wit
On 21/09/15 19:40, Grant Grundler wrote:
> Jon, Ulf,
> Can we first get the current implementation upstream and _then_ add
> more patches to it?
>
> On Mon, Sep 21, 2015 at 4:19 AM, Jon Hunter wrote:
> ...
> + for (i = 0; i < num_of_cmds; i++) {
> + err = __mmc_blk_io
Certain eMMC devices allow vendor specific device information to be read
via a sequence of vendor commands. These vendor commands must be issued
in sequence and an atomic fashion. One way to support this would be to
add an ioctl function for sending a sequence of commands to the device
atomically a
Hi Ulf/Arend,
>
> > On Wed, Nov 26, 2014 at 11:40 PM, Arend van Spriel
> > wrote:
> > On 11/26/14 14:43, Ulf Hansson wrote:
> > > On 26 November 2014 at 12:07, Avinash Patil wrote:
> > > From: Bing Zhao
>
> > > This patch adds new API to handle scatter gather aggregation.
>
> > Why is this ne
