Rob Emanuele :
> Greetings,
>
> This patch creates a new AT91 Multimedia Card Interface (MCI) driver
> that supports using both MCI slots at the same time. I'm looking for
> others to test this patch on other boards within the same family of
> chips.
>
> This driver is a port the Atmel AVR32 MCI driver which uses similar silicon.
I am very interested with this work. But, you will have to tell us what
is the precise relation between this code and the Atmel AVR32 MCI driver.
Why did you rename all function and variables to at91... instead of
trying to modify the atmel-mci driver ? Was the needed behavior so far
from the original code that you decided to create another completely new
one ? Please enlighten us.
Moreover, it seems that in your code, DMA is not supported so atmel-mci
without the DMA option enabled should be working without modification at
all (am I missing something ?).
> In addition it modifies the AT91SAM9G20-EK's board platform config to
> support having MCI Slot A hooked to an SD Slot. This was the board
> that this was developed on. To support MCI Slot A it was needed to not
> enable the LEDs on the AT91SAM9G20-EK board if SD/MMC Slot A is
> enabled. The Slot A pins overlap the LEDs on Rev A and B boards.
This is a different board, so you will have to create a different board
source file (board-my9g20customboard.c) or find a clever way of sharing
code (true, can be preferable as only a few lines are changing).
Best regards,
--
Nicolas Ferre
Greetings Nicolas,
Thank you for your interest in this.
On Tue, Jun 2, 2009 at 1:49 AM, Nicolas Ferre <[email protected]> wrote:
> Rob Emanuele :
>> Greetings,
>>
>> This patch creates a new AT91 Multimedia Card Interface (MCI) driver
>> that supports using both MCI slots at the same time. ?I'm looking for
>> others to test this patch on other boards within the same family of
>> chips.
>>
>> This driver is a port the Atmel AVR32 MCI driver which uses similar silicon.
>
> I am very interested with this work. But, you will have to tell us what
> is the precise relation between this code and the Atmel AVR32 MCI driver.
> Why did you rename all function and variables to at91... instead of
> trying to modify the atmel-mci driver ? Was the needed behavior so far
> from the original code that you decided to create another completely new
> one ? Please enlighten us.
>
> Moreover, it seems that in your code, DMA is not supported so atmel-mci
> without the DMA option enabled should be working without modification at
> all (am I missing something ?).
Currently the behavior is similar to that of the AVR32. The DMA
support will be vastly different and the registers are not a perfect
match. Those were the main reasons for diverging the driver from the
AVR32. I need to be sure this code can work as well as possible
without regard for the AVR32 (as I do not have the ability to test
against it for regressions). As the driver improves in performance
and gets to a very stable point I would be happy to look at
re-integrating them.
>
>> In addition it modifies the AT91SAM9G20-EK's board platform config to
>> support having MCI Slot A hooked to an SD Slot. ?This was the board
>> that this was developed on. To support MCI Slot A it was needed to not
>> enable the LEDs on the AT91SAM9G20-EK board if SD/MMC Slot A is
>> enabled. ?The Slot A pins overlap the LEDs on Rev A and B boards.
>
> This is a different board, so you will have to create a different board
> source file (board-my9g20customboard.c) or find a clever way of sharing
> code (true, can be preferable as only a few lines are changing).
I have one that I can include in the next version of the patch.
As it stands now, I am having trouble writing more than a small file
to both cards simultaneously (from the user's point of view). I can
write to one card and then the other. I start to get errors when, for
example, I write continuously to slot B and then try to write anything
more than 16k to slot A. I'm exploring the causes of this. I'm
thinking it is either the controller needs to be fully reconfigured
when switching between slots or that the locks in the driver aren't
protecting everything they need to be.
Again thank you for your interest,
Rob Emanuele