Message ID | 1326462636-8869-1-git-send-email-mchehab@redhat.com (mailing list archive) |
---|---|
State | Accepted, archived |
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 1RlhWm-00062d-CO for patchwork@linuxtv.org; Fri, 13 Jan 2012 14:50:44 +0100 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtp for <patchwork@linuxtv.org> id 1RlhWl-0002Vg-Is; Fri, 13 Jan 2012 14:50:44 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758161Ab2AMNul (ORCPT <rfc822;patchwork@linuxtv.org>); Fri, 13 Jan 2012 08:50:41 -0500 Received: from mx1.redhat.com ([209.132.183.28]:36891 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753052Ab2AMNul (ORCPT <rfc822;linux-media@vger.kernel.org>); Fri, 13 Jan 2012 08:50:41 -0500 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0DDoebe008739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <linux-media@vger.kernel.org>; Fri, 13 Jan 2012 08:50:40 -0500 Received: from pedra (vpn-231-90.phx2.redhat.com [10.3.231.90]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0DDod8c026324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jan 2012 08:50:40 -0500 Received: from v4l by pedra with local (Exim 4.76) (envelope-from <mchehab@redhat.com>) id 1RlhWf-0002K1-AJ; Fri, 13 Jan 2012 11:50:37 -0200 From: Mauro Carvalho Chehab <mchehab@redhat.com> Cc: Mauro Carvalho Chehab <mchehab@redhat.com>, Linux Media Mailing List <linux-media@vger.kernel.org> Subject: [PATCH] [media] dvb-core: preserve the delivery system at cache clear Date: Fri, 13 Jan 2012 11:50:36 -0200 Message-Id: <1326462636-8869-1-git-send-email-mchehab@redhat.com> In-Reply-To: <4F101940.2020408@gmail.com> References: <4F101940.2020408@gmail.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 To: unlisted-recipients:; (no To-header on input) 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: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.1.13.133627 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1200_1299 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, FROM_NAME_PHRASE 0, TO_UNDISCLOSED_RECIPIENTS 0, __ANY_URI 0, __CP_URI_IN_BODY 0, __HAS_MSGID 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MULTIPLE_RCPTS_CC_X2 0, __PHISH_SPEAR_STRUCTURE_1 0, __PHISH_SPEAR_STRUCTURE_2 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __TO_MALFORMED_3 0, __URI_NO_WWW 0, __URI_NS ' |
Commit Message
Mauro Carvalho Chehab
Jan. 13, 2012, 1:50 p.m. UTC
The changeset 240ab508aa is incomplete, as the first thing that
happens at cache clear is to do a memset with 0 to the cache.
So, the delivery system needs to be explicitly preserved there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
---
If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should
fix the current issue.
drivers/media/dvb/dvb-core/dvb_frontend.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
Comments
Il 13/01/2012 14:50, Mauro Carvalho Chehab ha scritto: > The changeset 240ab508aa is incomplete, as the first thing that > happens at cache clear is to do a memset with 0 to the cache. > > So, the delivery system needs to be explicitly preserved there. > > Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com> > > --- > > If Kaffeine doesn't call FE_SET_PROPERTY for non-DVB-S2, this should > fix the current issue. > > drivers/media/dvb/dvb-core/dvb_frontend.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c > index 2ad7faf..f5fa7aa 100644 > --- a/drivers/media/dvb/dvb-core/dvb_frontend.c > +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c > @@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe) > { > struct dtv_frontend_properties *c = &fe->dtv_property_cache; > int i; > + u32 delsys; > > + delsys = c->delivery_system; > memset(c, 0, sizeof(struct dtv_frontend_properties)); > + c->delivery_system = delsys; > > c->state = DTV_CLEAR; > Hi Mauro, I applied this new patch on top of the current media_build tree and I can confirm that the issue with Kaffeine is solved. All of my DVB-T sticks works fine again. Best regards, Gianluca -- 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
Thanks for the patch Mauro. According to Gianluca that solves the backwards compatibility issue. This is great news. In other news I've tried a few experiments. Firstly I tried using a 3.2.0 unmodified straight out of the box kernel on my Core 2 64-bit system. I was unable to produce any faults. This would tend to lead one to suspect that it's a 32-bit problem or that my 32-bit machine is a bit flaky or slow. So, as I wanted to try the new alpha 3 for Mageia 2 (a Mandriva fork) out and it has a 3.0 kernel that seemed to be a good idea. The bad news is that I'd run out of hardware. So I thought I'd be clever and run it as a virtual machine on my Core 2 system. The good news is that it correctly recognised the stick and it seemed to work for standard definition. However, after setting it to record some HDTV programmes it failed. More importantly it failed in the same way as the 32-bit system. This makes me think it's some kind of timing problem. The USB passthrough of VirtualBox may well not operate at the performance required for HDTV. Also by this time I'd put the stick on a USB extension lead which may have adversely affected the power feed. For my next series of tests I plan to run it again on bare hardware. I'm going to try and use my older Core 2 machine which should have the CPU and electrical power. None of which explains why it works on the 32-bit Athlon XP 2200+ when it's running 3.0.0 though. And has done so reliably for some time. Maybe some other things are happening in the kernel that much up the device timing or something. Anyway, I'll keep people posted as to the progression of the testing. Best regards, Jim. -- 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 13-01-2012 22:00, Jim Darby escreveu: > Thanks for the patch Mauro. According to Gianluca that solves the backwards compatibility issue. This is great news. Good! > In other news I've tried a few experiments. Firstly I tried using a 3.2.0 unmodified straight out of the box kernel on my Core 2 64-bit system. I was unable to produce any faults. This would tend to lead one to suspect that it's a 32-bit problem or that my 32-bit machine is a bit flaky or slow. > > So, as I wanted to try the new alpha 3 for Mageia 2 (a Mandriva fork) out and it has a 3.0 kernel that seemed to be a good idea. The bad news is that I'd run out of hardware. So I thought I'd be clever and run it as a virtual machine on my Core 2 system. > > The good news is that it correctly recognised the stick and it seemed to work for standard definition. However, after setting it to record some HDTV programmes it failed. More importantly it failed in the same way as the 32-bit system. > > This makes me think it's some kind of timing problem. The USB passthrough of VirtualBox may well not operate at the performance required for HDTV. Also by this time I'd put the stick on a USB extension lead which may have adversely affected the power feed. Never used the USB passthrough of VirtualBox. At KVM, Hans de Goede wrote several patches to allow it to work with webcams. On my tests with it with video cards, sometimes it works, sometimes it doesn't. > For my next series of tests I plan to run it again on bare hardware. I'm going to try and use my older Core 2 machine which should have the CPU and electrical power. > > None of which explains why it works on the 32-bit Athlon XP 2200+ when it's running 3.0.0 though. And has done so reliably for some time. Maybe some other things are happening in the kernel that much up the device timing or something. > > Anyway, I'll keep people posted as to the progression of the testing. From DVB drivers perspective, a full 32bits system should work just like a 64 bits one. Btw, I was working with a 32 bits kernel for my ISDB-T tests with the dvbv5-scan tool I'm writing. I'm now using a 64 bits kernel for DVB-C, and everything is working as fine as before. > > Best regards, > > Jim. > -- > 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 -- 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
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c b/drivers/media/dvb/dvb-core/dvb_frontend.c index 2ad7faf..f5fa7aa 100644 --- a/drivers/media/dvb/dvb-core/dvb_frontend.c +++ b/drivers/media/dvb/dvb-core/dvb_frontend.c @@ -904,8 +904,11 @@ static int dvb_frontend_clear_cache(struct dvb_frontend *fe) { struct dtv_frontend_properties *c = &fe->dtv_property_cache; int i; + u32 delsys; + delsys = c->delivery_system; memset(c, 0, sizeof(struct dtv_frontend_properties)); + c->delivery_system = delsys; c->state = DTV_CLEAR;