[U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX

[Peter Barada <peterb@logicpd.com>]

On 11/06/2010 12:00 AM, Nishanth Menon wrote:
> Steve Sakoman wrote, on 11/05/2010 10:47 PM:
>    
>> While I understand that you are frustrated with the slow movement in
>> getting the kernel mux cleaned up, I really can't support deliberately
>> breaking systems to force the issue.
>>
>> I don't think it does end users any service to have a u-boot "upgrade"
>> break their systems.  In the end, they are the ones who will be hurt
>> and u-boot will get the blame for causing the breakage.
>>
>> I'd rather see us put the energy into helping get the kernel in shape.
>>      
> In 2009 July[1], I raised the concern for OMAP3. at that point the fact
> was we did not have a clean mux framework in kernel. ok great, 2010 Nov
> now, there is *already* a framework for doing it in kernel upstream
> today. What rationale is there for OMAP3 beagleboard [1] still do muxing
> as it does today - we as a community are lazy to clean up our code? What
> happend as a result? There are linux-products out there which dont use
> u-boot as bootloader and development non-linux OS's out there which use
> u-boot as a bootloader - in the case of the linux-products, surprises
> were found for the upstream kernel depending on u-boot for their muxes
> and development-OSes found the same mistake when they switched to their
> native bootloaders at a later point.
>
> Why should OMAP4 mux framework not move forward despite two rounds of
> RFC patches posted[3]? I am not asking this to be done tomorrow, I am
> asking our community for a deadline - If v2010.12 is too close, fine,
> then lets schedule it for after v2011.03 tag for example ->  is'nt 4
> months not good enough to get an already existing mux framework upstream
> in kernel.org for OMAP4? or should OMAP4 products go through the same
> experience of OMAP3?
>
> Conceptually it is simple - a software does just what it is supposed to
> do - u-boot for OMAP today does way more than it's charter and I
> personally find it obnoxious! All I am saying is this: we all agree this
> is messed up, I have an itch, I am willing to do the cleanup as well,
> just tell me when it is right to do it, I just don't want to deal with
> crappy code anymore!
>
> Ref:
> [1] http://www.mail-archive.com/u-boot at lists.denx.de/msg17423.html
> [2]
> http://git.denx.de/?p=u-boot.git;a=blob;f=board/ti/beagle/beagle.h;h=ec0da6d745477437c1c776db7929690e1e568437;hb=HEAD
> [3] http://marc.info/?l=linux-omap&m=128752700004693&w=2
>    
Personally I'd like to see the kernel and u-boot disconnect on the 
pinmux; In my world I have a module with an OMAP35x on it and customers 
design their own baseboards and use pins as they see fit.  We start with 
a common u-boot and kernel that operates on two SDK boards, and 
customers design their own baseboards assigning pins to various 
functions.  One customer may want the camera pins as a camera while 
another uses them for GPIO; u-boot shouldn't care about how the kernel 
uses the pins, it should just pinmux what it needs(following an 
approximation):

1) DDR (if not already running in DDR)
2) GPMC for NAND
3) Serial console
4) USB Host (if u-boot is so configured)

Then the kernel should configure pins it uses on a registered 
platform_device basis; i.e. setup the pinmux for that particular 
platform_device can probe its hardware.  Then the kernel can save even 
more power by leaving unused pins in Mode 7 (i.e. Hi-z) that are not 
used which saves even more power in suspend.

Previously in the OMAP kernel space u-boot was responsible for setting 
up the pinmux, but with the latest changes, more of the pinmux setup is 
moving to the kernel and it is time for a complete disconnect, i.e. the 
kernel must assume that anything it wants to configure needs to have its 
pinmux setup; yes there will be a period of pain, but its a lot easier 
to break the assumption than keep providing one....

-- 
Peter Barada
peterb at logicpd.com