[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGoCfixdyOJoyUQfMWzM2KHjMGJE5pRS8C0+rR1nDCir7jTpwQ@mail.gmail.com>
Date: Mon, 12 Jan 2015 23:44:23 -0500
From: Devin Heitmueller <dheitmueller@...nellabs.com>
To: Shuah Khan <shuahkh@....samsung.com>
Cc: Mauro Carvalho Chehab <m.chehab@...sung.com>,
Hans Verkuil <hans.verkuil@...co.com>,
Prabhakar Lad <prabhakar.csengg@...il.com>,
"sakari.ailus@...ux.intel.com" <sakari.ailus@...ux.intel.com>,
Laurent Pinchart <laurent.pinchart@...asonboard.com>,
Tim Mester <ttmesterr@...il.com>,
Linux Media Mailing List <linux-media@...r.kernel.org>,
Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v3 3/3] media: au0828 remove video and vbi buffer timeout work-around
Hi Shuah,
On Mon, Jan 12, 2015 at 9:56 PM, Shuah Khan <shuahkh@....samsung.com> wrote:
> au0828 does video and vbi buffer timeout handling to prevent
> applications such as tvtime from hanging by ensuring that the
> video frames continue to be delivered even when the ITU-656
> input isn't receiving any data. This work-around is complex
> as it introduces set and clear timer code paths in start/stop
> streaming, and close interfaces. However, tvtime will hang
> without the following tvtime change:
I'm confused. When we last debated whether this patch would be
accepted, the last message from Mauro said the following:
> That means that we'll need to keep holding such timeout code for
> years, until all distros update to a new tvtime, of course assuming
> that this is the only one application with such issue.
In other words, the timeout code has to stay in there since otherwise
it will cause ABI breakage. It's great that Hans has submitted a
patch to improve tvtime, and over the next couple of years that patch
might actually start to appear in distributions. That unfortunately
doesn't change the fact that everybody who updates their kernel (or
has it updated for them as part of their distribution) will go from
"works fine" to "completely broken".
The driver was working before the VB2 conversion, so if there is now
instability then it's likely that some bug was introduced during the
conversion to VB2. Simply ripping out the timeout code seems like the
wrong approach to addressing a regression likely caused by your own
VB2 conversion patch.
Devin
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists