On 08/29/2016 01:49 PM, Andrzej Hajda wrote:
Hi,
On 08/27/2016 11:55 AM, Randy Li wrote:
Hi:
I have been reported that the setting the profile, level and bitrate
through the v4l2 extra controls would not make the encoded result
different. I tried it recently, it is true. Although the h264
Hi,
On 08/27/2016 11:55 AM, Randy Li wrote:
> Hi:
>
>I have been reported that the setting the profile, level and bitrate
> through the v4l2 extra controls would not make the encoded result
> different. I tried it recently, it is true. Although the h264 parser
> would tell me the result hav
This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.
Results of the daily build of media_tree:
date: Mon Aug 29 04:00:15 CEST 2016
git branch: test
git hash: fb6609280db902bd5d34445fba1c926e95e63914
gcc versi
On Sun, Aug 28, 2016 at 09:33:54PM +0100, Chris Wilson wrote:
> On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote:
> > Currently we install a callback for performing poll on a dma-buf,
> > irrespective of the timeout. This involves taking a spinlock, as well as
> > unnecessary work, and
On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote:
> Currently we install a callback for performing poll on a dma-buf,
> irrespective of the timeout. This involves taking a spinlock, as well as
> unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> multiple threads.
From: Randy Dunlap
The problem is that this driver uses a "common" driver supplement
which calls a few dib3000mc*() functions but that driver is not
"select"ed by DVB_USB_DIBUSB_MB. We can fix the build errors by
selecting DVB_DIB3000MC (at the expense of around 8 KB on x86_64)
just to add a few
On Sun, Aug 28, 2016 at 05:37:47PM +0100, Chris Wilson wrote:
> Currently we install a callback for performing poll on a dma-buf,
> irrespective of the timeout. This involves taking a spinlock, as well as
> unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> multiple threads.
Currently we install a callback for performing poll on a dma-buf,
irrespective of the timeout. This involves taking a spinlock, as well as
unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
multiple threads.
We can query whether the poll will block prior to installing the
cal
Hello Bin,
I would like to start new thread on my issue. Let me recall where the issue is:
There is 100% frame lost in pwc webcam driver due to lots of
zero-length packages coming from musb driver.
The issue is present in all kernels (including 4.8) starting from the commit:
f551e13529833e052f75e
