On Sat, Jan 14, 2012 at 2:33 AM, Stephen Warren <[email protected]> wrote: > Dong Aisheng wrote at Friday, January 13, 2012 10:12 AM: >> On Thu, Jan 12, 2012 at 4:17 AM, Stephen Warren <[email protected]> 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 > _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
