Re: [patch/rfc 1/4] GPIO implementation framework

[David Brownell <david-b@pacbell.net>]

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/