On Thu, 24 Jul 2014 17:06:43 +0200 Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote: > Hi, > > Dne 24.7.2014 v 16:26 Boris BREZILLON napsal(a): > > Hello Jiří, > > > > First of all, please try to use git format-patch when submitting a > > patch to any kernel mailing list. > Sorry for that. > > > > On Thu, 24 Jul 2014 15:38:24 +0200 > > Jiří Prchal <jiri.prchal@xxxxxxxxxxx> wrote: > > > >> After ROMBOOT tries boot from flash on SPI0 NPCS0, this NPCS0 (PA14) remains set to PERIPH_A. > >> Because of that, this pin is unusable to something else. > >> This patch sets it back to GPIO. > > > > The policy is to leave pins in an unknown state till some peripheral > > need them. > > > > What are you trying to use this pin for ? > For chip select, but #3. And when SPI communicate with cs0 (PA22), it goes down too (PA14), so 2 devices on bus were > selected. Are you using a 9x5ek board or a custom one, in the latter case could you paste your spi0 node definition ? > > If you just want to use it as a chip select for an spi device, take a > > look at [1]. > At [1] it's OK until as cs0 is for example PA22 and cs1 is PA14. If you want PA14 to control cs1 and PA22 to control cs0 (both configured as GPIOs), you'll have the following definition: cs-gpios = <&pioA 22 0>, <&pioA 14 0>, <0>, <0>; > > > > Here the gpio is requested by the spi core when defining the cs-gpios > > property. The gpio controller then request the listed pins to the pin > > controller (pinctrl driver). > GPIO is not set in driver as GPIO, at least I didn't find it. Take a look at [1], which is set as the gpio_request_enable callback, called by pinctrl core when a gpio is requested. [1]http://lxr.free-electrons.com/source/drivers/pinctrl/pinctrl-at91.c#L665 -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
