All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Simek <michal.simek@xilinx.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] gpio: add gpio-hog support
Date: Mon, 27 May 2019 13:15:51 +0200	[thread overview]
Message-ID: <06d74faf-b576-6b54-f68d-fb0075190245@xilinx.com> (raw)
In-Reply-To: <c146c05a-933c-8670-3522-1e5592d4b895@denx.de>

On 27. 05. 19 11:36, Heiko Schocher wrote:
> Hello Michal,
> 
> Am 27.05.2019 um 09:13 schrieb Michal Simek:
>> On 27. 05. 19 8:30, Heiko Schocher wrote:
>>> add gpio-hog support. GPIO hogging is a mechanism
>>> providing automatic GPIO request and configuration
>>> as part of the gpio-controller's driver probe function.
>>>
>>> for more infos see:
>>> doc/device-tree-bindings/gpio/gpio.txt
>>>
>>> Signed-off-by: Heiko Schocher <hs@denx.de>
>>
>> I have tested it on zcu102 where I use gpio hogs for gt muxes.
> 
> Thanks!
> 
>> gpio hogs are handled and setup only when gpio controller is probed.
> 
> Yes, with my current approach ... If you need a gpio-hog in a gpio
> device, wich is not used, you can add in board code:
> 
> gpio_hog_lookup_name("name_of_the_gpio_hog");
> 
> and gpio driver (and gpio hogs) get probed ... but not really nice...
> 
>> Do we have a way how to say that controllers with gpio hogs should be
>> probed automatically?
> 
> No yet, but I am open for suggestions ;-)
> 
>> Right now you are calling it in post_probe which make sense but on the
>> other hand if you find gpio hog in bind you should probe the whole
>> driver without asking for request.
> 
> Yes, I also thought about this approach, but the problem is in
> 
> static int gpio_hog(struct udevice *dev)
> {
>         ofnode node;
>         struct gpio_dev_priv *uc_priv = NULL;
> 
>         uc_priv = dev_get_uclass_priv(dev);
>         if (!uc_priv) {
>                 printf("%s: missing private data.\n", __func__);
>                 return -EINVAL;
>         }
> 
> uc_priv is not valid @bind stage ...
> 
> But I can think of a function which scans all gpio nodes for
> gpio hog subnodes, and call device_probe() ?
> 
> But from where should this function be called?

The question is if this patch is reading that gpio-hogs at right stage.
Right now you are decoding them in post_probe. Normally getting
information from DT is done in ofdata_to_platdata.
It is question if this approach is also working for non DT case.

Anyway let's say you setup a flag in ofdata_to_platdata that there are
gpio hogs and then you know if you should probe that device or not.

btw: didn't send this before you v2 but should be still valid.
Let me test v2 now.

M

      reply	other threads:[~2019-05-27 11:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-27  6:30 [U-Boot] [PATCH] gpio: add gpio-hog support Heiko Schocher
2019-05-27  7:13 ` Michal Simek
2019-05-27  9:36   ` Heiko Schocher
2019-05-27 11:15     ` Michal Simek [this message]

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=06d74faf-b576-6b54-f68d-fb0075190245@xilinx.com \
    --to=michal.simek@xilinx.com \
    --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.