* Dong Aisheng <dongas86@gmail.com> [120207 17:22]:> On 2/4/12, Tony Lindgren <tony@atomide.com> wrote:>> The most difference may be the function enable due to hw difference.> But i see that for DT case, it seems function and group creation may> also be a problem.

Yes I think so, the pins should be static and added at once duringthe init. If you have other sets of pins, then they should probablybe separate driver instances. So we should be able to get rid of it.

How about try adding optional pinctrl-simple,pin-name entry that youcan add to each mux entry?

The generic plan is to make the names optional in pinctrl framework,and then expose the register addresses for future user space debugtools. So you may end up noticing that the pinctrl-simple.c driverprobably does not even need to care about the names.

> > +static int __init smux_allocate_pin_table(struct smux_device *smux)> > +{> > + int mux_bytes, i;> > +> > + mux_bytes = smux->width / BITS_PER_BYTE;> > + smux->pins.max = smux->size / mux_bytes;> > +> The main issue for IMX to use this driver is that IMX pins number can> not be calculated in this way> since the imx pin controller reg range contains mux reg range and> config reg range as well as a few other misc registers> And it seems it's also not fit for Tegra since Tegra2's one register> may involve many pins.> This may need some proper way to fix.

Well maybe take a look adding support for wider #pinmux-cells?

So far I was thinking we could have:

/* one mux register for each pin */#pinmux-cells = <2>;/* three mux registers for each pin */#pinmux-cells = <6>;...Note that for more complex mapping you may want to add a hardwarespecific .data entry that corresponds to the compatible flag, let'ssay for conf range offset to mux range offset.

Yes to summarize what we've discussed for people who have notbeen at the conference this week: The idea is the have a genericfunctions for the common bindings. Then have separate driverspecific bindings.

> > + val = of_get_property(pdev->dev.of_node,> > + "pinctrl-simple,register-width", &len);> Is there any reason not use of_property_read_u32 here? It may reduce some code.