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
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 functionali
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 gpio_
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 G
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 GPI
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(K
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", gp
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.
> >
>
> to
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;
> > + unsigne
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
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 mo
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 gp
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;
> +#en
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
thi
On Tuesday 13 November 2007, David Brownell wrote:
> http://marc.info/?l=linux-kernel&m=119463810905330&w=2
> http://marc.info/?l=linux-kernel&m=119463811005344&w=2
> http://marc.info/?l=linux-kernel&m=119463811105352&w=2
>
> Plus the appended tweak.
-ENOPATCH ... ;)
==
Minor fixu
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, thou
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 substantive
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 b/inc
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 del
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 783adcf..d
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 i
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.
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
"reques
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
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 upside
32 matches
Mail list logo
