4-bit SD Card mode

[Bernd Walter]

On Thu, Jun 07, 2007 at 12:16:08PM +0200, Björn König wrote:
> Neil wrote:
> > The controllers I've encountered all have a "1
> > bit/4 bit" mode setting, and as long as you tell the card to go in to 4
> > bit mode and set it in the hardware as well, the SD controller handles
> > everything for you.
> 
> You are right; I had an error in reasoning. It should handle it.
> 
> > What is the CPU in question?
> 
> There are issues with AT91RM9200, but now I think the problem is something
> else than I assumed.

What issues?
It is running fine for me beside it could be faster if 4bit and
multiblock transfers would have been implemented.
There are several hardware bugs and design flaws in the MCI hardware,
which make it difficult.

I have a 4bit patch available, but it's not running stable on my
hardware, however I don't think it has anything to do with line
sharing, since handling that is puporse of the MCI hardware.
Currently I have no clue why 4bit doesn't work stable.
Note, there is not reason to change width regulary unless you reselect
cards, which is only required for MMC.

About the multiblock thing.
Writing is not an extremly big issue, but the MCI hardware has
reversed byteorder and requires a buffer to copy data, which needs to
be big enough for requests.

Multiblock reading is problematic, you either need to stop the MCI
befor finishing the last block, or it will automatically start reading
the next one.
When DMA finishes after the last block the first bytes from the next
one get stuck into the read registers, since there is no DMA configured
for the unrequested block it's stuck.
Now the next transfer just gets poisoned with the stuck data bytes.
Atmels workaournd is to stop fast enough or reset the controller after
each transfer.
This hardware flaw at least expects a major change in the interrupt
state machine.
Reseting the controller each time is unlikely a good solution.
Maybe we can just fetch the stuck data bytes befor starting a new
transfer, but this is untested and not mentioned in Atmels offical
workaound.
It might be a better solution to setup a dummy DMA range after the last
intended block and then just reconfigure the PDA for the next transfer.

Unfortunately ENOTIME catched me during work on thoses issues.

-- 
B.Walter                http://www.bwct.de      http://www.fizon.de
bernd at bwct.de           info at bwct.de            support at fizon.de