mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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.

  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®