| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <53D21652.7050808@aksignal.cz>
Date: Fri, 25 Jul 2014 10:33:22 +0200
From: Jiří Prchal <jiri.prchal@...ignal.cz>
To: Boris BREZILLON <boris.brezillon@...e-electrons.com>
CC: Bo Shen <voice.shen@...el.com>, nicolas.ferre@...el.com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH] ARM: at91: at91sam9x5: sets NPCS0 (PA14) back to GPIO
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@...ignal.cz> 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@...ignal.cz> 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@...ignal.cz> 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 ?
>> I'm using custom board. My spi node:
>> spi0: spi@...00000 {
>> 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,
>
> Boris
>
> [1]http://lxr.free-electrons.com/source/drivers/spi/spi-atmel.c#L1031
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists