Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree

[Matt Sealey]

By the way just as an example, a board with the following could be
configured on i.MX53 without touching any IOMUX settings at all
besides DDR (which would get done at boot rom time through the dcd);

* Keypad (KPP)
* 24-bit Parallel display on IPU DI0
* GPIO6&7 pins 22 through 31, GPIO4 10 through 14, and a couple others
* Parallel camera on CSI0
* NAND
* Certain configurations of Ethernet
* PATA
* SD1 and SD2
* ESAI audio
* EIM bus
* CLKIH CLKIL and CLKO clocks

With discrete power (no PMIC), bitbang I2C and SPI to control whatever
minimal peripherals you need out there, this is basically a Smarttop.
Sure, it's not as fun as using the real SPI, I2C buses and you don't
get a UART, but it's possible.

-- 
Matt Sealey <matt@xxxxxxxxxxxxxx>
Product Development Analyst, Genesi USA, Inc.


On Fri, Aug 10, 2012 at 9:26 AM, Matt Sealey <matt@xxxxxxxxxxxxxx> wrote:
> On Fri, Aug 10, 2012 at 9:04 AM, Shawn Guo <shawn.guo@xxxxxxxxxx> wrote:
>> On Fri, Aug 10, 2012 at 08:36:02AM -0500, Matt Sealey wrote:
>>> Requiring it breaks the entire concept of the device tree to describe running
>>> hardware. It is not a configuration script. pinctrl should be optional
>>> - built in
>>> always, but not necessary to turn a board on if it's already configured.
>>>
>> How would kernel know if it's already configured, correctly?
>
> Trust! When we release the new U-Boot, it will be already configured,
> every pin in the schematic, every
> pin from the old kernels (not mainline, some of that was wrong),
> exactly the way it should be. There's
> nothing new with the Efika MX.
>
> If you try and boot it on the old Efika, it just won't work reliably
> for any peripheral U-Boot didn't
> already configure, but for the current version you'd get MMC, PATA,
> serial port, SPI (NOR/PMIC)
> which is all we configure in the DT right now anyway... this is only
> going to be an issue once we
> get to displays and USB (I2C isn't set up in the old one).
>
>>> What would happen if a board were designed that only used the default ALT
>>> settings on i.MX53 or so? You'd have to redefine every default IOMUX pad
>>> just to get it to boot. That's intolerable.
>>
>> Come on, even the pad configuration are all the default?  Even if that's
>> the case, yes, we still need to do it.  How do we know if firmware has
>> changed the settings or not.
>
> TRUST...
>
> Maybe you can't rely on the development boards from Freescale, but we have to
> do unit testing at every stage of operation for consumer devices. Once U-Boot
> passes all tests, why bother re-testing the exact same configuration, now done
> twice, in the kernel? I don't want to debug pad settings twice, and we shouldn't
> need to.
>
> If you really think it's necessary then fine, we'll do it.
>
> --
> Matt Sealey <matt@xxxxxxxxxxxxxx>
> Product Development Analyst, Genesi USA, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/