devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: Alex Courbot <acourbot@nvidia.com>,
	Linus Walleij <linus.walleij@linaro.org>
Cc: devicetree-discuss@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: How about a gpio_get(device *, char *) function?
Date: Mon, 26 Nov 2012 11:17:18 +0000	[thread overview]
Message-ID: <20121126111718.A44E43E0A01@localhost> (raw)
In-Reply-To: <38620644.IyR5R8rjKP@percival>

On Wed, 31 Oct 2012 18:04:09 +0900, Alex Courbot <acourbot@nvidia.com> wrote:
> Hi,
> 
> Would anyone be opposed to having a gpio_get() function that works similarly 
> to e.g. regulator_get() and clk_get()?
> 
> I can see some good reasons to have this:
> 
> - Less platform data to pass to drivers,
> - Consistency between different subsystems. Regulator, clock, PWM, ... all use 
> this scheme.
> - The "device-specific indirection" could make some DT structures more 
> reusable. Right now the only way to address a GPIO through the DT is via a 
> phandle that includes the GPIO number - thus hard-coded.
> 
> The implementation would be rather simple, and the function would just return 
> the right GPIO number (acquired through gpio_request).

I've got no problem with it, but the devil is in the API details. Draft
something up (unless you already have and I just haven't seen it yet...
I'll get to it).  :-)

BTW, I would prefer a system that resolves the gpio at .probe() time
instead of at registration time. That makes deferred probing easier.

g.

> 
> Rationale for this: I would like to be able to share power sequences between 
> devices, e.g. to completely extract the per-device resources from the 
> sequence. Every power sequence step references either a regulator, PWM, or 
> GPIO. For regulators and PWMs separation is easy because their subsystems 
> provide regulator_get() and pwm_get() which allow the resource to be 
> referenced by name in the sequence, and resolved to different instances 
> depending on the device. GPIOs, on the other hand, can only be referenced by 
> number - and that makes it necessary to duplicate the sequence's structure in 
> memory for every device that may use it. It if was possible to reference GPIOs 
> by names that resolve to different GPIO numbers according to the device, then 
> the problem would be solved.
> 
> There are probably other use-cases that would benefit from this, if you know of 
> one please feel free to share.
> 
> Thanks,
> Alex.
> 

-- 
Grant Likely, B.Sc, P.Eng.
Secret Lab Technologies, Ltd.

      parent reply	other threads:[~2012-11-26 11:17 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-31  9:04 How about a gpio_get(device *, char *) function? Alex Courbot
2012-10-31 15:25 ` Stephen Warren
     [not found]   ` <509142F5.4010307-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-11-01  2:48     ` Alex Courbot
2012-11-04 18:04 ` Linus Walleij
2012-11-05  7:31   ` Alex Courbot
2012-11-05 12:09     ` Linus Walleij
2012-11-26 11:25       ` Grant Likely
2012-11-05 17:35   ` Stephen Warren
2012-11-06  1:33     ` Alex Courbot
2012-11-07 21:24       ` Linus Walleij
2012-11-08  6:14         ` Alex Courbot
     [not found]         ` <CACRpkdYqCQc0Er1JR_eVzZPCycvKjd0Pph8Dcay0FbU3Q64D8A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-11-08  6:23           ` Alex Courbot
2012-11-13 13:13             ` Linus Walleij
2012-11-07 21:28     ` Linus Walleij
2012-11-26 11:14       ` Grant Likely
2012-11-28  3:38         ` Alex Courbot
2012-11-29 17:34           ` Grant Likely
2012-12-01 18:41             ` Linus Walleij
2012-12-03 14:15               ` Grant Likely
2012-11-26 11:17 ` Grant Likely [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=20121126111718.A44E43E0A01@localhost \
    --to=grant.likely@secretlab.ca \
    --cc=acourbot@nvidia.com \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).