[linux-dvb] Mantis driver: making cu1216.ko work for me
abraham.manu at gmail.com
Tue Feb 20 21:04:31 CET 2007
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.
> 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 ..
> 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)
> 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
More information about the linux-dvb