On Wednesday 20 December 2006 12:28, Steven Ellis wrote:
> Hans Verkuil wrote:
> > On Wednesday 20 December 2006 07:45, Steven Ellis wrote:
> >> Hans Verkuil wrote:
> >>> Hi all,
> >>>
> >>> I think it is getting time for people to start testing the ivtv
> >>> trunk from subversion. I've been running it for quite some time
> >>> now and it looks to be pretty solid. Ian Armstrong has added lots
> >>> of goodies in the framebuffer department (be sure to read the
> >>> README notes!), so that can use some testing as well.
> >>>
> >>> Regarding DMA problems: I think that these are solved for the
> >>> PVR500. I haven't yet done a REALLY long duration test but from
> >>> the shorter tests I did it is looking good. The DMA errors still
> >>> occur for other cards: it is a hardware issue with the cx23415/6
> >>> and there probably isn't anything I can do about it. Just don't
> >>> use CPU freq. changers and sometimes using a RAID array also
> >>> messes up the DMA.
> >>>
> >>> The reason that it works for the PVR500 is that the PVR500 has a
> >>> PCI bridge that seems to isolate the cx23416 chips from the main
> >>> PCI bus. It still could fail on the 0.9 drivers due to the way
> >>> DMA was handled in the driver. With the new trunk driver all DMA
> >>> is now done in the interrupt handler.
> >>>
> >>> Note: ivtv trunk requires the 2.6.19 kernel. It is probably very
> >>> easy to backport it to 2.6.18, it may even compile out of the
> >>> box. I just haven't tested it myself. When this driver version is
> >>> released I'll definitely backport it to 2.6.18.
> >>>
> >>> The trunk driver can be obtained here:
> >>>
> >>> http://ivtvdriver.org/viewcvs/ivtv/trunk.tar.gz?view=tar
> >>
> >> Great work Hans. Shame I don't have a machine with a 2.6.19 kernel
> >> running.
> >>
> >> How much of this might be backportable to the 0.4.x branch?
> >> Testing 0.4.9 at present at it seems to work well on my setup, but
> >> I'd like to reduce the DMA issues further.
> >
> > All I can say is that I'm not going to backport this to 0.4.x. I
> > have to make choices where I spend my time, and backporting simply
> > takes too much time. It's not a trivial thing to do. But if someone
> > else would be willing to take this on, then I'm happy to help out.
>
> Given the benefits I might be willing to work on it. At the moment
> I'd love to move all of the myPVR customers to a 2.6.18 kernel but
> there is a lot of regression testing required. Might have some time
> between Christmas and New Year to attempt it if you give me some
> pointers.
Backporting the trunk version to 0.4 will require regression testing in
any case! The backport requires not only backporting ivtv (where the
whole interrupt/DMA core has been replaced) but also the supporting i2c
modules from recent (>= 2.6.18) kernels. Actually, I'm not even sure
that it is possible to backport the i2c modules as that would probably
break existing drivers like bttv. So instead you would probably have to
backport ivtv, but adapt it to the older i2c modules included in
ivtv-0.4. Urgh.
I think you are better off waiting until the ivtv trunk is released, and
then upgrade to a 2.6.18 kernel.
At the moment I am doing a lot of testing to see what sort of features
are provided by the firmware but are not yet exported to the user level
API. Or are exported but are never fully tested. Once that's done I can
start work on designing proper v4l2 APIs for that and start the
discussions on the video4linux mailinglist to get it officially into
the kernel. I hope to get this done early January at the latest.
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
