Dear Claudio,
Dear Reinhard thank you for your review. I know that post the patches on an webserver isn't the common path but this time this was really a wip work...
0003-AT91-fix-compile-error-after-f5571dc9.patch
[at91sam9260_devices.c]
That include can not be necessary for your final board support! Note that your board config.h must define which SoC to use first, then include hardware.h to pull in the correct defines.
Inside the board config.h, before the include of hardware.h, I have the appropriate #define AT91SAM9G20 but build fails anyway due to undefined ATMEL_PIO_PORTS.
Have a look at at91avr32rework-2, I pushed the rework for at91sam9260/9g20/9xe-ek there. It compiles with a few warnings and runs.
dataflash still needs some cleanup work to be "nice". And gpio still partially needs legacy defined.
0004-AT91-define-the-mmci-base-address-for-at91sam9-20.patch
[at91sam9260.h]
Line 71 already has: #define ATMEL_BASE_MCI 0xfffa8000 If somewhere else MMCI is used that location must be fixed. We are using the naming introduced in the data sheets.
So the following should be converted: $ grep -inr 'ATMEL_BASE_MMCI' * arch/avr32/include/asm/arch-at32ap700x/hardware.h:78:#define ATMEL_BASE_MMCI 0xFFF02400 drivers/mmc/atmel_mci.h:241: readl((void *)ATMEL_BASE_MMCI + MMCI_##reg) drivers/mmc/atmel_mci.h:243: writel((value), (void *)ATMEL_BASE_MMCI + MMCI_##reg)
Correct. However atmel_mci is the "old" driver, at at91 we are using the common mmc driver gen_atmel_mci. This one should work for avr32 as well (not tested).
0005-AT91-replace-AT91_BASE_SPI-with-ATMEL_BASE_SPI0.patch
[atmel_dataflash_spi.c]
This is a separate patch for the rework of the *generic ATMEL* drivers. It should mention in the subject that it fixes the spi-dataflash driver. I can also squash that one into the "ATMEL: fix related common atmel driver files patch". However
feel free to do so if is convenient for you
For the at91sam9*ek port I had to convert dataflash_spi as well, and fixed the timeout loops to use the correct way. It would be good if you tested that on your board as well.
0006-AT91-move-spi-generic-function-from-top9000-board-to.patch
[spi_cs* functions]
Those functions are not generic. They might be similar on most at91sam9260/9g20/9xe boards but the use of GPIO pins as SPI chip selects is truly board specific. Note that top9000 defines 2x SPI with 4 chip selects each and therefore allows pins to flicker that in other boards might be used for different purposes. You can duplicate the functions but
That not true, I found that those 8 chip select are defined in **exactly** the same way inside at91sm9g20 datasheet. Finally I don't understand WHY those function are used to enable/disable CS when this function should be managed in hw...
According to comments in atmel_spi.c the hardware method is either broken or not flexible enough to hold CS active between individual calls to spi_transfers.
What do you suggest? I should replicate this code or keep a shared file for at91sam9260/9g20/9xe boards and leave avr32 in a separate file?
Not entirely true. Only *IF* you use the (supposedly broken) hardware assertion of the CS lines you are bound to exact those Pins (and above functions could be empty anyway). If you use software methods to assert CS lines (like those functions implement) you are free to use any GPIO pin or even pins at other devices to select an SPI peripheral.
Again: those functions spi_cs_* do not belong into the common SPI driver. You should also see that other AT91 chips and of course AVR32 use different hardware-assigned pins for SPI CS. They do belong in your board port.
Best Regards, Reinhard