Sorry, I thought you want a preliminary one, here's the one
tested and including your comments except for one:
if caller holds gpio_lock, gpio_ensure_requested() is actually
safe.
please review:
---
include/asm-generic/gpio.h | 35 +++-
lib/gpiolib.c | 212
On Tuesday 27 November 2007, eric miao wrote:
> status = chip->direction_input(chip, gpio);
> - if (status == 0)
> - clear_bit(gpio, chip->is_out);
> + if (status)
> + desc->is_out = 0;
You added that same bug in two places (direction_output too).
On Tuesday 27 November 2007, eric miao wrote:
>c) removal of "gpiochip_is_requested()", and use "gpio_desc->requested"
> instead
That's problematic for GPIO code that needs to know if a given
GPIO has been requested ... since you don't export gpio_desc[]
(and shouldn't) that
Thanks, I'll be looking at it ... the one thing I strongly dislike is
this change:
On Tuesday 27 November 2007, eric miao wrote:
> 4. use a loop for "gpio_desc[]" instead of a loop for "gpio_chips[]" in
> gpiolib_show(), change is straight forward; since it is now per gpio
> based, the
OK, here's the all-in-one patch based on David's most recent gpiolib fix,
Changes include:
1. use per gpio structure "gpio_desc", thus eliminating the restriction of
ARCH_GPIOS_PER_CHIP, thus making it possible leaving no holes in GPIOs
numbering
Note: the number of GPIOs on different
OK, here's the all-in-one patch based on David's most recent gpiolib fix,
Changes include:
1. use per gpio structure gpio_desc, thus eliminating the restriction of
ARCH_GPIOS_PER_CHIP, thus making it possible leaving no holes in GPIOs
numbering
Note: the number of GPIOs on different
Thanks, I'll be looking at it ... the one thing I strongly dislike is
this change:
On Tuesday 27 November 2007, eric miao wrote:
4. use a loop for gpio_desc[] instead of a loop for gpio_chips[] in
gpiolib_show(), change is straight forward; since it is now per gpio
based, the
On Tuesday 27 November 2007, eric miao wrote:
c) removal of gpiochip_is_requested(), and use gpio_desc-requested
instead
That's problematic for GPIO code that needs to know if a given
GPIO has been requested ... since you don't export gpio_desc[]
(and shouldn't) that functionality has
On Tuesday 27 November 2007, eric miao wrote:
status = chip-direction_input(chip, gpio);
- if (status == 0)
- clear_bit(gpio, chip-is_out);
+ if (status)
+ desc-is_out = 0;
You added that same bug in two places (direction_output too).
Only zero
Sorry, I thought you want a preliminary one, here's the one
tested and including your comments except for one:
if caller holds gpio_lock, gpio_ensure_requested() is actually
safe.
please review:
---
include/asm-generic/gpio.h | 35 +++-
lib/gpiolib.c | 212
On Tuesday 13 November 2007, David Brownell wrote:
> So the point of these is to make it easier for platforms
> (or even just boards) to make sure the GPIO number space
> is densely packed, rather than loosely so? Paying about
> 2KBytes for that privilege. (Assuming a 32 bit system
> with 256
On Tuesday 13 November 2007, David Brownell wrote:
So the point of these is to make it easier for platforms
(or even just boards) to make sure the GPIO number space
is densely packed, rather than loosely so? Paying about
2KBytes for that privilege. (Assuming a 32 bit system
with 256 GPIOs.)
Hi David,
On Sat, 17 Nov 2007 09:36:24 -0800, David Brownell wrote:
> On Saturday 17 November 2007, Jean Delvare wrote:
> > On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
> > > On Tuesday 13 November 2007, eric miao wrote:
> > > > if (!requested)
> > > > -
Hi David,
On Sat, 17 Nov 2007 09:36:24 -0800, David Brownell wrote:
On Saturday 17 November 2007, Jean Delvare wrote:
On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
On Tuesday 13 November 2007, eric miao wrote:
if (!requested)
- printk(KERN_DEBUG
On Saturday 17 November 2007, Jean Delvare wrote:
> On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
> > On Tuesday 13 November 2007, eric miao wrote:
> > > if (!requested)
> > > - printk(KERN_DEBUG "GPIO-%d autorequested\n",
> > > - chip->base + offset);
On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > if (!requested)
> > - printk(KERN_DEBUG "GPIO-%d autorequested\n",
> > - chip->base + offset);
> > + pr_debug("GPIO-%d autorequested\n",
On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
On Tuesday 13 November 2007, eric miao wrote:
if (!requested)
- printk(KERN_DEBUG GPIO-%d autorequested\n,
- chip-base + offset);
+ pr_debug(GPIO-%d autorequested\n, gpio);
Leave
On Saturday 17 November 2007, Jean Delvare wrote:
On Tue, 13 Nov 2007 20:36:13 -0800, David Brownell wrote:
On Tuesday 13 November 2007, eric miao wrote:
if (!requested)
- printk(KERN_DEBUG GPIO-%d autorequested\n,
- chip-base + offset);
+
Y, the IRQ <--> GPIO mapping is another thing I'm concerned about. Other than
that, all the other part of the gpiolib is a great work, actually,
I've been waiting
for this for quite a long time and just don't have time for a hands-on until
recently.
So let's get more feedback on this.
On Nov 14,
> > > struct gpio_desc {
> > > struct gpio_chip *chip;
> > > unsigned is_out:1;
> > > + unsigned requested:1;
> > > +#ifdef CONFIG_DEBUG_FS
> > > + const char *requested_str;
> > > +#endif
> >
> > Note that this means (on typical 32-bit embedded hardware)
> > twelve bytes per
On Tuesday 13 November 2007, eric miao wrote:
> > > > We "can" do most anything. What would that improve though?
> >
> > ... What would that improve, though? Your followup posts
> > still don't answer that question for me. I see the code,
> > but don't have an answer to that question.
> >
>
>
On Nov 14, 2007 12:36 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
> >
>
> > struct gpio_desc {
> > struct gpio_chip *chip;
> > unsigned is_out:1;
> > +
On Nov 14, 2007 12:18 PM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > Here comes the point of "struct gpio_desc"
> >
> > Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
> > "gpio_chip" to a list
>
> I see what it does, but don't
On Nov 14, 2007 11:30 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> > > > Can we use "per gpio based" structure instead of "per gpio_chip" based
> > > > one,
> > > > just like what the generic IRQ layer is doing nowadays?
> > >
> > > We "can" do
On Nov 14, 2007 11:25 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 13 November 2007, eric miao wrote:
> >
> > Here comes a bunch of patches to illustrate my idea, some are not related to
> > the point I mentioned, and they are not mature for now :-)
> >
> > Subject: [PATCH 1/5] add
On Tuesday 13 November 2007, eric miao wrote:
> Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
>
> struct gpio_desc {
> struct gpio_chip *chip;
> unsigned is_out:1;
> + unsigned requested:1;
> +#ifdef CONFIG_DEBUG_FS
> + const char *requested_str;
>
On Tuesday 13 November 2007, eric miao wrote:
> Here comes the point of "struct gpio_desc"
>
> Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
> "gpio_chip" to a list
I see what it does, but don't see the "why" ... surely
you can come up with a one sentence description of why
On Tuesday 13 November 2007, David Brownell wrote:
> http://marc.info/?l=linux-kernel=119463810905330=2
> http://marc.info/?l=linux-kernel=119463811005344=2
> http://marc.info/?l=linux-kernel=119463811105352=2
>
> Plus the appended tweak.
-ENOPATCH ... ;)
==
Minor fixups to the
On Tuesday 13 November 2007, eric miao wrote:
> > > Can we use "per gpio based" structure instead of "per gpio_chip" based
> > > one,
> > > just like what the generic IRQ layer is doing nowadays?
> >
> > We "can" do most anything. What would that improve though?
... What would that improve,
On Tuesday 13 November 2007, eric miao wrote:
>
> so that requested will always be used, only *requested_str will be used
> for DEBUG_FS tracking assistance
>
> Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking
> string
Doesn't seem unreasonable, since the extra cost is
On Tuesday 13 November 2007, eric miao wrote:
>
> Here comes a bunch of patches to illustrate my idea, some are not related to
> the point I mentioned, and they are not mature for now :-)
>
> Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range
> checking
I'll send
Subject: [PATCH 5/5] move per GPIO "requested" to "struct gpio_desc"
---
include/asm-generic/gpio.h | 17 +++-
lib/gpiolib.c | 62 ---
2 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/include/asm-generic/gpio.h
Here comes the point of "struct gpio_desc"
Subject: [PATCH 3/5] use a per GPIO "struct gpio_desc" and chain
"gpio_chip" to a list
---
include/asm-generic/gpio.h |7 +
lib/gpiolib.c | 64 ++--
2 files changed, 39 insertions(+), 32
Subject: [PATCH] move per GPIO "is_out" to "struct gpio_desc"
---
include/asm-generic/gpio.h |4 +---
lib/gpiolib.c | 18 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index
so that requested will always be used, only *requested_str will be used
for DEBUG_FS tracking assistance
Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking string
---
include/asm-generic/gpio.h | 11 ++-
lib/gpiolib.c | 34
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range checking
---
lib/gpiolib.c | 32 ++--
1 files changed, 22
On Nov 14, 2007 3:06 AM, David Brownell <[EMAIL PROTECTED]> wrote:
> On Monday 12 November 2007, eric miao wrote:
> > Hi David,
> >
> > I hope I was not late giving my humble feedback on this framework :-)
> >
> > Can we use "per gpio based" structure instead of "per gpio_chip" based one,
> > just
On Monday 12 November 2007, eric miao wrote:
> Hi David,
>
> I hope I was not late giving my humble feedback on this framework :-)
>
> Can we use "per gpio based" structure instead of "per gpio_chip" based one,
> just like what the generic IRQ layer is doing nowadays?
We "can" do most anything.
On Monday 12 November 2007, eric miao wrote:
Hi David,
I hope I was not late giving my humble feedback on this framework :-)
Can we use per gpio based structure instead of per gpio_chip based one,
just like what the generic IRQ layer is doing nowadays?
We can do most anything. What would
On Nov 14, 2007 3:06 AM, David Brownell [EMAIL PROTECTED] wrote:
On Monday 12 November 2007, eric miao wrote:
Hi David,
I hope I was not late giving my humble feedback on this framework :-)
Can we use per gpio based structure instead of per gpio_chip based one,
just like what the
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range checking
---
lib/gpiolib.c | 32 ++--
1 files changed, 22
so that requested will always be used, only *requested_str will be used
for DEBUG_FS tracking assistance
Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking string
---
include/asm-generic/gpio.h | 11 ++-
lib/gpiolib.c | 34
Here comes the point of struct gpio_desc
Subject: [PATCH 3/5] use a per GPIO struct gpio_desc and chain
gpio_chip to a list
---
include/asm-generic/gpio.h |7 +
lib/gpiolib.c | 64 ++--
2 files changed, 39 insertions(+), 32
Subject: [PATCH] move per GPIO is_out to struct gpio_desc
---
include/asm-generic/gpio.h |4 +---
lib/gpiolib.c | 18 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index
Subject: [PATCH 5/5] move per GPIO requested to struct gpio_desc
---
include/asm-generic/gpio.h | 17 +++-
lib/gpiolib.c | 62 ---
2 files changed, 39 insertions(+), 40 deletions(-)
diff --git a/include/asm-generic/gpio.h
On Tuesday 13 November 2007, eric miao wrote:
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add gpio_is_onchip() for commonly used gpio range
checking
I'll send substantive
On Tuesday 13 November 2007, eric miao wrote:
so that requested will always be used, only *requested_str will be used
for DEBUG_FS tracking assistance
Subject: [PATCH 2/5] define gpio_chip.requested_str as a debugfs tracking
string
Doesn't seem unreasonable, since the extra cost is only
On Tuesday 13 November 2007, eric miao wrote:
Can we use per gpio based structure instead of per gpio_chip based
one,
just like what the generic IRQ layer is doing nowadays?
We can do most anything. What would that improve though?
... What would that improve, though? Your followup
On Tuesday 13 November 2007, David Brownell wrote:
http://marc.info/?l=linux-kernelm=119463810905330w=2
http://marc.info/?l=linux-kernelm=119463811005344w=2
http://marc.info/?l=linux-kernelm=119463811105352w=2
Plus the appended tweak.
-ENOPATCH ... ;)
==
Minor fixups to the
On Tuesday 13 November 2007, eric miao wrote:
Subject: [PATCH 5/5] move per GPIO requested to struct gpio_desc
struct gpio_desc {
struct gpio_chip *chip;
unsigned is_out:1;
+ unsigned requested:1;
+#ifdef CONFIG_DEBUG_FS
+ const char *requested_str;
+#endif
A
On Tuesday 13 November 2007, eric miao wrote:
Here comes the point of struct gpio_desc
Subject: [PATCH 3/5] use a per GPIO struct gpio_desc and chain
gpio_chip to a list
I see what it does, but don't see the why ... surely
you can come up with a one sentence description of why
this would be
On Nov 14, 2007 11:30 AM, David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, eric miao wrote:
Can we use per gpio based structure instead of per gpio_chip based
one,
just like what the generic IRQ layer is doing nowadays?
We can do most anything. What would
On Nov 14, 2007 12:36 PM, David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, eric miao wrote:
Subject: [PATCH 5/5] move per GPIO requested to struct gpio_desc
struct gpio_desc {
struct gpio_chip *chip;
unsigned is_out:1;
+ unsigned requested:1;
On Nov 14, 2007 11:25 AM, David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, eric miao wrote:
Here comes a bunch of patches to illustrate my idea, some are not related to
the point I mentioned, and they are not mature for now :-)
Subject: [PATCH 1/5] add
On Tuesday 13 November 2007, eric miao wrote:
We can do most anything. What would that improve though?
... What would that improve, though? Your followup posts
still don't answer that question for me. I see the code,
but don't have an answer to that question.
to be honest, I
On Nov 14, 2007 12:18 PM, David Brownell [EMAIL PROTECTED] wrote:
On Tuesday 13 November 2007, eric miao wrote:
Here comes the point of struct gpio_desc
Subject: [PATCH 3/5] use a per GPIO struct gpio_desc and chain
gpio_chip to a list
I see what it does, but don't see the why ...
struct gpio_desc {
struct gpio_chip *chip;
unsigned is_out:1;
+ unsigned requested:1;
+#ifdef CONFIG_DEBUG_FS
+ const char *requested_str;
+#endif
Note that this means (on typical 32-bit embedded hardware)
twelve bytes per GPIO, which if you assume
Y, the IRQ -- GPIO mapping is another thing I'm concerned about. Other than
that, all the other part of the gpiolib is a great work, actually,
I've been waiting
for this for quite a long time and just don't have time for a hands-on until
recently.
So let's get more feedback on this.
On Nov 14,
Hi David,
I hope I was not late giving my humble feedback on this framework :-)
Can we use "per gpio based" structure instead of "per gpio_chip" based one,
just like what the generic IRQ layer is doing nowadays? So that
a. you don't have to declare per gpio_chip "can_sleep", "is_out" and
Hi David,
I hope I was not late giving my humble feedback on this framework :-)
Can we use per gpio based structure instead of per gpio_chip based one,
just like what the generic IRQ layer is doing nowadays? So that
a. you don't have to declare per gpio_chip can_sleep, is_out and
requested.
On Monday 29 October 2007, David Brownell wrote:
>
> Provides new implementation infrastructure that platforms may choose to use
> when implementing the GPIO programming interface. Platforms can update their
> GPIO support to use this. The downside is slower access to non-inlined GPIOs;
>
On Monday 29 October 2007, David Brownell wrote:
Provides new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. The downside is slower access to non-inlined GPIOs;
rarely a
Provides new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. The downside is slower access to non-inlined GPIOs;
rarely a problem except when bitbanging some protocol. The
Provides new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. The downside is slower access to non-inlined GPIOs;
rarely a problem except when bitbanging some protocol. The
64 matches
Mail list logo
