Re: [RFC v2 0/7] OMAP4: mux: Add the OMAP4430 ES1 & ES2 support

["Cousson, Benoit" <b-cousson@ti.com>]

Hi Tony,

On 10/20/2010 1:06 AM, Tony Lindgren wrote:
> * Benoit Cousson<b-cousson@ti.com>  [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..

They should. The defines are all based on pad names that are all unique. 
Assuming HW folks didn't messed up the spec...

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

OK, you were thinking of the MMC remux case only.
That might be enough for the moment, because the other needs I heard 
about does not seems to be in mainline anyway (USB or modem link).

>> 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 :)

I played with debugfs a little bit but was trying to avoid messing up 
with pins already used... in fact I should do the opposite. That's a 
nice technique...

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

In that case only the ES1 can be there. ES2 support will be in 2.6.37 only.

That's why I have a dependency with lo/master. Do you want to split the 
series in two parts?

Thanks,
Benoit