On Sat, 1 Dec 2012 19:41:39 +0100, Linus Walleij
wrote:
> On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely
> wrote:
> > On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot
> > wrote:
> >> On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> >> > I don't have any problem with a gpio_get
On Sat, 1 Dec 2012 19:41:39 +0100, Linus Walleij linus.wall...@linaro.org
wrote:
On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely grant.lik...@secretlab.ca
wrote:
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot acour...@nvidia.com
wrote:
On Monday 26 November 2012 19:14:31 Grant Likely
On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely wrote:
> On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot wrote:
>> On Monday 26 November 2012 19:14:31 Grant Likely wrote:
>> > I don't have any problem with a gpio_get function, but I do agree that
>> > making it return an opaque handle is how it
On Thu, Nov 29, 2012 at 6:34 PM, Grant Likely grant.lik...@secretlab.ca wrote:
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot acour...@nvidia.com wrote:
On Monday 26 November 2012 19:14:31 Grant Likely wrote:
I don't have any problem with a gpio_get function, but I do agree that
making it
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot wrote:
> On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> > I don't have any problem with a gpio_get function, but I do agree that
> > making it return an opaque handle is how it should be written with a new
> > set of accessors. The
On Wed, 28 Nov 2012 12:38:38 +0900, Alex Courbot acour...@nvidia.com wrote:
On Monday 26 November 2012 19:14:31 Grant Likely wrote:
I don't have any problem with a gpio_get function, but I do agree that
making it return an opaque handle is how it should be written with a new
set of
On Monday 26 November 2012 19:14:31 Grant Likely wrote:
> I don't have any problem with a gpio_get function, but I do agree that
> making it return an opaque handle is how it should be written with a new
> set of accessors. The handle should probably be simply the pointer to
> the _desc[number]
On Monday 26 November 2012 19:14:31 Grant Likely wrote:
I don't have any problem with a gpio_get function, but I do agree that
making it return an opaque handle is how it should be written with a new
set of accessors. The handle should probably be simply the pointer to
the gpio_desc[number]
On Wed, 31 Oct 2012 18:04:09 +0900, 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()?
>
> I can see some good reasons to have this:
>
> - Less platform data to pass to drivers,
> - Consistency
On Wed, 7 Nov 2012 22:28:01 +0100, Linus Walleij
wrote:
> On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren wrote:
> > [Me]
> >> gpio_get() should get an abstract handle just like clk_get() or
> >> regulator_get(), not a fixed numeral.
> >
> > I don't really see why the return type of gpio_get()
On Mon, 5 Nov 2012 13:09:20 +0100, Linus Walleij
wrote:
> On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot wrote:
>
> > Interesting. I see you already gave the whole thing a thought. What I don't
> > understand however is what is so wrong with the current GPIO numberspace
> > that
> > you want to
On Mon, 5 Nov 2012 13:09:20 +0100, Linus Walleij linus.wall...@linaro.org
wrote:
On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot acour...@nvidia.com wrote:
Interesting. I see you already gave the whole thing a thought. What I don't
understand however is what is so wrong with the current GPIO
On Wed, 7 Nov 2012 22:28:01 +0100, Linus Walleij linus.wall...@linaro.org
wrote:
On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren swar...@wwwdotorg.org wrote:
[Me]
gpio_get() should get an abstract handle just like clk_get() or
regulator_get(), not a fixed numeral.
I don't really see why
On Wed, 31 Oct 2012 18:04:09 +0900, Alex Courbot acour...@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,
-
On Thu, Nov 8, 2012 at 7:23 AM, Alex Courbot wrote:
> On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
>> On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot wrote:
>> > How about, in a first time (and because I'd also like to get the power
>> > seqs
>> > moving on), a typedef from int to
On Thu, Nov 8, 2012 at 7:23 AM, Alex Courbot acour...@nvidia.com wrote:
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot acour...@nvidia.com wrote:
How about, in a first time (and because I'd also like to get the power
seqs
moving on),
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot wrote:
> > How about, in a first time (and because I'd also like to get the power
> > seqs
> > moving on), a typedef from int to gpio_handle_t and a first implementation
> > of the
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
> I would prefer to create, e.g. in
> something like:
>
> struct gpio;
>
> struct gpio *gpio_get(struct device *dev, const char *name);
>
> int gpio_get_value(struct gpio *g);
>
> Nothing more! I.e. struct gpio is an opaque cookie,
On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren wrote:
> [Me]
>> gpio_get() should get an abstract handle just like clk_get() or
>> regulator_get(), not a fixed numeral.
>
> I don't really see why the return type of gpio_get() influences whether
> it can be implemented or not.
It doesn't
On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot wrote:
> How about, in a first time (and because I'd also like to get the power seqs
> moving on), a typedef from int to gpio_handle_t and a first implementation of
> the gpio_handle_*() API that would just call the existing integer-based API
> (apart
On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot acour...@nvidia.com wrote:
How about, in a first time (and because I'd also like to get the power seqs
moving on), a typedef from int to gpio_handle_t and a first implementation of
the gpio_handle_*() API that would just call the existing
On Mon, Nov 5, 2012 at 6:35 PM, Stephen Warren swar...@wwwdotorg.org wrote:
[Me]
gpio_get() should get an abstract handle just like clk_get() or
regulator_get(), not a fixed numeral.
I don't really see why the return type of gpio_get() influences whether
it can be implemented or not.
It
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
I would prefer to create, e.g. in linux/gpio/consumer.h
something like:
struct gpio;
struct gpio *gpio_get(struct device *dev, const char *name);
int gpio_get_value(struct gpio *g);
Nothing more! I.e. struct gpio is an opaque
On Thursday 08 November 2012 05:24:19 Linus Walleij wrote:
On Tue, Nov 6, 2012 at 2:33 AM, Alex Courbot acour...@nvidia.com wrote:
How about, in a first time (and because I'd also like to get the power
seqs
moving on), a typedef from int to gpio_handle_t and a first implementation
of the
On Tuesday 06 November 2012 01:35:11 Stephen Warren wrote:
> On 11/04/2012 11:04 AM, Linus Walleij wrote:
> > On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot
wrote:
> >> Would anyone be opposed to having a gpio_get() function that works
> >> similarly to e.g. regulator_get() and clk_get()?
> >
>
On 11/04/2012 11:04 AM, Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote:
>
>> Would anyone be opposed to having a gpio_get() function that works similarly
>> to e.g. regulator_get() and clk_get()?
>
> I understand the concept and why you want to do this.
>
> However
On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot wrote:
> Interesting. I see you already gave the whole thing a thought. What I don't
> understand however is what is so wrong with the current GPIO numberspace that
> you want to replace it? Whether we use simple integers or blind pointers, the
>
On Mon, Nov 5, 2012 at 8:31 AM, Alex Courbot acour...@nvidia.com wrote:
Interesting. I see you already gave the whole thing a thought. What I don't
understand however is what is so wrong with the current GPIO numberspace that
you want to replace it? Whether we use simple integers or blind
On 11/04/2012 11:04 AM, Linus Walleij wrote:
On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot acour...@nvidia.com wrote:
Would anyone be opposed to having a gpio_get() function that works similarly
to e.g. regulator_get() and clk_get()?
I understand the concept and why you want to do this.
On Tuesday 06 November 2012 01:35:11 Stephen Warren wrote:
On 11/04/2012 11:04 AM, Linus Walleij wrote:
On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot acour...@nvidia.com
wrote:
Would anyone be opposed to having a gpio_get() function that works
similarly to e.g. regulator_get() and
Hi Linus, thanks for the reply!
On Monday 05 November 2012 02:04:33 Linus Walleij wrote:
> On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote:
> > Would anyone be opposed to having a gpio_get() function that works
> > similarly to e.g. regulator_get() and clk_get()?
>
> I understand the
On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot wrote:
> Would anyone be opposed to having a gpio_get() function that works similarly
> to e.g. regulator_get() and clk_get()?
I understand the concept and why you want to do this.
However I think the global GPIO numberspace defeats the
purpose.
On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot acour...@nvidia.com wrote:
Would anyone be opposed to having a gpio_get() function that works similarly
to e.g. regulator_get() and clk_get()?
I understand the concept and why you want to do this.
However I think the global GPIO numberspace
Hi Linus, thanks for the reply!
On Monday 05 November 2012 02:04:33 Linus Walleij wrote:
On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot acour...@nvidia.com wrote:
Would anyone be opposed to having a gpio_get() function that works
similarly to e.g. regulator_get() and clk_get()?
I
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
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
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
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
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
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
40 matches
Mail list logo
