[lkml]   [2012]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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 <> wrote:
    > > Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM:
    > >> On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren <> 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:
    > >> >> 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.


     \ /
      Last update: 2012-01-17 20:47    [W:0.032 / U:76.224 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site