[U-Boot] [PATCH 2/2] arm: mx6: cm_fx6: use gpio request

[Simon Glass]

Hi Nikita,

On 2 October 2014 08:17, Nikita Kiryanov <nikita at compulab.co.il> wrote:
> Use gpio_request for all the gpios that are utilized by various
> subsystems in cm-fx6, and refactor the relevant init functions
> so that all gpios are requested during board_init(), not during
> subsystem init, thus avoiding the need to manage gpio ownership
> each time a subsystem is initialized.
>
> The new division of labor is:
> During board_init() muxes are setup and gpios are requested.
> During subsystem init gpios are toggled.
>
> Cc: Igor Grinberg <grinberg at compulab.co.il>
> Cc: Simon Glass <sjg at chromium.org>
> Signed-off-by: Nikita Kiryanov <nikita at compulab.co.il>

Copying my comments from the other patch:

I've thought about that quite a lot as part of the driver model work.
Claiming GPIOs in board code doesn't feel right to me:

1. If using device tree, the GPIOs are in there, and it means the
board code needs to go looking there as well as the driver. The board
code actually needs to sniff around in the driver's device tree nodes.
That just seems honky.

2. In the driver model world, we hope that board init will fade away
to a large extent. Certainly it should be possible to specify most of
what a driver needs in device tree or platform data. Getting rid of
the explicit init calls in U-Boot (board_init_f(), board_init(),
board_late_init(), board_early_init_f(), ...) is a nice effect of
driver model I hope.

3. Even if not using device tree, and using platform data, where the
board code may specify the platform data, it still feels honky for the
board to be parsing its own data (designed for use by the driver) to
claim GPIOs.

4. I don't really see why pre-claiming enforces anything. If two
subsystems claim the same GPIO you are going to get an error somewhere
in any case.

5. If you look at the calls that drivers make to find out information
from the board file, or perform some init (mmc does this, USB,
ethernet, etc.) it is mostly because the driver has no idea of the
specifics of the board. Device tree and platform data fix exactly this
problem. The driver has the best idea of when it needs to start up,
when it needs this resource of that. In some cases the driver have the
ability to operate in two modes (e.g. 4 bit or 8 bit SDIO, UART
with/without flow control) and this means the init depends on the
driver's mode.

Having said that, it's your board and if you really want to go this
way in the interim, then I'm not going to strongly object.

Regards,
Simon