[linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

[linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

[Matthias Schwarzott]

[-- Attachment #1: Type: text/plain, Size: 863 bytes --]

Hi Manu, hi Steven!

It seems an update of dvb-core breaks tuning of cx24123.
After updating to latest v4l-dvb the nova-s plus card just did no longer lock 
to any channel. So I bisected it, and found this commit:

changeset:   9344:aa3a67b658e8
parent:      9296:e2a8b9b9c294
user:        Manu Abraham <manu@linuxtv.org>
date:        Tue Oct 14 23:34:07 2008 +0400
summary:     DVB-Core update

http://linuxtv.org/hg/v4l-dvb/rev/aa3a67b658e8

It basically did update the dvb-kernel-thread and enhanced the code using 
get_frontend_algo.

The codepath when get_frontend_algo returns *_ALGO_HW stayed the same, only 
one line got removed: params = &fepriv->parameter

Just re-adding that line made my card working again. Either this was lost, or 
the last two lines using "params" should also be converted to directly 
use "&fepriv->parameters".

Regards
Matthias

[-- Attachment #2: fix-tune-algo-hw.diff --]
[-- Type: text/x-diff, Size: 348 bytes --]

--- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -584,6 +584,7 @@ restart:
 
 				if (fepriv->state & FESTATE_RETUNE) {
 					dprintk("%s: Retune requested, FESTATE_RETUNE\n", __func__);
+					params = &fepriv->parameters;
 					fepriv->state = FESTATE_TUNED;
 				}
 

[-- Attachment #3: Type: text/plain, Size: 150 bytes --]

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

[Manu Abraham]

Hi Mathias,

Matthias Schwarzott wrote:
> Hi Manu, hi Steven!
> 
> It seems an update of dvb-core breaks tuning of cx24123.
> After updating to latest v4l-dvb the nova-s plus card just did no longer lock 
> to any channel. So I bisected it, and found this commit:
> 
> changeset:   9344:aa3a67b658e8
> parent:      9296:e2a8b9b9c294
> user:        Manu Abraham <manu@linuxtv.org>
> date:        Tue Oct 14 23:34:07 2008 +0400
> summary:     DVB-Core update
> 
> http://linuxtv.org/hg/v4l-dvb/rev/aa3a67b658e8
> 
> It basically did update the dvb-kernel-thread and enhanced the code using 
> get_frontend_algo.
> 
> The codepath when get_frontend_algo returns *_ALGO_HW stayed the same, only 
> one line got removed: params = &fepriv->parameter
> 
> Just re-adding that line made my card working again. Either this was lost, or 
> the last two lines using "params" should also be converted to directly 
> use "&fepriv->parameters".

True. In the port, the one line got missed out. Thanks for taking the
time to look at it.

BTW, i don't see any reason why cx24123 should be using HW_ALGO as it is
a standard demodulator. When we have a dedicated microcontroller
employed to do that check, we might like to use HW_ALGO, since it would
simply handle it. Not in the case of standard demodulators. As an
example i could say cinergyT2, dst etc would be candidates for HW_ALGO,
where tuning is offloaded to a onboard microcontroller.

But overall, the fix looks fine though, for the devices that make use of
HW_ALGO


Please do have a Signed-off-by line so that it can be applied.

Reviewed-by: Manu Abraham <manu@linuxtv.org>

Thanks,
Manu

> ------------------------------------------------------------------------
> 
> --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> @@ -584,6 +584,7 @@ restart:
>  
>  				if (fepriv->state & FESTATE_RETUNE) {
>  					dprintk("%s: Retune requested, FESTATE_RETUNE\n", __func__);
> +					params = &fepriv->parameters;
>  					fepriv->state = FESTATE_TUNED;
>  				}
>  


_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

[Matthias Schwarzott]

On Montag, 27. Oktober 2008, Manu Abraham wrote:
> Hi Mathias,
>
Hi Manu!

> Matthias Schwarzott wrote:
> > Hi Manu, hi Steven!
> >
> > It seems an update of dvb-core breaks tuning of cx24123.
> > After updating to latest v4l-dvb the nova-s plus card just did no longer
> > lock to any channel. So I bisected it, and found this commit:
> >
> > changeset:   9344:aa3a67b658e8
> > parent:      9296:e2a8b9b9c294
> > user:        Manu Abraham <manu@linuxtv.org>
> > date:        Tue Oct 14 23:34:07 2008 +0400
> > summary:     DVB-Core update
> >
> > http://linuxtv.org/hg/v4l-dvb/rev/aa3a67b658e8
> >
> > It basically did update the dvb-kernel-thread and enhanced the code using
> > get_frontend_algo.
> >
> > The codepath when get_frontend_algo returns *_ALGO_HW stayed the same,
> > only one line got removed: params = &fepriv->parameter
> >
> > Just re-adding that line made my card working again. Either this was
> > lost, or the last two lines using "params" should also be converted to
> > directly use "&fepriv->parameters".
>
> True. In the port, the one line got missed out. Thanks for taking the
> time to look at it.
>
> BTW, i don't see any reason why cx24123 should be using HW_ALGO as it is
> a standard demodulator. When we have a dedicated microcontroller
> employed to do that check, we might like to use HW_ALGO, since it would
> simply handle it. Not in the case of standard demodulators. As an
> example i could say cinergyT2, dst etc would be candidates for HW_ALGO,
> where tuning is offloaded to a onboard microcontroller.
>
I dont have much insight in what these algo settings do. Only idea I have 
about this is: cx24123 may not need software zigzag.
If that gives a larger gain in lock-speed, then mt312 may also be a candidate 
for ALGO_HW as it can lock to signals not exactly centered to the IF.
But I doubt, as that hw then should lock at the first try and not even trigger 
zigzag steps.

> But overall, the fix looks fine though, for the devices that make use of
> HW_ALGO
>
>
> Please do have a Signed-off-by line so that it can be applied.
>

Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>

> Reviewed-by: Manu Abraham <manu@linuxtv.org>
>
> Thanks,
> Manu
>
> > ------------------------------------------------------------------------
> >
> > --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> > +++ v4l-dvb/linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> > @@ -584,6 +584,7 @@ restart:
> >
> >  				if (fepriv->state & FESTATE_RETUNE) {
> >  					dprintk("%s: Retune requested, FESTATE_RETUNE\n", __func__);
> > +					params = &fepriv->parameters;
> >  					fepriv->state = FESTATE_TUNED;
> >  				}



_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

Re: [linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

[Manu Abraham]

Matthias Schwarzott wrote:
> On Montag, 27. Oktober 2008, Manu Abraham wrote:
>> Hi Mathias,
>>
> Hi Manu!
> 
>> Matthias Schwarzott wrote:
>>> Hi Manu, hi Steven!
>>>
>>> It seems an update of dvb-core breaks tuning of cx24123.
>>> After updating to latest v4l-dvb the nova-s plus card just did no longer
>>> lock to any channel. So I bisected it, and found this commit:
>>>
>>> changeset:   9344:aa3a67b658e8
>>> parent:      9296:e2a8b9b9c294
>>> user:        Manu Abraham <manu@linuxtv.org>
>>> date:        Tue Oct 14 23:34:07 2008 +0400
>>> summary:     DVB-Core update
>>>
>>> http://linuxtv.org/hg/v4l-dvb/rev/aa3a67b658e8
>>>
>>> It basically did update the dvb-kernel-thread and enhanced the code using
>>> get_frontend_algo.
>>>
>>> The codepath when get_frontend_algo returns *_ALGO_HW stayed the same,
>>> only one line got removed: params = &fepriv->parameter
>>>
>>> Just re-adding that line made my card working again. Either this was
>>> lost, or the last two lines using "params" should also be converted to
>>> directly use "&fepriv->parameters".
>> True. In the port, the one line got missed out. Thanks for taking the
>> time to look at it.
>>
>> BTW, i don't see any reason why cx24123 should be using HW_ALGO as it is
>> a standard demodulator. When we have a dedicated microcontroller
>> employed to do that check, we might like to use HW_ALGO, since it would
>> simply handle it. Not in the case of standard demodulators. As an
>> example i could say cinergyT2, dst etc would be candidates for HW_ALGO,
>> where tuning is offloaded to a onboard microcontroller.
>>
> I dont have much insight in what these algo settings do. Only idea I have 
> about this is: cx24123 may not need software zigzag.

Ok, should be fine, if that's the case. software zigzag is one thing,
another is lock monitoring, ie: if LOCK fails, it should autotune by
itself; similar to FE_CAN_RECOVER.

Though it brings the disadvantge to the cx24123 driver that it will not
try to reacquire a LOCK when LOCK fails for some unreason such as a
signal dropuot etc, when using HW_ALGO: might cause not to regain a
LOCK, would be a side effect, if it is incapable of doing a hardware
based LOCK monitor.

> If that gives a larger gain in lock-speed, then mt312 may also be a candidate 
> for ALGO_HW as it can lock to signals not exactly centered to the IF.
> But I doubt, as that hw then should lock at the first try and not even trigger 
> zigzag steps.

I don't think the MT312 does support either of the mentioned. Or does it
? Didn't take the time to look at the datasheet.


Regards,
Manu

_______________________________________________
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb