cron job: media_tree daily build: WARNINGS

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: Thu Nov 16 05:00:24 CET 2017 media-tree git hash:30b4e122d71cbec2944a5f8b558b88936ee42f10 media_build

[PATCH] [media] winbond-cir: Fix pnp_irq's error checking for wbcir_probe

The pnp_irq() function returns -1 if an error occurs. pnp_irq() error checking for zero is not correct. Signed-off-by: Arvind Yadav --- drivers/media/rc/winbond-cir.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/winbond-cir.c

Re: [GIT PULL for v4.15-rc1] media updates

On Wed, Nov 15, 2017 at 4:28 PM, Mauro Carvalho Chehab wrote: > > PS.: This time, there is a merge from staging tree, from the same commit > you pulled on your tree, in order to solve a conflict at the > atomisp driver, as reported by Stephen Rothwell. Please

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

On Wed, Nov 15, 2017 at 10:31:14AM -0800, Tim Harvey wrote: > On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote: > > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote: > >> Add support for the TDA1997x HDMI receivers. > >> > >> Cc: Hans Verkuil > >>

Re: [PATCH v4 00/12] [dt-bindings] [media] Add document file and driver for Sony CXD2880 DVB-T2/T tuner + demodulator

Hi, all I sent the patch series of Sony CXD2880 DVB-T2/T tuner + demodulator driver version 4 on 13th/Oct. Are there any comments, advices and review results for them? I'd like to get better understanding of current review status for our codes. Regards, Takiguchi

[PATCH/RFC 0/2] V4L2: Handle the race condition between device access and unbind

Hello, This small RFC is an attempt to handle the race condition that exists between device access and device unbind. Devices can be unbound from drivers in three different ways: - When the driver module is unloaded, the driver is unregistered and unbound from all devices it was bound to. As

[PATCH/RFC 2/2] v4l: rcar-vin: Wait for device access to complete before unplugging

To avoid races between device access and unplug, call the video_device_unplug() function in the platform driver remove handler. This will unsure that all device access completes before the remove handler proceeds to free resources. Signed-off-by: Laurent Pinchart

[PATCH/RFC 1/2] v4l: v4l2-dev: Add infrastructure to protect device unplug race

Device unplug being asynchronous, it naturally races with operations performed by userspace through ioctls or other file operations on video device nodes. This leads to potential access to freed memory or to other resources during device access if unplug occurs during device access. To solve

[GIT PULL for v4.15-rc1] media updates

Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media tags/media/v4.15-1 For: - Documentation for digital TV (both kAPI and uAPI) are now in sync with the implementation (except for legacy/deprecated ioctls). This is a major step, as there were

Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

Hi Niklas, On Thursday, 16 November 2017 01:34:33 EET Niklas Söderlund wrote: > On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote: > > The rvin_dev data structure contains driver private data for an instance > > of the VIN. It is allocated dynamically at probe time, and must be freed > > once

Re: [PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

Hi Laurent, Thanks for your patch. On 2017-11-16 00:49:07 +0200, Laurent Pinchart wrote: > The rvin_dev data structure contains driver private data for an instance > of the VIN. It is allocated dynamically at probe time, and must be freed > once all users are gone. > > The structure is

Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

Hi Rob, Thanks for your feedback. On 2017-11-15 13:59:36 -0600, Rob Herring wrote: > On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote: > > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers > > are located between the video sources (CSI-2 transmitters) and

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

Hi Rob, Thanks for your feedback, much appreciated! On 2017-11-15 14:02:26 -0600, Rob Herring wrote: > On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote: > > Document the devicetree bindings for the CSI-2 inputs available on Gen3. > > > > There is a need to add a custom property

[PATCH] v4l: rcar-vin: Implement V4L2 video node release handler

The rvin_dev data structure contains driver private data for an instance of the VIN. It is allocated dynamically at probe time, and must be freed once all users are gone. The structure is currently allocated with devm_kzalloc(), which results in memory being freed when the device is unbound. If a

Re: [PATCH v7 01/25] rcar-vin: add Gen3 devicetree bindings documentation

On Sat, Nov 11, 2017 at 01:38:11AM +0100, Niklas Söderlund wrote: > Document the devicetree bindings for the CSI-2 inputs available on Gen3. > > There is a need to add a custom property 'renesas,id' and to define > which CSI-2 input is described in which endpoint under the port@1 node. > This

Re: [PATCH v11 1/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver documentation

On Sat, Nov 11, 2017 at 01:25:25AM +0100, Niklas Söderlund wrote: > Documentation for Renesas R-Car MIPI CSI-2 receiver. The CSI-2 receivers > are located between the video sources (CSI-2 transmitters) and the video > grabbers (VIN) on Gen3 of Renesas R-Car SoC. > > Each CSI-2 device is connected

Re: camss: camera controls missing on vfe interfaces

Todor et all, Any hint on how to tackle this? I can contribute patches, but I'd like to understand what the idea is. Thanks, Daniel On Thursday, October 26, 2017 06:11 PM, Daniel Mack wrote: > Hi Todor, > > When using the camss driver trough one of its /dev/videoX device nodes, >

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Hi Jacopo, On Wed, Nov 15, 2017 at 7:15 PM, jacopo mondi wrote: > On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote: >> On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi >> wrote: >> > --- /dev/null >> > +++

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

On Wed, Nov 15, 2017 at 7:52 AM, Rob Herring wrote: > On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote: >> Add support for the TDA1997x HDMI receivers. >> >> Cc: Hans Verkuil >> Signed-off-by: Tim Harvey >> --- >> v3: >> -

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Hi Geert, On Wed, Nov 15, 2017 at 02:07:31PM +0100, Geert Uytterhoeven wrote: > Hi Jacopo, > > CC devicetree folks Yeah, sorry I forgot them. Sorry about this and thanks for adding the address back! > > On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi > wrote: > > Add

[PATCH] v4l: sh_mobile_ceu: Return buffers on streamoff()

videobuf2 core reports an error when not all buffers have been returned to the framework: drivers/media/v4l2-core/videobuf2-core.c:1651 WARN_ON(atomic_read(>owned_by_drv_count)) Fix this returning all buffers currently in capture queue. Signed-off-by: Jacopo Mondi

[RFC v5 07/11] [media] vb2: add in-fence support to QBUF

From: Gustavo Padovan Receive in-fence from userspace and add support for waiting on them before queueing the buffer to the driver. Buffers can't be queued to the driver before its fences signal. And a buffer can't be queue to the driver out of the order they were

[RFC v5 04/11] [media] vivid: mark vivid queues as ordered_in_driver

From: Gustavo Padovan ordered_in_driver is used to optimize the use of explicit synchronization when the driver guarantees ordering we can use the same fence context for out-fences. In this case userspace will know that the buffers won't be signaling out of order.

[RFC v5 08/11] [media] vb2: add videobuf2 dma-buf fence helpers

From: Javier Martinez Canillas Add a videobuf2-fence.h header file that contains different helpers for DMA buffer sharing explicit fence support in videobuf2. v2: - use fence context provided by the caller in vb2_fence_alloc() Signed-off-by: Javier Martinez Canillas

[RFC v5 09/11] [media] vb2: add infrastructure to support out-fences

From: Gustavo Padovan Add vb2_setup_out_fence() and the needed members to struct vb2_buffer. v3: - Do not hold yet another ref to the out_fence (Brian Starkey) v2: - change it to reflect fd_install at DQEVENT - add fence context for out-fences

[RFC v5 11/11] [media] v4l: Document explicit synchronization behavior

From: Gustavo Padovan Add section to VIDIOC_QBUF about it v4: - Document ordering behavior for in-fences - Document V4L2_CAP_ORDERED capability - Remove doc about OUT_FENCE event - Document immediate return of out-fence in QBUF v3:

[RFC v5 01/11] [media] v4l: add V4L2_CAP_ORDERED to the uapi

From: Gustavo Padovan When using explicit synchronization userspace needs to know if the queue can deliver everything back in the same order, so we added a new capability that drivers can use to report that they are capable of keeping ordering. In videobuf2 core

[RFC v5 10/11] [media] vb2: add out-fence support to QBUF

From: Gustavo Padovan If V4L2_BUF_FLAG_OUT_FENCE flag is present on the QBUF call we create an out_fence and send its fd to userspace on the fence_fd field as a return arg for the QBUF call. The fence is signaled on buffer_done(), when the job on the buffer is

[RFC v5 02/11] [media] vivid: add the V4L2_CAP_ORDERED capability

From: Gustavo Padovan vivid guarantees the ordering of buffer when processing then, so add the V4L2_CAP_ORDERED capability to inform userspace of that. Signed-off-by: Gustavo Padovan --- drivers/media/platform/vivid/vivid-core.c |

[RFC v5 05/11] [media] vb2: check earlier if stream can be started

From: Gustavo Padovan To support explicit synchronization we need to run all operations that can fail before we queue the buffer to the driver. With fences the queueing will be delayed if the fence is not signaled yet and it will be better if such callback do not

[RFC v5 06/11] [media] vb2: add explicit fence user API

From: Gustavo Padovan Turn the reserved2 field into fence_fd that we will use to send an in-fence to the kernel and return an out-fence from the kernel to userspace. Two new flags were added, V4L2_BUF_FLAG_IN_FENCE, that should be used when sending a fence to the

[RFC v5 03/11] [media] vb2: add 'ordered_in_driver' property to queues

From: Gustavo Padovan We use ordered_in_driver property to optimize for the case where the driver can deliver the buffers in an ordered fashion. When it is ordered we can use the same fence context for all fences, but when it is not we need to a new context for

[RFC v5 00/11] V4L2 Explicit Synchronization

From: Gustavo Padovan Hi, After the comments received in the last patchset[1] and during the media summit [2] here is the new and improved version of the patchset. The implementation is simpler, smaller and cover a lot more cases. If you look to the last

Re: [PATCH v11 2/2] media: rcar-csi2: add Renesas R-Car MIPI CSI-2 receiver driver

Hi, I just noticed I made a small mistake in this patch, see bellow. I will send out a new version in a few days with this fix included but I don't want to spam the list too much so I give it a few more days if there is any other feedback. On 2017-11-11 01:25:26 +0100, Niklas Söderlund wrote:

Re: [PATCH 3/5] media: i2c: Add TDA1997x HDMI receiver driver

On Thu, Nov 09, 2017 at 10:45:34AM -0800, Tim Harvey wrote: > Add support for the TDA1997x HDMI receivers. > > Cc: Hans Verkuil > Signed-off-by: Tim Harvey > --- > v3: > - use V4L2_DV_BT_FRAME_WIDTH/HEIGHT macros > - fixed missing break > - use only

[PATCH] v4l: async: use the v4l2_dev from the root notifier when matching sub-devices

When matching and registering a sub-device from a sub-notifier use the v4l2_device from the root parent notifier. Using the v4l2_dev stored in the sub-notifier itself is incorrect as it might not be set. This can be demonstrated by unbinding and rebinding the adv748x driver and observing that it

Re: [RFC PATCH 0/5] Rockchip ISP1 Driver

Hi Tomasz, 2017-11-15 16:03 GMT+08:00 Tomasz Figa : > Hi Jacob, > > Thanks for sending the series! > > On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen wrote: >> This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 >> SoC. >> >> TODO:

[PATCH v2] dvb_dev_get_fd(): return fd of local devices

This makes it possible to poll a local device. Getting the fd is preferrable to adding a dvb_dev_poll() function, because we can poll several fds together in an event-based program. This is not implemented for remote devices, as polling a remote fd does not make sense. We could instead return the

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

Hi Sakari, thanks for review! On Wed, Nov 15, 2017 at 02:45:51PM +0200, Sakari Ailus wrote: > Hi Jacopo, > > Could you remove the original driver and send the patch using git > send-email -C ? That way a single patch would address converting it to a > proper V4L2 driver as well as move it to

Re: [PATCH v1 06/10] sh: sh7722: Rename CEU clock

Hi Jacopo, On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi wrote: > Rename CEU clock to match the new platform driver name used in Migo-R. > > There are no other sh7722 based devices Migo-R apart, so we can safely > rename this. > > Signed-off-by: Jacopo Mondi

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Hi Jacopo, CC devicetree folks On Wed, Nov 15, 2017 at 11:55 AM, Jacopo Mondi wrote: > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > Signed-off-by: Jacopo Mondi > --- > .../devicetree/bindings/media/renesas,ceu.txt

Re: [PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

Hi Jacopo, Could you remove the original driver and send the patch using git send-email -C ? That way a single patch would address converting it to a proper V4L2 driver as well as move it to the correct location. The changes would be easier to review that way since then, well, it'd be easier to

Re: [PATCH v1 02/10] include: media: Add Renesas CEU driver interface

Hi Jacopo, On Wed, Nov 15, 2017 at 11:55:55AM +0100, Jacopo Mondi wrote: > Add renesas-ceu header file. > > Do not remove the existing sh_mobile_ceu.h one as long as the original > driver does not go away. Hmm. This isn't really not about not removing a file but adding a new one. Do you really

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Hi Jacopo, Thanks for the patchset. Please see my comments below. On Wed, Nov 15, 2017 at 11:55:54AM +0100, Jacopo Mondi wrote: > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > Signed-off-by: Jacopo Mondi > --- >

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

Hi Kieran, > I think it's easier to see updated patches if they are posted as a new thread, > with an increased version number. [PATCH v2], [PATCH v3] etc... > > Not a problem now - but might help your updated patches get seen next time. I will keep that in mind for next time. :) > Looks like

[PATCH] media: v4l2-fwnode: Check subdev count after checking port

Current implementation of __v4l2_async_notifier_parse_fwnode_endpoints() checks first whether subdev_count >= subdev_max and only then whether the port being parsed matches the given port index. This triggers an error in otherwise valid cases of skipping ports that do not match. Fix this by

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

Hi Edgar, Thanks for addressing my concerns in this updated patch. On 12/10/17 08:54, Edgar Thier wrote: > > Use flags the device exposes for UVC controls. > This allows the device to define which property flags are set. > > Since some cameras offer auto-adjustments for properties (e.g.

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

Hi Edgar, On 15/11/17 08:11, Edgar Thier wrote: > Hi, > > I was wondering if there are any problems with my latest patch or if it > simply slipped through. Slipped though in high mail volumes :) I think it's easier to see updated patches if they are posted as a new thread, with an increased

Hello Dear...

Hello Dear... I know that this message will come to you as a surprise. I hoped that you will not expose or betray this trust and confident that I am about to repose on you, my name is M, Shakour Rosarita. I am 19 years old Girl, female, from Tartu Syria, (never married) 61 kg, white in

[PATCH 1/2] dvb_logfunc: add a user private parameter

--- lib/include/libdvbv5/dvb-dev.h | 3 ++- lib/include/libdvbv5/dvb-fe.h | 9 +++-- lib/include/libdvbv5/dvb-log.h | 33 + lib/libdvbv5/dvb-dev.c | 3 ++- lib/libdvbv5/dvb-fe.c | 15 --- lib/libdvbv5/dvb-log.c | 3 ++-

[PATCH 2/2] dvbv5-daemon: 0 is a valid fd

--- utils/dvb/dvbv5-daemon.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/dvb/dvbv5-daemon.c b/utils/dvb/dvbv5-daemon.c index 58485ac6..711694e0 100644 --- a/utils/dvb/dvbv5-daemon.c +++ b/utils/dvb/dvbv5-daemon.c @@ -570,7 +570,7 @@ void dvb_remote_log(void *priv,

Re: [PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Hi Jacopo, A couple of minor language fixups inline. On 15/11/17 10:55, Jacopo Mondi wrote: > Add bindings documentation for Renesas Capture Engine Unit (CEU). > > Signed-off-by: Jacopo Mondi > --- > .../devicetree/bindings/media/renesas,ceu.txt | 87 >

[PATCH v1 10/10] media: i2c: tw9910: Remove soc_camera dependencies

Remove soc_camera framework dependencies from tw9910 sensor driver. - Handle clock directly - Register async subdevice - Add platform specific enable/disable functions - Adjust build system This commit does not remove the original soc_camera based driver. Signed-off-by: Jacopo Mondi

[PATCH v1 03/10] v4l: platform: Add Renesas CEU driver

Add driver for Renesas Capture Engine Unit (CEU). The CEU interface supports capturing 'data' (YUV422) and 'images' (NV[12|21|16|61]). This driver aims to replace the soc_camera based sh_mobile_ceu one. Tested with ov7670 camera sensor, providing YUYV_2X8 data on Renesas RZ platform GR-Peach.

[PATCH v1 01/10] dt-bindings: media: Add Renesas CEU bindings

Add bindings documentation for Renesas Capture Engine Unit (CEU). Signed-off-by: Jacopo Mondi --- .../devicetree/bindings/media/renesas,ceu.txt | 87 ++ 1 file changed, 87 insertions(+) create mode 100644

[PATCH v1 02/10] include: media: Add Renesas CEU driver interface

Add renesas-ceu header file. Do not remove the existing sh_mobile_ceu.h one as long as the original driver does not go away. Signed-off-by: Jacopo Mondi --- include/media/drv-intf/renesas-ceu.h | 23 +++ 1 file changed, 23 insertions(+) create

[PATCH v1 05/10] arch: sh: migor: Use new renesas-ceu camera driver

Migo-R platform uses sh_mobile_ceu camera driver, which is now being replaced by a proper V4L2 camera driver named 'renesas-ceu'. Move Migo-R platform to use the v4l2 renesas-ceu camera driver interface and get rid of soc_camera defined components used to register sensor drivers. Also, memory

[PATCH v1 08/10] media: i2c: ov772x: Remove soc_camera dependencies

Remove soc_camera framework dependencies from ov772x sensor driver. - Handle clock directly - Register async subdevice - Add platform specific enable/disable functions - Adjust build system This commit does not remove the original soc_camera based driver. Signed-off-by: Jacopo Mondi

[PATCH v1 04/10] ARM: dts: r7s72100: Add Capture Engine Unit (CEU)

Add Capture Engine Unit (CEU) node to device tree. Signed-off-by: Jacopo Mondi --- arch/arm/boot/dts/r7s72100.dtsi | 12 ++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/r7s72100.dtsi b/arch/arm/boot/dts/r7s72100.dtsi index

[PATCH v1 07/10] v4l: i2c: Copy ov772x soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. Signed-off-by: Jacopo Mondi --- drivers/media/i2c/ov772x.c | 1124 1 file changed, 1124

[PATCH v1 00/10] Renesas Capture Engine Unit (CEU) V4L2 driver

Hello, this series implementes a modern V4L2 driver for Renesas Capture Engine Unit (CEU). CEU is currently supported by the soc_camera based driver drivers/media/platform/soc_camera/sh_mobile_ceu_camera.c The driver supports capturing images in planar formats (NV12/21 and NV16/61) and

[PATCH v1 09/10] v4l: i2c: Copy tw9910 soc_camera sensor driver

Copy the soc_camera based driver in v4l2 sensor driver directory. This commit just copies the original file without modifying it. Signed-off-by: Jacopo Mondi --- drivers/media/i2c/tw9910.c | 999 + 1 file changed, 999

[PATCH v1 06/10] sh: sh7722: Rename CEU clock

Rename CEU clock to match the new platform driver name used in Migo-R. There are no other sh7722 based devices Migo-R apart, so we can safely rename this. Signed-off-by: Jacopo Mondi --- arch/sh/kernel/cpu/sh4a/clock-sh7722.c | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH] dvb_dev_get_fd(): return fd of local devices

This makes it possible to poll a local device. Getting the fd is preferrable to adding a dvb_dev_poll() function, because we can poll several fds together in an event-based program. This is not implemented for remote devices, as polling a remote fd does not make sense. We could instead return the

Re: [RFCv1 PATCH 0/6] v4l2-ctrls: implement requests

Hi Alexandre, On 15/11/17 10:38, Alexandre Courbot wrote: > Hi Hans! > > Thanks for the patchset! It looks quite good at first sight, a few comments > and > questions follow though. > > On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote: >> From: Hans Verkuil

Re: [RFCv1 PATCH 0/6] v4l2-ctrls: implement requests

Hi Hans! Thanks for the patchset! It looks quite good at first sight, a few comments and questions follow though. On Monday, November 13, 2017 11:34:02 PM JST, Hans Verkuil wrote: From: Hans Verkuil Hi Alexandre, This is a first implementation of the request API in

Re: [RFC PATCH 0/5] Rockchip ISP1 Driver

Hi Jacob, Thanks for sending the series! On Wed, Nov 15, 2017 at 3:29 PM, Jacob Chen wrote: > This patch series add a ISP(Camera) v4l2 driver for rockchip rk3288/rk3399 > SoC. > > TODO: > - Thomas is rewriting the binding code between isp, phy, sensors, i hope we >

Re: [PATCH] uvcvideo: Apply flags from device to actual properties

Hi, I was wondering if there are any problems with my latest patch or if it simply slipped through. Regards, Edgar On 10/12/2017 09:54 AM, Edgar Thier wrote: > > Use flags the device exposes for UVC controls. > This allows the device to define which property flags are set. > > Since some