Re: [PATCH 0/5] OMAP4: mux: Initialise OMAP4 mux pins.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 11/18/2010 8:06 PM, Tony Lindgren wrote:
* sricharan<r.sricharan@xxxxxx>  [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?

Regards,
Benoit
--
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


[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux