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: Tue May 23 05:00:28 CEST 2017
media-tree git hash:36bcba973ad478042d1ffc6e89afd92e8bd17030
media_build gi
On Mon, 2017-05-22 at 16:16 +0200, Hans Verkuil wrote:
> On 05/22/2017 04:14 PM, Matthias Brugger wrote:
> >
> >
> > On 22/05/17 11:09, Hans Verkuil wrote:
> >> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:
> >>
> >> Who should take care of the dtsi changes? I'm not sure who maintains the
> >> md
From: Daniel Kurtz
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifie
Changes in v4:
- Add backwards compability if dts is out-of-date
Changes in v3:
- Upload patches again because forget to add v2 in title
Changes in v2:
- Update commit message
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu a
From: Daniel Kurtz
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifie
If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.
Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems. This also simplifies the
device tree.
A
On Tue, May 16, 2017 at 02:56:22PM +0200, Benjamin Gaignard wrote:
Commit message?
Preferred subject prefix is "dt-bindings: media: ..."
> Signed-off-by: Benjamin Gaignard
> ---
> .../devicetree/bindings/media/st,stm32-cec.txt| 19
> +++
> 1 file changed, 19 insertions
Fix warning issued by sparse: Using plain integer as NULL pointer
Signed-off-by: Paolo Cretaro
---
drivers/staging/media/atomisp/i2c/ov5693/ov5693.c | 2 +-
.../media/atomisp/pci/atomisp2/css2400/runtime/bufq/src/bufq.c| 2 +-
.../media/atomisp/pci/atomisp2/css2400/ru
On Mon, May 01, 2017 at 06:10:12PM +0200, David Härdeman wrote:
> Leave repeat handling to rc-core.
>
> Signed-off-by: David Härdeman
> ---
> drivers/media/rc/ir-sanyo-decoder.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/rc/ir-sanyo-decod
On Mon, May 01, 2017 at 06:10:06PM +0200, David Härdeman wrote:
> Obvious fix, leave repeat handling to rc-core
>
> Signed-off-by: David Härdeman
> ---
> drivers/media/rc/ir-nec-decoder.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/media/rc/ir-n
On Mon, May 01, 2017 at 06:04:42PM +0200, David Härdeman wrote:
> Using the kernel ida facilities, we can avoid a lot of unnecessary code and
> at the same
> time get rid of lirc_dev_lock in favour of per-device locks (the irctls array
> was used
> throughout lirc_dev so this patch necessarily to
From: Robb Glasser
The size of uvc_control_mapping is user controlled leading to a
potential heap overflow in the uvc driver. This adds a check to verify
the user provided size fits within the bounds of the defined buffer
size.
Signed-off-by: Robb Glasser
[groeck: cherry picked from
https://so
From: Kieran Bingham
Devices supporting multiple endpoints on a single device node must set
their subdevice fwnode to the endpoint to allow distinct comparisons.
Adapt the match_fwnode call to compare against the provided fwnodes
first, but also to search for a comparison against the parent fwno
From: Kieran Bingham
As devices become more complicated, it becomes necessary (and more
accurate) to match devices based on their endpoint, as devices may
have multiple subdevices.
To support using endpoints in the V4L2 async subdev framework, while
some devices still use their device fwnode, we
From: Kieran Bingham
Provide a helper to obtain the parent device fwnode without first
parsing the remote-endpoint as per fwnode_graph_get_remote_port_parent.
Signed-off-by: Kieran Bingham
---
v2:
- Rebase on top of Sakari's acpi-graph-clean branch and simplify
v3:
- Fix up kerneldoc
- Get
Reviewing my own post:
On 19/05/17 17:16, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Devices supporting multiple endpoints on a single device node must set
> their subdevice fwnode to the endpoint to allow distinct comparisons.
>
> Adapt the match_fwnode call to compare against the provid
Hi Sakari,
On 19/05/17 22:51, Sakari Ailus wrote:
> Hi Kieran,
>
> On Fri, May 19, 2017 at 05:16:02PM +0100, Kieran Bingham wrote:
>> +struct fwnode_handle *
>> +fwnode_graph_get_port_parent(struct fwnode_handle *endpoint)
>> +{
>> +return fwnode_call_ptr_op(endpoint, graph_get_port_parent);
The hardware codec is not colorspace aware. We should trust userspace to
set the correct colorimetry information on the OUTPUT queue and mirror
the exact same setting on the CAPTURE queue.
There is no reason to restrict colorspace to JPEG or REC709 only. Also,
set the default colorspace, as return
Hi Laurent,
On 18/05/17 15:01, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Wednesday 17 May 2017 16:03:39 Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Devices supporting multiple endpoints on a single device node must set
>> their subdevice fwnode to the endp
Hi Mauro,
I would like this series to go in the same pull-request to the DRM tree as the
previous series you acked.
Again, the series touches both V4L2, and DRM, to provide another fix up the
Rcar-DU driver.
I have reviewed and tested the whole series
Would it be possible to get your Acked-by:
From: Magnus Damm
On Gen2 hardware the VSP1 is a bus master and accesses the display list
and video buffers through DMA directly. On Gen3 hardware, however,
memory accesses go through a separate IP core called FCP.
The VSP1 driver unconditionally maps DMA buffers through the VSP device.
While th
From: Laurent Pinchart
Direct callers of the FCP API hold a reference to the FCP module due to
module linkage, there's no need to take another one manually. Take a
reference to the device instead to ensure that it won't disappear behind
the caller's back.
Signed-off-by: Laurent Pinchart
Reviewe
From: Laurent Pinchart
The new rcar_fcp_get_device() function retrieves the struct device
related to the FCP device. This is useful to handle DMA mapping through
the right device.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Signed-off-by: Kieran Bingham
---
drivers/media/plat
From: Laurent Pinchart
For planes handled by a VSP instance, map the framebuffer memory through
the VSP to ensure proper IOMMU handling.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
[Kieran: Fix infinite loop on fail]
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/r
From: Laurent Pinchart
The display buffers must be mapped for DMA through the device that
performs memory access. Expose an API to map and unmap memory through
the VSP device to be used by the DU.
As all the buffers allocated by the DU driver are coherent, we can skip
cache handling when mapping
Hello,
This patch series fixes the rcar-du-drm driver to support VSP plane sources
with an IOMMU. It is available for convenience at
git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git vsp-du/iommu-fcp
On R-Car Gen3 the DU has no direct memory access but sources planes through
VSP instan
On 05/22/2017 04:14 PM, Matthias Brugger wrote:
>
>
> On 22/05/17 11:09, Hans Verkuil wrote:
>> On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:
>>
>> Who should take care of the dtsi changes? I'm not sure who maintains the mdp
>> dts.
>
> I will take care of the dtsi patches.
>
>>
>> The driver c
On 22/05/17 11:09, Hans Verkuil wrote:
On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:
Who should take care of the dtsi changes? I'm not sure who maintains the mdp
dts.
I will take care of the dtsi patches.
The driver change and the dtsi change need to be in sync, so it is probably
easiest
The isp->inputs[] array has isp->input_cnt elements which have been
initialized so this > should be >=.
This bug is harmless. The check against ATOM_ISP_MAX_INPUTS prevents us
from reading beyond the end of the array. The uninitialized elements
are zeroed out so we will end up returning -EINVAL
On 04/21/2017 11:53 AM, Jose Abreu wrote:
> This is an initial submission for the Synopsys Designware HDMI RX
> Controller Driver. This driver interacts with a phy driver so that
> a communication between them is created and a video pipeline is
> configured.
>
> The controller + phy pipeline can t
Hi Hans,
Thanks for the review!
On 22-05-2017 11:04, Hans Verkuil wrote:
> On 04/21/2017 11:53 AM, Jose Abreu wrote:
>> This adds support for the Synopsys Designware HDMI RX PHY e405. This
>> phy receives and decodes HDMI video that is delivered to a controller.
>>
>> Main features included in
On 04/21/2017 11:53 AM, Jose Abreu wrote:
> This adds support for the Synopsys Designware HDMI RX PHY e405. This
> phy receives and decodes HDMI video that is delivered to a controller.
>
> Main features included in this driver are:
> - Equalizer algorithm that chooses the phy best settings
Hi Hans,
On 21-04-2017 10:53, Jose Abreu wrote:
> Hi All,
>
> This is a RFC series that is intended to collect comments regarding the
> Synopsys Designware HDMI RX controller and Synopsys Designware HDMI RX e405
> PHY
> drivers.
>
> The Synopsys Designware HDMI RX controller is an HDMI receiver
On Sun, May 21, 2017 at 10:09:48PM +0200, Takashi Iwai wrote:
> Replace the copy and the silence ops with the new merged ops.
> The silence is performed only when CONFIG_SND_BF5XX_MMAP_SUPPORT is
> set (since copy_silence ops is set only with this config), so in
> bf5xx-ac97.c we have a bit tricky
Let's fix this serious bug before it ends up in the 4.12 release.
Regards,
Hans
The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:
[media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update()
(2017-05-19 07:12:05 -0300)
are available in the git reposi
Various fixes for 4.13.
The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:
[media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update()
(2017-05-19 07:12:05 -0300)
are available in the git repository at:
git://linuxtv.org/hverkuil/media_tree.git for-v4.13a
Hi Devin,
On 04/20/2017 01:13 AM, Devin Heitmueller wrote:
> The USB core and sysfs will attempt to enumerate certain parameters
> which are unsupported by the au0828 - causing inconsistent behavior
> and sometimes causing the chip to reset. Avoid making these calls.
>
> This problem manifested
On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:
Who should take care of the dtsi changes? I'm not sure who maintains the mdp
dts.
The driver change and the dtsi change need to be in sync, so it is probably
easiest
to merge this via one tree.
Here is my Acked-by for these three patches:
Acked-by:
On 05/04/2017 11:42 PM, Gustavo A. R. Silva wrote:
> Fix function prototype so the position of arguments camif->colorfx_cb and
> camif->colorfx_cr match the order of the parameters when calling
> camif_hw_set_effect() function.
>
> Addresses-Coverity-ID: 1248800
> Addresses-Coverity-ID: 1269141
>
From: Colin Ian King
Trivial fix to spelling mistake in dev_err message
Signed-off-by: Colin Ian King
---
drivers/media/usb/em28xx/em28xx-cards.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c
b/drivers/media/usb/em28xx/em28xx-c
On 5/22/2017 15:52, Hugues FRUCHET wrote:
Hi Songjun,
It was an advice from Hans, I copy/paste the comment here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html
>> + /* Enable stream on the sub device */
>> + ret = v4l2_subdev_call(dcmi->entity.subdev, video,
Hi Songjun,
It was an advice from Hans, I copy/paste the comment here:
http://www.mail-archive.com/linux-media@vger.kernel.org/msg112338.html
>> + /* Enable stream on the sub device */
>> + ret = v4l2_subdev_call(dcmi->entity.subdev, video, s_stream, 1);
>> + if (ret && ret != -ENOI
On 05/19/2017 12:07 AM, Gustavo A. R. Silva wrote:
>
> Hello everybody,
>
> While looking into Coverity ID 1226903 I ran into the following piece
> of code at drivers/media/pci/cx25821/cx25821-medusa-video.c:393:
>
> 393int medusa_set_videostandard(struct cx25821_dev *dev)
> 394{
> 395
Hi Mauro,
This pull requests adds support for the Qualcomm venus codec driver.
Regards,
Hans
The following changes since commit 36bcba973ad478042d1ffc6e89afd92e8bd17030:
[media] mtk_vcodec_dec: return error at mtk_vdec_pic_info_update()
(2017-05-19 07:12:05 -0300)
are available in
On 05/21/2017 10:09 PM, Takashi Iwai wrote:
> Replace the copy and the silence ops with the new merged ops.
> It's a capture stream, thus no silence is needed.
>
> Signed-off-by: Takashi Iwai
Acked-by: Hans Verkuil
Regards,
Hans
> ---
> drivers/media/pci/solo6x10/solo6x10-g723.c | 1
45 matches
Mail list logo