matt at genesi-usa
Aug 10, 2012, 7:42 AM
Post #14 of 17
By the way just as an example, a board with the following could be
Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree
[In reply to]
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
* Certain configurations of Ethernet
* 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 [at] genesi-usa>
Product Development Analyst, Genesi USA, Inc.
On Fri, Aug 10, 2012 at 9:26 AM, Matt Sealey <matt [at] genesi-usa> wrote:
> On Fri, Aug 10, 2012 at 9:04 AM, Shawn Guo <shawn.guo [at] linaro> 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.
> 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 [at] genesi-usa>
> 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 [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/