[U-Boot] [PATCH 2/2] mx5: Use default pin initializers

[Stefano Babic]

On 16/08/2012 23:25, Matt Sealey wrote:
> On Thu, Aug 16, 2012 at 3:09 PM, Benoît Thébaudeau
> <benoit.thebaudeau at advansee.com> wrote:
>> Dear Matt Sealey,
>>

Hi Matt,

>>> I'm gonna NACK this because most of these pin settings are actually
>>> the POR defaults anyway (UART1 is
>>> the example I can easily pick out).
>>>
>>> .. unless someone's setting them up wrong between warn reboots, or
>>> changing a UART into something else
>>> later in boot.. which is unfathomable.. we don't need to even touch
>>> the iomux controller to get a working UART
>>> on MX51, Efika MX or anything.
>>>
>>> Why bother touching them?
>>
>> I agree, but the purpose of this patch is not to add this code, only to move it
>> to a common place... Why didn't you NAK the addition of these boards because of
>> that?
> 

I am coming a little later in the discussion, sorry.

> Why bother changing it in the first place if it's already doing the
> same thing? :)
> 
> I have a MAJOR nit that is going to ruin your day; this is from
> mx51_uart1_init_pins, just one line:
> 
>  mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
> 
> Why are you using the old mxc_request_iomux model, when MX6 and
> Sabrelite for example uses the newer iomux_v3_configure_pad model?

This is a point I see as an improvement for the current pinmux in i.MX.
At least MX53 and MX6 share the same code, but MX51 was not upgraded to
work as the other ones.

My personal point for the pinmux is that it is *very* difficult to set
the same pin configuration for a function, such as spi1 or uart1 as done
in this patchset. The hardware developer can have used a different
pinout as "normal", because they need to do this.

So the pinmux must always be customized for each board.

> 
> Surely someone should be thinking of putting that into place for MX51
> and MX53 first so these pin init things can be done on the newer one.
> I already ported 2012.07 for Efika MX and have an include (Troy
> Kisky's got a copy of it too, we sent it there hoping for a little
> review but he doesn't have our board to test IIRC) and a working tree.
> 
> What's stopping us submitting this already? Churn. Also, we thought we
> could get away with U-Boot doing the grunt work of configuring pins
> where needed, and the Linux DT guys vetoed it in favor of needlessly
> reconfiguring the pins U-Boot already set up by redefining them for
> reconfiguration in the DT anyway -

The kernel rule is to set itself the pinmux and not rely on the setup of
the bootloader. This makes completely sense. U-Boot should set only the
pins it really needs.

> For i.MX we have two iomux models and function sets available for
> doing identical stuff. Isn't that kind of wasteful?

It is bad - my point is that we can concentrate efforts to have only one
implementation reducing current confusion ;-)

> 
> No, there was never a good reason for it. It's there because whoever
> wrote the very, very original code in the first place (Pegatron)
> didn't read the docs properly and just set everything up regardless of
> whether it was already set up, then whoever put the Efika MX support
> in mainline didn't read the docs either and just reformatted what was
> there in our source release and/or read the schematics without fact
> checking.
> 
> It's a hideous legacy being perpetuated here. I am fully in favor of
> you leaving Efika MX out to languish in the deep dark recesses of
> boards that might compile but are basically doing weird stuff, and
> nobody uses anyway, until we work out the situation to actually
> support the board 100% in the most efficient way possible.
> 
> I'll throw a patchset out to add the iomux-mx51.h file (with all the
> pins Efika MX needs at least.

I see now your patchset - I put it in my queue for review, rather it is
a long queue..

> 
> As for problems during reboots, well, unsupported configurations are
> unsupported configurations. If your kernel muxes out DIFFERENT pins to
> U-Boot, expect U-Boot to burn the board.

All SOCs have a default value for the IOMUX after a reset. Freescale
guarantees (apart the errata..) that the pins have always the same value
after a reset.

It is then duty of the hardware developer to make certain that the board
does not burn after a reset - even if u-boot could fix something, it is
not assured how much time it can take after a reset.

> As it stands, the old
> "linux-legacy" kernels don't make too heavy a set of changes (maybe
> just drive strength and hysteresis stuff that is totally pointless).
> If you boot U-Boot from POR and then boot a DT linux kernel, it'll all
> be exactly the same on every reboot. Boot an old kernel and it'll
> still work.

And if it does not work, the fix should be in kernel, not in u-boot.

> You can't be too careful here, and by that I mean, you
> can't keep reconfiguring the chip just because you think there may be
> the possibility of some idiot doing something wrong.

We all know that this is impossible because idiots are very creative ;-)

Best regards,
Stefano Babic

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================