From patchwork Tue Mar 6 17:46:37 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Scheller X-Patchwork-Id: 10262345 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EDB5E6055D for ; Tue, 6 Mar 2018 17:46:47 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DD4F228AB9 for ; Tue, 6 Mar 2018 17:46:47 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D1DFF29045; Tue, 6 Mar 2018 17:46:47 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2A2C128AB9 for ; Tue, 6 Mar 2018 17:46:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932934AbeCFRqp (ORCPT ); Tue, 6 Mar 2018 12:46:45 -0500 Received: from mail-wm0-f42.google.com ([74.125.82.42]:35124 "EHLO mail-wm0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932656AbeCFRqn (ORCPT ); Tue, 6 Mar 2018 12:46:43 -0500 Received: by mail-wm0-f42.google.com with SMTP id x7so23791733wmc.0 for ; Tue, 06 Mar 2018 09:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references; bh=g7jcGVrsu0ophFHTPCWz3RRjM/yomzMSYVSL2nm45h8=; b=VB3a3zpvFdpWwfGAKGX4qTn2E0QIG1zc0ukXO/sgO9WvS50MYHDYRE7eFzC/orgEdB 8R6DzjB3kI811JpgLjIbtloFV3tfBIWbRMdePVzIwgkMf3GC1ROfAv78cIdgh/9sJJTU WnVlEJJNeHPHWMxzgruPOmsXr+Zy69uDPAz/Ha7WVH5AUmOKHf73DtRZTiVo9SxjnOU1 hyhrmUHRZdYo+PNpBbBmYd512EkhLaF1D1O6x+ih62eCxZjMwtJqFPwKWzUqMohuL8zX WXDIPsLo91dDV+8Sd/XZ7rUPUEPnTQ3GgiAyKGL7CS54EhSUpCz5KpnbBkPZp8ZXtkfw gxJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references; bh=g7jcGVrsu0ophFHTPCWz3RRjM/yomzMSYVSL2nm45h8=; b=j/zIJwT6nrebVYwf9INZXUx5qaUqLlie1NUG7KrxC6eMX3fxyFRLI88c9CY3ldP42+ VTrV7GQkgkkINeNeoCrxaKLtrNMh3djh69+7X41JAoK2QoHWM+uHOOwAbIGyHRumnAsR nyaOKsc5jnwD0KnTiH9dCPQ+mZC1ep6W1/lDXjS/4cQ/Kre+8eaZItgGNYs6u/UJ1rYB 2I65S8DJ9vGXSVuefmnTbwQ8D8o1thGxstqcqAWXqRNrFSo0iCr0bKrP8v+5Qx+j7Kta axlL15kpkQglDkz5KY5gxLexzJP+soYPbXJu2jFnnMg5Yj9kZxpwU1759XkFV1FPqtYP +xcQ== X-Gm-Message-State: AElRT7ELLy0fhVOh9Y1Bb9Bh1svXeMemcJjBKM9XepaohWkP19pczyvh MrViBfE9AOyKhnsSf121nhCLYA== X-Google-Smtp-Source: AG47ELuXv1J2LbIG8jTb0RZHbCGlzhuWSFQ2e2Ryfw4MzyVx44y7rKn3cbiTXLh4oUzpG+z15lH5yw== X-Received: by 10.28.12.79 with SMTP id 76mr11116904wmm.116.1520358401648; Tue, 06 Mar 2018 09:46:41 -0800 (PST) Received: from dvbdev.wuest.de (ip-84-118-193-200.unity-media.net. [84.118.193.200]) by smtp.gmail.com with ESMTPSA id c78sm9809385wmd.45.2018.03.06.09.46.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Mar 2018 09:46:41 -0800 (PST) From: Daniel Scheller To: linux-media@vger.kernel.org, mchehab@kernel.org, mchehab@s-opensource.com Subject: [PATCH 2/2] [media] ngene: compensate for TS buffer offset shifts Date: Tue, 6 Mar 2018 18:46:37 +0100 Message-Id: <20180306174637.24618-3-d.scheller.oss@gmail.com> X-Mailer: git-send-email 2.16.1 In-Reply-To: <20180306174637.24618-1-d.scheller.oss@gmail.com> References: <20180306174637.24618-1-d.scheller.oss@gmail.com> Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Daniel Scheller 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) take 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 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 of 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. This compensation can be toggled by the ci_tsfix modparam, which defaults to 1 (enabled). In the case of problems, this can be turned off by setting the parameter to 0 to restore the old behaviour. Signed-off-by: Daniel Scheller --- drivers/media/pci/ngene/ngene-dvb.c | 91 ++++++++++++++++++++++++++++++++++++- drivers/media/pci/ngene/ngene.h | 3 ++ 2 files changed, 93 insertions(+), 1 deletion(-) diff --git a/drivers/media/pci/ngene/ngene-dvb.c b/drivers/media/pci/ngene/ngene-dvb.c index 93a07a370cfd..fee89b9ed9c1 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 ****************************************************/ @@ -139,6 +142,24 @@ static void swap_buffer(u32 *p, u32 len) /* start of filler packet */ static u8 fill_ts[] = { 0x47, 0x1f, 0xff, 0x10, TS_FILLER }; +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 % 188; + } + } + + 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,86 @@ 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 shift + * (max. 188 bytes, tsoff will be mod 188) + */ + 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); + + /* + * offset corrected. re-check remaining + * len for a full TS frame, break and + * skip to fragment handling if < 188. + */ + if (len < 188) + break; + } + } + 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]; };