From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Stephen Warren <swarren@nvidia.com>,
Stephen Warren <swarren@wwwdotorg.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Fri, 4 May 2012 17:32:51 +0200 [thread overview]
Message-ID: <20120504153251.GE7788@game.jcrosoft.org> (raw)
In-Reply-To: <20120504150342.GI5140@atomide.com>
On 08:03 Fri 04 May , Tony Lindgren wrote:
> * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120503 22:08]:
> >
> > In my mind in the driver we do not have to care how to list
> > register/unregister the group. We just need to be able to do this
> >
> > pinctrl_register_group(...)
> >
> > or
> >
> > pinctrl_unregistewr_group(...)
> >
> > On at91 we have this type of controller
>
> Ah I see. Yeah makes sense. Also I think we should let the pinctrl
> core eventually manage the pins more too. Right now the pins are
> a static array in the driver, which makes things unnecessarily
> complex for the DT case. It would be nice to also have something like
> pinctrl_register/unregister_pin instead of requiring them all
> be registered while registering with the framework initially.
>
> But all that can be improved later on once we get the binding down..
agreed at 100%
>
> > one pin can have multiple function and each function can be on different pin
> > and we need to program and represent each of them one by one
> >
> > And each pin have different parameter
> >
> > so I was thinking to do like on gpio
> >
> > uart {
> > pin = < &pioA 12 {pararms} >
> >
> > }
>
> Hmm I assume the "12" above the gpio number?
no pin number in the bank because it could not be gpio
evenif on at91 and nearly on the controller I known it is the case
>
> > and use macro as basicaly we are just this
> >
> > and this can be applied to tegra too as you will just refer the pin in this hw
> > pin block
>
> I was thinking of adding gpio eventually as a separate attribute with
> something like the following. Here cam_d10 pin is used as gpio109:
>
> cam_d10.gpio_109 {
> pinctrl-simple,cells = <0xfa 0x104>; /* OMAP_PIN_INPUT | OMAP_MUX_MODE4 */
> gpio = <&gpio4 13 0>; /* gpio109 */
> };
>
> The reasoning for this is that as we may not care about the gpio number
> for all pins, it should be optional. Would that work for you?
yes
but I was thinking to put it as a param but why not
my idea was this
pinctrl@fffff200 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "atmel,at91rm9200-pinctrl";
atmel,mux-mask = <
/* A B */
0xffffffff 0xffc003ff /* pioA */
0xffffffff 0x800f8f00 /* pioB */
0xffffffff 0x00000e00 /* pioC */
0xffffffff 0xff0c1381 /* pioD */
0xffffffff 0x81ffff81 /* pioE */
>;
pioA: gpio@fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio@fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio@fffff600 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <4 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioD: gpio@fffff800 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fffffa00 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffffa00 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = < &pioB 12 0 0
&pioB 13 0 2 >;
/* with macro */
pins = < &pioB 12 MUX_A NO_PULL_UP
&pioB 13 MUX_A PULL_UP >;
};
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = < &pioB 19 MUX_A PULL_UP /* rxd */
&pioB 18 MUX_A NO_PULL_UP >; /* txd */
};
uart0_rts_cts {
groups = < &uart0_rxd_txd >;
pins = < &pioB 17 MUX_B NO_PULL_UP /* rts */
&pioB 15 MUX_B NO_PULL_UP >; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = < &uart0_rts_cts >;
gpios = <&pioC 1 0>;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Best Regards,
J.
WARNING: multiple messages have this Message-ID (diff)
From: plagnioj@jcrosoft.com (Jean-Christophe PLAGNIOL-VILLARD)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Fri, 4 May 2012 17:32:51 +0200 [thread overview]
Message-ID: <20120504153251.GE7788@game.jcrosoft.org> (raw)
In-Reply-To: <20120504150342.GI5140@atomide.com>
On 08:03 Fri 04 May , Tony Lindgren wrote:
> * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120503 22:08]:
> >
> > In my mind in the driver we do not have to care how to list
> > register/unregister the group. We just need to be able to do this
> >
> > pinctrl_register_group(...)
> >
> > or
> >
> > pinctrl_unregistewr_group(...)
> >
> > On at91 we have this type of controller
>
> Ah I see. Yeah makes sense. Also I think we should let the pinctrl
> core eventually manage the pins more too. Right now the pins are
> a static array in the driver, which makes things unnecessarily
> complex for the DT case. It would be nice to also have something like
> pinctrl_register/unregister_pin instead of requiring them all
> be registered while registering with the framework initially.
>
> But all that can be improved later on once we get the binding down..
agreed at 100%
>
> > one pin can have multiple function and each function can be on different pin
> > and we need to program and represent each of them one by one
> >
> > And each pin have different parameter
> >
> > so I was thinking to do like on gpio
> >
> > uart {
> > pin = < &pioA 12 {pararms} >
> >
> > }
>
> Hmm I assume the "12" above the gpio number?
no pin number in the bank because it could not be gpio
evenif on at91 and nearly on the controller I known it is the case
>
> > and use macro as basicaly we are just this
> >
> > and this can be applied to tegra too as you will just refer the pin in this hw
> > pin block
>
> I was thinking of adding gpio eventually as a separate attribute with
> something like the following. Here cam_d10 pin is used as gpio109:
>
> cam_d10.gpio_109 {
> pinctrl-simple,cells = <0xfa 0x104>; /* OMAP_PIN_INPUT | OMAP_MUX_MODE4 */
> gpio = <&gpio4 13 0>; /* gpio109 */
> };
>
> The reasoning for this is that as we may not care about the gpio number
> for all pins, it should be optional. Would that work for you?
yes
but I was thinking to put it as a param but why not
my idea was this
pinctrl at fffff200 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "atmel,at91rm9200-pinctrl";
atmel,mux-mask = <
/* A B */
0xffffffff 0xffc003ff /* pioA */
0xffffffff 0x800f8f00 /* pioB */
0xffffffff 0x00000e00 /* pioC */
0xffffffff 0xff0c1381 /* pioD */
0xffffffff 0x81ffff81 /* pioE */
>;
pioA: gpio at fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio at fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio at fffff600 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <4 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioD: gpio at fffff800 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioE: gpio at fffffa00 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffffa00 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = < &pioB 12 0 0
&pioB 13 0 2 >;
/* with macro */
pins = < &pioB 12 MUX_A NO_PULL_UP
&pioB 13 MUX_A PULL_UP >;
};
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = < &pioB 19 MUX_A PULL_UP /* rxd */
&pioB 18 MUX_A NO_PULL_UP >; /* txd */
};
uart0_rts_cts {
groups = < &uart0_rxd_txd >;
pins = < &pioB 17 MUX_B NO_PULL_UP /* rts */
&pioB 15 MUX_B NO_PULL_UP >; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = < &uart0_rts_cts >;
gpios = <&pioC 1 0>;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Best Regards,
J.
WARNING: multiple messages have this Message-ID (diff)
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>,
Linus Walleij <linus.walleij@linaro.org>,
linux-omap@vger.kernel.org, Stephen Warren <swarren@nvidia.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf
Date: Fri, 4 May 2012 17:32:51 +0200 [thread overview]
Message-ID: <20120504153251.GE7788@game.jcrosoft.org> (raw)
In-Reply-To: <20120504150342.GI5140@atomide.com>
On 08:03 Fri 04 May , Tony Lindgren wrote:
> * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120503 22:08]:
> >
> > In my mind in the driver we do not have to care how to list
> > register/unregister the group. We just need to be able to do this
> >
> > pinctrl_register_group(...)
> >
> > or
> >
> > pinctrl_unregistewr_group(...)
> >
> > On at91 we have this type of controller
>
> Ah I see. Yeah makes sense. Also I think we should let the pinctrl
> core eventually manage the pins more too. Right now the pins are
> a static array in the driver, which makes things unnecessarily
> complex for the DT case. It would be nice to also have something like
> pinctrl_register/unregister_pin instead of requiring them all
> be registered while registering with the framework initially.
>
> But all that can be improved later on once we get the binding down..
agreed at 100%
>
> > one pin can have multiple function and each function can be on different pin
> > and we need to program and represent each of them one by one
> >
> > And each pin have different parameter
> >
> > so I was thinking to do like on gpio
> >
> > uart {
> > pin = < &pioA 12 {pararms} >
> >
> > }
>
> Hmm I assume the "12" above the gpio number?
no pin number in the bank because it could not be gpio
evenif on at91 and nearly on the controller I known it is the case
>
> > and use macro as basicaly we are just this
> >
> > and this can be applied to tegra too as you will just refer the pin in this hw
> > pin block
>
> I was thinking of adding gpio eventually as a separate attribute with
> something like the following. Here cam_d10 pin is used as gpio109:
>
> cam_d10.gpio_109 {
> pinctrl-simple,cells = <0xfa 0x104>; /* OMAP_PIN_INPUT | OMAP_MUX_MODE4 */
> gpio = <&gpio4 13 0>; /* gpio109 */
> };
>
> The reasoning for this is that as we may not care about the gpio number
> for all pins, it should be optional. Would that work for you?
yes
but I was thinking to put it as a param but why not
my idea was this
pinctrl@fffff200 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "atmel,at91rm9200-pinctrl";
atmel,mux-mask = <
/* A B */
0xffffffff 0xffc003ff /* pioA */
0xffffffff 0x800f8f00 /* pioB */
0xffffffff 0x00000e00 /* pioC */
0xffffffff 0xff0c1381 /* pioD */
0xffffffff 0x81ffff81 /* pioE */
>;
pioA: gpio@fffff200 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff200 0x100>;
interrupts = <2 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioB: gpio@fffff400 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff400 0x100>;
interrupts = <3 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioC: gpio@fffff600 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff600 0x100>;
interrupts = <4 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioD: gpio@fffff800 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffff800 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
pioE: gpio@fffffa00 {
compatible = "atmel,at91rm9200-gpio";
reg = <0xfffffa00 0x100>;
interrupts = <5 4>;
#gpio-cells = <2>;
gpio-controller;
interrupt-controller;
};
dbgu {
pins = < &pioB 12 0 0
&pioB 13 0 2 >;
/* with macro */
pins = < &pioB 12 MUX_A NO_PULL_UP
&pioB 13 MUX_A PULL_UP >;
};
/* and also the notion of linked group
* as on uart of network you have often the same subset of pin use.
*
* As example on uart rxd/txd is use for the group without rts/cts
* and the one with it
* on ethernet the RMII pin are use also on MII
*/
uart0_rxd_txd {
pins = < &pioB 19 MUX_A PULL_UP /* rxd */
&pioB 18 MUX_A NO_PULL_UP >; /* txd */
};
uart0_rts_cts {
groups = < &uart0_rxd_txd >;
pins = < &pioB 17 MUX_B NO_PULL_UP /* rts */
&pioB 15 MUX_B NO_PULL_UP >; /* cts */
};
uart0_rts_cts_external_pull_up {
groups = < &uart0_rts_cts >;
gpios = <&pioC 1 0>;
};
};
The idea is to avoid duplication the xlate for pins will be driver specific
with maybe a common implementation
the 3 or 4 first fix as done on gpio
Best Regards,
J.
next prev parent reply other threads:[~2012-05-04 15:32 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 17:24 [PATCH] pinctrl: Add generic pinctrl-simple driver that supports omap2+ padconf Tony Lindgren
2012-05-02 17:24 ` Tony Lindgren
2012-05-03 6:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03 6:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03 15:27 ` Tony Lindgren
2012-05-03 15:27 ` Tony Lindgren
2012-05-03 22:34 ` Stephen Warren
2012-05-03 22:34 ` Stephen Warren
2012-05-04 4:43 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 4:43 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:03 ` Tony Lindgren
2012-05-04 15:03 ` Tony Lindgren
2012-05-04 15:32 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2012-05-04 15:32 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:32 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:34 ` Tony Lindgren
2012-05-04 16:34 ` Tony Lindgren
2012-05-04 16:38 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:38 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 18:55 ` Stephen Warren
2012-05-04 18:55 ` Stephen Warren
2012-05-04 22:08 ` Tony Lindgren
2012-05-04 22:08 ` Tony Lindgren
2012-05-09 20:19 ` Stephen Warren
2012-05-09 20:19 ` Stephen Warren
2012-05-09 20:49 ` Tony Lindgren
2012-05-09 20:49 ` Tony Lindgren
2012-05-10 17:05 ` Stephen Warren
2012-05-10 17:05 ` Stephen Warren
2012-05-10 17:27 ` Tony Lindgren
2012-05-10 17:27 ` Tony Lindgren
2012-05-11 19:17 ` Stephen Warren
2012-05-11 19:17 ` Stephen Warren
2012-05-11 19:51 ` Tony Lindgren
2012-05-11 19:51 ` Tony Lindgren
2012-05-11 21:04 ` Stephen Warren
2012-05-11 21:04 ` Stephen Warren
2012-05-11 21:18 ` Tony Lindgren
2012-05-11 21:18 ` Tony Lindgren
2012-05-12 23:49 ` Linus Walleij
2012-05-12 23:49 ` Linus Walleij
2012-05-12 23:49 ` Linus Walleij
2012-05-14 18:38 ` Stephen Warren
2012-05-14 18:38 ` Stephen Warren
2012-05-15 20:07 ` Tony Lindgren
2012-05-15 20:07 ` Tony Lindgren
2012-05-16 7:14 ` Linus Walleij
2012-05-16 7:14 ` Linus Walleij
2012-05-16 15:53 ` Stephen Warren
2012-05-16 15:53 ` Stephen Warren
2012-05-05 2:04 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-05 2:04 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-09 20:24 ` Stephen Warren
2012-05-09 20:24 ` Stephen Warren
2012-05-09 9:09 ` Linus Walleij
2012-05-09 9:09 ` Linus Walleij
2012-05-09 20:50 ` Tony Lindgren
2012-05-09 20:50 ` Tony Lindgren
2012-05-04 19:23 ` Stephen Warren
2012-05-04 19:23 ` Stephen Warren
2012-05-04 21:57 ` Tony Lindgren
2012-05-04 21:57 ` Tony Lindgren
2012-05-09 20:16 ` Stephen Warren
2012-05-09 20:16 ` Stephen Warren
2012-05-09 21:08 ` Tony Lindgren
2012-05-09 21:08 ` Tony Lindgren
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120504153251.GE7788@game.jcrosoft.org \
--to=plagnioj@jcrosoft.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=swarren@nvidia.com \
--cc=swarren@wwwdotorg.org \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.