public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Nishanth Menon <menon.nishanth@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX
Date: Tue, 09 Nov 2010 05:38:17 -0600	[thread overview]
Message-ID: <4CD932A9.30901@gmail.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59302348EE480@dbde02.ent.ti.com>

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

      reply	other threads:[~2010-11-09 11:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-05 19:56 [U-Boot] ARM: OMAP3/4: proposal: Cleanup MUX Nishanth Menon
2010-11-06  2:47 ` Steve Sakoman
2010-11-06  4:00   ` Nishanth Menon
2010-11-06  4:59     ` Peter Barada
2010-11-09  0:38       ` Nishanth Menon
2010-11-09  8:48         ` Premi, Sanjeev
2010-11-09 11:38           ` Nishanth Menon [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CD932A9.30901@gmail.com \
    --to=menon.nishanth@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox