[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAM_ZknVjRo0vo2_SLmZSW7R_8LpNkmj-c3q1uBahEa_bSBK0hQ@mail.gmail.com>
Date: Mon, 8 Feb 2016 12:23:57 +0200
From: Andrey Utkin <andrey.utkin@...p.bluecherry.net>
To: Hans Verkuil <hverkuil@...all.nl>
Cc: Linux Media <linux-media@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"kernel-mentors@...enic.com" <kernel-mentors@...enic.com>,
devel@...verdev.osuosl.org,
kernel-janitors <kernel-janitors@...r.kernel.org>,
Mauro Carvalho Chehab <mchehab@....samsung.com>,
Ezequiel Garcia <ezequiel@...guardiasur.com.ar>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Andrey Utkin <andrey.od.utkin@...il.com>
Subject: Re: [RFC PATCH v0] Add tw5864 driver
On Mon, Feb 8, 2016 at 11:58 AM, Hans Verkuil <hverkuil@...all.nl> wrote:
> Hi Andrey,
>
> Hmm, it looks like I forgot to reply. Sorry about that.
Thank you very much anyway.
> I wouldn't change the memcpy: in my experience it is very useful to get a
> well-formed compressed stream out of the hardware. And the overhead of
> having to do a memcpy is a small price to pay and on modern CPUs should
> be barely noticeable for SDTV inputs.
So there's no usecase for scatter-gather approach, right?
> I don't believe that the lockups you see are related to the memcpy as
> such. The trace says that a cpu is stuck for 22s, no way that is related
> to something like that. It looks more like a deadlock somewhere.
There was a locking issue (lack of _irqsave) and was fixed since then.
> Regarding the compliance tests: don't pass VB2_USERPTR (doesn't work well
> with videobuf2-dma-contig). Also add vidioc_expbuf = vb2_ioctl_expbuf for
> the DMABUF support. That should clear up some of the errors you see.
Thank you!
--
Bluecherry developer.
Powered by blists - more mailing lists