linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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 06:43:05 +0200	[thread overview]
Message-ID: <20120504044305.GD7788@game.jcrosoft.org> (raw)
In-Reply-To: <4FA30805.5050804@wwwdotorg.org>

On 16:34 Thu 03 May     , Stephen Warren wrote:
> On 05/03/2012 09:27 AM, Tony Lindgren wrote:
> > Hi,
> > 
> > * Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com> [120503 00:16]:
> >>
> >> 	I really like it
> >>
> >> 	I was working on something simillar
> >>
> >> 	but can we split the group management so we can use it on other
> >> 	bindings
> > 
> > Hmm I'm not sure I follow on the group management splitting, can you specify
> > what you have in mind here?
> > 
> > If you mean moving more things into pinctrl fwk, then yeah I'd assume that
> > will happen eventually and drivers like this will end up becoming more minimal.
> 
> Jean-Christophe, forgive me if I'm putting words in your mouth, but I
> assume the following is what you mean:
> 
> There are two pieces of data required by the pinctrl subsystem:
> 
> a) The set of pins, functions, and groups that exist.
> 
> b) The specific function to select for each pin/group on a given board.
> 
> Item (a) can be represented in the pinctrl driver (e.g. as in the Tegra
> driver), or can be represented in device tree in order to avoid large
> tables in the driver.
> 
> Item (b) has to be represented in device tree, since the whole point is
> that it's board-specific.
> 
> For all DT bindings I've seen that choose to represent (a) in the DT
> rather than in the driver, the DT represents (b) directly, and (a) is
> implicitly extracted/created based on (a).
> 
> When I was first thinking about DT bindings for pinctrl, I had hoped
> that even if (a) was represented in DT, the DT nodes/properties for (a)
> and (b) would be entirely separate, so that the binding for (b) could be
> completely common across all SoCs, even though the binding for (a) would
> perhaps be different across SoCs (if it existed at all).
> 
> So, perhaps Jean-Christophe is talking about splitting up (a) and (b) in
> device tree?
> 
> Or perhaps Jean-Christophe only refers to the code that creates the
> group and function definitions from (b), and not the actual DT binding
> itself?
yes you are right Stephen
I was thinking of both but the second could be a first step

today we tend all to represent the group of pin in DT

for TI, IM, MXC, at91, ST and others

the way to represend the groups are exactly the same

a group is a node with a set on pin

uart {
 pincfg......
}

and the group is uart

so we do need to have a common way to handle it in c

the code propose by Tony is really what I'm working on to acheive this

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

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} >

}

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

Best Regards,
J.

  reply	other threads:[~2012-05-04  4:43 UTC|newest]

Thread overview: 32+ 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-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 [this message]
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
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=20120504044305.GD7788@game.jcrosoft.org \
    --to=plagnioj@jcrosoft.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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;
as well as URLs for NNTP newsgroup(s).