[linux-dvb] Mantis driver: making cu1216.ko work for me

Marko Ristola marko.ristola at kolumbus.fi
Thu Feb 22 00:17:12 CET 2007

Manu Abraham wrote:
> On 2/20/07, Marko Ristola <marko.ristola at kolumbus.fi> wrote:
>> Manu,
>> Is there a way that how my patches could be applied into the Mantis
>> development tree?
> I did break up your [patches and applied it except for the CU1216 
> related ones.
I took a quick look about http://kromtek.com/dvb/mantis-adapter-a2.tar.bz2.
It is a new version for me. So I'll test it in the following days.

>> Is there some way that they could be delivered into the main Linux
>> development tree some day?
> I have been working a bit hard on the mantis tree, since that tree
> need to be merged alongwith the multiproto tree as well, because of
> the STB0899 on the VP-1041.
> Have been working a bit in that direction, but not there yet ..
> http://kromtek.com/dvb/mantis-adapter-a2.tar.bz2
Here are changes that are needed to compile that tar file with 2.6.19:

mantis-adapter-a2/v4l/config-compat.h:4:26: error: linux/config.h: No 
such file or directory
linux/config.h doesn't exist anymore. Fix: dont include it at least 
since 2.6.18.

mantis-adapter-a2/v4l/flexcop-pci.c:297: warning: passing argument 2 of 
'request_irq' from incompatible pointer type
Since 2.6.19 IRQ handler routine doesn't have the third parameter anymore:
OLD CODE with <= 2.6.18:
static irqreturn_t flexcop_pci_isr(int irq, void *dev_id, struct pt_regs 
NEW CODE with >= 2.6.19:
static irqreturn_t flexcop_pci_isr(int irq, void *dev_id)
There are many these kinds of changes, but the easy
fix to just to remove the regs argument works always for 2.6.19.

mantis-adapter-a2/v4l/bttv-i2c.c:105: error: unknown field 'mdelay' 
specified in initializer
This kind of error can be fixed by removing mdelay completely in kernels 
since 2.6.18.

>> Of course, I need to supply small patches.
>> I've noticed on this list that you use cu1216 also.
>> It would be good, if both my card and yours would work with the same
>> drivers.
>> Maybe there are other cu1216 cards or use cases out there?
>> Maybe it would be good to identify the differing devices somehow to be
>> able to distinguish them?
> I have pulled in changes from what you sent into
> http://kromtek.com/dvb/mantis.tar.bz2
Thank you.

>> Some needed changes:
>> mantis_dma.c: DMA START/STOP: MANTIS_GPIF_ADDR: don't turn 0x3000 (or
>> something) flag off or
>>                         FE_LOCK status reading fails.
> IIRC, this one is a show stopper for all cards. i do remembering
> pulling in this one.
> Since GPIF and I2C are shared, simply turning this on, stops all I2C
> transactions.
> But strange aspect is the prototype cards didn't have an issue with
> this. Probably some issue on the prototype cards.
>> mantis_dma.c: dvb_dmx_swfilter_204 / dvb_dmx_swfilter selection issue:
>>                         I need dvb_dmx_swfilter_204() urgently. How the
>> selection could be
>>                         handled in the driver without every user
>> patching the kernel?
>>                         A module parameter? some other way?
> It is done in an even better way in the tarball, this is based on the
> frontend on the card. (Also done)
Great also, but I suspect that it needs to be fixed:

mantis_dma.c:           (mantis->ts_size ? dvb_dmx_swfilter_204: 
mantis_dvb.c:   mantis->ts_size = 1; //188
mantis_vp1033.c:        .ts_size                = MANTIS_TS_204,
mantis_vp2033.c:        .ts_size        = MANTIS_TS_188,

It seems that mantis_dvb.c hardcodes mantis->ts_size as 1 for me which is
dvb_dmx_swfilter_204. I need dvb_dmx_swfilter though.

Manu, how about fixing the code in the following way:
- remove mantis->ts_size completely from the mantis_pci structure.
- mantis_dma.c should use mantis->hwconfig->ts_size instead.

So then if mantis_vp2033 code activates for me, it would use the correct
MANTIS_TS_188 mode.

>> cu1216.c: I needed some working heuristics to be able to get FE_LOCK.
>> The current Mantis implementation
>> doesn't work for me.
>> My solution was to simplify cu1216.c so that it works with
>> dvb_core.c's own lock acquiring heuristics.
>> - dvb_core.c has the responsibility to figure out correct inversion.
>> - dvb_core.c has the responsibility to figure out when it has a lock.
>> - cu1216.c, parameter setting function must figure out the best gain.
>> - cu1216.c informs dvb_core.c to wait minimum of 50ms for FE_LOCK to
>> come up (settings->min_delay_ms).
> Can you check whether this one exists in there ? I do remember pulling
> in a 50mS delay for the CU1216 after your comment, but the others i
> would appreciate if you can take a look as to whether it needs
> changes.

Unfortunately cu1216.c doesn't yet have a get_tune_settings() function.
I noticed, that the function has been implemented on many other 
dvb/frontend/?.c files though.

I noticed that li_oldIq and li_Iq heuristics is still in cu1216.c.
It didn't work for me. My fix was to remove the inversion heuristics
completely from cu1216_set_parameters().
Instead it used the value from fepriv->inversion.
That's the way to use dvb_core.c's own inversion heuristics.

The "set gain" heuristics works mostly in cu1216_set_parameters().
I moved uc_Gain and uc_oldGain as local parameters for 
I think that global parameters aren't needed for them.


> Thanks,
> Manu

More information about the linux-dvb mailing list