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 versio
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
---
drivers/media/us
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 remove
Em Fri, 21 Mar 2014 18:23:13 +0100
Frank Schäfer 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 their firmware... ?!
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 linux-firmw
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 "unsubscri
On Fri, 21 Mar 2014 14:16:20 +0200, Tomi Valkeinen
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 dtc is not nece
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
> >
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
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 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 b
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 Fri, Mar 21, 2014 at 12:44 PM, Laurent Pinchart
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
>> provide the tea, but I haven
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, Mar
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 s
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-
> core/v
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
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 ca
On Fri, 21 Mar 2014 11:44:24 +0100, Andrzej Hajda wrote:
> On 03/20/2014 06:23 PM, Grant Likely wrote:
> > On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart
> > wrote:
> >> On Tuesday 11 March 2014 14:59:20 Tomi Valkeinen wrote:
> >>> So depending on the use case, the endpoints would point to
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
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
---
arch/arm/boot/dts/am335x-base0033.dts | 28
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: Jean-Fr
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
---
driver
The tda998x being converted to a normal DRM encoder/connector,
there is no slave notion anymore.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/tilcdc/slave.txt | 18 --
1 file changed, 18 deletions(-)
delete mode 100644 Documentation/devicetree/bin
The connection between the video source and sink must follow
the media video interface.
Signed-off-by: Jean-Francois Moine
---
Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/
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
---
Documentation/devicetree/bindings/drm/i2c/tda998x.txt | 11 ++-
1 file ch
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
tree: git://git.monstr.eu/linux-2.6-microblaze xilinx/master-next-hdmi
head: 5a598a20aa7b370b221066b3a480e45461c1537f
commit: 18ab6fd57a81b544d19d5ad85b521ba5752897b4 [451/499] v4l2: add
VIDIOC_G/S_EDID support to the v4l2 core
config: make ARCH=s390 allmodconfig
All error/warnings:
drive
On 03/20/2014 06:23 PM, Grant Likely wrote:
> On Tue, 11 Mar 2014 14:16:37 +0100, Laurent Pinchart
> 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 point of view.
>>>
>>> An
> >>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
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] s5p-mf
From: Pawel Osciak
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
Signed-off-by: Arun Kumar K
---
drivers/media/platform/s5p-mfc/s5p_mfc.c | 19 +---
drivers/media/platform/s5p-mfc/s5p_mfc
From: Pawel Osciak
Currently, we allocate private codec buffers on STREAMON, which may fail
if we are out of memory. We don't check for failure though, which will
make us crash with the codec accessing random memory.
We shouldn't be failing STREAMON with out of memory errors though. So move
the
From: Pawel Osciak
- Honor return values from vb2_reqbufs on REQBUFS(0).
- Do not set the number of allocated buffers to 0 if userspace tries
to request buffers again without freeing them.
- There is no need to verify correct instance state on reqbufs, as we will
verify this in queue_setup(
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
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 ena
On 20/03/14 20:49, Laurent Pinchart wrote:
>> The CPU is the _controlling_ component - it's the component that has to
>> configure the peripherals so they all talk to each other in the right
>> way. Therefore, the view of it needs to be CPU centric.
>>
>> If we were providing a DT description for
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 thing. I'm talking about DT
> > > bindings to represent the topolo
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
Hi,
Thanks for
39 matches
Mail list logo
