Manu Abraham wrote:
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.
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
*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.
Great.
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:
dvb_dmx_swfilter)
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
cu1216_set_parameters().
I think that global parameters aren't needed for them.
Regards,
Marko
Thanks,
Manu
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
