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

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

[Nishanth Menon]

Folks,
I would like to work on the following: Cleanup mux configurations done 
in OMAP3 and 4 platforms. includes the following:
a) have isolate mux configurations per IP configuration, e.g. for EHCI, 
we have a mux array definition for EHCI etc..
b) remove ALL mux configurations that are not relevant for u-boot 
functionality - currently we do all muxing in u-boot(including stuff 
like camera which obviously we dont use in u-boot).

any kernel breakages as a result of "assumptions" of muxing already done 
is to be fixed in kernel itself - kernel *has* a mux framework for OMAP 
and platforms files *should* be using that for kernel functionality that 
they need. no point in carrying that burden in u-boot.

I would like to post this patches so that for the next merge window we 
could pull this in and notify the linux-omap kernel guys to fix their 
stuff if they depend on u-boot for mux configurations - it is high time 
they stop being closely tied to U-boot and have capability to deal with 
other bootloaders which may or maynot have capability for doing muxing - 
it also saves us to add and maintain mux configurations for linux kernel 
booting -> u-boot is supposed to support multiple operating systems (not 
just linux kernel).

-- 
Regards,
Nishanth Menon

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

[Steve Sakoman]

On Fri, Nov 5, 2010 at 12:56 PM, Nishanth Menon
<menon.nishanth@gmail.com> wrote:
> Folks,
> I would like to work on the following: Cleanup mux configurations done
> in OMAP3 and 4 platforms. includes the following:
> a) have isolate mux configurations per IP configuration, e.g. for EHCI,
> we have a mux array definition for EHCI etc..
> b) remove ALL mux configurations that are not relevant for u-boot
> functionality - currently we do all muxing in u-boot(including stuff
> like camera which obviously we dont use in u-boot).
>
> any kernel breakages as a result of "assumptions" of muxing already done
> is to be fixed in kernel itself - kernel *has* a mux framework for OMAP
> and platforms files *should* be using that for kernel functionality that
> they need. no point in carrying that burden in u-boot.
>
> I would like to post this patches so that for the next merge window we
> could pull this in and notify the linux-omap kernel guys to fix their
> stuff if they depend on u-boot for mux configurations - it is high time
> they stop being closely tied to U-boot and have capability to deal with
> other bootloaders which may or maynot have capability for doing muxing -
> it also saves us to add and maintain mux configurations for linux kernel
> booting -> u-boot is supposed to support multiple operating systems (not
> just linux kernel).

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.

Steve

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

[Nishanth Menon]

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

-- 
Regards,
Nishanth Menon

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

[Peter Barada]

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

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

[Nishanth Menon]

Peter Barada wrote, on 11/05/2010 11:59 PM:
> Personally I'd like to see the kernel and u-boot disconnect on the

Looks like we are getting to a consensus - we all seem to dislike the 
dependency of u-boot and kernel for mux as of today - can we think about 
post 2011March as a good time to start pushing the relevant changes in? 
if that is the case, I will start posting RFCs in the coming weeks so 
that we can get the relevant changes ready on time. Ofcourse, if there 
are others wishing to collaborate, folks are more than welcome :)

-- 
Regards,
Nishanth Menon

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

[Premi, Sanjeev]

 

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Nishanth Menon
> Sent: Tuesday, November 09, 2010 6:09 AM
> To: Peter Barada
> Cc: u-boot at lists.denx.de
> Subject: Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
> 
> Peter Barada wrote, on 11/05/2010 11:59 PM:
> > Personally I'd like to see the kernel and u-boot disconnect on the
> 
> Looks like we are getting to a consensus - we all seem to dislike the 
> dependency of u-boot and kernel for mux as of today - can we 
> think about 

[sp] In my opinion, we need to do minimal and necessary MUX settings
     in u-boot and let kernel manage itself.

     This also helps ensure that problems noticed in kernel are easy
     to replicate on other similar platforms. Last year I spent long
     time in convincing that wake-up on keypad was not working in Linux
     kernel; but folks using OMAP3430SDP maintained it worked fine.
     Root cause - relevant PADCONF was set in u-boot for 3430SDP.
     (not quoting mail-chain)

     We may not be able to eliminate such instances altogether - but
     can have less of such instances.

> post 2011March as a good time to start pushing the relevant 
> changes in? 
> if that is the case, I will start posting RFCs in the coming weeks so 

[sp] Can you list what chanages you are trying to propose? ...without
     going as far as RFC.

     the mails quoted in previous message are again too long and wide
     in discussion. A concise list will help.

~sanjeev

> that we can get the relevant changes ready on time. Ofcourse, 
> if there 
> are others wishing to collaborate, folks are more than welcome :)
> 
> -- 
> Regards,
> Nishanth Menon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

[Nishanth Menon]

Premi, Sanjeev wrote, on 11/09/2010 02:48 AM:
>>
>> Peter Barada wrote, on 11/05/2010 11:59 PM:
>>> Personally I'd like to see the kernel and u-boot disconnect on the
>>
>> Looks like we are getting to a consensus - we all seem to dislike the
>> dependency of u-boot and kernel for mux as of today - can we
>> think about
>
> [sp] In my opinion, we need to do minimal and necessary MUX settings
>       in u-boot and let kernel manage itself.
>
>       This also helps ensure that problems noticed in kernel are easy
>       to replicate on other similar platforms. Last year I spent long
>       time in convincing that wake-up on keypad was not working in Linux
>       kernel; but folks using OMAP3430SDP maintained it worked fine.
>       Root cause - relevant PADCONF was set in u-boot for 3430SDP.
>       (not quoting mail-chain)
>
>       We may not be able to eliminate such instances altogether - but
>       can have less of such instances.
I definitely agree.

>
>> post 2011March as a good time to start pushing the relevant
>> changes in?
>> if that is the case, I will start posting RFCs in the coming weeks so
>
> [sp] Can you list what chanages you are trying to propose? ...without
>       going as far as RFC.
>
>       the mails quoted in previous message are again too long and wide
>       in discussion. A concise list will help.
Have'nt got to the code yet - had no intent of spending those cycles if 
the community had no interest in it and without a potential date OR had 
some issue which I could not think about. but anyways, here is the 
overall idea:
per Soc, have muxes per IP - I did not think it was worthwhile to do a 
complex mux (dynamic) as done in linux kernel.

DDR_CS0_MUX
DDR_CS1_MUX
GPMC_MUX -> need to think an elegant method to specify CSs to enable
I2C{1,2,3,4,5 - based on SoC}_MUX
MMC{0,1,2,3,4- based on SoC}_MUX
UART{0,1,2,3,4 - based on SoC}_MUX

If bootlogo enabled
DSS_PARALLEL_MUX
DSS_DSI_MUX

if USB OTG enabled
USB_OTG_MUX

if USB Host enabled
USB_EHCI_MUX

GPIO Muxes -> need some elegant way to specify which GPIOs map to which 
muxed pins..

if SPI enabled,
SPI_MUX

None of the muxing will be wakeup enabled -> wakeup is a kernel feature 
and should be done there. only mux mode and pull types should be set in 
u-boot.

The board file will still call the mux -> it will however only call the 
ones it needs to boot and load image.

One more additional thought I had was to introduce Mux Scheme per IP ->
e.g. DSS lines come out in different pin sequences -> we call each 
SCHEMEs so that new boards can find it a little easier to enable MUX..

-- 
Regards,
Nishanth Menon