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

Nishanth Menon
2010-11-09T11:38:17Z

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..