Allow use GPIO for IR remote receive on Odroid C2. #121
Conversation
The current definition is weird, and produce lots of sparse warnings: drivers/media/i2c/cx25840/cx25840-ir.c:448 txclk_tx_s_max_pulse_width() warn: impossible condition '(ns > 4294967295) => (0-u32max > u32max)' drivers/media/i2c/cx25840/cx25840-ir.c:461 rxclk_rx_s_max_pulse_width() warn: impossible condition '(ns > 4294967295) => (0-u32max > u32max)' drivers/media/i2c/cx25840/cx25840-ir.c:706 cx25840_ir_rx_read() warn: impossible condition '(v > 4294967295) => (0-u32max > u32max)' drivers/media/pci/ivtv/ivtv-queue.c:145 ivtv_queue_move() error: we previously assumed 'steal' could be null (see line 138) drivers/media/rc/streamzap.c:155 sz_push_full_pulse() warn: impossible condition '(rawir.duration > 4294967295) => (0-u32max > u32max)' drivers/media/rc/streamzap.c:169 sz_push_full_pulse() warn: impossible condition '(rawir.duration > 4294967295) => (0-u32max > u32max)' drivers/media/rc/redrat3.c:325 redrat3_us_to_len() warn: impossible condition '(microsec > 4294967295) => (0-u32max > u32max)' drivers/media/rc/redrat3.c:383 redrat3_process_ir_data() warn: impossible condition '(rawir.duration > 4294967295) => (0-u32max > u32max)' drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3676 pvr2_send_request_ex() error: we previously assumed 'write_data' could be null (see line 3648) drivers/media/usb/pvrusb2/pvrusb2-hdw.c:3829 pvr2_send_request_ex() error: we previously assumed 'read_data' could be null (see line 3649) drivers/media/pci/cx23885/cx23888-ir.c:463 txclk_tx_s_max_pulse_width() warn: impossible condition '(ns > 4294967295) => (0-u32max > u32max)' drivers/media/pci/cx23885/cx23888-ir.c:476 rxclk_rx_s_max_pulse_width() warn: impossible condition '(ns > 4294967295) => (0-u32max > u32max)' drivers/media/pci/cx23885/cx23888-ir.c:696 cx23888_ir_rx_read() warn: impossible condition '(v > 4294967295) => (0-u32max > u32max)' Use a more realistic value for it. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 6b20cf3)
A default timeout value of 125 ms should work for all decoders. Declare a constant to help standardize its' use. Signed-off-by: Eric Nelson <eric@nelint.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit c8e1bbc)
This macro is now part of the core. Remove from Siano driver. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 850c8a7)
Many decoders require a trailing space (period without IR illumination) to be delivered before completing a decode. Since the gpio-ir-recv driver only delivers events on gpio transitions, a single IR symbol (caused by a quick touch on an IR remote) will not be properly decoded without the use of a timer to flush the tail end state of the IR receiver. This patch initializes and uses a timer and the timeout field of rcdev to complete the stream and allow decode. The timeout can be overridden through the use of the LIRC_SET_REC_TIMEOUT ioctl. Signed-off-by: Eric Nelson <eric@nelint.com> Acked-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> (cherry picked from commit 3fb136f)
According to the documentation, a timeout of 0 turns off timeouts, which is not the case. Signed-off-by: Sean Young <sean@mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> (cherry picked from commit ee5310e)
This driver helps to register the device of GPIO based IR receiver, "gpio-ir-recv" with the gpio number and pulse trigger when driver is loading. For example, # modprobe gpio-ir-recv # modprobe gpioplug-ir-recv gpio_nr=249 active_low=1 Change-Id: I5c16a5b108fcd34d90885d37345c84aa0ac5cf9c (cherry picked from commit 4aed4fc)
|
Have you runtime tested this? From a quick glance the IR backports look fine but I guess probing gpio-ir-recv is going to fail as the meson pinctrl driver doesn't seem to implement to_irq https://github.com/LibreELEC/linux-amlogic/blob/amlogic-3.14.y/include/linux/gpio/driver.h#L86 which is required for gpio_to_irq linux-amlogic/drivers/media/rc/gpio-ir-recv.c Line 191 in ada059e |
|
I tested whole package (with irq banks side-commit) couple days before. AFAIK, meson-ir shouldnt come into play, when using gpio-ir + gpioplug is meson-ir blacklisted.. |
|
Please confirm if the patches in this PR work, ideally both with DVB drivers enabled and disabled in LibreELEC. We don't have the hardware to check this ourselves and as the pinctrl/IRQ changes that you had in your previous PR #120 are neither in this PR nor in LibreELEC/LibreELEC.tv#3206 I suspect something might be missing and it won't work as is |
Allright I will try to differentiate patch and test that also. Take a while until I compile that and make some more tests (I am working on another things also) So do you think that those commits are bad somehow also? (@Kwiboo excludes those) 1 2 3 |
|
I can't comment on commits 2 and 3 (this is not exactly my area of expertise) but they seem to be incomplete, otherwise commit 1 would not be needed. Commit 1 definitely is an ugly workaround and won't work if you enable DVB drivers in LE (unless you adapt that patch so it can be added to the dvb drivers, which isn't worth the hassle IMO). It would be good if the Hardkernel folks worked with upstream and added the missing IRQ code bits to the meson pinctrl driver. Then we had a reference how a proper solution should look like and we could also be sure it'll still work in LE10 when we switch AML to upstream kernel and get rid of all the ugly out-of-tree vendor patches. |
|
I think that this "won't work if you enable DVB drivers in LE" is quite big problem, although it has far away from affecting majority of users propably. In the other hand, I can understand, that DVB drivers are not coming from HK. I am really trying to organize and make GPIO IR changes widelly avaible for users. Therefore I made a comprehensive comparation of amlogic kernels related to the GPIO IR possibilities: HK linux - odroidc2-3.14.y CoreELEC linux-amlogic amlogic-3.14-nougat Custom, implemented in CoreELEC: LibreELEC linux-amlogic Custom, not implemented in LibreELEC: But when we talking about LibreELEC and Odroid (C2), wouldnt make sense to use official HK linux amlogic for that device? I mean, would be ideal to keep up HK kernel and upstream (I will try to ask), but lets say they wont or dont wanna (some those Gpio changes are there for years), considering LibreELEC and images for Odroid C2 platform, I dont see anything wrong to profit from / use kernel, provided by HW manufacturer, to get best user experience? I will also ask CE devs to try push tuning into HK linux. |
|
Adding separate (vendor) kernel versions, is not really an option as this creates a huge maintenance overhead. Each kernel needs separate testing, fixing, backporting of improvements etc so we aim to reduce the total number of kernels used in LE, not increase it further. AML 3.14 is basically on life support and we are careful not to add stuff which could break thing or cause major (support) headaches. |
Adding gpioplug-ir-recv is module to allow receive IR from remote through IR diode connected to the GPIO pins (together with gpio-ir-recv, which is already present on LibreELEC). Without gpioplug is not possible to use IR RX through GPIO. Gpioplug-ir-recv is originated by Cloudshell, and later on taken by HK developers as officialy supported method to support IR GPIO receive: 1 / 2 / 3
Cherrypicking from CoreELEC/linux-amlogic@03f89a8...9d8ccf4.
backporting the flush timer for gpio-ir-recv
Needed for LibreELEC/LibreELEC.tv#3206