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, 2007 3:19 PM, David Brownell <[EMAIL PROTECTED]> wrote: > > > > > 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 256 GPIOs means > > > an extra 3 KB static memory compared to the patch I sent. > > Actually, 2K is a more accurate number -- ignore DEBUG_FS. > > > > Note this reduces the memory in gpio_chip, so it consumes almost same > > memory as the patch you sent. > > No; the amount of space shaved from a typical (32-bit banks) > gpio_chip is *exactly* the cost of one gpio_desc: two words. > In one case, two bitmaps. In the other, a pointer, two bits, > and internal struct padding. > > So unless each bank has only a single GPIO, this approach > does cost more memory. Both for the extra memory associated > with each gpio_chip that's used, and for unused gpio_desc. > > That's not necessarily a bad thing, though it's always worth > avoiding bloat. > Well, absolutely agree on this. > - Dave > -- Cheers - eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/