[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130208220357.198c313c@redhat.com>
Date: Fri, 8 Feb 2013 22:03:57 -0200
From: Mauro Carvalho Chehab <mchehab@...hat.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
Cc: Grant Likely <grant.likely@...retlab.ca>,
Rob Herring <rob.herring@...xeda.com>,
Rob Landley <rob@...dley.net>,
Benoit Thebaudeau <benoit.thebaudeau@...ansee.com>,
David Hardeman <david@...deman.nu>,
Trilok Soni <tsoni@...eaurora.org>,
Sylwester Nawrocki <s.nawrocki@...sung.com>,
Matus Ujhelyi <ujhelyi.m@...il.com>,
devicetree-discuss@...ts.ozlabs.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-media@...r.kernel.org
Subject: Re: [PATCH v2] media: rc: gpio-ir-recv: add support for device tree
parsing
Em Fri, 8 Feb 2013 21:38:07 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@...il.com> escreveu:
> This patch adds device tree parsing for gpio_ir_recv platform_data and
> the mandatory binding documentation. It basically follows what we already
> have for e.g. gpio_keys. All required device tree properties are OS
> independent but an optional property allow linux specific support for rc
> maps.
>
> There was a similar patch sent by Matus Ujhelyi but that discussion
> died after the first reviews.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
> ---
> Changelog
>
> v1->v2:
> - get rid of ptr returned by _get_devtree_pdata()
> - check for of_node instead for NULL pdata
> - remove unneccessary double check for gpios property
> - remove unneccessary #ifdef CONFIG_OF around match table
>
> Cc: Grant Likely <grant.likely@...retlab.ca>
> Cc: Rob Herring <rob.herring@...xeda.com>
> Cc: Rob Landley <rob@...dley.net>
> Cc: Mauro Carvalho Chehab <mchehab@...hat.com>
> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@...il.com>
> Cc: Benoit Thebaudeau <benoit.thebaudeau@...ansee.com>
> Cc: David Hardeman <david@...deman.nu>
> Cc: Trilok Soni <tsoni@...eaurora.org>
> Cc: Sylwester Nawrocki <s.nawrocki@...sung.com>
> Cc: Matus Ujhelyi <ujhelyi.m@...il.com>
> Cc: devicetree-discuss@...ts.ozlabs.org
> Cc: linux-doc@...r.kernel.org
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-media@...r.kernel.org
> ---
> .../devicetree/bindings/media/gpio-ir-receiver.txt | 16 ++++++
> drivers/media/rc/gpio-ir-recv.c | 57 ++++++++++++++++++++
> 2 files changed, 73 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
>
> diff --git a/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> new file mode 100644
> index 0000000..8589f30
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> @@ -0,0 +1,16 @@
> +Device-Tree bindings for GPIO IR receiver
> +
> +Required properties:
> + - compatible = "gpio-ir-receiver";
> + - gpios: OF device-tree gpio specification.
> +
> +Optional properties:
> + - linux,rc-map-name: Linux specific remote control map name.
> +
> +Example node:
> +
> + ir: ir-receiver {
> + compatible = "gpio-ir-receiver";
> + gpios = <&gpio0 19 1>;
> + linux,rc-map-name = "rc-rc6-mce";
Please change this to:
linux,rc-map-name = RC_MAP_RC6_MCE;
(as defined at include/media/rc-map.h).
The idea of having those strings defined at the same header file is to:
- make sure that the same keyboard is spelled at the same way on
all places;
- avoid people to duplicate IR keytables, using different names;
- help userspace to get the right table. In the future, the
plan is to remove all keytables from kernelspace, keeping there just the
name of the keytable. The existing userspace code (ir-keytables, part
of v4l-utils) use the keytable name to dynamically load the right table
in runtime and to switch the IR core to only handle the protocol that
it is associated with the loaded keytable.
Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists