Dear Mateusz Kulikowski,
On 11/28/2013 10:29 PM, Mateusz Kulikowski wrote:
On 11.11.2013 12:03, Andreas Bießmann wrote:
<snip>
- /* 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#)?
please use the freshly defined GPIO_PIN_Px() macros from [1].
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).
The series includes change for atmel_nand [2], therefore you can remove that switch.
<snip>
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?
I'll apply that patch [3] this weekend.
Or should I wait for your GPIO RFC?
Is out now ... ;)
Best regards
Andreas Bießmann
[1] http://patchwork.ozlabs.org/patch/295264/ [2] http://patchwork.ozlabs.org/patch/295268/ [3] http://patchwork.ozlabs.org/patch/291958/