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