Reg pinmux driver for OMAP based SoC- AM335X

[Hiremath, Vaibhav]

On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote:
> Hi,
> 
> * Mohammed, Afzal <afzal at 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. 

Tony,

Is this hosted or accessible somewhere? Just for reference...

Thanks,
Vaibhav

> 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
>