Reg pinmux driver for OMAP based SoC- AM335X

[tony@atomide.com (Tony Lindgren)]

Hi,

* Mohammed, Afzal <afzal@ti.com> [120131 06:04]:
> Hi Tony,
> 
> I am working on implementing pincontrol driver for AM335X SoC (OMAP34XX family).
> 
> Is there any specific plan you have in mind w.r.t incorporating
> pincontrol driver for OMAP family of SoC's. There was an initial patch
> for OMAP4 pin control driver, but it seems you were in favour of a
> DT based approach. As per my understanding after going through few threads
> (lot more remaining) is that pincontrol driver can be either a DT based
> or non-DT based (either way we are going out of platform folders), and
> it seems you prefer a DT based approach (have seen mentioning about
> pinmux-simple.c).

With at least omaps, there are few good reasons to go for a common
DT only driver:

1. We already have about 6k lines of mux data and seem to be
   adding several thousands of lines of mux data each year.

2. The driver does not need this data, it just needs to know how
   to operate certain kind of mux registers. The data is mostly
   handy for developers for debugging, and that can be done via
   debugfs and userspace tools.
 
> Tegra pincontrol driver posted recently, seems to use DT to distinguish only
> the SoC type, with all the pincontrol information for SoC present in Kernel.
> 
> I would be thankful if you can give me some pointers on how to proceed for
> AM335X pincontrol driver and/or any work in progress for OMAP pincontrol driver.

The plan is to deprecate the existing arch/arm/*omap*/*mux* code,
and cut it down to minimum. And then add DT only mux support that should
work for at least omap2+. That should work for am335x too.

There's currently some discussion going on regarding the pinmux device
tree binding and how dynamic mux states should be handled. But I'd
assume we'll have basic support available very soon.

The driver I'm working leaves all the data out of kernel, and the driver
just knows how to handle a pinmux register instances. Then debugging
tools can be done in userspace via debugfs to display more detailed
SoC specific information.

So it might be worth waiting just a little bit longer. If you have
resources to spend on the pinmuxing, then creating some userspace tool
to display SoC specific information would be nice :) For the userspace
tool, we can use the data in arch/arm/mach-omap2/mux*2*.[ch].

Regards,

Tony