Re: Regression: v4l/bttv vbi vs iommu

[Dr. David Alan Gilbert]

* Hans Verkuil (hverkuil@xxxxxxxxx) wrote:
> Hi Dave,

Hi Hans,
  I've trimmed the iommu list off now, since we've got past them.

> On 11/11/2023 20:57, Dr. David Alan Gilbert wrote:
> > * Hans Verkuil (hverkuil@xxxxxxxxx) wrote:
> >> On 13/08/2023 15:14, Dr. David Alan Gilbert wrote:
> >>> * Hans Verkuil (hverkuil@xxxxxxxxx) wrote:
> >>>> On 03/02/2023 07:35, Christoph Hellwig wrote:
> >>>>> On Wed, Feb 01, 2023 at 09:48:46PM +0100, Hans Verkuil wrote:
> >>>>>> In fact, the plan is to replace the old and deprecated videobuf framework by the vb2
> >>>>>> framework in the bttv driver in the next 2-3 months or so. That will also automatically
> >>>>>> solve this problem.
> >>>>>
> >>>>> It would be great to expedite removal of the old videbuf code given
> >>>>> how many problems it has.
> >>>>
> >>>> We're working on it. A lot of old drivers in drivers/staging/media/deprecated will
> >>>> be removed in 6.3, and that leaves the cx18, bttv and saa7146 drivers that still use
> >>>> vb1.
> >>>>
> >>>> This week I posted patches converting cx18 to vb2 and someone else will work on the
> >>>> bttv conversion. We thought we could remove saa7146 as well, but it turns out that
> >>>> that is still very much in use (somewhat unexpectedly), so I plan to convert that
> >>>> one this month (I hope).
> >>>>
> >>>> I aim for removing vb1 in kernel 6.4 or 6.5.
> >>>
> >>> Did this go in, I'm happy to give it a go if this is a world to test.
> >>
> >> I just merged it for 6.6.
> > 
> > Hi Hans,
> >   Apologies in the delay, I've just got around to looking at 6.6
> > for this.
> >   I'd say it's looking pretty good, oops free so far.
> > There are a couple of oddities, which I'm not sure are an issue or not:
> > 
> > a) Loss of 'seq' field.
> >   The bttv used to include a sequence number in each vbi line;
> > That now seems to be 0; I don't think it's a big loss, but it was
> > used by some tools to see if they dropped frames, and it's confusing
> > it into moaning about it.
> 
> Hmm, I knew about this, but I thought it was something that the driver did.
> Instead, it turns out it was a videobuf 'feature' in videobuf_read_stream().
> 
> This would affect saa7146 and bttv, since both enabled that. None of the
> other driver with VBI capabilities ever used that, AFAICT.

Yeh I can believe it; the code I'm using from Alistair (cc'd) checks it
to see if you're losing any if on a bttv.

> > b) Frame vs fields
> > 
> > I tend to run xawtv at the same time as dumping vbi; with xawtv grabbing
> > frames, the vbi is showing it grabbing 50fps, if I drop xawtv to
> > no-capture, the vbi is showing it at 25fps; I've not figured out yet if
> > that's actually losing data or just reorganising it.
> > (The reason for running xawtv is that it was found that the AGC on the
> > bttv goes out if you've not got it running sometimes).
> 
> Odd.

Alistair has a neat little test setup generating an image stream;
what that seems to be showing for me is that if I run:

   a) xawtv with 'capture' off in parallel with the VBI read, all is
   good

   b) xawtv with 'capture' to 'grab display' in parallel with the VBI
   read, then the VBI read is getting 'extra' frames in it, where they
   start out as being blank extra frames in between valid ones, but then
   seem to contain an old frame at some point.

   So there's something going on.

> For both items it will have to wait until I have access again to my test
> equipment in 2 weeks.

No rush.

Dave

> Regards,
> 
> 	Hans
> 
> > 
> > Anyway, thanks for fixing the rework that fixed the crash!
> > 
> > Dave
> > 
> > 
> >>
> >> Regards,
> >>
> >> 	Hans
> >>
> 
-- 
 -----Open up your eyes, open up your mind, open up your code -------   
/ Dr. David Alan Gilbert    |       Running GNU/Linux       | Happy  \ 
\        dave @ treblig.org |                               | In Hex /
 \ _________________________|_____ http://www.treblig.org   |_______/