Re: [PATCH] ARM: at91: at91sam9x5: sets NPCS0 (PA14) back to GPIO

From: JiÅÃ Prchal
Date: Fri Jul 25 2014 - 04:33:37 EST

I changed manually .config,
now it's there:
[ 1.195312] spi spi0.0: gpio_request: 23
[ 1.195312] spi spi0.1: gpio_request: 22
[ 1.199218] spi spi0.2: gpio_request: 93
[ 1.203125] spi spi0.3: gpio_request: 14

But still not working.

Dne 25.7.2014 v 09:53 Boris BREZILLON napsal(a):
On Fri, 25 Jul 2014 08:14:40 +0200
JiÅÃ Prchal <jiri.prchal@xxxxxxxxxxx> wrote:

Dne 24.7.2014 v 17:58 Boris BREZILLON napsal(a):
On Thu, 24 Jul 2014 17:06:43 +0200
JiÅÃ Prchal <jiri.prchal@xxxxxxxxxxx> wrote:


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

Are you using a 9x5ek board or a custom one, in the latter case could
you paste your spi0 node definition ?
I'm using custom board. My spi node:
spi0: spi@f0000000 {
status = "okay";
cs-gpios = <&pioA 23 0
&pioA 22 0
&pioC 29 0
&pioA 14 0>;

fm25@0 {
compatible = "cypress,fm25";
spi-max-frequency = <40000000>;
reg = <0>;
pagesize = <256>;
size = <131072>;
address-width = <24>;
/* ADC */
spidev@1 {
compatible = "spidev";
reg = <1>;
spi-max-frequency = <1000000>;
/* IO expander for busaddr */
spidev@2 {
compatible = "spidev";
reg = <2>;
label = "busaddr";
spi-max-frequency = <10000000>;
/* audio codec */
codec: codec@3 {
compatible = "ti,tlv320aic3x";
spi-max-frequency = <1000000>;
reg = <3>;

This does not work without patch, because of 2 chips selected at one time because of PA14 is periph_a. Probably ROMBOOT
changes that.

Yes, boot code stored in ROM probably mux PA14 to periph A function,
but with your definition PA 14 should be set GPIO mode when the codec
device is created.

I don't see any obvious error in your definition, could you add a trace
there [1] to see if the gpio is successfully requested ?
Could you also paste the content of /sys/kernel/debug/gpio ?

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>;
See my node.

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.
But is this called from spi driver when requesting gpios as cs?

Yes, it's part of the gpio_request process:
gpio_request calls request method on at91 gpio_chip which in turn
calls pinctrl_request_gpio which then calls the gpio_request_enable
method I previously mentioned.

Best Regards,



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at