On 2/22/07, Marko Ristola <marko.ristola@xxxxxxxxxxx> wrote:
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.
mantis-adapter-a2 has the adapter API changes and nor specific to the mantis, it is the mantis.tar.bz2 that which is relevant to the mantis.
>> 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.
I will need to regenerate the tree, after the recent changes.
> >> 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.
i think something went wrong in the mantis tree after my hg downgrade with the mantis tree.
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.
Some more PCI changes are expected in there for the mantis. MANTIS_TS_188 would be the right way to go. Maybe did not test that much, but that's the intended way to go. You can make your changes to the adapter tree in this regard, will pull in the relevant changes to a regenerated tree.
> 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.
Ok.
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.
Ok Thanks. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
