Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
> -Original Message- > From: u-boot-boun...@lists.denx.de > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Nishanth Menon > Sent: Tuesday, November 09, 2010 6:09 AM > To: Peter Barada > Cc: u-boot@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@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
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=12875274693&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
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
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=12875274693&w=2 -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
On Fri, Nov 5, 2010 at 12:56 PM, Nishanth Menon 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
