On Tue, Jan 31, 2012 at 22:35:11, Tony Lindgren wrote: > Hi, > > * Mohammed, Afzal <afzal@xxxxxx> [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 > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
