[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKGA1bkBtK4iWv-0sWHXBuNYeTOpPMZE=P-JCHBNe3_uwTYftQ@mail.gmail.com>
Date: Fri, 10 Aug 2012 09:42:57 -0500
From: Matt Sealey <matt@...esi-usa.com>
To: Shawn Guo <shawn.guo@...aro.org>
Cc: Fabio Estevam <festevam@...il.com>,
Steev Klimaszewski <steev@...esi-usa.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux ARM Kernel Mailing List
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] efikamx: reintroduce Genesi Efika MX Smarttop via device tree
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@...esi-usa.com>
Product Development Analyst, Genesi USA, Inc.
On Fri, Aug 10, 2012 at 9:26 AM, Matt Sealey <matt@...esi-usa.com> wrote:
> On Fri, Aug 10, 2012 at 9:04 AM, Shawn Guo <shawn.guo@...aro.org> 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@...esi-usa.com>
> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists