[U-Boot] [PATCH v2] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263)
Mateusz Kulikowski
mateusz.kulikowski at gmail.com
Thu Nov 28 22:29:48 CET 2013
Dear Andreas Bießmann,
On 11.11.2013 12:03, Andreas Bießmann wrote:
(...)
>> +#include <asm/arch/hardware.h>
>> +#if defined(CONFIG_MACB)
>
> I think we can include the headers unconditionally, or is there a problem?
No problem with that.
>> +
>> + writel(1 << ATMEL_ID_PIOA | 1 << ATMEL_ID_PIOCDE, &pmc->pcer);
>> +
>> + /* Configure RDY/BSY */
>> + at91_set_gpio_input(CONFIG_SYS_NAND_READY_PIN, 1);
>
> Could you please use the generic GPIO API here? Is it Ok for you to not
> mux the pullup for the ready pin?
I've checked schematics - board has external pull-ups, so I can use generic GPIO.
>> +
>> + /* Enable NandFlash */
>> + at91_set_gpio_output(CONFIG_SYS_NAND_ENABLE_PIN, 1);
>
> Here you could really use the gpio_direction_output(). I sent out an RFC
> lately to define new GPIO_PIN_Px() macros. As long as that RFC is not
> reworked and included I think it is Ok to use the CONFIG_ATMEL_LEGACY
> defines.
> Please switch to the generic GPIO API for defining GPIO direction and
> switching GPIO, even on AT91. On the long run we will remove the
> redundant at91_pio API, at least regarding plane GPIO functionality.
> Therefore it would be good to use that API now, even if it costs some
> function calls currently.
Do I understand correctly, that for all ports that I use (via generic GPIO) I should create "temporary" defines
(with hardcoded gpio#)?
Perhaps I'm missing something, but I currently see no other way to get GPIO# (It will change once your RFC is included).
Of course CONFIG_ATMEL_LEGACY has to stay, as atmel_nand uses CONFIG_SYS_NAND_*_PIN and is still using old API (I guess this also needs fixing).
>> + /* Re-enable pull-up */
>> + at91_set_pio_pullup(AT91_PIO_PORTC, 25, 1);
>> + at91_set_pio_pullup(AT91_PIO_PORTE, 25, 1);
>> + at91_set_pio_pullup(AT91_PIO_PORTE, 26, 1);
>> +
>> + at91_macb_hw_init();
>
> Heiko proposed a solution for unifying macb reset sequence.
+1
I will also switch usb_a9263_macb_hw_init() to generic GPIO (and remove re-enabling of pull-ups as they are dropped by at91_macb_hw_init).
>> +#ifdef CONFIG_HAS_DATAFLASH
>> + at91_set_pio_output(AT91_PIO_PORTE, 20, 1); /* select spi0 clock */
>
> Here we could also use the generic GPIO API. Beside that, did you really
> copy the at91sam9263 here? IOW, do you really have a slot for MMC/DF
> here and therefore require to switch the clock?
I copied (see at91sam9263ek.c:256).
I've checked board schematics and this pin is floating, so for v3 I'll drop it.
>
> Beside these minor complaints there is nothing to stop inclusion for
> 2014.01. Please stay tuned and do not send v3 immediately cause of the
> ongoing change for GPIO API and consolidation of macb reset.
> I think another ping from your side in about two weeks would be Ok, if
> you haven't seen changes in the two mentioned points on the list.
Ping :)
Do I understand correctly, that phy_reset RFC will be soon applied, then I should post v3?
Or should I wait for your GPIO RFC?
In the meantime I will start playing with SPL, as u-boot image grows slowly and soon I'll be forced to cut another features just to keep it small enough.
Best Regards,
Mateusz
More information about the U-Boot
mailing list