[media] dvb-core: preserve the delivery system at cache clear

Message ID 1326462636-8869-1-git-send-email-mchehab@redhat.com (mailing list archive)
State Accepted, archived
Headers

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

Gianluca Gennari Jan. 13, 2012, 4:04 p.m. UTC | #1
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
  
Jim Darby Jan. 14, 2012, midnight UTC | #2
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
  
Mauro Carvalho Chehab Jan. 14, 2012, 2:51 p.m. UTC | #3
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
  

Patch

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;