lkml.org 
[lkml]   [2012]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings
Dong Aisheng wrote at Saturday, January 14, 2012 10:58 AM:
> On Sat, Jan 14, 2012 at 2:33 AM, Stephen Warren <swarren@nvidia.com> wrote:
> > Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM:
> >> On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren <swarren@nvidia.com> wrote:
> >> ...
> >> >> To keep consistency as the currently design of pinctrl subsystem and also meet
> >> >> the dt design philosophy, we still do not introduce a pinmux map in dt.
> >> >> Instead, we choose to scan all the device node with a 'pinmux' phandle to construct
> >> >> a pinmux map table before register the pin controller device(here we may also scan
> >> >> the hog_on_boot node) and I guess it's easy to do that.
> >> > ...
> >> >> (Without scan the device node to construct the pinmux map table, we can only get the map
> >> >> Information when we run the pinmux_get.
> >> >> See: https://lkml.org/lkml/2012/1/5/153
> >> >> So no pinmux map table exists and we surely do not want to see that the sysfs exporting
> >> >> pinmux map information works in dt but unwork in non-dt)
...
> >> And i'm not sure it's the right place for of_platform.c to handle
> >> pinmux things when create new devices.
> >
> > So of_device_alloc(), which is called by of_platform_populate() for each
> > device, already parses basic DT content such as reg and interrupts, and
> > converts them to Linux resources. I'd consider parsing any pinmux properties
> > and registering them with the pinctrl subsystem to be of a similar nature,
> > so adding some code to of_device_alloc() that calls a core pinmux function
> > to parse the DT node seems reasonable to me.
> >
> It's not perfect to me since pinmux map looks not the pure hw
> conception like reg/int.
> but i wonder if we can find a better way, (scanning?)

I suppose up-front scanning might work. To be fully safe, I think you'd
need to:

Enumerate all nodes with a compatible property (for anything without,
it won't be a device node, so who knows what it is).

In those nodes, look for pinctrl and pinctrl-names properties. If they're
present, process them.

For each phandle, make sure the referenced "pin configuration node" has
a specific pinctrl compatible flag (just to make sure it really is pin
control data, not some random other thing that happens to be pointed at
by a property named pinctrl from some random binding developed by some
3rd-party without review.)

I propose for this:

compatible = "pinctrl-configuration";

Now, you know the device node and the pin configuration, so you can create
the pinctrl mapping table entries.

--
nvpublic



\
 
 \ /
  Last update: 2012-01-17 20:47    [from the cache]
©2003-2011 Jasper Spaans