On Tuesday 27 January 2009, Hugo Villeneuve wrote:
> On Tue, 27 Jan 2009 11:10:51 -0800
> David Brownell <[email protected]> wrote:
>
> > On Tuesday 27 January 2009, Hugo Villeneuve wrote:
> > > I´m trying to use a Marvell 88w8686 chip with a DM6446 and the
> > > libertas driver. So far it looks promising as the libertas is able
> > > to detect the chip, send the firmware to it and configure it.
> >
> > You neglected to say which kernel. Current GIT?
>
> Hi Dave,
> sorry, my kernel is davinci-2.6 GIT.
OK ...
> > If so, are you using the RFT patch I sent along,
> > to activate the SDIO IRQ?
>
> I did not use any patches.
>
> > So far as I know, no GIT kernel has ever supported
> > SDIO IRQs. If it's some non-git kernel, please
> > give the above combination a try. I know I've
> > triggered DMA error IRQs and seen them handled
> > correctly.
>
> So if I am using the latest davinci git kernel, should I apply your
> patch? If so where is it located?
I just resent that.
Capsule summary of what I write below: this looks like
an issue specific to SDIO. So I suspect you'll need to
dive into SDIO a bit and debug this ...
> I also found that prior to the crash, I have this error message <DMA
> write error>, also coming from the mmc_davinci_dma_cb() function:
>
> Begin kernel log
> -------------------------------------------
> mmc0: starting CMD52 arg 10004000 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10004000, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001008 00000000 00000000 00000000
> mmc0: starting CMD53 arg 92000020 flags 000001b5
> mmc0: blksz 32 blocks 1 flags 00000100 tsac 1000 ms nsac 0
> davinci_mmc davinci_mmc.0: MMCSD : Data xfer (block write), DTO 0
> cycles + 1000000000 ns, 1 blocks of 32 bytes davinci_mmc davinci_mmc.0:
> CMD53, arg 0x92000020, R1/R5/R6/R7 response
Looks like your mailer is mangling lines there ... that should
be two lines (one longish), not three.
> davinci_mmc davinci_mmc.0: DMA write error
> mmc0: req done (CMD53): 0: 00002000 00000000 00000000 00000000
> mmc0: 32 bytes transferred: -5
OK, so this time the DMA error callback seems to have worked as
it should. I'd have to dive into MMC and SDIO specs to see what
that command and status bit signify, but -EIO after a DMA error
is appropriate. And subsequent commands act OK...
> mmc0: starting CMD52 arg 00000a00 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x00000a00, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
> mmc0: starting CMD52 arg 10000a00 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10000a00, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
> mmc0: starting CMD52 arg 90000afd flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x90000afd, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 000010fd 00000000 00000000 00000000
> mmc0: starting CMD52 arg 00000a00 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x00000a00, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001002 00000000 00000000 00000000
> mmc0: starting CMD52 arg 10000a00 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10000a00, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001001 00000000 00000000 00000000
> mmc0: starting CMD52 arg 90000afe flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x90000afe, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 000010fe 00000000 00000000 00000000
> mmc0: starting CMD52 arg 10006800 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10006800, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 0000101d 00000000 00000000 00000000
> mmc0: starting CMD52 arg 10006a00 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10006a00, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 00001000 00000000 00000000 00000000
> mmc0: starting CMD52 arg 10004000 flags 00000195
> davinci_mmc davinci_mmc.0: CMD52, arg 0x10004000, R1/R5/R6/R7 response
> mmc0: req done (CMD52): 0: 0000100a 00000000 00000000 00000000
> mmc0: starting CMD53 arg 12000020 flags 000001b5
> mmc0: blksz 32 blocks 1 flags 00000200 tsac 1000 ms nsac 0
> davinci_mmc davinci_mmc.0: MMCSD : Data xfer (block read), DTO 0 cycles
> + 1000000000 ns, 1 blocks of 32 bytes davinci_mmc davinci_mmc.0: CMD53,
> arg 0x12000020, R1/R5/R6/R7 response mmc0: req done (CMD53): 0:
> 00002000 00000000 00000000 00000000 mmc0: 32 bytes transferred: 0
OK, that block *read* worked OK ... note that CMD53 is used
for both reads and writes here.
> davinci_mmc davinci_mmc.0: host->data is NULL
> Unable to handle kernel NULL pointer dereference at virtual address
> 00000014
That "host->data is NULL" message is your own, I take it?
Because the only similar message in the driver has a prefix,
"TC:host->data is NULL". It shows on an error case: a
transfer complete IRQ, but no transfer active.
What's odd here is that the DMA should already have been
cleanly shut down.
Also: I'm suspecting that "host" itself is NULL, which
should never happen ... what are the arguments provided
to that DMA error callback?
CMD53 is SD_IO_RW_EXTENDED ... I suspect the current code
is making an assumption that CMD53 doesn't follow, which
explains both the errors observed here. It might relate
to SDIO IRQs, since <linux/mmc/sdio.h> refers to various
cases where they appear during CMD53.
- Dave
> -------------------------------------------
> End kernel log
>
> I don´t have any clue as to what could cause this DMA write error...
Something related to code paths for SDIO CMD53 acting unlike
the MMC and SD code paths that work so far. Look at the SDIO
code in mmc/core and at the public SDIO specs.
FYI -- minor diagnostics-tweaking patch below.
- Dave
---
drivers/mmc/host/davinci_mmc.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
--- a/drivers/mmc/host/davinci_mmc.c
+++ b/drivers/mmc/host/davinci_mmc.c
@@ -660,13 +660,12 @@ mmc_davinci_prepare_data(struct mmc_davi
return;
}
- dev_dbg(mmc_dev(host->mmc),
- "MMCSD : Data xfer (%s %s), "
- "DTO %d cycles + %d ns, %d blocks of %d bytes\n",
+ dev_dbg(mmc_dev(host->mmc), "%s %s, %d blocks of %d bytes\n",
(data->flags & MMC_DATA_STREAM) ? "stream" : "block",
(data->flags & MMC_DATA_WRITE) ? "write" : "read",
- data->timeout_clks, data->timeout_ns,
data->blocks, data->blksz);
+ dev_dbg(mmc_dev(host->mmc), " DTO %d cycles + %d ns\n",
+ data->timeout_clks, data->timeout_ns);
/* Convert ns to clock cycles by assuming 20MHz frequency
* 1 cycle at 20MHz = 500 ns
@@ -867,12 +866,6 @@ static void mmc_davinci_cmd_done(struct
{
host->cmd = NULL;
- if (!cmd) {
- dev_warn(mmc_dev(host->mmc),
- "%s(): No cmd ptr\n", __func__);
- return;
- }
-
if (cmd->flags & MMC_RSP_PRESENT) {
if (cmd->flags & MMC_RSP_136) {
/* response type 2 */
@@ -948,7 +941,8 @@ static inline int handle_core_command(
end_transfer = 1;
data->bytes_xfered += data->blocks * data->blksz;
} else {
- dev_warn(mmc_dev(host->mmc), "TC:host->data is NULL\n");
+ dev_err(mmc_dev(host->mmc),
+ "DATDNE with no host->data\n");
}
}
@@ -991,8 +985,8 @@ static inline int handle_core_command(
if (qstatus & MMCST0_TOUTRS) {
/* Command timeout */
if (host->cmd) {
- dev_dbg(mmc_dev(host->mmc), "MMCSD: CMD%d "
- "timeout, status %x\n",
+ dev_dbg(mmc_dev(host->mmc),
+ "CMD%d timeout, status %x\n",
host->cmd->opcode, qstatus);
host->cmd->error = -ETIMEDOUT;
if (data) {
@@ -1016,7 +1010,7 @@ static inline int handle_core_command(
if (qstatus & MMCST0_RSPDNE) {
/* End of command phase */
- end_command = 1;
+ end_command = (int) host->cmd;
}
if (end_command)
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
