lkml.org 
[lkml]   [2012]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: How about a gpio_get(device *, char *) function?
Date
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.


\
 
 \ /
  Last update: 2012-11-26 18:01    [W:0.129 / U:1.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site