On 11/29/2013 02:45 PM, Lars-Peter Clausen wrote:
On 11/29/2013 11:37 AM, Linus Walleij wrote:
On Wed, Nov 27, 2013 at 5:40 PM, Laurent Pinchart
<laurent.pinchart@xxxxxxxxxxxxxxxx> wrote:
(CC'ing Linus Walleij, Wolfram Sang and LAKML)
On Wednesday 27 November 2013 16:32:01 Valentine wrote:
On 11/27/2013 04:14 PM, Hans Verkuil wrote:
Yes, of course. Although the adv7604 has two interrupt lines, so if you
would want to use the second, then that would still have to be specified
through the platform data.
In this case the GPIO should be configured as interrupt source in the
platform code. But this doesn't seem to work with R-Car GPIO since it is
initialized later, and the gpio_to_irq function returns an error.
The simplest way seemed to use a GPIO number in the platform data
to have the adv driver configure the pin and request the IRQ.
I'm not sure how to easily defer I2C board info IRQ setup (and
camera/subdevice probing) until GPIO driver is ready.
Good question. This looks like a core problem to me, not specific to the
adv761x driver. Linus, Wolfram, do you have a comment on that ?
So we recently has a large-ish discussion involving me, Stephen
Warren and Jean-Christophe, leading to the conclusion that the
gpio_chip and irq_chip abstractions are orthogonal, and you should
be able to request a GPIO or IRQ without interacting with the other
subsystem.
Specifically you should be able to request an IRQ from the irq_chip
portions of the driver without first requesting the GPIO line.
Some drivers already support this.
We added an internal API to the gpiolib so that the lib, *internally*
can be made aware that a certain GPIO line is used for IRQs,
see commit d468bf9ecaabd3bf3a6134e5a369ced82b1d1ca1
"gpio: add API to be strict about GPIO IRQ usage"
So I guess the answer to the question is something like, fix
the GPIO driver to stop requiring the GPIO lines to be requested
and configured before being used as IRQs, delete that code,
and while you're at it add a call to gpiod_lock_as_irq()
to your GPIO driver in the right spot: examples are on the
mailing list and my mark-irqs branch in the GPIO tree.
As far as I understand it this already works more or less with the driver.
The problem is that the IRQ numbers are dynamically allocated, while the
GPIO numbers apparently are not. So the board code knows the the GPIO number
at compile time and can pass this to the diver which then does a gpio_to_irq
to lookup the IRQ number.
This is correct.
This of course isn't really a problem with
devicetree, but only with platform board code.
I'm not sure what's the difference here and why it is not a problem with devicetree?
The other problem with R-Car GPIO driver is that it apparently does not support level IRQs.
- Lars
Thanks,
Val.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
