All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mauro Carvalho Chehab <mchehab@redhat.com>
To: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Rob Landley <rob@landley.net>,
	Benoit Thebaudeau <benoit.thebaudeau@advansee.com>,
	David Hardeman <david@hardeman.nu>,
	Trilok Soni <tsoni@codeaurora.org>,
	devicetree-discuss@lists.ozlabs.org,
	linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH RESEND] media: rc: gpio-ir-recv: add support for device tree parsing
Date: Fri, 8 Feb 2013 15:57:07 -0200	[thread overview]
Message-ID: <20130208155707.65a0fbab@redhat.com> (raw)
In-Reply-To: <5112905E.3020400@gmail.com>

Em Wed, 06 Feb 2013 18:18:22 +0100
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> escreveu:

> On 02/06/2013 02:48 PM, Sylwester Nawrocki wrote:
> > On 02/06/2013 09:03 AM, Sebastian Hesselbarth wrote:
> >> 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 optional properties allow linux specific support for rc
> >> protocols and 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@gmail.com>
> >> ---
> > ...
> >> 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..937760c
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/gpio-ir-receiver.txt
> >> @@ -0,0 +1,20 @@
> >> +Device-Tree bindings for GPIO IR receiver
> >> +
> >> +Required properties:
> >> +	- compatible = "gpio-ir-receiver";
> >> +	- gpios: OF device-tree gpio specification.
> >> +
> >> +Optional properties:
> >> +	- linux,allowed-rc-protocols: Linux specific u64 bitmask of allowed
> >> +	    rc protocols.
> >
> > You likely need to specify in these bindings documentation which bit
> > corresponds to which RC protocol.
> >
> > I'm not very familiar with the RC internals, but why it has to be
> > specified statically in the device tree, when decoding seems to be
> > mostly software defined ? I might be missing something though..
> 
> Sylwester,
> 
> I am not familiar with RC internals either. Maybe somebody with more
> insight in media/rc can clarify the specific needs for the rc subsystem.
> I was just transferring the DT support approach taken by gpio_keys to
> gpio_ir_recv as I will be using it on mach-dove/cubox soon.

The allowed rc protocol field are there for devices with hardware IR
support, where only a limited set of remote protocols can be decoded.

For software decoders RC_BIT_ALL is the proper setup. Users of course
can change it via sysfs at runtime, or a software decoder may be
disabled at compilation time by not selecting its CONFIG_* var.

> > Couldn't this be configured at run time, with all protocols allowed
> > as the default ?
> 
> Actually, this is how the internal rc code works. If there is nothing
> defined for allowed_protocols it assumes that all protocols are supported.
> That is why above node properties are optional.
> 
> About the binding documentation of allowed_protocols, rc_map, or the
> default behavior of current linux code, I don't think they will stay
> in-sync for long. 

Why not? The rc_map name is used either by Kernelspace or by Userspace,
in order to provide the IR keycode name that matches a given keytable.

There's no plans to change it, even in the long term.

Regards,
Mauro.

-- 

Cheers,
Mauro

  reply	other threads:[~2013-02-08 17:57 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-28 19:07 [PATCH] media: rc: gpio-ir-recv: add support for device tree parsing Sebastian Hesselbarth
2013-02-06  8:03 ` [PATCH RESEND] " Sebastian Hesselbarth
2013-02-06 13:48   ` Sylwester Nawrocki
2013-02-06 17:18     ` Sebastian Hesselbarth
2013-02-08 17:57       ` Mauro Carvalho Chehab [this message]
2013-02-08 18:12         ` Sebastian Hesselbarth
2013-02-08 19:06           ` Mauro Carvalho Chehab
2013-02-08 19:03       ` Sylwester Nawrocki
2013-02-08 20:38   ` [PATCH v2] " Sebastian Hesselbarth
2013-02-08 21:26     ` Sylwester Nawrocki
2013-02-08 21:36       ` Sebastian Hesselbarth
2013-02-08 21:52         ` Sylwester Nawrocki
2013-02-08 22:47     ` [PATCH v3] " Sebastian Hesselbarth
2013-02-09  0:03     ` [PATCH v2] " Mauro Carvalho Chehab
2013-02-09  0:45       ` Sebastian Hesselbarth
2013-02-09 13:41         ` Mauro Carvalho Chehab
2013-02-09 17:05         ` Sylwester Nawrocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130208155707.65a0fbab@redhat.com \
    --to=mchehab@redhat.com \
    --cc=benoit.thebaudeau@advansee.com \
    --cc=david@hardeman.nu \
    --cc=devicetree-discuss@lists.ozlabs.org \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=s.nawrocki@samsung.com \
    --cc=sebastian.hesselbarth@gmail.com \
    --cc=tsoni@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.