From: Daniel Scheller <d.scheller.oss@gmail.com>
To: linux-media@vger.kernel.org, mchehab@kernel.org,
mchehab@s-opensource.com
Subject: [PATCH 12/12] [media] ngene: compensate for TS buffer offset shifts
Date: Sat, 24 Feb 2018 19:55:34 +0100 [thread overview]
Message-ID: <20180224185534.13792-13-d.scheller.oss@gmail.com> (raw)
In-Reply-To: <20180224185534.13792-1-d.scheller.oss@gmail.com>
From: Daniel Scheller <d.scheller@gmx.net>
A possible hardware bug was discovered when using CA addon hardware
attached to the ngene hardware, in that the TS input buffer much likely
will shift and thus become unaligned to 188 byte blocks (a full TS frame)
when things like CA module initialisation (which happens via differing
communication paths) takes place. This causes the TS NULL removal in
tsin_exchange() to fail to detect this previously inserted data and thus
causes userspace applications to receive data they didn't sent beforehand
and ultimately can cause troubles.
On driver load with an inserted CAM, buffers are fine at first (note that
the driver has to keep the communication running from/to the card by
inserting TS NULL frames, this is done in tsout_exchange() via
FillTSBuffer() - that data is simply sent back by the hardware):
offset | 0 1 2 3 4 5 .... 188 189 190 191 192 193 .... 376
data | 47 1f ff 10 6f 6f .... 47 1f ff 10 6f 6f .... 47
After a few seconds, the CA module is recognised and initialised, which is
signalled by
dvb_ca_en50221: dvb_ca adapter X: DVB CAM detected and initialised successfully
This is where the first shift happens (this is always four bytes), buffer
becomes like this:
offset | 0 1 2 3 4 5 .... 188 189 190 191 192 193 .... 376
data | 6f 6f 6f 6f 47 1f .... 6f 6f 6f 6f 47 1f .... 6f
Next, VDR, TVHeadend or any other CI aware application is started, buffers
will shift by even more bytes. It is believed this is due to the hardware
not handling control and data bytes properly distinct, and control data
having an influence on the actual data stream, which we cannot properly
detect at the driver level.
Workaround this hardware quirk by adding a detection for the TS sync byte
0x47 before each TS frame copy, scan for a new SYNC byte and a TS NULL
packet if buffers become unaligned, take note of that offset and apply
that when copying data to the DVB ring buffers. The last <188 bytes from
the hardware buffers are stored in a temp buffer (tsin_buffer), for which
the remainder will be in the beginning of the next hardware buffer (next
iteration if tsin_exchange()). That remainder will be appended to the
temp buffer and finally sent to the DVB ring buffer. The resulting TS
stream is perfectly fine, and the TS NULL packets inserted by the driver
which are sent back are properly removed. The resulting offset is being
clamped to 188 byte segments (one TS packet). Though this can result in
a repeated TS packet if the overall offset grows beyond this (and it
will grow only on CA initialisation), this is still way better than
unaligned TS frames and data sent to userspace that just isn't supposed
to be there.
Signed-off-by: Daniel Scheller <d.scheller@gmx.net>
---
drivers/media/pci/ngene/ngene-dvb.c | 80 ++++++++++++++++++++++++++++++++++++-
drivers/media/pci/ngene/ngene.h | 3 ++
2 files changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/media/pci/ngene/ngene-dvb.c b/drivers/media/pci/ngene/ngene-dvb.c
index 6d72b9f69418..5abf69f6bc4b 100644
--- a/drivers/media/pci/ngene/ngene-dvb.c
+++ b/drivers/media/pci/ngene/ngene-dvb.c
@@ -38,6 +38,9 @@
#include "ngene.h"
+static int ci_tsfix = 1;
+module_param(ci_tsfix, int, 0444);
+MODULE_PARM_DESC(ci_tsfix, "Detect and fix TS buffer offset shifs in conjunction with CI expansions (default: 1/enabled)");
/****************************************************************************/
/* COMMAND API interface ****************************************************/
@@ -123,6 +126,24 @@ static u32 overflow;
static u32 stripped;
#endif
+static int tsin_find_offset(void *buf, u32 len)
+{
+ int i, l;
+
+ l = len - sizeof(fill_ts);
+ if (l <= 0)
+ return -1;
+
+ for (i = 0; i < l; i++) {
+ if (((char *)buf)[i] == 0x47) {
+ if (!memcmp(buf + i, fill_ts, sizeof(fill_ts)))
+ return i;
+ }
+ }
+
+ return -1;
+}
+
static inline void tsin_copy_stripped(struct ngene *dev, void *buf)
{
if (memcmp(buf, fill_ts, sizeof(fill_ts)) != 0) {
@@ -153,18 +174,75 @@ void *tsin_exchange(void *priv, void *buf, u32 len, u32 clock, u32 flags)
{
struct ngene_channel *chan = priv;
struct ngene *dev = chan->dev;
-
+ int tsoff;
if (flags & DF_SWAP32)
swap_buffer(buf, len);
if (dev->ci.en && chan->number == 2) {
+ /* blindly copy buffers if ci_tsfix is disabled */
+ if (!ci_tsfix) {
+ while (len >= 188) {
+ tsin_copy_stripped(dev, buf);
+
+ buf += 188;
+ len -= 188;
+ }
+ return NULL;
+ }
+
+ /* ci_tsfix = 1 */
+
+ /*
+ * since the remainder of the TS packet which got cut off
+ * in the previous tsin_exchange() run is at the beginning
+ * of the new TS buffer, append this to the temp buffer and
+ * send it to the DVB ringbuffer afterwards.
+ */
+ if (chan->tsin_offset) {
+ memcpy(&chan->tsin_buffer[(188 - chan->tsin_offset)],
+ buf, chan->tsin_offset);
+ tsin_copy_stripped(dev, &chan->tsin_buffer);
+
+ buf += chan->tsin_offset;
+ len -= chan->tsin_offset;
+ }
+
+ /*
+ * copy TS packets to the DVB ringbuffer and detect new offset
+ * shifts by checking for a valid TS SYNC byte
+ */
while (len >= 188) {
+ if (*((char *)buf) != 0x47) {
+ /* no SYNC header, find new offset */
+ tsoff = tsin_find_offset(buf, len);
+ if (tsoff > 0) {
+ chan->tsin_offset += tsoff;
+ chan->tsin_offset %= 188;
+
+ buf += tsoff;
+ len -= tsoff;
+
+ dev_info(&dev->pci_dev->dev,
+ "%s(): tsin_offset shift by %d on channel %d\n",
+ __func__, tsoff,
+ chan->number);
+ }
+ }
+
tsin_copy_stripped(dev, buf);
buf += 188;
len -= 188;
}
+
+ /*
+ * if a fragment is left, copy to temp buffer. The remainder
+ * will be appended in the next tsin_exchange() iteration.
+ */
+ if (len > 0 && len < 188)
+ memcpy(&chan->tsin_buffer, buf, len);
+
return NULL;
}
diff --git a/drivers/media/pci/ngene/ngene.h b/drivers/media/pci/ngene/ngene.h
index 66d8eaa28549..01d9f1b58fcb 100644
--- a/drivers/media/pci/ngene/ngene.h
+++ b/drivers/media/pci/ngene/ngene.h
@@ -732,6 +732,9 @@ struct ngene_channel {
#endif
int running;
+
+ int tsin_offset;
+ u8 tsin_buffer[188];
};
--
2.16.1
prev parent reply other threads:[~2018-02-24 18:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-24 18:55 [PATCH 00/12] ngene-updates: Hardware support, TS buffer shift fix Daniel Scheller
2018-02-24 18:55 ` [PATCH 01/12] [media] ngene: add two additional PCI IDs Daniel Scheller
2018-02-24 18:55 ` [PATCH 02/12] [media] ngene: convert kernellog printing from printk() to dev_*() macros Daniel Scheller
2018-02-24 18:55 ` [PATCH 03/12] [media] ngene: use defines to identify the demod_type Daniel Scheller
2018-02-24 18:55 ` [PATCH 04/12] [media] ngene: support STV0367 DVB-C/T DuoFlex addons Daniel Scheller
2018-02-24 18:55 ` [PATCH 05/12] [media] ngene: add XO2 module support Daniel Scheller
2018-02-24 18:55 ` [PATCH 06/12] [media] ngene: add support for Sony CXD28xx-based DuoFlex modules Daniel Scheller
2018-02-24 18:55 ` [PATCH 07/12] [media] ngene: add support for DuoFlex S2 V4 addon modules Daniel Scheller
2018-02-24 18:55 ` [PATCH 08/12] [media] ngene: deduplicate I2C adapter evaluation Daniel Scheller
2018-02-24 18:55 ` [PATCH 09/12] [media] ngene: check for CXD2099AR presence before attaching Daniel Scheller
2018-02-24 18:55 ` [PATCH 10/12] [media] ngene: don't treat non-existing demods as error Daniel Scheller
2018-02-24 18:55 ` [PATCH 11/12] [media] ngene: move the tsin_exchange() stripcopy block into a function Daniel Scheller
2018-02-24 18:55 ` Daniel Scheller [this message]
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=20180224185534.13792-13-d.scheller.oss@gmail.com \
--to=d.scheller.oss@gmail.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=mchehab@s-opensource.com \
/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