Re: [RFC PATCH v3 2/5] pinctrl: add dt binding support for pinmux mappings

[Dong Aisheng]

On Sat, Jan 14, 2012 at 2:33 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM:
>> On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren <swarren@xxxxxxxxxx> 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)
>> >
>> > Hmmm. I'm not sure that the pinctrl code should actively scan all nodes
>> > in the device tree for pin mux properties. That seems a little invasive;
>> > how does pinctrl know which nodes it really should be looking at, and
>> > which nodes are random internal parts of some device's custom binding?
>> >
>> > Personally, I think I'd be OK with the sysfs pinctrl map file only
>> > containing the map entries for devices that had used the pinctrl API,
>> > and hence only parsing the pinmux properties in pinmux_get().
>> >
>> > However, we could perhaps do better by registering a bus notifier, and
>> > pro-actively parsing the top-level DT node (if there is one) for every
>> > device that is created. That way, the mapping would be parsed as soon
>> > as the device was created (or perhaps after probe?).
>>
>> After refer to usb bus notifier, usb core will register a bus notifier.
>> When a new usb bus is registered, it will notify the usb core for a
>> new bus added.
>>
>> So i guess you mean pinctrl core provides a notifier to handle the map
>> creation when new map is found during parsing each device node, right?
>
> Yes.
>
>> But it seems parsing of device node and creation of device is at the very early
>> stage when call of_platform_populate in .init_machine code and pinctrl subsystem
>> may still have not change to run to register a bus notifier.
>
> That's possible. There are some early initcalls that might work out
> fine for this,
Ok, looks .init_machine is the level of ARCH_INIT, will try a earlier one.
and we may add that init function in pinctrl core if it's reasonable.

> but...
but what?

>
>> 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 wonder it may not work for pinmux map case.
>> If pinctrl core does not provide notifier, who else can be the right
>> one to privide it?
>>
>> > The only case this
>> > might not cover is DT nodes for which the kernel doesn't actually have
>> > a driver, and hence no device is created.
>>
>> Per my understanding, the device creation should be independent on the driver.
>> I don't know why no device is created if not have a driver.
>> Did i miss something?
>
> Yes, I think the device gets created irrespective, so this isn't actually a problem
>
> --
> nvpublic
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/