From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Andreas_Bie=DFmann?= Date: Fri, 29 Nov 2013 12:31:53 +0100 Subject: [U-Boot] [PATCH v2] arm: at91: support for the Calao USB-A9263 board (based on AT91SAM9263) In-Reply-To: <5297B5CC.4040300@gmail.com> References: <526F7BFE.9050900@gmail.com> <1383347981-4707-1-git-send-email-mateusz.kulikowski@gmail.com> <5280B99C.1070702@gmail.com> <5297B5CC.4040300@gmail.com> Message-ID: <52987B29.3030802@gmail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Mateusz Kulikowski, On 11/28/2013 10:29 PM, Mateusz Kulikowski wrote: > On 11.11.2013 12:03, Andreas Bie?mann wrote: >>> + >>> + /* 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. >> 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/