From: "Marko Mäkelä" <marko.makela@iki.fi>
To: Sean Young <sean@mess.org>
Cc: linux-media@vger.kernel.org
Subject: Re: [PATCH 2/2] media: rtl28xxu: improve IR receiver
Date: Mon, 27 Jun 2022 08:00:45 +0300 [thread overview]
Message-ID: <Yrk5faigZEiZ7KXk@jyty> (raw)
In-Reply-To: <YrhSK5l0uQZT76Fi@jyty>
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]
Sun, Jun 26, 2022 at 03:33:48PM +0300, Marko Mäkelä wrote:
>How about the following improvement? If IR_RX_BC is a simple cursor to
>the 128-byte IR_RX_BUF, then rtl2832u_rc_query() could avoid sending
>refresh_tab[] but simply remember where the previous call left off. We
>could always read the 128 bytes at IR_RX_BUF, and process everything
>between the previous position reported by IR_RX_BC and the current
>position reported by IR_RX_BC, and treat buf[] as a ring buffer.
I experimented with this on the 5.19.0-rc3 kernel. With the attached
patch applied on top of this patch series, "ir-keytables -t" reported
only one RC5 encoded key-down event. I had to unplug and plug in the
adapter in order to receive another RC5 event. The refresh command seems
to be necessary for the device to store and forward further IR data.
>Last time I tested it, the patch was a significant improvement. I think
>that "perfect" is the enemy of "good enough", and the patch should be
>included in the kernel.
The remaining problem definitely is a limitation of the interface. There
is little that can be done to work around it.
Marko
[-- Attachment #2: rc_bc_ringbuffer.patch --]
[-- Type: text/x-diff, Size: 2783 bytes --]
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index a83b1107fc7f..04670cec727c 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1711,16 +1711,10 @@ static int rtl2831u_get_rc_config(struct dvb_usb_device *d,
static int rtl2832u_rc_query(struct dvb_usb_device *d)
{
- int ret, i, len;
+ int ret, i, end;
struct rtl28xxu_dev *dev = d->priv;
struct ir_raw_event ev = {};
u8 buf[128];
- static const struct rtl28xxu_reg_val_mask refresh_tab[] = {
- {IR_RX_IF, 0x03, 0xff},
- {IR_RX_BUF_CTRL, 0x80, 0xff},
- {IR_RX_CTRL, 0x80, 0xff},
- };
- u32 idle_length;
/* init remote controller */
if (!dev->rc_active) {
@@ -1761,48 +1755,22 @@ static int rtl2832u_rc_query(struct dvb_usb_device *d)
goto exit;
ret = rtl28xxu_rd_reg(d, IR_RX_BC, &buf[0]);
- if (ret || buf[0] > sizeof(buf))
+ if (ret)
goto err;
- len = buf[0];
+ i = dev->rc_bc;
+ end = dev->rc_bc = buf[0] & 0x7f;
/* read raw code from hw */
- ret = rtl28xxu_rd_regs(d, IR_RX_BUF, buf, len);
+ ret = rtl28xxu_rd_regs(d, IR_RX_BUF, buf, sizeof buf);
if (ret)
goto err;
- dev_dbg(&d->intf->dev, "IR_RX_BUF=%*ph\n", len, buf);
-
- /* if the receiver is not idle yet, do not process */
- idle_length = 0;
- if (len > 2) {
- if (!(buf[len - 1] & 0x80))
- idle_length += buf[len - 1];
- if (!(buf[len - 2] & 0x80))
- idle_length += buf[len - 2];
- }
-
- if (idle_length < 0xbf) {
- /*
- * If the IR does not end with a space equal to the idle
- * length, then the IR is not complete yet and more is to
- * arrive shortly. If we process it and flush the buffer now,
- * we end up missing IR.
- */
- dev_dbg(&d->intf->dev, "ignoring idle=%x\n", idle_length);
- return 0;
- }
-
- /* let hw receive new code */
- for (i = 0; i < ARRAY_SIZE(refresh_tab); i++) {
- ret = rtl28xxu_wr_reg_mask(d, refresh_tab[i].reg,
- refresh_tab[i].val, refresh_tab[i].mask);
- if (ret)
- goto err;
- }
+ dev_dbg(&d->intf->dev, "IR_RX_BUF=%d,%*ph\n", end,
+ (int) sizeof buf, buf);
/* pass data to Kernel IR decoder */
- for (i = 0; i < len; i++) {
+ for (; i != end; i++, i &= 0x7f) {
ev.pulse = buf[i] >> 7;
ev.duration = 51 * (buf[i] & 0x7f);
ir_raw_event_store_with_filter(d->rc_dev, &ev);
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
index d5e207baa05d..b1abd73a3020 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.h
@@ -64,6 +64,7 @@ struct rtl28xxu_dev {
u8 tuner;
char *tuner_name;
u8 page; /* integrated demod active register page */
+ u8 rc_bc;
struct i2c_adapter *demod_i2c_adapter;
bool rc_active;
bool new_i2c_write;
next prev parent reply other threads:[~2022-06-27 5:01 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-12 16:32 [PATCH 0/2] Fix rtl28xxu nec/rc5 receiver Sean Young
2022-02-12 16:32 ` [PATCH 1/2] media: rc-core: split IR timeout into rawir timeout and keyup delay Sean Young
2022-02-12 16:32 ` [PATCH 2/2] media: rtl28xxu: improve IR receiver Sean Young
2022-06-26 12:33 ` Marko Mäkelä
2022-06-27 5:00 ` Marko Mäkelä [this message]
2022-07-02 8:17 ` Sean Young
2022-06-27 10:53 ` Sean Young
2022-06-28 6:27 ` Marko Mäkelä
2022-07-02 8:14 ` Sean Young
2022-07-03 17:02 ` Marko Mäkelä
2022-07-04 7:21 ` Sean Young
2022-07-04 9:20 ` Marko Mäkelä
2022-07-04 10:00 ` Sean Young
2022-07-04 19:04 ` Marko Mäkelä
2022-07-05 7:25 ` Sean Young
2022-07-05 8:48 ` Marko Mäkelä
2022-07-05 9:26 ` Sean Young
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=Yrk5faigZEiZ7KXk@jyty \
--to=marko.makela@iki.fi \
--cc=linux-media@vger.kernel.org \
--cc=sean@mess.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox