[linux-dvb] commit 9344:aa3a67b658e8 (DVB-Core update) breaks tuning of cx24123
abraham.manu at gmail.com
Mon Oct 27 20:59:04 CET 2008
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 at linuxtv.org>
>>> date: Tue Oct 14 23:34:07 2008 +0400
>>> summary: DVB-Core update
>>> It basically did update the dvb-kernel-thread and enhanced the code using
>>> 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.
More information about the linux-dvb