[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a1f8a9fa-50c6-44e2-9be8-2c0cc60c9906@xs4all.nl>
Date: Mon, 13 Nov 2023 15:38:26 +0100
From: Hans Verkuil <hverkuil@...all.nl>
To: "Dr. David Alan Gilbert" <dave@...blig.org>, a.j.buxton@...il.com
Cc: iommu@...ts.linux.dev, mchehab@...nel.org,
linux-media@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Regression: v4l/bttv vbi vs iommu
Hi Dave,
On 11/11/2023 20:57, Dr. David Alan Gilbert wrote:
> * Hans Verkuil (hverkuil@...all.nl) wrote:
>> On 13/08/2023 15:14, Dr. David Alan Gilbert wrote:
>>> * Hans Verkuil (hverkuil@...all.nl) 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.
>
> 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.
For both items it will have to wait until I have access again to my test
equipment in 2 weeks.
Regards,
Hans
>
> Anyway, thanks for fixing the rework that fixed the crash!
>
> Dave
>
>
>>
>> Regards,
>>
>> Hans
>>
Powered by blists - more mailing lists