commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123

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 <[email protected]>
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".

Hi Mathias,

Quoted 17 lines · Matthias Schwarzott

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 <[email protected]>
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.

Quoted 6 lines

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 <[email protected]>

Thanks,
Manu

Quoted 6 lines

------------------------------------------------------------------------

linux/drivers/media/dvb/dvb-core/dvb_frontend.c +0 -0

@@ -584,6 +584,7 @@ restart:
 

linux/drivers/media/dvb/dvb-core/dvb_frontend.c restart: · line 589

Quoted 5 lines

linux/drivers/media/dvb/dvb-core/dvb_frontend.c +1 -0

 				if (fepriv->state & FESTATE_RETUNE) {
 					dprintk("%s: Retune requested, FESTATE_RETUNE\n", __func__);
+					params = &fepriv->parameters;
 					fepriv->state = FESTATE_TUNED;
 				}

Quoted 2 lines · Manu Abraham

Hi Mathias,

Hi Manu!

Quoted 27 lines

Quoted 17 lines · Matthias Schwarzott

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 <[email protected]>
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.

Quoted 6 lines

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.

Quoted 7 lines

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.