[PATCH v3 1/2] device property: Add fwnode_graph_get_port_parent

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

[PATCH v3 0/2] v4l: async: Match parent devices

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

[PATCH] [media] uvcvideo: Prevent heap overflow in uvc driver

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

Re: [PATCH 13/16] lirc_dev: use an ida instead of a hand-rolled array to keep track of minors

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

[PATCH] [media] atomisp: use NULL instead of 0 for pointers

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 +-

Re: [PATCH 4/7] rc-core: sanyo - leave the internals of rc_dev alone

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

Re: [PATCH 3/7] rc-core: img-nec-decoder - leave the internals of rc_dev alone

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

Re: [PATCH v3 0/3] Fix mdp device tree

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 > >>

[PATCH v4 3/3] media: mtk-mdp: Fix mdp device tree

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

[PATCH v4 1/3] dt-bindings: mt8173: Fix mdp device tree

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.

[PATCH v4 2/3] arm64: dts: mt8173: Fix mdp device tree

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

[PATCH v4 0/3] Fix mdp device tree

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

cron job: media_tree daily build: ERRORS

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

Re: [PATCH v2 1/2] binding for stm32 cec driver

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 > +++ >

Re: [PATCH v2 1/2] device property: Add fwnode_graph_get_port_parent

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);

Re: [PATCH v2 2/2] v4l: async: Match parent devices

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

Re: [PATCH v1 2/3] device property: Add fwnode_graph_get_port_parent

Hi Laurent and Kieran, On Fri, May 19, 2017 at 05:42:07PM +0300, Laurent Pinchart wrote: > Hi Kieran, > > On Friday 19 May 2017 14:34:33 Kieran Bingham wrote: > > On 18/05/17 14:36, Laurent Pinchart wrote: > > > On Wednesday 17 May 2017 16:03:38 Kieran Bingham wrote: > > >> From: Kieran Bingham

Re: [PATCH v1] [media] atmel-isi: code cleanup

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,

[GIT PULL FOR v4.13] Add qualcomm venus codec

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

Re: [PATCH v1] [media] atmel-isi: code cleanup

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 !=

Re: [PATCH 15/16] [media] solo6x10: Convert to copy_silence ops

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 > --- >

Re: [media-pci-cx25821] question about value overwrite

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

[PATCH] [media] em28xx: fix spelling mistake: "missdetected" -> "misdetected"

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

[PATCH] atomisp2: off by one in atomisp_s_input()

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

[GIT PULL FOR v4.13] Various fixes

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

Re: [PATCH 14/16] ASoC: blackfin: Convert to copy_silence ops

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

Re: [RFC 1/2] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver

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

Re: [PATCH] media: platform: s3c-camif: fix function prototype

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 >

[GIT PULL FOR v4.12] Fix stupid rainshadow bug

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

Re: [RFC 0/2] Synopsys Designware HDMI Video Capture Controller + PHY

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

Re: [PATCH v3 0/3] Fix mdp device tree

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:

Re: [PATCH 08/12] Add USB quirk for HVR-950q to avoid intermittent device resets

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

Re: [RFC 1/2] [media] platform: Add Synopsys Designware HDMI RX PHY e405 Driver

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

Re: [RFC 2/2] [media] platform: Add Synopsys Designware HDMI RX Controller Driver

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

Re: [PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

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:

Re: [PATCH v3 0/3] Fix mdp device tree

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

Re: [PATCH v3 0/3] Fix mdp device tree

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

[PATCH v3 4/5] v4l: vsp1: Add API to map and unmap DRM buffers through the VSP

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

[PATCH v3 0/5] R-Car DU: Fix IOMMU operation when connected to VSP

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

[PATCH v3 5/5] drm: rcar-du: Map memory through the VSP device

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

[PATCH v3 3/5] v4l: vsp1: Map the DL and video buffers through the proper bus master

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

[PATCH v3 1/5] v4l: rcar-fcp: Don't get/put module reference

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

[PATCH v3 2/5] v4l: rcar-fcp: Add an API to retrieve the FCP device

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

Re: [PATCH v1 3/3] v4l: async: Match parent devices

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

[PATCH] [media] coda: improve colorimetry handling

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

[PATCH v3 2/2] v4l: async: Match parent devices

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