[U-Boot] at91 family status

[Reinhard Meyer]

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