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

[Anton Vorontsov <avorontsov@ru.mvista.com>]

On Tue, Sep 04, 2007 at 01:17:51AM +0200, Segher Boessenkool wrote:
>> I expect very few things from the bootloader: setup memory controller,
>
> Setup CPUs, clocks and voltages, system busses, system controllers,
> memory controllers, memory itself,

Yup-yup, these little things. ;-) But clocks and voltages are set
up by the firmware to initially boot the kernel. After kernel
booted, it can, and should, and do manage this stuff. Power
management (includingturning on/off clocks, voltages), cpu freq
(this leads into whole other management issues, like changing
prescalers for companion chips and/or on-board CPLDs, if they're
getting clocks from the CPU-dependant source).

That's for clocks and voltages. Ok, let's back to GPIOs.

> _and system GPIOs_ :-)

Yup, firmware should set up gpios, to make initial kernel boot.
After that, kernel can and should manage GPIOs. Few examples.

Say units (like USB or SPI) can work in very different modes. And
it's okay if user want to change device mode in the runtime. Often
that means that we must also change GPIOs' dedicated functions or
even directions. Say, SPI slave or master, USB host/device/otg,
and so on.

Yes, probably there is no single powerpc driver actually doing this
today, because of many reasons. Some features unneeded today, some
are hard to implement. And maybe there is no single PowerPC device
yet that needs this, I don't know, but it's easy to imagine. ;-)

Another example, power management - if some unit temporarily unused,
to save power GPIOs should be set up differently. Say if SPI unit
turned off (unused just now), it's wise to bring their dedicated
GPIOs to "power saving" state (be it output0/1 or input, it
depends).

"Unneeded" GPIO pin drains less than 1 mA, but if there are bunch of
such GPIOs, this could be a real issue, especially on battery
powered devices.

And yet another GPIOs use from the kernel side I can bring, and it's
real use case: software-managed chip-selects, just like I have to
use for MMC-over-SPI.

To sum up: kernel anyway must be aware of GPIOs, and I'd prefer
smart kernel wrt GPIOs, instead of dumb kernel blindly relying on
the firmware setup.


At the same time I agree: doing gpio setup in the board file isn't a
great solution, just like doing it in the device tree. But hard-code
gpio setup in the firmware is much worse and short-sighted approach.

Thanks,

-- 
Anton Vorontsov
email: cbou@mail.ru
backup email: ya-cbou@yandex.ru
irc://irc.freenode.net/bd2