Em Wed, 06 Feb 2013 18:18:22 +0100 Sebastian Hesselbarth <sebastian.hesselbarth@xxxxxxxxx> 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@xxxxxxxxx> > >> --- > > ... > >> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
