* Benoit Cousson <b-cousson@xxxxxx> [101019 15:14]: > Hi Tony, > > Upon Nishanth request, here is the updated version... > > It takes into account your proposal to store partition > information in a partition structure instead of inside every pad entries. > The mechanism relies on the uniqueness of the pad name in each partition to > find the correct partition during iteration. OK, using the offset defines won't be unique necessarily.. > Removed as well some cpu_is_xxx calls from the core code by adding a couple of > flags during partition init. That's great. > Please note that due to low level access to mux api from the RX51 board code, > I have to disable the mux change to build properly with omap2plus_defconfig. > Look like you do have some idea to fix that :-) > I was thinking of: > - brute force approach that consist of keeping all the data after init, and > thus allowing removing the __init in the omap_mux_init_signal API > - or adding some flag in the pad entry to keep them after init . Well I was thinking we just register a board specific dynamic mux table and then call that when hitting retention or off and restore after that. Still need to think about that a bit more, I don't know if we want the automatic muxing of gpio pins still in addition to that. > Boot tested on SDP4430 with ES1.0 & ES2.0 with omap2plus_defconfig. Still require > some real driver to use that mux API in order to validate it. You can test by echoing wrong values after booting via /sys to mess up the MMC data lines and then type sync :) > The series is on top of lo/master (2.6.36-rc8) and is available here: > git://gitorious.org/omap-pm/linux.git ctrl-wip/mux-omap4-v2 For pulling anything in, the git branches need to be based on something that's immutable. So preferrably v2.6.35 or some recent -rc tag in this case. Or rebase it on v2.6.36 after that's been released. 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
