[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20071017193713.38D3923A5D5@adsl-69-226-248-13.dsl.pltn13.pacbell.net>
Date: Wed, 17 Oct 2007 12:37:13 -0700
From: David Brownell <david-b@...bell.net>
To: linux-kernel@...r.kernel.org, drzeus-list@...eus.cx
Subject: Re: mmc_spi stopped working
> I just tried out mmc_spi on Linux HEAD and it no longer works. :/
I noticed that too. I've got a patch for one bug (appended), and
will be looking at a fix for the second.
> It seems to be caused by changes in the SPI core on how to handled bus
> sharing. All I'm getting in dmesg is this:
>
> [17179577.832000] mmc_spi spi1.0: can't share SPI bus
> [17179577.836000] mmc_spi: probe of spi1.0 failed with error -31
That issue is 49dce689ad4ef0fd1f970ef762168e4bd46f69a3, the
classdev-elimination patch from Tony Jones. It broke the
"does this bus have more than one device" test by relocating
the relevant sysfs nodes.
Quick workaround for that one is to disable the fault return
after that test.
- Dave
========== CUT HERE
When enumerating MMC cards using SPI, don't support the "just probe"
mechanism since it doesn't always work. Instead, always wait for the
reset to complete before issuing the next request.
This is a regression ... this SanDisk MMC card used to enumerate with
no trouble, despite this particular spec violation.
Signed-off-by: David Brownell <dbrownell@...rs.sourceforge.net>
--- a/drivers/mmc/core/mmc_ops.c 2007-10-13 17:44:43.000000000 -0700
+++ b/drivers/mmc/core/mmc_ops.c 2007-10-16 18:54:38.000000000 -0700
@@ -115,8 +115,11 @@ int mmc_send_op_cond(struct mmc_host *ho
if (err)
break;
- /* if we're just probing, do a single pass */
- if (ocr == 0)
+ /* if we're just probing, do a single pass ... except,
+ * accomodate cards which don't behave right until a
+ * SPI reset completes.
+ */
+ if (ocr == 0 && !mmc_host_is_spi(host))
break;
/* otherwise wait until reset completes */
-
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