lkml.org 
[lkml]   [2012]   [Oct]   [31]   [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 Wednesday 31 October 2012 23:25:41 Stephen Warren wrote:
> On 10/31/2012 03:04 AM, Alex Courbot wrote:
> > Hi,
> >
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
>
> One major stumbling block is that with device tree, each individual
> binding gets to decide on the specific naming of the propert{y,ies} that
> define the GPIO(s) for the device, and so there's no way to provide a
> generic implementation of that function.

The idea is not to make every GPIOs declared so far accessible through this
function - as you point out this would be tricky at best - but to also define
how they should be properly declared (similarly to regulators and pals) for
bindings that need to use get_gpio(). Existing bindings and drivers that can
live without it should not be modified. And now that you mention it, the end of
the GPIO declaration anarchy would be another point in favor of this feature.

Now I am aware that almost every subsystem comes with its own scheme for
declaring resources in the DT and there will be an long fight to decide which
one should apply here, but I'm willing to take that road.

> Related, I've always wished that DT nodes looked like:
>
> device {
> reg = <...>;
> compatible = <...>;
> resources {
> pwms = <...>;
> regulators = <...>;
> clocks = <...>;
> gpios = <...>;
> other-devices = <...>; /* for custom API dependencies */
> };
> config {
> /* device-specific properties */
> };
> child-busses {
> 0 = { ... };
> 1 = { ... };
> };
> };
>
> ... specifically so that all resource allocation, and perhaps even child
> bus enumeration, could be completely standardized in the DT/device core.
> This could also feed into deferred probe, which could then be purely
> implemented inside the DT/driver core. However, that'd require something
> incompatible like "device tree 2.0"

I think this would be awesome. This could even probably be implemented without
breaking things, if everything takes place inside well-defined subnodes of the
device.

Alex.



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