On Thu, Nov 14, 2013 at 09:46:48PM +0000, Marek Belisko wrote:
> Signed-off-by: Marek Belisko <marek@xxxxxxxxxxxxx>
> ---
> Documentation/devicetree/bindings/misc/bmp085.txt | 8 ++++
> drivers/misc/bmp085.c | 53 ++++++++++++++++++++---
> 2 files changed, 55 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt
> index 91dfda2..c6033d5 100644
> --- a/Documentation/devicetree/bindings/misc/bmp085.txt
> +++ b/Documentation/devicetree/bindings/misc/bmp085.txt
> @@ -8,6 +8,9 @@ Optional properties:
> - temp-measurement-period: temperature measurement period (milliseconds)
> - default-oversampling: default oversampling value to be used at startup,
> value range is 0-3 with rising sensitivity.
> +- gpio: if device is using EOC irq line gpio can be specified to setup interrupt
> + handling
> +- irq: interrupt with no gpio
>
> Example:
>
> @@ -17,4 +20,9 @@ pressure@77 {
> chip-id = <10>;
> temp-measurement-period = <100>;
> default-oversampling = <2>;
> + gpio = <&gpio0 17 0>;
> +
> + OR
> +
> + irq = <75>;
There's some contention over the description of gpio-based IRQs in DT.
>From the point of view of the device there is a logical IRQ output; the
fact that this happens to be wired up to a GPIO pin that can happen to
generate interrupts isn't anything to do with the device itself. There
are plenty of device we have now whose interrupt lines could be wired to
GPIOs. I see no reason to extend their bindings to support explicit
GPIOs for IRQs, and I see no reason the driver should have to handle
this.
It would be far nicer for the device binding to just have the interrupts
property, and for the gpio controller to act as an interrupt-controller,
with the appropriate pin management.
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
