From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tony Lindgren <tony@atomide.com>,
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: Sat, 5 May 2012 04:04:14 +0200 [thread overview]
Message-ID: <20120505020414.GJ7788@game.jcrosoft.org> (raw)
In-Reply-To: <4FA42631.6060304@wwwdotorg.org>
On 12:55 Fri 04 May , Stephen Warren wrote:
> On 05/04/2012 10:34 AM, Tony Lindgren wrote:
> > * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120504 08:58]:
> >> On 08:03 Fri 04 May , Tony Lindgren wrote:
> >>>>
> >>>> 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
> >
> > Yes OK, but pin number 12 in the gpio bank, not in the mux register.
> > Got it.
>
> I'd prefer to avoid any references to GPIOs here; not all muxable pins
> are GPIOs and not all GPIOs are muxable pins. Lets keep the two concepts
> independent.
my idea was to have a phandle pinctrl specific to represent the bank
and use it in the same way as done on gpio
>
> >> 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 >;
> >> };
> >
> > I could change to use this too no problem. The only concern I have is
> > that is "&pioB 12" immutable for all gpio controllers?
>
> You mean is the number of cells used to specify a GPIO the same
> everywhere? No. It's defined by #gpio-cells in the GPIO controller node.
>
> But again, the GPIO binding shouldn't be related to the pinctrl binding
> directly.
>
> > Grepping the *.dts* files, at least exynos is using the following
> > for gpios:
> >
> > gpios = <&gpx2 0 0 0 2>;
> >
> > If we can conclude that phandle to the gpio controller instance and
> > the register offset is always enough here, then I'm OK changing to
> > that format. It would actually save some parsing in most cases.
> >
> >> /* 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 */
> >> };
>
> I don't really see how that DT format represents pins, functions, and
> nodes directly, and separately from which of those a board chooses to
> use. I think this binding and the one Tony originally proposed are
> eseentially semantically identical.
>
> Going back to my idea of separating SoC and board configurations, if we
> did that, I'd expect to see something more like:
>
> soc.dtsi or board.dts:
>
> This is the data that the pin controller driver needs to export to
> pinctrl core. This can be completely enumerated in the soc.dtsi, or
> perhaps for uncommonly used pins/groups/functions, only included in the
> board.dts that actually uses it to cut down on soc.dtsi's size:
>
> This data is not needed for SoCs whose pinctrl drivers include it in
> their driver file instead of DT.
I agree on at91 I propose exactly this but get the following comment tat we
are going to have too much node.
so the idea I propoose with the pins array is to avoid this issue
my first bindings on at91
functions {
};
1) we describe one functin per pin
functions {
rxd_pb12 {
atmel,pin-id = <&pioB 12>;
atmel,mux = <0>;
};
txd_pb13 {
atmel,pin-id = <&piaB 13>;
atmel,pull = <2>;
atmel,mux = <0>;
};
txd0_pb19 {
atmel,pin-id = <&pioB 19>;
atmel,pull = <2>;
atmel,mux = <0>;
};
rxd0_pb18 {
atmel,pin-id = <&pioB 18>;
atmel,mux = <0>;
};
rts0_pb17 {
atmel,pin-id = <&pioB 17>;
atmel,mux = <1>;
};
cts0_pb15 {
atmel,pin-id = <&pioB 15>;
atmel,mux = <1>;
};
};
groups {
dbgu {
pinctrl,functions = <
&rxd_pb12 &txd_pb13 >;
};
uart0_rxd_txd {
pinctrl,functions = <
&rxd0_pb18 &txd0_pb19 >;
};
uart0_rts_cts {
pinctrl,functions = <
&rxd0_pb18 &txd0_pb19
&rts0_pb17 &cts0_pb15 >;
};
};
Best Regards,
J.
next prev parent reply other threads:[~2012-05-05 2:26 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-02 17:24 Tony Lindgren
2012-05-03 6:51 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-03 15:27 ` Tony Lindgren
2012-05-03 22:34 ` Stephen Warren
2012-05-04 4:43 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 15:03 ` Tony Lindgren
2012-05-04 15:32 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 16:34 ` Tony Lindgren
2012-05-04 16:38 ` Jean-Christophe PLAGNIOL-VILLARD
2012-05-04 18:55 ` Stephen Warren
2012-05-04 22:08 ` Tony Lindgren
2012-05-09 20:19 ` Stephen Warren
2012-05-09 20:49 ` Tony Lindgren
2012-05-10 17:05 ` Stephen Warren
2012-05-10 17:27 ` Tony Lindgren
2012-05-11 19:17 ` Stephen Warren
2012-05-11 19:51 ` Tony Lindgren
2012-05-11 21:04 ` Stephen Warren
2012-05-11 21:18 ` Tony Lindgren
2012-05-12 23:49 ` Linus Walleij
2012-05-14 18:38 ` Stephen Warren
2012-05-15 20:07 ` Tony Lindgren
2012-05-16 7:14 ` Linus Walleij
2012-05-16 15:53 ` Stephen Warren
2012-05-05 2:04 ` Jean-Christophe PLAGNIOL-VILLARD [this message]
2012-05-09 20:24 ` Stephen Warren
2012-05-09 9:09 ` Linus Walleij
2012-05-09 20:50 ` Tony Lindgren
2012-05-04 19:23 ` Stephen Warren
2012-05-04 21:57 ` Tony Lindgren
2012-05-09 20:16 ` Stephen Warren
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=20120505020414.GJ7788@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®