Hi Damiano,
On Thursday 11 June 2015 14:28:55 Damiano Albani wrote:
> Hello,
>
> I've recently got hold of a Logitech C930e webcam.
> AFAIK that's the only consumer webcam that support UVC 1.5 and H.264/SVC.
> Unfortunately, compared to its predecessor the C920, it is not very well
> supported on
The last CVT standard introduced reduced blanking version 2 which is signaled by
a vsync of 8. Log this.
Signed-off-by: Hans Verkuil
diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c
b/drivers/media/v4l2-core/v4l2-dv-timings.c
index eefad4f..5d9e896 100644
--- a/drivers/media/v4l2-core/v4l
On Thu, Jun 11, 2015 at 10:27:30PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> Thank you for the patch.
>
> On Thursday 11 June 2015 22:18:01 Sakari Ailus wrote:
> > V4L2 async sub-devices are currently matched (OF case) based on the struct
> > device_node pointer in struct device. LED device
On 06/03/2015 03:59 PM, William Towle wrote:
> This adds V4L2_MBUS_FMT_RGB888_1X24 input format support
> which is used by the ADV7612 chip.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Simon Horman
> Signed-off-by: Yoshihiro Kaneko
>
> Modified to use MEDIA_BUS_FMT_* constants
>
> Signe
On 06/03/2015 03:59 PM, William Towle wrote:
> From: Ben Dooks
>
> Add a proper of match id for use when the device is being bound via
> device tree, to avoid having to use the i2c old-style binding of the
> device.
>
> Signed-off-by: Ben Dooks
> Signed-off-by: William.Towle
> Reviewed-by: Rob
On 06/03/2015 03:59 PM, William Towle wrote:
> From: Ian Molton
>
> Adds support to the adv7604 driver for specifying the default input
> port in the Device tree. If no value is provided, the driver will be
> unable to select an input without help from userspace.
>
> Tested-by: William Towle
>
On 06/03/2015 03:59 PM, William Towle wrote:
> From: Ian Molton
>
> This documentation accompanies the patch adding support for the ADV7612
> dual HDMI decoder / repeater chip.
>
> Signed-off-by: Ian Molton
> Reviewed-by: William Towle
Acked-by: Hans Verkuil
> ---
> .../devicetree/bindings
Hi William,
Two comments, see below.
On 06/03/2015 03:59 PM, William Towle wrote:
> Add support for the ADV7612 chip as implemented on Renesas' Lager
> board to adv7604.c, including lists for formats/colourspace/timing
> selection and an IRQ handler.
>
> Signed-off-by: William Towle
> ---
> dr
On 06/11/2015 03:54 PM, Borislav Petkov wrote:
> On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
>> From: "Luis R. Rodriguez"
>>
>> There is no good reason not to, we eventually delete it as well.
>>
>> Cc: Toshi Kani
>> Cc: Roland Dreier
>> Cc: Sean Hefty
>> Cc: Hal Rosensto
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: Fri Jun 12 04:00:19 CEST 2015
git branch: test
git hash: e42c8c6eb456f8978de417ea349eef676ef4385c
gcc versi
On Thu, Jun 11, 2015 at 05:23:16PM -0600, Toshi Kani wrote:
> On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
> :
> > Pending RIP MTRR patches
> >
> >
> > There are a few pending series so I wanted to provide a status update
> > on those series.
> >
> > mtrr: bur
On Thu, 2015-06-11 at 13:36 -0700, Luis R. Rodriguez wrote:
:
> Pending RIP MTRR patches
>
>
> There are a few pending series so I wanted to provide a status update
> on those series.
>
> mtrr: bury MTRR - unexport mtrr_add() and mtrr_del()
>
> This is the nail on the MTRR
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
The series to bury direct MTRR use is almost all in and on its way to
v4.2. As the pending series continue slowly to be merged I wanted to
take the time to reiterate the justification for these changes in
hopes it may help those still reviewing some of these patches which
are pending and to help do
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
C
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
Boris,
the following patches make use of the newly exported pat_enabled()
which went in through your tree. All driver and respective subsystem
maintainers have Acked these patches and are OK for them to go in through
your tree. Please let me know if there any issues or
> Could you please send me the output of 'lsusb -v -d 045e:07be' and
> 'lsusb -v -
> d 045e:07bf' (running as root if possible) ?
Bus 001 Device 004: ID 045e:07bf Microsoft Corp.
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 2.00
bDeviceClas
On Thu, Jun 11, 2015 at 10:49:59AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> Mauro,
>
> since the ivtv patch is already acked by the driver maintainer
> and depends on an x86 symbol that went through Boris' tree are you
> OK in it going through Boris' tree?
Sorry I resent
On Thu, Jun 11, 2015 at 10:50:01AM -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> There is no good reason not to, we eventually delete it as well.
>
> Cc: Toshi Kani
> Cc: Roland Dreier
> Cc: Sean Hefty
> Cc: Hal Rosenstock
> Cc: Suresh Siddha
> Cc: Ingo Molnar
> Cc: Thoma
On 06/11/2015 08:54 PM, Andrew Morton wrote:
> On Thu, 11 Jun 2015 11:08:47 +0200 Hans Verkuil wrote:
>
>> I discovered a regression on a prerequisite patch merged in the media
>> tree that until solved prevents parts of this patch series from going in.
>>
>> See: http://www.mail-archive.com/linu
Le 11/06/2015 15:28, Vladimir Zapolskiy a écrit :
> To be consistent with other genalloc interface namings, rename
> dev_get_gen_pool() to gen_pool_get(). The original omitted "dev_"
> prefix is removed, since it points to argument type of the function,
> and so it does not bring any useful informa
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen wrote:
> This reverts commit ad90b6b0f10566d4a5546e27fe455ce3b5e6b6c7.
>
> This patch breaks I2C communication towards Si2168. After reverting and
> applying the other patch in this series the I2C communication is
> correct.
Tested-By: Steven Toth
Ch
On Sat, Jun 6, 2015 at 3:44 AM, Olli Salonen wrote:
> The i2c_reg_len for Si2168 should be 0 for correct I2C communication.
>
> Signed-off-by: Olli Salonen
Tested-By: Steven Toth
Checked with a HVR-2205 and a HVR-2215, firmware loads as expected.
--
Steven Toth - Kernel Labs
http://www.kerne
Hi Sakari,
Thank you for the patch.
On Thursday 11 June 2015 22:18:01 Sakari Ailus wrote:
> V4L2 async sub-devices are currently matched (OF case) based on the struct
> device_node pointer in struct device. LED devices may have more than one
> LED, and in that case the OF node to match is not dir
On Thu, Jun 11, 2015 at 2:58 PM, Jeff Allen wrote:
> Thanks, I did that and it is working now. However, I ran into another
> problem. The card will not scan any channels. I live in the Chicago area
> and my cable provider is Wowway. Wowway requires a main set top box and
> digital adapters for
V4L2 async sub-devices are currently matched (OF case) based on the struct
device_node pointer in struct device. LED devices may have more than one
LED, and in that case the OF node to match is not directly the device's
node, but a LED's node.
Signed-off-by: Laurent Pinchart
Signed-off-by: Sakari
Hi Josh,
On Thu, 11 Jun 2015, Josh Wu wrote:
> Hi, Guennadi
>
> Any feedback for this patch series?
Sorry, I haven't found the time to look at patches from you and William
Towle, they are at the top of my todo list now - after all the compulsory
things, of course. I'll handle them as soon as
On Thu, 11 Jun 2015 11:08:47 +0200 Hans Verkuil wrote:
> I discovered a regression on a prerequisite patch merged in the media
> tree that until solved prevents parts of this patch series from going in.
>
> See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html
>
> Jan is on
On Fri, Jun 5, 2015 at 9:40 AM, Olli Salonen wrote:
> Hi Steven,
>
> It seems to me that that part of the code is identical to your driver, no?
Sorry for the noise. I'm been swamped with a couple of things and just
getting back to the ML now.
You are correct.
--
Steven Toth - Kernel Labs
http:
On Wed, Jun 10, 2015 at 1:23 PM, Jeff Allen wrote:
> I am trying to get the firmware to load on a fresh install of Ubuntu 15.04
> desktop 64-bit on a new system.
>
> uname -a
> Linux 3.19.0-15-generic #15-Ubuntu SMP Thu Apr 16 23:32:37 UTC 2015 x86_64
> x86_64 x86_64 GNU/Linux
That's not going to
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Toshi Kani
Cc: Roland Dreier
Cc: Sean Hefty
Cc: Hal Rosenstock
Cc: Suresh Siddha
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
C
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
From: "Luis R. Rodriguez"
Mauro,
since the ivtv patch is already acked by the driver maintainer
and depends on an x86 symbol that went through Boris' tree are you
OK in it going through Boris' tree?
Boris,
provided the outcome of the above maintainer's preference for you
to merge these please
From: "Luis R. Rodriguez"
We are burrying direct access to MTRR code support on
x86 in order to take advantage of PAT. In the future we
also want to make the default behaviour of ioremap_nocache()
to use strong UC, use of mtrr_add() on those systems
would make write-combining void.
In order to h
On 06/11/15 06:21, Laurent Pinchart wrote:
> Hello,
>
> (CC'ing Tomi Valkeinen)
>
> On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote:
>> From: Jan Kara
>>
>> Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
>> hand made mapping of virtual address to physica
On Mon, Jun 08, 2015 at 09:57:12PM -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 08 Jun 2015 17:20:19 -0700
> "Luis R. Rodriguez" escreveu:
>
> > From: "Luis R. Rodriguez"
> >
> > Mauro,
> >
> > since the ivtv patch is already acked by the driver maintainer
> > and depends on an x86 symbol tha
Thanks for confirming the HVR-955Q SNR and other data is available via
the DVBv5 API.
Before switching my signal/antenna test programs to DVBv5, 'll see if
I can figure out why the dvb-fe-tool is not returning the SNR data and
error rate statistics from the HVR-955Q even though it does return
this
Hi Dennis,
On Tuesday 09 June 2015 18:40:41 Dennis Chen wrote:
> > Is this needed ? Looking at the patch your cameras are UVC-compliant
> > and should thus be picked by the uvcvideo driver without any change to
> > the code.
>
> The cameras are UVC-compliant but are not recognized by the uvc driv
Hello,
On Wednesday 10 June 2015 13:00:20 Masanari Iida wrote:
> On Wed, Jun 10, 2015 at 7:27 AM, Mauro Carvalho Chehab wrote:
> > Em Wed, 27 May 2015 15:05:42 +0300
> >
> > Laurent Pinchart escreveu:
> >> Even though 'compatability' has a dedicated entry in the Wiktionary,
> >> it's listed as '
Hi Michael,
On Sunday 07 June 2015 17:35:48 Michael Allwright wrote:
> Thanks for the patch Laurent!
>
> I have found out now what I have missed, I did not declare the DMA
> channels in my DT. I'm now able to capture frames at 720p. VGA and
> QVGA frames are coming out grainy and discoloured for
Hello,
(CC'ing Tomi Valkeinen)
On Wednesday 10 June 2015 06:20:45 Mauro Carvalho Chehab wrote:
> From: Jan Kara
>
> Convert omap_vout_uservirt_to_phys() to use get_vaddr_pfns() instead of
> hand made mapping of virtual address to physical address. Also the
> function leaked page reference from
To be consistent with other kernel interface namings, rename
of_get_named_gen_pool() to of_gen_pool_get(). In the original
function name "_named" suffix references to a device tree property,
which contains a phandle to a device and the corresponding
device driver is assumed to register a gen_pool o
Trivial nonfunctional change initially based on discussion
https://lkml.org/lkml/2015/6/8/588
Worth to mention that instead of the assumed new name
dev_gen_pool_get(), this change attempts to be more close to other
in-kernel interfaces and new function name is just gen_pool_get().
The change is b
To be consistent with other genalloc interface namings, rename
dev_get_gen_pool() to gen_pool_get(). The original omitted "dev_"
prefix is removed, since it points to argument type of the function,
and so it does not bring any useful information.
Signed-off-by: Vladimir Zapolskiy
---
arch/arm/ma
Hello,
I've recently got hold of a Logitech C930e webcam.
AFAIK that's the only consumer webcam that support UVC 1.5 and H.264/SVC.
Unfortunately, compared to its predecessor the C920, it is not very
well supported on Linux.
For example, the H.264 capability doesn't appear in the list of formats:
Acked-by: Fabien Dessenne
> -Original Message-
> From: Mauro Carvalho Chehab [mailto:mche...@osg.samsung.com]
> Sent: jeudi 11 juin 2015 12:37
> To: Fabien DESSENNE
> Cc: Linux Media Mailing List; Mauro Carvalho Chehab
> Subject: Re: [PATCH 2/2] [media] bdisp-debug: don't try to divide by
Klientskie bazi tel +79133913837 Email: nonen2...@gmail.com ICQ:6288862 Yznaite
podrobnee!!!
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Fabien,
Em Thu, 11 Jun 2015 11:26:22 +0200
Fabien DESSENNE escreveu:
> Hi Mauro,
>
> Please check my comments below.
>
> > -Original Message-
> > From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> > ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
> > Sent: merc
Hi Mauro,
Please check my comments below.
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
> Sent: mercredi 10 juin 2015 22:59
> To: Linux Media Mailing List
> Cc: Mauro Carvalho Chehab; Mauro C
Hi Andrew,
I discovered a regression on a prerequisite patch merged in the media
tree that until solved prevents parts of this patch series from going in.
See: http://www.mail-archive.com/linux-media@vger.kernel.org/msg89538.html
Jan is on vacation, and I don't know if I have time this weekend t
Jan,
This patch causes a regressing in videobuf2-dma-sg with a potential deadlock:
[ 82.290231] ==
[ 82.290232] [ INFO: possible circular locking dependency detected ]
[ 82.290235] 4.1.0-rc3-tb1 #12 Not tainted
[ 82.290236] -
Acked-by: Fabien Dessenne
> -Original Message-
> From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
> ow...@vger.kernel.org] On Behalf Of Mauro Carvalho Chehab
> Sent: mercredi 10 juin 2015 17:35
> To: Linux Media Mailing List
> Cc: Mauro Carvalho Chehab; Mauro Carvalho Chehab
>
lo lo,
I would like to use my Pinnacle Dazzle DVC usb encoder with kernels
3.10-4.0, but I'm getting the same error all the time.
Latest working kernel is the 3.4 line.
What happend with the driver?
dmesg
Description: Binary data
On (06/10/15 06:20), Mauro Carvalho Chehab wrote:
[..]
> +
> +/**
> + * frame_vector_destroy() - free memory allocated to carry frame vector
> + * @vec: Frame vector to free
> + *
> + * Free structure allocated by frame_vector_create() to carry frames.
> + */
> +void frame_vector_destroy(struct
55 matches
Mail list logo
