RE: [PATCH 1/1] DaVinci: MMC: V4: MMC/SD controller driver forDaVinci family.

From: Kumar, Purushotam
Date: Tue Apr 21 2009 - 10:15:39 EST


> >
> > This required by SD controller as suggested by IP designer. Please
> > look at SD controller spec at http://www.ti.com/litv/pdf/sprue30d .
> > Please check section 3.2/3.6 and point no 11/10 in the controller spec.
>
> In this case the spec says in a note in 2.7.2 that priming
> the fifo is needed for "write transactions" ... since no
> "fifo became empty" IRQ is generated. It does not limit it
> to the WRITE_BLOCK and WRITE_MULTIPLE_BLOCK commands.
>
> Those examples are for writing single and multiple blocks; there
> are no SDIO write operations shown, for example, or password
> passing operations. Those would also suffer from the lack of
> a "fifo became empty" IRQ.
>

It seems you are right that FIFO is required to be primed before any write transaction.

> > It does not talk about priming by 32 bytes for any other command.
> Said diffferently, *every* PIO write transaction shown primes
> the fifo ... but there are no examples of non-block writes.

We need to prime the FIFO beforehand with whatever data we intend to transfer. We looked into SDIO driver on DM6446 and observed that it requires priming.


> > This restriction is from SD controller.
>
> Could you confirm that interpretation with the folk who have
> provided that silicon block?
>
> If your reading is correct, and it's really a restriction to
> those two commands, the documentation should change to say
> that "single and multiple block write commands" require FIFO
> priming ... not all "write transactions" as now written.

Apart from above there was a doubt for:
if (!host->do_dma && (host->data_dir == DAVINCI_MMC_DATADIR_WRITE))
davinci_fifo_data_trans(host, 32);
We will also remove check for CMD25 and CMD24 before priming and so it will allow priming for all commands.

Although there does seem to be a bug there ... it should never fill the
fifo with more data than is being sent.

The second parameter is rightly justified as it is the length of fifo. If
you see inside the davinci_fifo_data_trans() the FIFO is only primed based
upon the data size during that transfer. So in a way we are not filling the
fifo with more data.

We will re-submit patch tomorrow. Please let us know if you have any further concerns.
Regards,
Purushotam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/