[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4A269251.8090706@atmel.com>
Date: Wed, 03 Jun 2009 17:10:09 +0200
From: Nicolas Ferre <nicolas.ferre@...el.com>
To: Rob Emanuele <poorarm@...reis.com>
CC: Joey Oravec <joravec@...wtech.com>,
linux-arm-kernel@...ts.arm.linux.org.uk,
linux-kernel@...r.kernel.org,
Haavard Skinnemoen <hskinnemoen@...el.com>
Subject: Re: [PATCH] New AT91 MCI Driver that supports both MCI slots used
at the same time
Rob Emanuele :
> Greetings Joey,
>>> + if (host->need_reset) {
>>> + at91_mci_write(host, AT91_MCI_CR, AT91_MCI_SWRST);
>>> + at91_mci_write(host, AT91_MCI_CR, AT91_MCI_MCIEN);
>>> + at91_mci_write(host, AT91_MCI_MR, host->mode_reg);
>>> + host->need_reset = false;
>>> + }
>>>
>> In my experience some at91s need a reset after every single command,
>> otherwise bad things happen. I think the need_reset logic is too
>> conservative in this driver.
>
> I'll try this and probably make it an option to always reset before
> each command.
This systematic reset was remove by Haavard with this comment:
"Also, don't reset the controller between each transfer. That was an
attempt to work around earlier bugs, and it never really worked very
well."
http://lkml.org/lkml/2008/10/5/152
This reset remains in at91_mci and it does improve things on this driver
but I do not know it a better written driver can prevent from doing this...
>>> + /*
>>> + * WRPROOF and RDPROOF prevent overruns/underruns by
>>> + * stopping the clock when the FIFO is full/empty.
>>> + * This state is not expected to last for long.
>>> + */
>>> + host->mode_reg = (AT91_MCI_CLKDIV & clkdiv) |
>>> AT91_MCI_WRPROOF
>>> + | AT91_MCI_RDPROOF;
>>>
>> These registers are not in all at91 chips especially the at91sam9261.
>
> I'll look into this but will not be able to test every case.
Only at91rm9200 & at91sam9261/9261s are unable to setup these
functionalities.
Best regards,
--
Nicolas Ferre
--
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