On 03/14/2014 10:04 PM, Alexey Khoroshilov wrote:
There is request_irq() in init_device(), but the interrupt is not removed
on failure paths. The patch adds proper error handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
On Fri, 21 Mar 2014 00:26:12 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Thursday 20 March 2014 23:12:50 Grant Likely wrote:
On Thu, 20 Mar 2014 19:52:53 +0100, Laurent Pinchart wrote:
Then we might not be talking about the same thing. I'm talking about DT
On 03/20/2014 04:34 PM, Lee Jones wrote:
On Thu, 20 Mar 2014, Jacek Anaszewski wrote:
This patch adds led-flash support to Maxim max77693 chipset.
Device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for Multimedia Framework is
On 03/20/2014 04:28 PM, Richard Purdie wrote:
On Thu, 2014-03-20 at 15:51 +0100, Jacek Anaszewski wrote:
Some LED devices support two operation modes - torch and
flash. This patch provides support for flash LED devices
in the LED subsystem by introducing new sysfs attributes
and kernel internal
This patch series contain some fixes and cleanups done to the
s5p-mfc decoder in reqbuf, streamon and open/close commands. These
patches are present in the ChromeOS tree and just rebased onto the
media-tree and tested.
Pawel Osciak (3):
[media] s5p-mfc: Fixes for decode REQBUFS.
[media]
From: Pawel Osciak posc...@chromium.org
This is in preparation for a new flow to fix issues with streamon, which
should not be allocating buffer memory.
Signed-off-by: Pawel Osciak posc...@chromium.org
Signed-off-by: Arun Kumar K arun...@samsung.com
---
drivers/media/platform/s5p-mfc/s5p_mfc.c
This patch adds led-flash support to Maxim max77693 chipset.
Device can be exposed to user space through LED subsystem
sysfs interface or through V4L2 subdevice when the support
for Multimedia Framework is enabled. Device supports up to
two leds which can work in flash and torch mode. Leds
On 03/20/2014 06:23 PM, Grant Likely wrote:
On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
So depending on the use case, the endpoints would point to opposite
direction from the encoder's
According to the media video interface, the video source and sink
ports must be identified by mutual phandles.
This patch adds the 'port' property of the tda998x (sink side).
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
Changing the tda998x driver to a simple encoder/connector simplifies
the code of the tilcdc driver. This change is permitted by
Russell's infrastructure for componentised
The connection between the video source and sink must follow
the media video interface.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git
The tda998x being converted to a normal DRM encoder/connector,
there is no slave notion anymore.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 --
1 file changed, 18 deletions(-)
delete mode 100644
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector and the tilcdc_slave glue being removed, the
declaration of the HDMI transmitter description must be changed in
the associated DTs.
Signed-off-by: Jean-Francois Moine moin...@free.fr
---
The tda998x being moved from a 'slave encoder' to a normal DRM
encoder/connector, the tilcdc_slave glue is not needed anymore.
This patch uses the infrastructure for componentised subsystems
for waiting to the tda998x full start and to give it the pointer
to the DRM device.
Signed-off-by:
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
This patch changes the driver to a normal DRM encoder/connector
thanks to the infrastructure for componentised subsystems.
Signed-off-by: Jean-Francois Moine
On Fri, Mar 21, 2014 at 11:27:45AM +0100, Jean-Francois Moine wrote:
The 'slave encoder' structure of the tda998x driver asks for glue
between the DRM driver and the encoder/connector structures.
Given how close we are to the coming merge window, that the discussion
about the of-graph bindings
On Fri, 21 Mar 2014 11:44:24 +0100, Andrzej Hajda a.ha...@samsung.com wrote:
On 03/20/2014 06:23 PM, Grant Likely wrote:
On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
So depending on
On 20/03/14 19:01, Grant Likely wrote:
I think depending on a generic graph walk is where I have the biggest
concern about the design. I don't think it is a good idea for the master
device to try a generic walk over the graph looking for other devices
that might be components because it
On 21/03/14 13:47, Grant Likely wrote:
I'm firm on the opinion that the checking must also happen at runtime.
The biggest part of my objection has been how easy it would be to get a
linkage out of sync, and dtc is not necessarily the last tool to touch
the dtb before the kernel gets booted. I
On Fri, Mar 07, 2014 at 12:24:33AM +0100, Laurent Pinchart wrote:
However, we (as in the V4L2 community, and me personally) would have
appreciated to be CC'ed on the proposal. As you might know we already had a
solution for this problem, albeit V4L2-specific, in drivers/media/v4l2-
Hi Grant,
On Friday 21 March 2014 08:15:34 Grant Likely wrote:
On Fri, 21 Mar 2014 00:26:12 +0100, Laurent Pinchart wrote:
On Thursday 20 March 2014 23:12:50 Grant Likely wrote:
On Thu, 20 Mar 2014 19:52:53 +0100, Laurent Pinchart wrote:
Then we might not be talking about the same
Devin and myself will be in San Jose all week, although we do have
existing plans for May 2nd.
If we can fit the mini-summit in then we will, or we'll catch up with
individual people during the conference itself.
Best,
- Steve
--
Steven Toth - Kernel Labs
http://www.kernellabs.com
On Wed,
On Fri, Mar 21, 2014 at 12:44 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
Hi Grant,
On Friday 21 March 2014 08:15:34 Grant Likely wrote:
Why don't we instead try a Google Hangout or a phone call today.
Anywhere between 11:30 and 14:00 GMT would work for me. I'd offer to
On 21/03/14 00:32, Laurent Pinchart wrote:
The OF graph bindings documentation could just specify the ports node as
optional and mandate individual device bindings to specify it as mandatory or
forbidden (possibly with a default behaviour to avoid making all device
bindings too verbose).
On 21/03/14 14:37, Tomi Valkeinen wrote:
On 21/03/14 00:32, Laurent Pinchart wrote:
The OF graph bindings documentation could just specify the ports node as
optional and mandate individual device bindings to specify it as mandatory
or
forbidden (possibly with a default behaviour to
Hi Tomi,
On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote:
On 21/03/14 00:32, Laurent Pinchart wrote:
The OF graph bindings documentation could just specify the ports node as
optional and mandate individual device bindings to specify it as mandatory
or forbidden (possibly with a
On 21/03/14 16:13, Laurent Pinchart wrote:
Hi Tomi,
On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote:
On 21/03/14 00:32, Laurent Pinchart wrote:
The OF graph bindings documentation could just specify the ports node as
optional and mandate individual device bindings to specify it as
Hi Tomi,
On Friday 21 March 2014 16:22:52 Tomi Valkeinen wrote:
On 21/03/14 16:13, Laurent Pinchart wrote:
On Friday 21 March 2014 15:37:17 Tomi Valkeinen wrote:
On 21/03/14 00:32, Laurent Pinchart wrote:
The OF graph bindings documentation could just specify the ports node as
optional
On Fri, 21 Mar 2014 14:16:20 +0200, Tomi Valkeinen tomi.valkei...@ti.com
wrote:
On 21/03/14 13:47, Grant Likely wrote:
I'm firm on the opinion that the checking must also happen at runtime.
The biggest part of my objection has been how easy it would be to get a
linkage out of sync, and
Hi,
are there any reasons why the xc2028/3028 firmware files are not
included in the linux-firmware tree ?
The xc5000 firmware is already there, so it seems Xceive|has nothing
against| redistribution of their firmware... ?!
Regards,
Frank
--
To unsubscribe from this list: send the line
Hi Frank,
I specifically asked for and received permission from
Xceive/CrestaTech to make the xc5000 firmware freely redistributable.
They were unwilling to entertain that though for the xc2028/3028 as
they considered it a long deprecated product.
In order to include firmware blobs in
Em Fri, 21 Mar 2014 18:23:13 +0100
Frank Schäfer fschaefer@googlemail.com escreveu:
Hi,
are there any reasons why the xc2028/3028 firmware files are not
included in the linux-firmware tree ?
The xc5000 firmware is already there, so it seems Xceive|has nothing
against| redistribution of
On 03/11/2014 12:39 AM, Jonathan McCrohan wrote:
Hi Oliver,
On Thu, 06 Feb 2014 09:25:14 +0100, Quentin Glidic wrote:
Hello,
When building dvb-apps from the Mercurial repository, you hit the
following error:
install: cannot stat 'atsc/*': No such file or directory
Can you test it now? I
Change em28xx_scaler_set() to use em28xx_reg_len() to get register
lengths for EM28XX_R30_HSCALELOW and EM28XX_R32_VSCALELOW registers,
instead of hard-coding the length. Moved em28xx_reg_len() definition
for it to be visible to em28xx_scaler_set().
Signed-off-by: Shuah Khan shuah...@samsung.com
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 Mar 22 04:00:13 CET 2014
git branch: test
git hash: ed97a6fe5308e5982d118a25f0697b791af5ec50
gcc
35 matches
Mail list logo
