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