* Cousson, Benoit <b-cous...@ti.com> [101118 12:56]: > On 11/18/2010 8:06 PM, Tony Lindgren wrote: > >* sricharan<r.sricha...@ti.com> [101114 23:26]: > >>This series updates the core device drivers to use mux framework > >>for OMAP4 SDP and PANDA board. It's generated against the > >>linux-omap master branch. It has a dependency on the Benoit's > >>omap4 mux data series. > > > ><snip> > > > >>2. Do PAD configuration independently for each module > >>Pros: > >> a. Avoids repetition of similar data for different boards. > >> b. Gives a knowledge of how pins are configured for a module > >> to the respective owners. > >> c. Pads are not initialised unless they are really needed. > >>Cons: > >> a. Can become difficult to maintain if lot of data tend to be > >> different across boards. > > > >For the common modules, we should have generic platform init code > >using hwmod. And that init code is the logical place to do the muxing. > > > >We also need to consider that the pin muxing is board specific. > >So in cases where the are alternative signal paths, we need to pass > >the signal names from board-*.c file to the platform driver init code. > > What about the omap_board_mux array in board file? Do you want to > get rid of it, or is the plan is to use that for pads that does not > belong to any driver or pads that are purely board specific?
Well we might as well keep it around for now as that's the way some people prefer to do the muxing. But yeah, eventually that could be for only board specific unused pads. I'll post some sample patches related to the uart (re)muxing within next few days, then let's see how that will work for other devices. Here's the rough plan in case you have some ideas on it: 1. board-*.c code calls omap_serial_init_port with struct omap_device_mux array that contains the pin names 2. serial.c init code muxes the pins the right way and sets wake-up events for omap3 & 4. It also populates the runtime remux values needed for omap2 uart 3. serial.c init code saves the struct omap_device_mux pointer to the related hwmod entry 4. omap_device_idle/shutdown can then call omap_remux if the omap_device_mux entry exists ... This should solve how devices need to initialize the pads. It should also work for all devices that may require runtime remuxing, like some USB transceivers and eMMC. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
