On 2/20/07, Marko Ristola <marko.ristola@xxxxxxxxxxx> 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.
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
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
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)
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.
Thanks,
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
