On Sunday, July 14, 2013 18:44:13 Devin Heitmueller wrote: > On Sun, Jul 14, 2013 at 5:39 PM, Hans Verkuil <hverkuil@xxxxxxxxx> wrote: > >> > If you can get cx25821-video.c to work with vb2, then we can take a look at the alsa > >> > code. > > If I can make a suggestion: fix the lock problem first. That's why I propose to move to vb2 :-) I looked at it for a bit and what makes locking a problem is videobuf in the first place. It's the cause of the locking problems and the solution is to get rid of it. In vb2 I understand at least who is locking what, whereas videobuf is locking and unlocking at the weirdest places. From what I remember it was not really solvable without hacking videobuf, which is something you really don't want to do. Don't ask me the details, it's been a while ago that I looked at this particular issue. I did similar vb2 conversions for go7007 and solo6x10 for pretty much the same reasons: fixing an unmaintainable locking spaghetti. In general I agree with you, but in this particular case moving to vb2 *is* the solution for the problem. Regards, Hans > The last > thing you want to do is simultaneously debug a known buffer management > problem at the same time you're trying to port to VB2. I panic'd my > system enough times during the em28xx conversion where you really want > to know whether the source is the VB2 work in progress or some other > issue with buffer management. > > I'm not saying to not do the VB2 port -- just that you would be well > served to have a reasonable stable driver before attempting to do the > port. > > That said, I guess it's possible that digging into the code enough to > understand what specifically has to be done for a VB2 port might > reveal the source of the locking problem, but that's not how I would > do it. > > Devin > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
