Re: [ivtv-devel] vbi device numbering with the pvr350
On Mon, 2005-11-21 at 23:00 +0100, Hans Verkuil wrote: The first drawback can be countered by the fact that ivtv is still an unofficial driver with a 0.x version number. People using it should expect some changes every now and then. (So I hope to get this change accepted before ivtv is included in the main kernel). It won't be before 2.6.17 at the earliest before ivtv is in shape for such a step. And this is very optimistic indeed. But it is the working goal right now, even if it is a fairly long term goal? Yes, definitely. The audio/video drivers are already in the 2.6.15 kernel. There is just so much cleaning up to do. I am also waiting for some new code to be merged from the Japanese branch. That has to be done first before I can start the cleanup process. The second drawback is just an extra motivation for people to update their kernel, so I wouldn't take it too serious. If people have no big objections I will implement a patch that does these changes and post it here. Sure! Please make a ticket for it and attach the patch (ivtvdriver.org/trac). That way it isn't lost in the noise. I assume I make the patch against trunk? or 0.5.0? Trunk is easiest, I think. Regards, Sigmund A. Helberg P.S the README.devices say the maximum number of cards is 12. We failed even booting with more than 8, is this because of the pvr350 itself, or is it a problem with the chipset on our box? Someone mentioned something about lacking interrupt sharing. Interrupt sharing should work fine. Does the boot fail as soon as the ivtv driver is loaded? If it's before that then it has nothing to do with ivtv. We managed to go from 5 to 8 cards by modifing the driver, so the problem with more than 8 cards is definitly not in the driver. What modification? The vbi minor numbering? I have not personally tried this excersice (and will not be able to, unfortunatly), but from what I understand it did not even get past POST. And how do you manage to cram more than 8 pvr350 cards into one PC? Very simply by using a pc with more than 8 pci slots. I didn't know they existed. I thought you were using an external PCI box (don't know the correct name but we have one at work). Note that the ivtv-fb driver is probably buggy when used with more than 1 PVR350 (globals in the driver, haven't gotten around to removing them), so you shouldn't load that one. We haven't used it at least, if modprobe ivtv will drag it in as well it is probably some there, but I don't think it is No, you have to load it explicitly. Hans ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] vbi device numbering with the pvr350
On Tue, 2005-11-22 at 10:20 +0100, Hans Verkuil wrote: The second drawback is just an extra motivation for people to update their kernel, so I wouldn't take it too serious. If people have no big objections I will implement a patch that does these changes and post it here. Sure! Please make a ticket for it and attach the patch (ivtvdriver.org/trac). That way it isn't lost in the noise. I assume I make the patch against trunk? or 0.5.0? Trunk is easiest, I think. Ticket #57 filed with patch attached. Hope I got it right. Regards, Sigmund A. Helberg P.S the README.devices say the maximum number of cards is 12. We failed even booting with more than 8, is this because of the pvr350 itself, or is it a problem with the chipset on our box? Someone mentioned something about lacking interrupt sharing. Interrupt sharing should work fine. Does the boot fail as soon as the ivtv driver is loaded? If it's before that then it has nothing to do with ivtv. We managed to go from 5 to 8 cards by modifing the driver, so the problem with more than 8 cards is definitly not in the driver. What modification? The vbi minor numbering? The change that made the difference was in in videodev.c of v4l, and is allready applied there. It to was related to vbi devices, but in a slightly different fashion. That change along with this one is imo the clean fix. I have not personally tried this excersice (and will not be able to, unfortunatly), but from what I understand it did not even get past POST. And how do you manage to cram more than 8 pvr350 cards into one PC? Very simply by using a pc with more than 8 pci slots. I didn't know they existed. I thought you were using an external PCI box (don't know the correct name but we have one at work). Perhaps this is something in between. It is a picmg passive backplane with lots of slots, and a single board computer connected in one of them. Sigmund ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel ___ ivtv-devel mailing list ivtv-devel@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel
Re: [ivtv-devel] vbi device numbering with the pvr350
On Monday 21 November 2005 12:06, Sigmund Augdal Helberg wrote:
Currently the base device numbers for everything except vbi* is at
steps of 8. This means that if you put more than 4 pvr350-cards in
the same box the vbi device numbers become all messed up. With a
recently accepted patch to v4l the number of vbi devices is increased
to allow more than five pvr350-cards simultaneous. With this patch
there should be enough vbi devices to allow changing the vbi base
devices to go from vbi{0,4,8} to vbi{0,8,16}, so that the correct vbi
device could still be easily found when more than 4 cards are
available.
Some obvious drawbacks with such a change:
* Existing software using vbi4 and vbi8 might break
I am not aware of the existance of such software, and anyway, no
software may assume fixed vbi devices, it should always to possible to
specify them explicitly.
* Device numbering will be screwed up for people using up-to-speed
ivtv with outdated v4l
Their problem :-)
The first drawback can be countered by the fact that ivtv is still an
unofficial driver with a 0.x version number. People using it should
expect some changes every now and then. (So I hope to get this change
accepted before ivtv is included in the main kernel).
It won't be before 2.6.17 at the earliest before ivtv is in shape for
such a step. And this is very optimistic indeed.
The second drawback is just an extra motivation for people to update
their kernel, so I wouldn't take it too serious.
If people have no big objections I will implement a patch that does
these changes and post it here.
Sure! Please make a ticket for it and attach the patch
(ivtvdriver.org/trac). That way it isn't lost in the noise.
Regards,
Sigmund A. Helberg
P.S the README.devices say the maximum number of cards is 12. We
failed even booting with more than 8, is this because of the pvr350
itself, or is it a problem with the chipset on our box? Someone
mentioned something about lacking interrupt sharing.
Interrupt sharing should work fine. Does the boot fail as soon as the
ivtv driver is loaded? If it's before that then it has nothing to do
with ivtv. And how do you manage to cram more than 8 pvr350 cards into
one PC? Note that the ivtv-fb driver is probably buggy when used with
more than 1 PVR350 (globals in the driver, haven't gotten around to
removing them), so you shouldn't load that one.
Hans
___
ivtv-devel mailing list
ivtv-devel@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
