On Fri, Aug 05, 2011 at 12:33:31PM -0700, Stephen Warren wrote:
Russell King - ARM Linux wrote at Friday, August 05, 2011 1:15 PM:
On Fri, Aug 05, 2011 at 08:43:20AM -0700, Stephen Warren wrote:
Russell King - ARM Linux wrote at Friday, August 05, 2011 3:40 AM:
On Thu, Aug 04, 2011 at 05:00:17PM -0600, Stephen Warren wrote:
In http://www.spinics.net/lists/linux-tegra/msg01731.html, Mark Brown pointed out that it was a little silly forcing every board or driver to gpio_request() a GPIO that is later converted to an IRQ, and passed to request_irq. The first patch in this series instead makes the core IRQ code perform these calls when appropriate, to avoid duplicating it everywhere.
Trying to go from IRQ to GPIO is not a good idea - most of the IRQ <-> GPIO macros we have today are just plain broken. Many of them just add or subtract a constant, which means non-GPIO IRQs have an apparant GPIO number too. Couple this with the fact that all positive GPIO numbers are valid, and this is a recipe for wrong GPIOs getting used and GPIOs being requested for non-GPIO IRQs.
I think this was also discussed in the past, and the conclusion was that IRQs should be kept separate from GPIOs. Maybe views have changed since then...
However, if we do want to do this, then it would be much better to provide a new API for requesting GPIO IRQs, eg:
gpio_request_irq()
which would wrap around request_threaded_irq(), takes a GPIO number, does the GPIO->IRQ conversion internally, and whatever GPIO setup is required. Something like this:
With that approach, drivers need to explicitly know whether they're passed a GPIO or an IRQ, and do something different, or they need to choose to only accept a GPIO or IRQ.
You completely missed the biggest reason why your approach is broken.
No, I didn't.
Yes you did.
I was discussing whether an alternative API for IRQ registration would work, and I was pointing out some problems with it.
That has nothing to do with whether my original proposal is workable.
And that proves that you missed the point. I am suggesting an alternative solution precisely because your original proposal is unworkable.