Re: [PATCH v7 3/3] [POWERPC] MPC832x_RDB: update dts to use SPI1in QE, register mmc_spi stub

[Timur Tabi <timur@freescale.com>]

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).

Some history:

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.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale