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@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 pet...@logicpd.com _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot