* Trying to use IR driver for my SoC @ 2017-06-29 15:29 Mason 2017-06-29 15:35 ` Mason 2017-06-29 15:55 ` Sean Young 0 siblings, 2 replies; 12+ messages in thread From: Mason @ 2017-06-29 15:29 UTC (permalink / raw) To: linux-media; +Cc: Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic Hello, I'm trying to use an IR driver written for my SoC: https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c I added these options to my defconfig: +CONFIG_MEDIA_SUPPORT=y +CONFIG_MEDIA_RC_SUPPORT=y +CONFIG_RC_DEVICES=y +CONFIG_IR_TANGO=y (I don't think I need the RC decoders, because the HW is supposed to support HW decoding of NEC, RC5, RC6). These are the logs printed at boot: [ 1.827842] IR NEC protocol handler initialized [ 1.832407] IR RC5(x/sz) protocol handler initialized [ 1.837491] IR RC6 protocol handler initialized [ 1.842049] IR JVC protocol handler initialized [ 1.846606] IR Sony protocol handler initialized [ 1.851248] IR SANYO protocol handler initialized [ 1.855979] IR Sharp protocol handler initialized [ 1.860708] IR MCE Keyboard/mouse protocol handler initialized [ 1.866575] IR XMP protocol handler initialized [ 1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21 [ 1.878241] Registered IR keymap rc-empty [ 1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0 [ 1.889473] tango_ir_open [ 1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 I was naively expecting some kind of dev/input/event0 node I could cat to grab all the remote control key presses. But I don't see anything relevant in /dev /sys/devices/platform/soc/10518.ir/rc/rc0/input0$ ls -l total 0 drwxr-xr-x 2 root root 0 Jan 1 00:00 capabilities lrwxrwxrwx 1 root root 0 Jan 1 00:07 device -> ../../rc0 drwxr-xr-x 2 root root 0 Jan 1 00:07 id -r--r--r-- 1 root root 4096 Jan 1 00:07 modalias -r--r--r-- 1 root root 4096 Jan 1 00:00 name -r--r--r-- 1 root root 4096 Jan 1 00:07 phys -r--r--r-- 1 root root 4096 Jan 1 00:00 properties lrwxrwxrwx 1 root root 0 Jan 1 00:07 subsystem -> ../../../../../../../class/input -rw-r--r-- 1 root root 4096 Jan 1 00:00 uevent -r--r--r-- 1 root root 4096 Jan 1 00:07 uniq $ cat * cat: read error: Is a directory cat: read error: Is a directory cat: read error: Is a directory input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw tango-ir tango-ir/input0 0 cat: read error: Is a directory PRODUCT=0/0/0/0 NAME="tango-ir" PHYS="tango-ir/input0" PROP=0 EV=100013 KEY=1000000 0 0 0 0 MSC=10 MODALIAS=input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw The IR interrupt count remains at 0, even I use the RC nearby. (It works in a legacy system, using a different driver.) I suppose I am missing some important piece of the puzzle? I hope someone can point me in the right direction. Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 15:29 Trying to use IR driver for my SoC Mason @ 2017-06-29 15:35 ` Mason 2017-06-29 15:55 ` Sean Young 1 sibling, 0 replies; 12+ messages in thread From: Mason @ 2017-06-29 15:35 UTC (permalink / raw) To: linux-media; +Cc: Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On 29/06/2017 17:29, Mason wrote: > I suppose I am missing some important piece of the puzzle? > I hope someone can point me in the right direction. FWIW, $ ir-keytable -v Found device /sys/class/rc/rc0/ Input sysfs node is /sys/class/rc/rc0/input0/ Couldn't find any node at /sys/class/rc/rc0/input0/event*. Segmentation fault $ ir-keytable --version IR keytable control version 1.12.2 Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 15:29 Trying to use IR driver for my SoC Mason 2017-06-29 15:35 ` Mason @ 2017-06-29 15:55 ` Sean Young 2017-06-29 16:25 ` Mason 1 sibling, 1 reply; 12+ messages in thread From: Sean Young @ 2017-06-29 15:55 UTC (permalink / raw) To: Mason; +Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic Hello, On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote: > I'm trying to use an IR driver written for my SoC: > https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c > > I added these options to my defconfig: > > +CONFIG_MEDIA_SUPPORT=y > +CONFIG_MEDIA_RC_SUPPORT=y > +CONFIG_RC_DEVICES=y > +CONFIG_IR_TANGO=y > > (I don't think I need the RC decoders, because the HW is supposed > to support HW decoding of NEC, RC5, RC6). I haven't seen this driver before, what hardware is this for? > These are the logs printed at boot: > > [ 1.827842] IR NEC protocol handler initialized > [ 1.832407] IR RC5(x/sz) protocol handler initialized > [ 1.837491] IR RC6 protocol handler initialized > [ 1.842049] IR JVC protocol handler initialized > [ 1.846606] IR Sony protocol handler initialized > [ 1.851248] IR SANYO protocol handler initialized > [ 1.855979] IR Sharp protocol handler initialized > [ 1.860708] IR MCE Keyboard/mouse protocol handler initialized > [ 1.866575] IR XMP protocol handler initialized > [ 1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21 > [ 1.878241] Registered IR keymap rc-empty > [ 1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0 > [ 1.889473] tango_ir_open > [ 1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 > > > I was naively expecting some kind of dev/input/event0 node > I could cat to grab all the remote control key presses. > > But I don't see anything relevant in /dev Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices? > /sys/devices/platform/soc/10518.ir/rc/rc0/input0$ ls -l > total 0 > drwxr-xr-x 2 root root 0 Jan 1 00:00 capabilities > lrwxrwxrwx 1 root root 0 Jan 1 00:07 device -> ../../rc0 > drwxr-xr-x 2 root root 0 Jan 1 00:07 id > -r--r--r-- 1 root root 4096 Jan 1 00:07 modalias > -r--r--r-- 1 root root 4096 Jan 1 00:00 name > -r--r--r-- 1 root root 4096 Jan 1 00:07 phys > -r--r--r-- 1 root root 4096 Jan 1 00:00 properties > lrwxrwxrwx 1 root root 0 Jan 1 00:07 subsystem -> ../../../../../../../class/input > -rw-r--r-- 1 root root 4096 Jan 1 00:00 uevent > -r--r--r-- 1 root root 4096 Jan 1 00:07 uniq > > $ cat * > cat: read error: Is a directory > cat: read error: Is a directory > cat: read error: Is a directory > input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw > tango-ir > tango-ir/input0 > 0 > cat: read error: Is a directory > PRODUCT=0/0/0/0 > NAME="tango-ir" > PHYS="tango-ir/input0" > PROP=0 > EV=100013 > KEY=1000000 0 0 0 0 > MSC=10 > MODALIAS=input:b0000v0000p0000e0000-e0,1,4,14,k98,ram4,lsfw > > > The IR interrupt count remains at 0, even I use the RC nearby. > (It works in a legacy system, using a different driver.) By opening the /dev/input/event0 device, tango_ir_open() gets called which presumably enables interrupts or IR decoding for the device. It's hard to say without knowing anything about the soc. It would be nice to see this driver merged to mainline. Sean ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 15:55 ` Sean Young @ 2017-06-29 16:25 ` Mason 2017-06-29 17:50 ` Sean Young 0 siblings, 1 reply; 12+ messages in thread From: Mason @ 2017-06-29 16:25 UTC (permalink / raw) To: Sean Young Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic Hello, On 29/06/2017 17:55, Sean Young wrote: > On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote: > >> I'm trying to use an IR driver written for my SoC: >> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c >> >> I added these options to my defconfig: >> >> +CONFIG_MEDIA_SUPPORT=y >> +CONFIG_MEDIA_RC_SUPPORT=y >> +CONFIG_RC_DEVICES=y >> +CONFIG_IR_TANGO=y >> >> (I don't think I need the RC decoders, because the HW is supposed >> to support HW decoding of NEC, RC5, RC6). > > I haven't seen this driver before, what hardware is this for? Sigma Designs tango3/tango4 (SMP86xx and SMP87xx) >> These are the logs printed at boot: >> >> [ 1.827842] IR NEC protocol handler initialized >> [ 1.832407] IR RC5(x/sz) protocol handler initialized >> [ 1.837491] IR RC6 protocol handler initialized >> [ 1.842049] IR JVC protocol handler initialized >> [ 1.846606] IR Sony protocol handler initialized >> [ 1.851248] IR SANYO protocol handler initialized >> [ 1.855979] IR Sharp protocol handler initialized >> [ 1.860708] IR MCE Keyboard/mouse protocol handler initialized >> [ 1.866575] IR XMP protocol handler initialized >> [ 1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21 >> [ 1.878241] Registered IR keymap rc-empty >> [ 1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0 >> [ 1.889473] tango_ir_open >> [ 1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 >> >> >> I was naively expecting some kind of dev/input/event0 node >> I could cat to grab all the remote control key presses. >> >> But I don't see anything relevant in /dev > > Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices? I was indeed missing CONFIG_INPUT_EVDEV. As for udev: [ 2.199642] udevd[960]: starting eudev-3.2.1 $ ls -l /dev/input/ total 0 drwxr-xr-x 2 root root 60 Jan 1 00:00 by-path crw-rw---- 1 root input 13, 64 Jan 1 00:00 event0 But still no cookie: $ cat /dev/input/event0 remains mute :-( $ ir-keytable -v -t Found device /sys/class/rc/rc0/ Input sysfs node is /sys/class/rc/rc0/input0/ Event sysfs node is /sys/class/rc/rc0/input0/event0/ Parsing uevent /sys/class/rc/rc0/input0/event0/uevent /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-empty input device is /dev/input/event0 /sys/class/rc/rc0/protocols protocol rc-5 (disabled) /sys/class/rc/rc0/protocols protocol nec (disabled) /sys/class/rc/rc0/protocols protocol rc-6 (disabled) Opening /dev/input/event0 Input Protocol version: 0x00010001 Testing events. Please, press CTRL-C to abort. ^C Is rc-empty perhaps not the right choice? > By opening the /dev/input/event0 device, tango_ir_open() gets called which > presumably enables interrupts or IR decoding for the device. It's hard to > say without knowing anything about the soc. Actually tango_ir_open() is called at boot, before any process has a chance to open /dev/input/event0 [ 1.926730] [<c03cd9a4>] (tango_ir_open) from [<c03c8554>] (rc_open+0x44/0x6c) [ 1.933994] [<c03c8554>] (rc_open) from [<c03be890>] (input_open_device+0x74/0xac) [ 1.941610] [<c03be890>] (input_open_device) from [<c032f96c>] (kbd_connect+0x64/0x80) [ 1.949570] [<c032f96c>] (kbd_connect) from [<c03bf0dc>] (input_attach_handler+0x1bc/0x1f4) [ 1.957965] [<c03bf0dc>] (input_attach_handler) from [<c03bf58c>] (input_register_device+0x3b4/0x42c) [ 1.967234] [<c03bf58c>] (input_register_device) from [<c03c9be8>] (rc_register_device+0x2d8/0x52c) [ 1.976327] [<c03c9be8>] (rc_register_device) from [<c03cdcfc>] (tango_ir_probe+0x328/0x3a4) [ 1.984815] [<c03cdcfc>] (tango_ir_probe) from [<c03508b0>] (platform_drv_probe+0x34/0x6c) [ 1.993124] [<c03508b0>] (platform_drv_probe) from [<c034f360>] (really_probe+0x1c4/0x250) But I have a printk in the ISR, and it's obviously not called. > It would be nice to see this driver merged to mainline. +1 (especially if I can get it to work) Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 16:25 ` Mason @ 2017-06-29 17:50 ` Sean Young 2017-06-29 19:12 ` Mason 2017-07-05 12:55 ` Mason 0 siblings, 2 replies; 12+ messages in thread From: Sean Young @ 2017-06-29 17:50 UTC (permalink / raw) To: Mason; +Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote: > On 29/06/2017 17:55, Sean Young wrote: > > > On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote: > > > >> I'm trying to use an IR driver written for my SoC: > >> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c > >> > >> I added these options to my defconfig: > >> > >> +CONFIG_MEDIA_SUPPORT=y > >> +CONFIG_MEDIA_RC_SUPPORT=y > >> +CONFIG_RC_DEVICES=y > >> +CONFIG_IR_TANGO=y > >> > >> (I don't think I need the RC decoders, because the HW is supposed > >> to support HW decoding of NEC, RC5, RC6). > > > > I haven't seen this driver before, what hardware is this for? > > Sigma Designs tango3/tango4 (SMP86xx and SMP87xx) > > >> These are the logs printed at boot: > >> > >> [ 1.827842] IR NEC protocol handler initialized > >> [ 1.832407] IR RC5(x/sz) protocol handler initialized > >> [ 1.837491] IR RC6 protocol handler initialized > >> [ 1.842049] IR JVC protocol handler initialized > >> [ 1.846606] IR Sony protocol handler initialized > >> [ 1.851248] IR SANYO protocol handler initialized > >> [ 1.855979] IR Sharp protocol handler initialized > >> [ 1.860708] IR MCE Keyboard/mouse protocol handler initialized > >> [ 1.866575] IR XMP protocol handler initialized > >> [ 1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21 > >> [ 1.878241] Registered IR keymap rc-empty > >> [ 1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0 > >> [ 1.889473] tango_ir_open > >> [ 1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 > >> > >> > >> I was naively expecting some kind of dev/input/event0 node > >> I could cat to grab all the remote control key presses. > >> > >> But I don't see anything relevant in /dev > > > > Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices? > > I was indeed missing CONFIG_INPUT_EVDEV. > > As for udev: > [ 2.199642] udevd[960]: starting eudev-3.2.1 > > $ ls -l /dev/input/ > total 0 > drwxr-xr-x 2 root root 60 Jan 1 00:00 by-path > crw-rw---- 1 root input 13, 64 Jan 1 00:00 event0 > > But still no cookie: > $ cat /dev/input/event0 > remains mute :-( > > $ ir-keytable -v -t > Found device /sys/class/rc/rc0/ > Input sysfs node is /sys/class/rc/rc0/input0/ > Event sysfs node is /sys/class/rc/rc0/input0/event0/ > Parsing uevent /sys/class/rc/rc0/input0/event0/uevent > /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 > /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 > /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 > Parsing uevent /sys/class/rc/rc0/uevent > /sys/class/rc/rc0/uevent uevent NAME=rc-empty > input device is /dev/input/event0 > /sys/class/rc/rc0/protocols protocol rc-5 (disabled) > /sys/class/rc/rc0/protocols protocol nec (disabled) > /sys/class/rc/rc0/protocols protocol rc-6 (disabled) > Opening /dev/input/event0 > Input Protocol version: 0x00010001 > Testing events. Please, press CTRL-C to abort. > ^C > > Is rc-empty perhaps not the right choice? rc-empty means there is no mapping from scancode to keycode. When you run "ir-keytable -v -t" you should at see scancodes when the driver generates them with rc_keydown(). > > By opening the /dev/input/event0 device, tango_ir_open() gets called which > > presumably enables interrupts or IR decoding for the device. It's hard to > > say without knowing anything about the soc. > > Actually tango_ir_open() is called at boot, before any process > has a chance to open /dev/input/event0 > > [ 1.926730] [<c03cd9a4>] (tango_ir_open) from [<c03c8554>] (rc_open+0x44/0x6c) > [ 1.933994] [<c03c8554>] (rc_open) from [<c03be890>] (input_open_device+0x74/0xac) > [ 1.941610] [<c03be890>] (input_open_device) from [<c032f96c>] (kbd_connect+0x64/0x80) > [ 1.949570] [<c032f96c>] (kbd_connect) from [<c03bf0dc>] (input_attach_handler+0x1bc/0x1f4) > [ 1.957965] [<c03bf0dc>] (input_attach_handler) from [<c03bf58c>] (input_register_device+0x3b4/0x42c) > [ 1.967234] [<c03bf58c>] (input_register_device) from [<c03c9be8>] (rc_register_device+0x2d8/0x52c) > [ 1.976327] [<c03c9be8>] (rc_register_device) from [<c03cdcfc>] (tango_ir_probe+0x328/0x3a4) > [ 1.984815] [<c03cdcfc>] (tango_ir_probe) from [<c03508b0>] (platform_drv_probe+0x34/0x6c) > [ 1.993124] [<c03508b0>] (platform_drv_probe) from [<c034f360>] (really_probe+0x1c4/0x250) Ah, that's interesting. The vt console taking a feed from the device, that makes sense. > But I have a printk in the ISR, and it's obviously not called. >From a cursory glance at the driver I can't see anything wrong. The only thing that stands out is RC5_TIME_BASE. If that is the bit length or shortest pulse/space? In the latter case it should be 888 usec. It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode. Failing that some documentation would be great :) > > It would be nice to see this driver merged to mainline. > > +1 (especially if I can get it to work) Sean ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 17:50 ` Sean Young @ 2017-06-29 19:12 ` Mason 2017-06-29 19:44 ` Sean Young 2017-07-05 12:55 ` Mason 1 sibling, 1 reply; 12+ messages in thread From: Mason @ 2017-06-29 19:12 UTC (permalink / raw) To: Sean Young Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On 29/06/2017 19:50, Sean Young wrote: > On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote: > >> $ ir-keytable -v -t >> Found device /sys/class/rc/rc0/ >> Input sysfs node is /sys/class/rc/rc0/input0/ >> Event sysfs node is /sys/class/rc/rc0/input0/event0/ >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >> Parsing uevent /sys/class/rc/rc0/uevent >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >> input device is /dev/input/event0 >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >> /sys/class/rc/rc0/protocols protocol nec (disabled) >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) I had overlooked this. Is it expected for these protocols to be marked as "disabled"? >> Opening /dev/input/event0 >> Input Protocol version: 0x00010001 >> Testing events. Please, press CTRL-C to abort. >> ^C >> >> Is rc-empty perhaps not the right choice? > > rc-empty means there is no mapping from scancode to keycode. When you > run "ir-keytable -v -t" you should at see scancodes when the driver > generates them with rc_keydown(). So the mapping can be done either in the kernel, or in user-space by the application consuming the scancodes, right? > From a cursory glance at the driver I can't see anything wrong. > > The only thing that stands out is RC5_TIME_BASE. If that is the bit > length or shortest pulse/space? In the latter case it should be 888 usec. Need to locate some docs. > It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode. What do you mean? How do I try them? > Failing that some documentation would be great :) I will try finding some. Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 19:12 ` Mason @ 2017-06-29 19:44 ` Sean Young 2017-07-10 8:40 ` Mason 0 siblings, 1 reply; 12+ messages in thread From: Sean Young @ 2017-06-29 19:44 UTC (permalink / raw) To: Mason; +Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote: > On 29/06/2017 19:50, Sean Young wrote: > > > On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote: > > > >> $ ir-keytable -v -t > >> Found device /sys/class/rc/rc0/ > >> Input sysfs node is /sys/class/rc/rc0/input0/ > >> Event sysfs node is /sys/class/rc/rc0/input0/event0/ > >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent > >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 > >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 > >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 > >> Parsing uevent /sys/class/rc/rc0/uevent > >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty > >> input device is /dev/input/event0 > >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) > >> /sys/class/rc/rc0/protocols protocol nec (disabled) > >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) > > I had overlooked this. Is it expected for these protocols > to be marked as "disabled"? Ah, good point, I forgot about that. :/ "ir-keytable -p all -t -v" should enable all protocols and test. > >> Opening /dev/input/event0 > >> Input Protocol version: 0x00010001 > >> Testing events. Please, press CTRL-C to abort. > >> ^C > >> > >> Is rc-empty perhaps not the right choice? > > > > rc-empty means there is no mapping from scancode to keycode. When you > > run "ir-keytable -v -t" you should at see scancodes when the driver > > generates them with rc_keydown(). > > So the mapping can be done either in the kernel, or in > user-space by the application consuming the scancodes, > right? That's right, although I do not know of any user-space application that does this; scancodes are mostly useful for debugging. > > From a cursory glance at the driver I can't see anything wrong. > > > > The only thing that stands out is RC5_TIME_BASE. If that is the bit > > length or shortest pulse/space? In the latter case it should be 888 usec. > > Need to locate some docs. > > > It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode. > > What do you mean? How do I try them? Well, presumably you're using a remote control for testing. It would be useful if you had remotes which could do all protocols that the IR receiver supports, so you can try all three of them. Another way of doing this is using an IR transmitter and using ir-ctl to send scancodes. Sean ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 19:44 ` Sean Young @ 2017-07-10 8:40 ` Mason 2017-07-11 18:35 ` Sean Young 0 siblings, 1 reply; 12+ messages in thread From: Mason @ 2017-07-10 8:40 UTC (permalink / raw) To: Sean Young Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On 29/06/2017 21:44, Sean Young wrote: > On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote: > >> On 29/06/2017 19:50, Sean Young wrote: >> >>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote: >>> >>>> $ ir-keytable -v -t >>>> Found device /sys/class/rc/rc0/ >>>> Input sysfs node is /sys/class/rc/rc0/input0/ >>>> Event sysfs node is /sys/class/rc/rc0/input0/event0/ >>>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >>>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >>>> Parsing uevent /sys/class/rc/rc0/uevent >>>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >>>> input device is /dev/input/event0 >>>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >>>> /sys/class/rc/rc0/protocols protocol nec (disabled) >>>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) >> >> I had overlooked this. Is it expected for these protocols >> to be marked as "disabled"? > > Ah, good point, I forgot about that. :/ > > "ir-keytable -p all -t -v" should enable all protocols and test. After hours of thrashing around, I finally figured out that the IRQ was misconfigured... Doh! Here's the output from pressing '1' for one second on the RC: # cat /dev/input/event0 | hexdump -vC 00000000 04 04 00 00 7a 08 07 00 04 00 04 00 41 cb 04 00 |....z.......A...| 00000010 04 04 00 00 7a 08 07 00 00 00 00 00 00 00 00 00 |....z...........| 00000020 04 04 00 00 f4 da 07 00 04 00 04 00 00 00 00 00 |................| 00000030 04 04 00 00 f4 da 07 00 00 00 00 00 00 00 00 00 |................| 00000040 04 04 00 00 f1 7f 09 00 04 00 04 00 00 00 00 00 |................| 00000050 04 04 00 00 f1 7f 09 00 00 00 00 00 00 00 00 00 |................| 00000060 04 04 00 00 f2 24 0b 00 04 00 04 00 00 00 00 00 |.....$..........| 00000070 04 04 00 00 f2 24 0b 00 00 00 00 00 00 00 00 00 |.....$..........| 00000080 04 04 00 00 f3 c9 0c 00 04 00 04 00 00 00 00 00 |................| 00000090 04 04 00 00 f3 c9 0c 00 00 00 00 00 00 00 00 00 |................| 000000a0 04 04 00 00 f6 6e 0e 00 04 00 04 00 00 00 00 00 |.....n..........| 000000b0 04 04 00 00 f6 6e 0e 00 00 00 00 00 00 00 00 00 |.....n..........| 000000c0 05 04 00 00 ba d1 00 00 04 00 04 00 00 00 00 00 |................| 000000d0 05 04 00 00 ba d1 00 00 00 00 00 00 00 00 00 00 |................| 000000e0 05 04 00 00 bb 76 02 00 04 00 04 00 00 00 00 00 |.....v..........| 000000f0 05 04 00 00 bb 76 02 00 00 00 00 00 00 00 00 00 |.....v..........| 00000100 05 04 00 00 bd 1b 04 00 04 00 04 00 00 00 00 00 |................| 00000110 05 04 00 00 bd 1b 04 00 00 00 00 00 00 00 00 00 |................| 00000120 05 04 00 00 be c0 05 00 04 00 04 00 00 00 00 00 |................| 00000130 05 04 00 00 be c0 05 00 00 00 00 00 00 00 00 00 |................| 00000140 05 04 00 00 c2 65 07 00 04 00 04 00 00 00 00 00 |.....e..........| 00000150 05 04 00 00 c2 65 07 00 00 00 00 00 00 00 00 00 |.....e..........| I'm not sure what these mean. There seems to be some kind of timestamp? And something else? How do I tell which protocol this RC is using? Repeating the test (pressing '1' for one second) with ir-keytable: # ir-keytable -p all -t -v Found device /sys/class/rc/rc0/ Input sysfs node is /sys/class/rc/rc0/input0/ Event sysfs node is /sys/class/rc/rc0/input0/event0/ Parsing uevent /sys/class/rc/rc0/input0/event0/uevent /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-empty input device is /dev/input/event0 /sys/class/rc/rc0/protocols protocol rc-5 (disabled) /sys/class/rc/rc0/protocols protocol nec (disabled) /sys/class/rc/rc0/protocols protocol rc-6 (disabled) Opening /dev/input/event0 Input Protocol version: 0x00010001 /sys/class/rc/rc0//protocols: Invalid argument Couldn't change the IR protocols Testing events. Please, press CTRL-C to abort. 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 1296.124872: event type EV_SYN(0x00). 1296.178753: event type EV_MSC(0x04): scancode = 0x00 1296.178753: event type EV_SYN(0x00). 1296.286526: event type EV_MSC(0x04): scancode = 0x00 1296.286526: event type EV_SYN(0x00). 1296.394303: event type EV_MSC(0x04): scancode = 0x00 1296.394303: event type EV_SYN(0x00). 1296.502081: event type EV_MSC(0x04): scancode = 0x00 1296.502081: event type EV_SYN(0x00). 1296.609857: event type EV_MSC(0x04): scancode = 0x00 1296.609857: event type EV_SYN(0x00). 1296.717635: event type EV_MSC(0x04): scancode = 0x00 1296.717635: event type EV_SYN(0x00). 1296.825412: event type EV_MSC(0x04): scancode = 0x00 1296.825412: event type EV_SYN(0x00). 1296.933189: event type EV_MSC(0x04): scancode = 0x00 1296.933189: event type EV_SYN(0x00). 1297.040967: event type EV_MSC(0x04): scancode = 0x00 1297.040967: event type EV_SYN(0x00). 1297.148745: event type EV_MSC(0x04): scancode = 0x00 1297.148745: event type EV_SYN(0x00). 1297.256522: event type EV_MSC(0x04): scancode = 0x00 1297.256522: event type EV_SYN(0x00). It looks like scancode 0x00 means "REPEAT" ? And 0x4cb41 would be '1' then? If I compile the legacy driver (which is much more cryptic) it outputs 04 cb 41 be So 0x4cb41 in common - plus a trailing 0xbe (what is that? Some kind of checksum perhaps?) (For '2', I get 04 cb 03 fc) I'm a bit confused between "protocols", "decoders", "scancodes", "keys", "keymaps". Is there some high-level doc somewhere? I found this, but it seems to dive straight into API details: https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/rc/remote_controllers.html I'll start a separate thread to discuss the available IR hardware on the board I'm using. Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-07-10 8:40 ` Mason @ 2017-07-11 18:35 ` Sean Young 2017-07-11 21:51 ` Mason 0 siblings, 1 reply; 12+ messages in thread From: Sean Young @ 2017-07-11 18:35 UTC (permalink / raw) To: Mason; +Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On Mon, Jul 10, 2017 at 10:40:04AM +0200, Mason wrote: > On 29/06/2017 21:44, Sean Young wrote: > > > On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote: > > > >> On 29/06/2017 19:50, Sean Young wrote: > >> > >>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote: > >>> > >>>> $ ir-keytable -v -t > >>>> Found device /sys/class/rc/rc0/ > >>>> Input sysfs node is /sys/class/rc/rc0/input0/ > >>>> Event sysfs node is /sys/class/rc/rc0/input0/event0/ > >>>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent > >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 > >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 > >>>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 > >>>> Parsing uevent /sys/class/rc/rc0/uevent > >>>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty > >>>> input device is /dev/input/event0 > >>>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) > >>>> /sys/class/rc/rc0/protocols protocol nec (disabled) > >>>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) > >> > >> I had overlooked this. Is it expected for these protocols > >> to be marked as "disabled"? > > > > Ah, good point, I forgot about that. :/ > > > > "ir-keytable -p all -t -v" should enable all protocols and test. > > After hours of thrashing around, I finally figured out that > the IRQ was misconfigured... Doh! > > Here's the output from pressing '1' for one second on the RC: > > # cat /dev/input/event0 | hexdump -vC > 00000000 04 04 00 00 7a 08 07 00 04 00 04 00 41 cb 04 00 |....z.......A...| -snip- It might be easier to use "ir-keytable -t" for this, or evtest. > I'm not sure what these mean. There seems to be some kind of > timestamp? And something else? You're reading "struct input_event" here, see the input api. > How do I tell which protocol > this RC is using? That's an awkward question to answer. This is not passed to user space at the moment, that's one of addition I want to make to the lirc user space api in the near future. For the moment I would suggest just putting printk() in your code when you call rc_keydown(). > Repeating the test (pressing '1' for one second) with ir-keytable: > > # ir-keytable -p all -t -v > Found device /sys/class/rc/rc0/ > Input sysfs node is /sys/class/rc/rc0/input0/ > Event sysfs node is /sys/class/rc/rc0/input0/event0/ > Parsing uevent /sys/class/rc/rc0/input0/event0/uevent > /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 > /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 > /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 > Parsing uevent /sys/class/rc/rc0/uevent > /sys/class/rc/rc0/uevent uevent NAME=rc-empty > input device is /dev/input/event0 > /sys/class/rc/rc0/protocols protocol rc-5 (disabled) > /sys/class/rc/rc0/protocols protocol nec (disabled) > /sys/class/rc/rc0/protocols protocol rc-6 (disabled) > Opening /dev/input/event0 > Input Protocol version: 0x00010001 > /sys/class/rc/rc0//protocols: Invalid argument > Couldn't change the IR protocols > Testing events. Please, press CTRL-C to abort. > 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 > 1296.124872: event type EV_SYN(0x00). > 1296.178753: event type EV_MSC(0x04): scancode = 0x00 > 1296.178753: event type EV_SYN(0x00). > 1296.286526: event type EV_MSC(0x04): scancode = 0x00 > 1296.286526: event type EV_SYN(0x00). > 1296.394303: event type EV_MSC(0x04): scancode = 0x00 > 1296.394303: event type EV_SYN(0x00). > 1296.502081: event type EV_MSC(0x04): scancode = 0x00 > 1296.502081: event type EV_SYN(0x00). > 1296.609857: event type EV_MSC(0x04): scancode = 0x00 > 1296.609857: event type EV_SYN(0x00). > 1296.717635: event type EV_MSC(0x04): scancode = 0x00 > 1296.717635: event type EV_SYN(0x00). > 1296.825412: event type EV_MSC(0x04): scancode = 0x00 > 1296.825412: event type EV_SYN(0x00). > 1296.933189: event type EV_MSC(0x04): scancode = 0x00 > 1296.933189: event type EV_SYN(0x00). > 1297.040967: event type EV_MSC(0x04): scancode = 0x00 > 1297.040967: event type EV_SYN(0x00). > 1297.148745: event type EV_MSC(0x04): scancode = 0x00 > 1297.148745: event type EV_SYN(0x00). > 1297.256522: event type EV_MSC(0x04): scancode = 0x00 > 1297.256522: event type EV_SYN(0x00). > > It looks like scancode 0x00 means "REPEAT" ? This looks like nec repeat to me; nec repeats are sent every 110ms; however when a repeat occurs, the driver should call rc_repeat(), sending a scancode of 0 won't work. > And 0x4cb41 would be '1' then? > > If I compile the legacy driver (which is much more cryptic) > it outputs 04 cb 41 be ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this into extended nec (so the driver should send RC_TYPE_NECX), see https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68 > So 0x4cb41 in common - plus a trailing 0xbe (what is that? > Some kind of checksum perhaps?) That's part of the nec protocol. > (For '2', I get 04 cb 03 fc) See http://www.sbprojects.com/knowledge/ir/nec.php > I'm a bit confused between "protocols", "decoders", "scancodes", > "keys", "keymaps". Is there some high-level doc somewhere? I don't think there is. The infrared led is either on or off[1], so an IR message is a series of pulses and spaces (pulse for IR on, space for IR absent). There are different protocols for encoding these IR messages, e.g. nec, rc5. When they are decoded, you end up with a scancode (32 bit number). The keymap maps scancodes to keys, so in your case we would want a keymap with: scancode 0x4cb41 = KEY_1 scancode 0x4cb03 = KEY_2 etc. Then KEY_1 will be reported to the input layer and you can use the remote as you would expect. The decoder can either be done in hardware (firmware?) and in software; in your case it is done in hardware. [1] Ignoring the carrier for simplicity, that rarely matters. > I found this, but it seems to dive straight into API details: > https://www.linuxtv.org/downloads/v4l-dvb-apis-new/uapi/rc/remote_controllers.html > > I'll start a separate thread to discuss the available IR hardware > on the board I'm using. Sean ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-07-11 18:35 ` Sean Young @ 2017-07-11 21:51 ` Mason 2017-07-12 7:21 ` Sean Young 0 siblings, 1 reply; 12+ messages in thread From: Mason @ 2017-07-11 21:51 UTC (permalink / raw) To: Sean Young Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On 11/07/2017 20:35, Sean Young wrote: > Mason wrote: > >> Repeating the test (pressing '1' for one second) with ir-keytable: >> >> # ir-keytable -p all -t -v >> Found device /sys/class/rc/rc0/ >> Input sysfs node is /sys/class/rc/rc0/input0/ >> Event sysfs node is /sys/class/rc/rc0/input0/event0/ >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >> Parsing uevent /sys/class/rc/rc0/uevent >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >> input device is /dev/input/event0 >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >> /sys/class/rc/rc0/protocols protocol nec (disabled) >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) >> Opening /dev/input/event0 >> Input Protocol version: 0x00010001 >> /sys/class/rc/rc0//protocols: Invalid argument >> Couldn't change the IR protocols >> Testing events. Please, press CTRL-C to abort. >> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 >> 1296.124872: event type EV_SYN(0x00). >> 1296.178753: event type EV_MSC(0x04): scancode = 0x00 >> 1296.178753: event type EV_SYN(0x00). >> 1296.286526: event type EV_MSC(0x04): scancode = 0x00 >> 1296.286526: event type EV_SYN(0x00). >> 1296.394303: event type EV_MSC(0x04): scancode = 0x00 >> 1296.394303: event type EV_SYN(0x00). >> 1296.502081: event type EV_MSC(0x04): scancode = 0x00 >> 1296.502081: event type EV_SYN(0x00). >> 1296.609857: event type EV_MSC(0x04): scancode = 0x00 >> 1296.609857: event type EV_SYN(0x00). >> 1296.717635: event type EV_MSC(0x04): scancode = 0x00 >> 1296.717635: event type EV_SYN(0x00). >> 1296.825412: event type EV_MSC(0x04): scancode = 0x00 >> 1296.825412: event type EV_SYN(0x00). >> 1296.933189: event type EV_MSC(0x04): scancode = 0x00 >> 1296.933189: event type EV_SYN(0x00). >> 1297.040967: event type EV_MSC(0x04): scancode = 0x00 >> 1297.040967: event type EV_SYN(0x00). >> 1297.148745: event type EV_MSC(0x04): scancode = 0x00 >> 1297.148745: event type EV_SYN(0x00). >> 1297.256522: event type EV_MSC(0x04): scancode = 0x00 >> 1297.256522: event type EV_SYN(0x00). >> >> It looks like scancode 0x00 means "REPEAT" ? > > This looks like nec repeat to me; nec repeats are sent every 110ms; > however when a repeat occurs, the driver should call rc_repeat(), > sending a scancode of 0 won't work. IIUC, the driver requires some fixup, to behave as user-space would expect; is that correct? Are you the reviewer for rc drivers? >> And 0x4cb41 would be '1' then? >> >> If I compile the legacy driver (which is much more cryptic) >> it outputs 04 cb 41 be > > ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this > into extended nec (so the driver should send RC_TYPE_NECX), see > https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68 Another required fixup IIUC, right? Thank you so much for all the insight you've provided. Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-07-11 21:51 ` Mason @ 2017-07-12 7:21 ` Sean Young 0 siblings, 0 replies; 12+ messages in thread From: Sean Young @ 2017-07-12 7:21 UTC (permalink / raw) To: Mason; +Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On Tue, Jul 11, 2017 at 11:51:02PM +0200, Mason wrote: > On 11/07/2017 20:35, Sean Young wrote: > > > Mason wrote: > > > >> Repeating the test (pressing '1' for one second) with ir-keytable: > >> > >> # ir-keytable -p all -t -v > >> Found device /sys/class/rc/rc0/ > >> Input sysfs node is /sys/class/rc/rc0/input0/ > >> Event sysfs node is /sys/class/rc/rc0/input0/event0/ > >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent > >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 > >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 > >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 > >> Parsing uevent /sys/class/rc/rc0/uevent > >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty > >> input device is /dev/input/event0 > >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) > >> /sys/class/rc/rc0/protocols protocol nec (disabled) > >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) > >> Opening /dev/input/event0 > >> Input Protocol version: 0x00010001 > >> /sys/class/rc/rc0//protocols: Invalid argument > >> Couldn't change the IR protocols > >> Testing events. Please, press CTRL-C to abort. > >> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 > >> 1296.124872: event type EV_SYN(0x00). > >> 1296.178753: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.178753: event type EV_SYN(0x00). > >> 1296.286526: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.286526: event type EV_SYN(0x00). > >> 1296.394303: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.394303: event type EV_SYN(0x00). > >> 1296.502081: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.502081: event type EV_SYN(0x00). > >> 1296.609857: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.609857: event type EV_SYN(0x00). > >> 1296.717635: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.717635: event type EV_SYN(0x00). > >> 1296.825412: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.825412: event type EV_SYN(0x00). > >> 1296.933189: event type EV_MSC(0x04): scancode = 0x00 > >> 1296.933189: event type EV_SYN(0x00). > >> 1297.040967: event type EV_MSC(0x04): scancode = 0x00 > >> 1297.040967: event type EV_SYN(0x00). > >> 1297.148745: event type EV_MSC(0x04): scancode = 0x00 > >> 1297.148745: event type EV_SYN(0x00). > >> 1297.256522: event type EV_MSC(0x04): scancode = 0x00 > >> 1297.256522: event type EV_SYN(0x00). > >> > >> It looks like scancode 0x00 means "REPEAT" ? > > > > This looks like nec repeat to me; nec repeats are sent every 110ms; > > however when a repeat occurs, the driver should call rc_repeat(), > > sending a scancode of 0 won't work. > > IIUC, the driver requires some fixup, to behave as user-space > would expect; is that correct? Yes, it does. > Are you the reviewer for rc drivers? Yes, I am. However there is plenty of knowledge on rc on this list. :) > >> And 0x4cb41 would be '1' then? > >> > >> If I compile the legacy driver (which is much more cryptic) > >> it outputs 04 cb 41 be > > > > ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this > > into extended nec (so the driver should send RC_TYPE_NECX), see > > https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68 > > Another required fixup IIUC, right? Yes, there is. > Thank you so much for all the insight you've provided. np. It's nice to see this driver mainlined. Thanks, Sean ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Trying to use IR driver for my SoC 2017-06-29 17:50 ` Sean Young 2017-06-29 19:12 ` Mason @ 2017-07-05 12:55 ` Mason 1 sibling, 0 replies; 12+ messages in thread From: Mason @ 2017-07-05 12:55 UTC (permalink / raw) To: Sean Young Cc: linux-media, Mauro Carvalho Chehab, Hans Verkuil, Thibaud Cornic On 29/06/2017 19:50, Sean Young wrote: > The only thing that stands out is RC5_TIME_BASE. If that is the bit > length or shortest pulse/space? In the latter case it should be 888 usec. IR_RC5_DECODER_CLK_DIV Length of 1 bit of the RC5 code in units of 27 MHz clks Default value = 0xbb86 => 1.778 ms #define RC5_TIME_BASE 1778 (time in microseconds apparently) clkdiv = clkrate * RC5_TIME_BASE / 1e6 = 48006 = 0xbb86 I don't really see the point of reprogramming the default value, though... I'm thinking GPIO directions might be misconfigured, which could explain why no IRQs are firing. Back to basics. Regards. ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-07-12 7:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-29 15:29 Trying to use IR driver for my SoC Mason 2017-06-29 15:35 ` Mason 2017-06-29 15:55 ` Sean Young 2017-06-29 16:25 ` Mason 2017-06-29 17:50 ` Sean Young 2017-06-29 19:12 ` Mason 2017-06-29 19:44 ` Sean Young 2017-07-10 8:40 ` Mason 2017-07-11 18:35 ` Sean Young 2017-07-11 21:51 ` Mason 2017-07-12 7:21 ` Sean Young 2017-07-05 12:55 ` Mason
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.