| Message ID | 1406027388-10336-1-git-send-email-ljalvs@gmail.com (mailing list archive) |
|---|---|
| State | Rejected, archived |
| Delegated to: | Michael Krufky |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1X9XxJ-00047j-I7; Tue, 22 Jul 2014 13:10:01 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.72/mailfrontend-7) with esmtp id 1X9XxH-0000MR-1k; Tue, 22 Jul 2014 13:10:01 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751755AbaGVLJ5 (ORCPT <rfc822;mkrufky@linuxtv.org> + 1 other); Tue, 22 Jul 2014 07:09:57 -0400 Received: from mail-we0-f170.google.com ([74.125.82.170]:41516 "EHLO mail-we0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751253AbaGVLJ5 (ORCPT <rfc822;linux-media@vger.kernel.org>); Tue, 22 Jul 2014 07:09:57 -0400 Received: by mail-we0-f170.google.com with SMTP id w62so8816018wes.1 for <linux-media@vger.kernel.org>; Tue, 22 Jul 2014 04:09:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id; bh=cJ6mSx5FgRSDxEBDxLTgxFgBZ6f9ntOYOhfsJKHDeFM=; b=RIw7idyEItA/eswe9B2Olx/U2t0TEZ25Dbe9sz6SEgld3+VmX67x79JM0Ne5xOJ7t2 JMfNzeLGTT/fJXo7uAkJYPZ5lBk5LXTkjYkdwMhrbI8DQ19CzJtuRvoTiZ+4zpViDtLq pokTOs+y8dIj52wvd0EpVqoU8uH41hH4hagTkQsFW2594OP3R5M8G1JLtOdspg79x4Gc ralL/n/Qna5UXkwRRX/pUOT8nBen14qtr/EqOZQ4crthdNfjI+X6dHtgRAsGH7OKuEKE Sydg3MvYWseNCd/Foaf/4GLF4UdXFHjDlb77RaQeffTmKeIr6GVBptEBBUREhZ5eiyX7 3zow== X-Received: by 10.194.90.106 with SMTP id bv10mr33533230wjb.20.1406027394116; Tue, 22 Jul 2014 04:09:54 -0700 (PDT) Received: from localhost.localdomain (a89-152-208-230.cpe.netcabo.pt. [89.152.208.230]) by mx.google.com with ESMTPSA id wv8sm223968wjb.1.2014.07.22.04.09.52 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Jul 2014 04:09:53 -0700 (PDT) From: Luis Alves <ljalvs@gmail.com> To: linux-media@vger.kernel.org Cc: crope@iki.fi, Luis Alves <ljalvs@gmail.com> Subject: [PATCH] si2157: Fix DVB-C bandwidth. Date: Tue, 22 Jul 2014 12:09:48 +0100 Message-Id: <1406027388-10336-1-git-send-email-ljalvs@gmail.com> X-Mailer: git-send-email 1.9.1 Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.7.22.110018 X-PMX-Spam: Gauge=IIIIIIIII, Probability=9%, Report=' FORGED_FROM_GMAIL 0.1, MULTIPLE_RCPTS 0.1, HTML_00_01 0.05, HTML_00_10 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1000_LESS 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, BODY_SIZE_800_899 0, DKIM_SIGNATURE 0, URI_ENDS_IN_HTML 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __FRAUD_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_FROM 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS , __YOUTUBE_RCVD 0' |
Commit Message
Luis Alves
July 22, 2014, 11:09 a.m. UTC
This patch fixes DVB-C reception.
Without setting the bandwidth to 8MHz the received stream gets corrupted.
Regards,
Luis
Signed-off-by: Luis Alves <ljalvs@gmail.com>
---
drivers/media/tuners/si2157.c | 1 +
1 file changed, 1 insertion(+)
Comments
On 22.07.2014 13:09, Luis Alves wrote: > This patch fixes DVB-C reception. > Without setting the bandwidth to 8MHz the received stream gets corrupted. Hi Luis, I also wonder if some code should default to bandwidth of 8MHz if none is set. But then I grepped for it and found code in drivers/media/dvb-core/dvb_frontend.c to calculate the bandwidth depending on delivery system and symbol rate. So if this works, the bandwidth should already be correct. Regards Matthias -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Tue, 22 Jul 2014 12:09:48 +0100 Luis Alves <ljalvs@gmail.com> escreveu: > This patch fixes DVB-C reception. > Without setting the bandwidth to 8MHz the received stream gets corrupted. > > Regards, > Luis > > Signed-off-by: Luis Alves <ljalvs@gmail.com> > --- > drivers/media/tuners/si2157.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c > index 6c53edb..e2de428 100644 > --- a/drivers/media/tuners/si2157.c > +++ b/drivers/media/tuners/si2157.c > @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) > break; > case SYS_DVBC_ANNEX_A: > delivery_system = 0x30; > + bandwidth = 0x08; Hmm... this patch looks wrong, as it will break DVB-C support where the bandwidth is lower than 6MHz. The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and the symbol rate. If this is not working for you, then something else is likely wrong. I suggest you to add a printk() there to show what's the value set at c->bandwidth_hz and what's the symbol rate that you're using. On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). Not sure if DVB-C2 allows selecting a different rolloff factor, nor if si2157 works with DVB-C2. > break; > default: > ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
That's right, A few days ago I also checked that with Antti. I've also had made some debugging and DVB core is in fact passing the correct bandwidth to the driver. But the true is that it doesn't work... The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results in 7MHz bw) using 7MHz filter value will make the TS stream unwatchable (lots of continuity errors). Can this be a hardware fault? All closed source drivers I've seen are hardcoding this value to 8MHz when working in dvb-c (easily seen on i2c sniffs). On Tue, Jul 22, 2014 at 5:10 PM, Mauro Carvalho Chehab <m.chehab@samsung.com> wrote: > Em Tue, 22 Jul 2014 12:09:48 +0100 > Luis Alves <ljalvs@gmail.com> escreveu: > >> This patch fixes DVB-C reception. >> Without setting the bandwidth to 8MHz the received stream gets corrupted. >> >> Regards, >> Luis >> >> Signed-off-by: Luis Alves <ljalvs@gmail.com> >> --- >> drivers/media/tuners/si2157.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c >> index 6c53edb..e2de428 100644 >> --- a/drivers/media/tuners/si2157.c >> +++ b/drivers/media/tuners/si2157.c >> @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) >> break; >> case SYS_DVBC_ANNEX_A: >> delivery_system = 0x30; >> + bandwidth = 0x08; > > Hmm... this patch looks wrong, as it will break DVB-C support where > the bandwidth is lower than 6MHz. > > The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and > the symbol rate. If this is not working for you, then something else > is likely wrong. > > I suggest you to add a printk() there to show what's the value set > at c->bandwidth_hz and what's the symbol rate that you're using. > > On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). > Not sure if DVB-C2 allows selecting a different rolloff factor, nor > if si2157 works with DVB-C2. > >> break; >> default: >> ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Em Tue, 22 Jul 2014 17:28:07 +0100 Luis Alves <ljalvs@gmail.com> escreveu: > That's right, > A few days ago I also checked that with Antti. I've also had made some > debugging and DVB core is in fact passing the correct bandwidth to the > driver. > > But the true is that it doesn't work... > The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results > in 7MHz bw) using 7MHz filter value will make the TS stream > unwatchable (lots of continuity errors). > > Can this be a hardware fault? > All closed source drivers I've seen are hardcoding this value to 8MHz > when working in dvb-c (easily seen on i2c sniffs). Could be. Well, here, the DVB-C channel operators use 6MHz-spaced channels, with symbol rate equal to 5,217 Kbaud. I'll see if I can test it latter this week with a PCTV 292e. Regards, Mauro > > > On Tue, Jul 22, 2014 at 5:10 PM, Mauro Carvalho Chehab > <m.chehab@samsung.com> wrote: > > Em Tue, 22 Jul 2014 12:09:48 +0100 > > Luis Alves <ljalvs@gmail.com> escreveu: > > > >> This patch fixes DVB-C reception. > >> Without setting the bandwidth to 8MHz the received stream gets corrupted. > >> > >> Regards, > >> Luis > >> > >> Signed-off-by: Luis Alves <ljalvs@gmail.com> > >> --- > >> drivers/media/tuners/si2157.c | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c > >> index 6c53edb..e2de428 100644 > >> --- a/drivers/media/tuners/si2157.c > >> +++ b/drivers/media/tuners/si2157.c > >> @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) > >> break; > >> case SYS_DVBC_ANNEX_A: > >> delivery_system = 0x30; > >> + bandwidth = 0x08; > > > > Hmm... this patch looks wrong, as it will break DVB-C support where > > the bandwidth is lower than 6MHz. > > > > The DVB core sets c->bandwidth_hz for DVB-C based on the rolloff and > > the symbol rate. If this is not working for you, then something else > > is likely wrong. > > > > I suggest you to add a printk() there to show what's the value set > > at c->bandwidth_hz and what's the symbol rate that you're using. > > > > On DVB-C, the rolloff is fixed (1.15 for annex A and 1.13 for Annex C). > > Not sure if DVB-C2 allows selecting a different rolloff factor, nor > > if si2157 works with DVB-C2. > > > >> break; > >> default: > >> ret = -EINVAL; -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/22/2014 08:03 PM, Mauro Carvalho Chehab wrote: > Em Tue, 22 Jul 2014 17:28:07 +0100 > Luis Alves <ljalvs@gmail.com> escreveu: > >> That's right, >> A few days ago I also checked that with Antti. I've also had made some >> debugging and DVB core is in fact passing the correct bandwidth to the >> driver. >> >> But the true is that it doesn't work... >> The sample I have is a dvb-c mux using QAM128 @ 6 Mbaud (which results >> in 7MHz bw) using 7MHz filter value will make the TS stream >> unwatchable (lots of continuity errors). >> >> Can this be a hardware fault? >> All closed source drivers I've seen are hardcoding this value to 8MHz >> when working in dvb-c (easily seen on i2c sniffs). > > Could be. Well, here, the DVB-C channel operators use 6MHz-spaced channels, > with symbol rate equal to 5,217 Kbaud. I'll see if I can test it latter > this week with a PCTV 292e. I could also test it against modulator. However, that patch seems to be wrong for my eyes too. Generally speaking RF tuner needs to know bandwidth to adjust filters on signal path. For narrow suitable is filter, the better will be signal. If you have 7MHz filter then you definitely want use it in a case your carrier fits that space. Larger filter will work, but CNR is worse. If filter is too narrow and cuts your carrier, you are not able to receive mux or at lest performance drop notably. What is you channel raster? Could you tell center frequencies of all your DVB-C muxes? Could you test with 7MHz bw, but adjust center frequency off from nominal ~0-500kHz to see if it helps. regards Antti
diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c index 6c53edb..e2de428 100644 --- a/drivers/media/tuners/si2157.c +++ b/drivers/media/tuners/si2157.c @@ -245,6 +245,7 @@ static int si2157_set_params(struct dvb_frontend *fe) break; case SYS_DVBC_ANNEX_A: delivery_system = 0x30; + bandwidth = 0x08; break; default: ret = -EINVAL;