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

[Igor Grinberg]

Hi Simon,

On 10/02/14 22:22, Simon Glass wrote:
> 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:

Please, don't get me wrong, we have of course read and thought about
this also considering your comments.
The thing is that currently, some of those GPIOs are way too board
specific and may be the right thing would be to leave it that way.
Also some are not board specific, and I will be very glad to pass
them to the drivers.
Yet, I think Nikita's patch is very sane for now.
Once we can pass the GPIOs to the drivers we will of course do this.
We will also be glad to help working on this as we always did (when
the schedule permits us).

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

I think this is case dependent. Really we're in the boot loader
world, things here are board specific in many cases.

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

I don't think it is possible.
There will always be boards that are not by the reference design
and there will have to be stuff done in the board files as it will
not concern any other boards or drivers.

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

Why even? Not using DT is not a bad practice at all!
DT has been designed as an API/ABI to the OS and not for the boot loader!
Boot loaders are board specific, period.
I don't mind using DT in the boot loader for ease and abstraction, but
don't be obsessed with it, because it will only lead to another,
pre-bootloader boot loader which will accommodate all the stuff you
are trying to avoid.

Regarding your feeling honky about parsing data by the board code:
There are so many cases, that I don't think you have considered,
where using DT _instead_ of run time initializations is a total
madness.
Here is one:
Same board, different configuration/revision/extension/variation/etc.
Instead of parsing stuff at runtime and adjusting things according
to detection, you propose an army of DT blobs? This sounds insane.

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

Two subsystems should never own the same GPIO at the same time.
If you follow that rule, there will be errors only in case when there
should errors.

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

This is correct. No doubt about this.
Yet, generic driver may have prerequisite on a custom board and
don't even know about this prerequisite.

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

Thanks!
I do really like the idea of DM and I think this should be developed
year ago. Yet, any framework should be flexible enough to give some
place on the stage to the board specific code.

-- 
Regards,
Igor.