Clock rates are stored in an unsigned long field, but -round_rate()
(which returns a rounded rate from a requested one) returns a long
value (errors are reported using negative error codes), which can lead
to long overflow if the clock rate exceed 2Ghz.
Change -round_rate() prototype to return 0
On 04/15/2015 10:08 PM, Guennadi Liakhovetski wrote:
On Thu, 9 Apr 2015, Hans Verkuil wrote:
From: Hans Verkuil hans.verk...@cisco.com
Replace all calls to the enum_mbus_fmt video op by the pad
enum_mbus_code op and remove the duplicate video op.
Signed-off-by: Hans Verkuil
Fix copy-and-paste errors:
Source - Process
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/Documentation/DocBook/media/v4l/controls.xml
b/Documentation/DocBook/media/v4l/controls.xml
index 4e9462f..6e1667b 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++
On Fri, Apr 17, 2015 at 10:29:08AM +0200, Hans Verkuil wrote:
Fix copy-and-paste errors:
Source - Process
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Thanks!
Acked-by: Sakari Ailus sakari.ai...@linux.intel.com
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP:
Hi Jemma,
Thanks for taking this one. I had this on my list for years.
On Mon, 13 Apr 2015 07:32:15 +0100 Jemma Denson jden...@gmail.com
wrote:
Oh, I was doing this the wrong way then. I did have some preamble to
this but it seems to have been stripped.
Anyway, this patch adds support for
On Thu, Apr 16, 2015 at 08:54:26PM +0200, Luis R. Rodriguez wrote:
Without WC, descriptors would end up as multiple 4B or 8B MWr packets
to the NIC, which has a pretty big performance impact on this
particular NIC.
How big are the descriptors?
Some are 64B (a batch of eight 8B
Hi Chris,
On Thursday 16 April 2015 13:05:30 Chris Whittenburg wrote:
On Tue, Apr 7, 2015 at 10:51 AM, Laurent Pinchart wrote:
Black level compensation is applied by the CCDC before writing raw frames
to memory. If your raw frames are correct BLC is probably not to blame.
The default
On 04/13/2015 03:19 PM, Kamil Debski wrote:
Hi Hans,
Thank you so much for the review.
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Hans Verkuil
Sent: Friday, March 20, 2015 7:08 PM
snip
+In order for a CEC adapter to be configured
Hi Hans,
On Friday 17 April 2015 12:27:41 Hans Verkuil wrote:
On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
Hello,
The v4l2_plane data_offset field has been introduced at the same time as
the the multiplane API to convey header size information between
kernelspace and userspace.
Hi Laurent,
On 04/14/2015 09:44 PM, Laurent Pinchart wrote:
Hello,
The v4l2_plane data_offset field has been introduced at the same time as the
the multiplane API to convey header size information between kernelspace and
userspace.
The API then became slightly controversial, both because
On 17/04/15 10:06, Patrick Boettcher wrote:
I have my Skystar S2 pointed to 19.2E.
That would be great if you could test on that, 28.2E can be a bit
conservative. The parts that I consider need testing are FEC and Pilot
on DVBS2 - I didn't have that much variety in FEC values, and as far as
I
Hi Hans,
On Saturday 21 March 2015 09:41:29 Hans Verkuil wrote:
I've been thinking about extending v4l2-compliance with v4l-subdev tests.
However, there are a few missing pieces that are needed before this can be
done.
First of all is that there is no subdev equivalent to VIDIOC_QUERYCAP,
On Fri, 17 Apr 2015, Tomeu Vizoso wrote:
When the system goes to sleep and afterwards resumes, a significant
amount of time is spent suspending and resuming devices that were
already runtime-suspended.
By setting the power.force_direct_complete flag, the PM core will ignore
the state of
When the system goes to sleep and afterwards resumes, a significant
amount of time is spent suspending and resuming devices that were
already runtime-suspended.
By setting the power.force_direct_complete flag, the PM core will ignore
the state of descendant devices and the device will be let in
v3: * Add a new power.force_direct_complete to let devices express that it's
safe to let them be runtime-suspended at system sleep regardless of the
state
of their descendants
v2: * Let creators of the input device to decide whether it should remain
runtime
(If I fcked something up, apologies in advance).
This is what happens when I reuse .config from 3.19.4 to build 4.0
--
usr/src/linux-4.0
❯ grep BT848 .config
CONFIG_VIDEO_BT848=m
❯ make menuconfig
scripts/kconfig/mconf
Pedja predivan at open.telekom.rs writes:
It might be clearer with a few screenshots.
http://imgur.com/w8nE50e
Proper link (sorry)
https://imgur.com/w8nE50e,nPEbUIr,k18Nr5f#0
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
On Fri, 17 Apr 2015 21:48:33 + (UTC)
Pedja wrote:
snip
Fixed it by enabling CONFIG_MEDIA_RADIO_SUPPORT in Device drivers/Multimedia
support.
Sorry for the noise.
Pedja
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
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: Sat Apr 18 04:00:20 CEST 2015
git branch: test
git hash: e183201b9e917daf2530b637b2f34f1d5afb934d
gcc
19 matches
Mail list logo
