Messages in this thread | | | From | David Brownell <> | Subject | Re: [patch/rfc 1/4] GPIO implementation framework | Date | Tue, 13 Nov 2007 23:08:47 -0800 |
| |
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 don't feel like the holes. Put restrictions on > the numbering of GPIOs might not be a good idea either.
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.)
I could see that being a reasonable tradeoff. I wouldn't have started there myself, but you know how that goes!
Does anyone else have any comments on that issue?
One point you haven't really brought up in this thread is your concern about the impact of this on IRQs. One issue being that for GPIOs used as IRQs, with linear mappings resembling
static inline int gpio_to_irq(unsigned gpio) { if (gpio >= LAST_IRQ_CAPABLE_GPIO) return -EINVAL; return irq + FIRST_GPIO_IRQ_NUMBER; }
then tightly packed GPIOs mean less space wasted for IRQ descriptors that would never be used.
And since an irq_desc bigger than your gpio_desc, there's a tradeoff between wasting space on unused gpio_desc structs versus unused irq_desc structs. 2 KBytes would cost about only 35 irq_desc structs, vs 256 gpio_desc structs.
I'm guessing that's why you care about dense packing for the GPIO numbers...
- 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/
| |