[linux-dvb] Mantis driver: making cu1216.ko work for me
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:
>> 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 ..
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
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
>> 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
>> 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
>> 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
> 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
>> 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
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.
More information about the linux-dvb