[PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub
timur at freescale.com
Fri Sep 7 00:35:29 EST 2007
Segher Boessenkool wrote:
>>> _and system GPIOs_ :-)
>> Yup, firmware should set up gpios, to make initial kernel boot.
>> After that, kernel can and should manage GPIOs.
> Sure. But only the GPIOs it _does_ need to toggle, not the ones
> that have to be fixed to a certain value (like everything that is
> described in the par_io nodes now).
The par_io nodes are statically defined because the we don't support the
concept of moving devices from one UCC to another. When the boards are
designed, typically the external PHYs (UART, Ethernet, whatever) are
hard-wired to a particular UCC, and so its par_io configuration is static.
This works only because there are usually more than enough UCCs for every
device. The 8360, for instance, has 8 UCCs, but the MPC8360EMDS only uses two
of them, for Ethernet.
So having the par_io nodes in the device tree is very convenient, because it
A) Is simple and compact
B) Doesn't require full-blown GPIO support
C) The device drivers can ignore par_io programming - they can just assume
that the pins are configured correctly.
D) It makes it easy for U-Boot and/or Linux to configure the pins.
There are some drawbacks. For instance on UART, in loopback mode, the par_io
pins should be reconfigured. Since loopback mode is a configurable option for
serial drivers, that means that a UCC UART driver (which I'm working on) needs
to be aware of the par_io pins. It would be nice if there were a way I could
tag a par_io node as being for loopback.
Linux Kernel Developer @ Freescale
More information about the Linuxppc-dev