All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] arm: mx6: cm_fx6: use gpio request
Date: Thu, 2 Oct 2014 13:22:43 -0600	[thread overview]
Message-ID: <CAPnjgZ2XFLPzX0MqjUYXN01Nk-pVYWZwZPhbVgAxOFHAF+68cg@mail.gmail.com> (raw)
In-Reply-To: <1412259444-11959-3-git-send-email-nikita@compulab.co.il>

Hi Nikita,

On 2 October 2014 08:17, Nikita Kiryanov <nikita@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@compulab.co.il>
> Cc: Simon Glass <sjg@chromium.org>
> Signed-off-by: Nikita Kiryanov <nikita@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

  reply	other threads:[~2014-10-02 19:22 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02  1:57 [U-Boot] [PATCH v4 0/9] dm: imx: Add driver model support for GPIO and serial on cm_fx6 Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 1/9] dm: linker_lists: Add a way to declare multiple objects Simon Glass
2014-10-23  3:05   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 2/9] dm: core: Allow a list of devices to be declared in one step Simon Glass
2014-10-23  3:05   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 3/9] initcall: Display error number when an error occurs Simon Glass
2014-10-23  3:05   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 4/9] dm: serial: Put common code into separate functions Simon Glass
2014-10-23  3:05   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 5/9] imx: Add error checking to setup_i2c() Simon Glass
2014-10-23  3:06   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 6/9] dm: imx: Use gpio_request() to request GPIOs Simon Glass
2014-10-02 14:17   ` [U-Boot] [PATCH 0/2] Split "dm: imx: Use gpio_request() to request GPIOs" Nikita Kiryanov
2014-10-02 14:17     ` [U-Boot] [PATCH 1/2] dm: imx: i2c: Use gpio_request() to request GPIOs Nikita Kiryanov
2014-10-03  6:39       ` Igor Grinberg
2014-10-14  7:25         ` Simon Glass
2014-10-21  9:51           ` Igor Grinberg
2014-10-23  3:06             ` Simon Glass
2014-10-02 14:17     ` [U-Boot] [PATCH 2/2] arm: mx6: cm_fx6: use gpio request Nikita Kiryanov
2014-10-02 19:22       ` Simon Glass [this message]
2014-10-03  7:41         ` Igor Grinberg
2014-10-03 14:04           ` Simon Glass
2014-10-05 10:52             ` Igor Grinberg
2014-10-05 18:32               ` Simon Glass
2014-10-06  5:47                 ` Igor Grinberg
2014-10-03  6:45       ` Igor Grinberg
2014-10-23  3:06       ` Simon Glass
2014-10-02 14:18   ` [U-Boot] [PATCH v4 6/9] dm: imx: Use gpio_request() to request GPIOs Nikita Kiryanov
2014-10-02 16:06     ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 7/9] dm: imx: gpio: Support driver model in MXC gpio driver Simon Glass
2014-10-23  3:06   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 8/9] dm: imx: serial: Support driver model in the MXC serial driver Simon Glass
2014-10-23  3:06   ` Simon Glass
2014-10-02  1:57 ` [U-Boot] [PATCH v4 9/9] dm: imx: Move cm_fx6 to use driver model for serial and GPIO Simon Glass
2014-10-02 14:16   ` Nikita Kiryanov
2014-10-23  3:06   ` Simon Glass
2014-10-02  1:59 ` [U-Boot] [PATCH v4 0/9] dm: imx: Add driver model support for GPIO and serial on cm_fx6 Simon Glass

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPnjgZ2XFLPzX0MqjUYXN01Nk-pVYWZwZPhbVgAxOFHAF+68cg@mail.gmail.com \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.