* [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list...
@ 2018-07-30 21:29 Patrick Doyle
2018-07-30 21:51 ` Thomas Petazzoni
0 siblings, 1 reply; 5+ messages in thread
From: Patrick Doyle @ 2018-07-30 21:29 UTC (permalink / raw)
To: buildroot
But you folks all know about this sort of stuff anyway, so I figured
I'd start by asking here.
I was just shocked to learn that, although I allocated a pin to a
certain function in my device tree, I was able to override the
operation of that pin via /sys/class/gpio (and thus crash my board
when it could no longer access it's flash properly).
Can anybody here tell me how I can prevent the GPIO subsystem from
overriding the pinmux I specified in my device tree? I guess I
thought that:
pinctrl at fc038000 {
pinctrl_nand_default: nand_default {
pinmux = <PIN_PA8__NWE_NANDWE>,
<PIN_PA9__NCS3>,
<PIN_PA10__A21_NANDALE>,
<PIN_PA11__A22_NANDCLE>,
<PIN_PA12__NRD_NANDOE>,
<PIN_PD8__NANDRDY>,
<PIN_PA0__D0>,
<PIN_PA1__D1>,
<PIN_PA2__D2>,
<PIN_PA3__D3>,
<PIN_PA4__D4>,
<PIN_PA5__D5>,
<PIN_PA6__D6>,
<PIN_PA7__D7>;
bias-disable;
};
would have done the trick (on my Microchip SAMA5D2x device).
--wpd
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list...
2018-07-30 21:29 [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list Patrick Doyle
@ 2018-07-30 21:51 ` Thomas Petazzoni
2018-07-31 13:53 ` Patrick Doyle
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Petazzoni @ 2018-07-30 21:51 UTC (permalink / raw)
To: buildroot
Hello Patrick,
On Mon, 30 Jul 2018 17:29:36 -0400, Patrick Doyle wrote:
> But you folks all know about this sort of stuff anyway, so I figured
> I'd start by asking here.
>
> I was just shocked to learn that, although I allocated a pin to a
> certain function in my device tree, I was able to override the
> operation of that pin via /sys/class/gpio (and thus crash my board
> when it could no longer access it's flash properly).
>
> Can anybody here tell me how I can prevent the GPIO subsystem from
> overriding the pinmux I specified in my device tree? I guess I
> thought that:
>
> pinctrl at fc038000 {
> pinctrl_nand_default: nand_default {
> pinmux = <PIN_PA8__NWE_NANDWE>,
> <PIN_PA9__NCS3>,
> <PIN_PA10__A21_NANDALE>,
> <PIN_PA11__A22_NANDCLE>,
> <PIN_PA12__NRD_NANDOE>,
> <PIN_PD8__NANDRDY>,
> <PIN_PA0__D0>,
> <PIN_PA1__D1>,
> <PIN_PA2__D2>,
> <PIN_PA3__D3>,
> <PIN_PA4__D4>,
> <PIN_PA5__D5>,
> <PIN_PA6__D6>,
> <PIN_PA7__D7>;
> bias-disable;
> };
>
> would have done the trick (on my Microchip SAMA5D2x device).
This snippet of Device Tree only declares a pinmux configuration. If
there is nothing referencing pinctrl_nand_default, then this pinmux
configuration is not used/applied, and the pins are not "reserved".
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list...
2018-07-30 21:51 ` Thomas Petazzoni
@ 2018-07-31 13:53 ` Patrick Doyle
2018-07-31 14:17 ` Thomas Petazzoni
0 siblings, 1 reply; 5+ messages in thread
From: Patrick Doyle @ 2018-07-31 13:53 UTC (permalink / raw)
To: buildroot
On Mon, Jul 30, 2018 at 5:51 PM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Hello Patrick,
>
> This snippet of Device Tree only declares a pinmux configuration. If
> there is nothing referencing pinctrl_nand_default, then this pinmux
> configuration is not used/applied, and the pins are not "reserved".
>
Hi Thomas,
Thank you for the quick reply. pinctrl_nand_default _is_ referenced
by the device tree clause for the nand controller:
nand0: nand at 80000000 {
nand-bus-width = <8>;
nand-ecc-mode = "hw";
nand-on-flash-bbt;
atmel,has-pmecc;
atmel,pmecc-cap = <12>;
atmel,pmecc-sector-size = <512>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_nand_default &pinctrl_nand_rdy_en>;
status = "okay";
...
Hence my confusion. Am I missing something else somewhere?
--wpd
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list...
2018-07-31 13:53 ` Patrick Doyle
@ 2018-07-31 14:17 ` Thomas Petazzoni
2018-07-31 15:17 ` Patrick Doyle
0 siblings, 1 reply; 5+ messages in thread
From: Thomas Petazzoni @ 2018-07-31 14:17 UTC (permalink / raw)
To: buildroot
Hello Patrick,
On Tue, 31 Jul 2018 09:53:34 -0400, Patrick Doyle wrote:
> Thank you for the quick reply. pinctrl_nand_default _is_ referenced
> by the device tree clause for the nand controller:
>
> nand0: nand at 80000000 {
> nand-bus-width = <8>;
> nand-ecc-mode = "hw";
> nand-on-flash-bbt;
> atmel,has-pmecc;
> atmel,pmecc-cap = <12>;
> atmel,pmecc-sector-size = <512>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_nand_default &pinctrl_nand_rdy_en>;
> status = "okay";
> ...
>
> Hence my confusion. Am I missing something else somewhere?
Asked internally, and my colleague Maxime Ripard (in Cc) gave some
explanation about this: it depends on whether the pinctrl driver uses
the strict mode or not and the Atmel doesn't.
This allows to request a pin as a GPIO even if this pin is already
muxed as a different functionality. Some details about this are
available at "GPIO mode pitfalls" in
https://www.kernel.org/doc/Documentation/driver-api/pinctl.rst (link
also provided by Maxime).
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list...
2018-07-31 14:17 ` Thomas Petazzoni
@ 2018-07-31 15:17 ` Patrick Doyle
0 siblings, 0 replies; 5+ messages in thread
From: Patrick Doyle @ 2018-07-31 15:17 UTC (permalink / raw)
To: buildroot
On Tue, Jul 31, 2018 at 10:18 AM Thomas Petazzoni
<thomas.petazzoni@bootlin.com> wrote:
> Asked internally, and my colleague Maxime Ripard (in Cc) gave some
> explanation about this: it depends on whether the pinctrl driver uses
> the strict mode or not and the Atmel doesn't.
>
> This allows to request a pin as a GPIO even if this pin is already
> muxed as a different functionality. Some details about this are
> available at "GPIO mode pitfalls" in
> https://www.kernel.org/doc/Documentation/driver-api/pinctl.rst (link
> also provided by Maxime).
Hmmm... I might try setting .strict = true in the Atmel driver and
seeing what blows up. If nothing blows up (or even if it does), then
I'll try harder to understand the differences between the two modes
and the implication on the Atmel driver.
Thanks again.
--wpd
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-31 15:17 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-30 21:29 [Buildroot] Random Linux/device tree/GPIO question posted to the wrong list Patrick Doyle
2018-07-30 21:51 ` Thomas Petazzoni
2018-07-31 13:53 ` Patrick Doyle
2018-07-31 14:17 ` Thomas Petazzoni
2018-07-31 15:17 ` Patrick Doyle
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.