Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 1/4] GPIO implementation framework | Date | Tue, 13 Nov 2007 23:19:47 -0800 |
| |
> > > 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.
- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |