Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

Hi, On Saturday, May 19, 2018 04:42 AM, Sam Bobrowicz wrote: This set of patches is also not working for my MIPI platform (mine has a 12 MHz external clock). I am pretty sure is isn't working because it does not include the following, which my tests have found to be necessary: 1) Setting pclk

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Hi Nicolas, On Friday, 18 May 2018 18:15:20 EEST Nicolas Dufresne wrote: > Le vendredi 18 mai 2018 à 15:38 +0300, Laurent Pinchart a écrit : > >> Before libv4l, media support for a given device were limited to a few > >> apps that knew how to decode the format. There were even cases were a > >>

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: Sat May 19 05:00:11 CEST 2018 media-tree git hash:7e6b6b945272c20f6b78d319e07f27897a8373c9 media_build

Re: [PATCH v3 03/12] media: ov5640: Remove the clocks registers initialization

On Fri, May 18, 2018 at 3:35 AM, Daniel Mack wrote: > On Thursday, May 17, 2018 10:53 AM, Maxime Ripard wrote: >> >> Part of the hardcoded initialization sequence is to set up the proper >> clock >> dividers. However, this is now done dynamically through proper code and as >>

Re: [Xen-devel][RFC 2/3] xen/grant-table: Extend API to work with DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/xen/grant-table.c | 49 +++ >

Re: [PATCH v4 06/12] media: dt-bindings: add bindings for i.MX7 media driver

On Fri, May 18, 2018 at 09:27:58AM +0100, Rui Miguel Silva wrote: > > > +endpoint node > > > +- > > > + > > > +- data-lanes: (required) an array specifying active physical > > > MIPI-CSI2 > > > + data input lanes and their mapping to logical lanes; the > > > +

Re: [PATCH v5 06/12] media: dt-bindings: add bindings for i.MX7 media driver

Hi Rui, On Fri, May 18, 2018 at 10:28:00AM +0100, Rui Miguel Silva wrote: > Add bindings documentation for i.MX7 media drivers. > > Signed-off-by: Rui Miguel Silva > --- > .../devicetree/bindings/media/imx7.txt| 125 ++ > 1 file changed, 125

Re: [Xen-devel] [RFC 1/3] xen/balloon: Allow allocating DMA buffers

On 05/17/2018 04:26 AM, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko A commit message would be useful. > > Signed-off-by: Oleksandr Andrushchenko > > for (i = 0; i < nr_pages; i++) { > -

Re: [PATCH v5 08/12] ARM: dts: imx7s: add multiplexer controls

Hi Rob, On Fri 18 May 2018 at 16:51, Rob Herring wrote: On Fri, May 18, 2018 at 10:28:02AM +0100, Rui Miguel Silva wrote: The IOMUXC General Purpose Register has bitfield to control video bus multiplexer to control the CSI input between the MIPI-CSI2 and parallel interface. Add that register

Re: [PATCH v5 07/12] ARM: dts: imx7s: add mipi phy power domain

Hi Rob, On Fri 18 May 2018 at 16:50, Rob Herring wrote: On Fri, May 18, 2018 at 10:28:01AM +0100, Rui Miguel Silva wrote: Add power domain index 0 related with mipi-phy to imx7s. Signed-off-by: Rui Miguel Silva --- arch/arm/boot/dts/imx7s.dtsi | 6 ++ 1 file

Re: [PATCH v5 06/12] media: dt-bindings: add bindings for i.MX7 media driver

Hi Rob, Thanks for your review, this and the other ones. On Fri 18 May 2018 at 16:49, Rob Herring wrote: On Fri, May 18, 2018 at 10:28:00AM +0100, Rui Miguel Silva wrote: Add bindings documentation for i.MX7 media drivers. Signed-off-by: Rui Miguel Silva ---

Re: [PATCH 05/15] mtd: nand: pxa3xx: remove the dmaengine compat need

Hi Robert, Thanks for this series. On Monday, April 02, 2018 04:26 PM, Robert Jarzmik wrote: From: Robert Jarzmik As the pxa architecture switched towards the dmaengine slave map, the old compatibility mechanism to acquire the dma requestor line number and

[PATCH] stk1160: Fix typo s/therwise/Otherwise

Fix a trivial typo. Signed-off-by: Ezequiel Garcia --- drivers/media/usb/stk1160/stk1160-core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/stk1160/stk1160-core.c b/drivers/media/usb/stk1160/stk1160-core.c index

[PATCH] stk1160: Add missing calls to mutex_destroy

The mutexes are not being destroyed in the release path. Fix it. Signed-off-by: Ezequiel Garcia --- drivers/media/usb/stk1160/stk1160-core.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/stk1160/stk1160-core.c

[PATCH] m2m-deinterlace: Remove DMA_ENGINE dependency

The DMA engine subsystem provides stubs for drivers to build with !DMA_ENGINE. Drop the config dependency. Signed-off-by: Ezequiel Garcia --- drivers/media/platform/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/platform/Kconfig

[PATCH] tw686x: Fix incorrect vb2_mem_ops GFP flags

When the driver is configured in the "memcpy" dma-mode, it uses vb2_vmalloc_memops, which is backed by a SLAB allocator and so shouldn't be using GFP_DMA32. Fix it. Signed-off-by: Ezequiel Garcia --- drivers/media/pci/tw686x/tw686x-video.c | 3 ++- 1 file changed, 2

Re: [PATCH v11 10/10] media: vsp1: Move video configuration to a cached dlb

Hi Kieran, Thank you for the patch. On Friday, 18 May 2018 23:42:03 EEST Kieran Bingham wrote: > From: Kieran Bingham > > We are now able to configure a pipeline directly into a local display > list body. Take advantage of this fact, and create a

Re: [PATCH v11 01/10] media: v4l: vsp1: Release buffers for each video node

On 18/05/18 21:53, Laurent Pinchart wrote: > Hi Kieran, > > Thank you for the patch. > > On Friday, 18 May 2018 23:41:54 EEST Kieran Bingham wrote: >> From: Kieran Bingham >> >> Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in >>

Re: [PATCH v11 02/10] media: vsp1: Move video suspend resume handling to video object

Hi Kieran, Thank you for the patch. On Friday, 18 May 2018 23:41:55 EEST Kieran Bingham wrote: > From: Kieran Bingham > > The suspend and resume handlers are only utilised by video pipelines, > yet the functions currently reside in the vsp1_pipe object.

Re: [PATCH v11 01/10] media: v4l: vsp1: Release buffers for each video node

Hi Kieran, Thank you for the patch. On Friday, 18 May 2018 23:41:54 EEST Kieran Bingham wrote: > From: Kieran Bingham > > Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in > start_streaming error path") introduced a helper to clean up buffers

Re: [PATCH v4 3/3] bpf: add selftest for lirc_mode2 type program

On Fri, May 18, 2018 at 1:17 PM, Y Song wrote: > On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: >> This is simple test over rc-loopback. >> >> Signed-off-by: Sean Young > > Acked-by: Yonghong Song Just one minor thing. You

[PATCH v11 08/10] media: vsp1: Refactor display list configure operations

From: Kieran Bingham The entities provide a single .configure operation which configures the object into the target display list, based on the vsp1_entity_params selection. Split the configure function into three parts, '.configure_stream()',

[PATCH v11 02/10] media: vsp1: Move video suspend resume handling to video object

From: Kieran Bingham The suspend and resume handlers are only utilised by video pipelines, yet the functions currently reside in the vsp1_pipe object. This causes an issue with resume, as the functions incorrectly call vsp1_pipeline_run() directly

[PATCH v11 09/10] media: vsp1: Adapt entities to configure into a body

From: Kieran Bingham Currently the entities store their configurations into a display list. Adapt this such that the code can be configured into a body directly, allowing greater flexibility and control of the content. All users of vsp1_dl_list_write()

[PATCH v11 06/10] media: vsp1: Convert display lists to use new body pool

From: Kieran Bingham Adapt the dl->body0 object to use an object from the body pool. This greatly reduces the pressure on the TLB for IPMMU use cases, as all of the lists use a single allocation for the main body. The CLU and LUT objects pre-allocate a

[PATCH v11 07/10] media: vsp1: Use reference counting for bodies

From: Kieran Bingham Extend the display list body with a reference count, allowing bodies to be kept as long as a reference is maintained. This provides the ability to keep a cached copy of bodies which will not change, so that they can be re-applied to

[PATCH v11 04/10] media: vsp1: Protect bodies against overflow

From: Kieran Bingham The body write function relies on the code never asking it to write more than the entries available in the list. Currently with each list body containing 256 entries, this is fine, but we can reduce this number greatly saving memory.

[PATCH v11 03/10] media: vsp1: Reword uses of 'fragment' as 'body'

From: Kieran Bingham Throughout the codebase, the term 'fragment' is used to represent a display list body. This term duplicates the 'body' which is already in use. The datasheet references these objects as a body, therefore replace all mentions of a

[PATCH v11 05/10] media: vsp1: Provide a body pool

From: Kieran Bingham Each display list allocates a body to store register values in a dma accessible buffer from a dma_alloc_wc() allocation. Each of these results in an entry in the IOMMU TLB, and a large number of display list allocations adds pressure

[PATCH v11 10/10] media: vsp1: Move video configuration to a cached dlb

From: Kieran Bingham We are now able to configure a pipeline directly into a local display list body. Take advantage of this fact, and create a cacheable body to store the configuration of the pipeline in the video object. vsp1_video_pipeline_run() is

[PATCH v11 01/10] media: v4l: vsp1: Release buffers for each video node

From: Kieran Bingham Commit 372b2b0399fc ("media: v4l: vsp1: Release buffers in start_streaming error path") introduced a helper to clean up buffers on error paths, but inadvertently changed the code such that only the output WPF buffers were cleaned,

[PATCH v11 00/10] vsp1: TLB optimisation and DL caching

From: Kieran Bingham Each display list currently allocates an area of DMA memory to store register settings for the VSP1 to process. Each of these allocations adds pressure to the IPMMU TLB entries. We can reduce the pressure by pre-allocating larger

Re: [PATCH] Fix spurious config-mycompat.h warnings

Hi! THX for the patch. @Hans: I applied the patch already, but I can't delete it from Patchwork. Please remove it there. BR, Jasmin

Re: [PATCH v4 3/3] bpf: add selftest for lirc_mode2 type program

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This is simple test over rc-loopback. > > Signed-off-by: Sean Young Acked-by: Yonghong Song > --- > tools/bpf/bpftool/prog.c | 1 + > tools/include/uapi/linux/bpf.h

Re: [PATCH v4 2/3] media: rc: introduce BPF_PROG_LIRC_MODE2

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > Add support for BPF_PROG_LIRC_MODE2. This type of BPF program can call > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report > that the last key should be repeated. > > The bpf program can be attached to using

Re: [PATCH v4 1/3] bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not found

On Fri, May 18, 2018 at 7:07 AM, Sean Young wrote: > This makes is it possible for bpf prog detach to return -ENOENT. > > Signed-off-by: Sean Young Acked-by: Yonghong Song

Re: [PATCH] gpu: ipu-v3: Fix BT1120 interlaced CCIR codes

On 05/18/2018 05:51 PM, Philipp Zabel wrote: > Hi Marek, > > On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote: >> The BT1120 interlaced CCIR codes are the same as BT656 ones >> and different than BT656 progressive CCIR codes, fix this. > > thank you for the patch, and sorry for the delay. >

[PATCH] Fix spurious config-mycompat.h warnings

Apparently a zero byte file size leads to "could not open" warnings. Adding a single comment to the file removes the warnings displayed after compilation. To prevent overwriting a user supplied config-mycompat.h the file is only created if it does not already exist. Also fix for possible spaces

[PATCH 18/20] videobuf2: assume q->lock is always set

From: Hans Verkuil Drop checks for q->lock. Drop calls to wait_finish/prepare, just lock/unlock q->lock. Signed-off-by: Hans Verkuil --- drivers/media/common/videobuf2/videobuf2-core.c | 21 ---

[PATCH 20/20] media: Remove wait_{prepare, finish}

Now that all drivers provide a proper vb2_queue lock, and that wait_{prepare, finish} are no longer in use, get rid of them. Signed-off-by: Ezequiel Garcia --- Documentation/media/kapi/v4l2-dev.rst | 7 +++ drivers/input/rmi4/rmi_f54.c

[PATCH 04/20] usbtv: Implement wait_prepare and wait_finish

This driver is currently specifying a vb2_queue lock, which means it straightforward to implement wait_prepare and wait_finish. Having these callbacks releases the queue lock while blocking, which improves latency by allowing for example streamoff or qbuf operations while waiting in dqbuf.

[PATCH 19/20] v4l2-ioctl.c: assume queue->lock is always set

From: Hans Verkuil vb2_queue now expects a valid lock pointer, so drop the checks for that in v4l2-ioctl.c. Signed-off-by: Hans Verkuil --- drivers/media/v4l2-core/v4l2-ioctl.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git

[PATCH 14/20] mx_emmaprp: Implement wait_prepare and wait_finish

This driver is currently specifying a video_device lock, which means it is protecting all the ioctls (including queue ioctls) with a single mutex. It's therefore straightforward to implement wait_prepare and wait_finish, by explicitly setting the vb2_queue lock. Having these callbacks releases

[PATCH 15/20] m2m-deinterlace: Implement wait_prepare and wait_finish

This driver is currently specifying a video_device lock, which means it is protecting all the ioctls (including queue ioctls) with a single mutex. It's therefore straightforward to implement wait_prepare and wait_finish, by explicitly setting the vb2_queue lock. Having these callbacks releases

[PATCH 16/20] stk1160: Set the vb2_queue lock before calling vb2_queue_init

The vb2_queue will soon be mandatory. The videobuf2 core will throw a verbose warning if it's not set. The stk1160 driver is setting the queue lock, but after the vb2_queue_init call. Avoid the warning by setting the lock before the queue initialization. Signed-off-by: Ezequiel Garcia

[PATCH 17/20] videobuf2-core: require q->lock

From: Hans Verkuil Refuse to initialize a vb2 queue if there is no lock specified. Signed-off-by: Hans Verkuil --- drivers/media/common/videobuf2/videobuf2-core.c | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH 11/20] dvb-core: Provide lock for vb2_queue

Use the vb2 context mutex to protect the vb2_queue. This allows to replace the ad-hoc wait_{prepare, finish} with vb2_ops_wait_{prepare, finish}. Signed-off-by: Ezequiel Garcia --- drivers/media/dvb-core/dvb_vb2.c | 22 +++--- 1 file changed, 3

[PATCH 12/20] venus: Add video_device and vb2_queue locks

video_device and vb2_queue locks are now both mandatory. Add them, remove driver ad-hoc locking, and implement wait_{prepare, finish}. To stay on the safe side, this commit uses a single mutex for both locks. Better latency can be obtained by separating these if needed. Signed-off-by: Ezequiel

[PATCH 10/20] staging: bcm2835-camera: Provide lock for vb2_queue

Use the device mutex to protect the vb2_queue. This allows to replace the ad-hoc wait_{prepare, finish} with vb2_ops_wait_{prepare, finish}. Signed-off-by: Ezequiel Garcia --- .../vc04_services/bcm2835-camera/bcm2835-camera.c | 24 +- 1 file changed,

[PATCH 13/20] davinci_vpfe: Add video_device and vb2_queue locks

Currently, this driver does not serialize its video4linux ioctls, which is a bug, as race conditions might appear. In addition, video_device and vb2_queue locks are now both mandatory. Add them, and implement wait_prepare and wait_finish. To stay on the safe side, this commit uses a single mutex

[PATCH 09/20] s5p-g2d: Implement wait_prepare and wait_finish

This driver is currently specifying a vb2_queue lock, which means it straightforward to implement wait_prepare and wait_finish. Having these callbacks releases the queue lock while blocking, which improves latency by allowing for example streamoff or qbuf operations while waiting in dqbuf.

[PATCH 06/20] omap4iss: Add video_device and vb2_queue locks

video_device and vb2_queue locks are now both mandatory. Add them, remove driver ad-hoc locks, and implement wait_{prepare, finish}. To stay on the safe side, this commit uses a single mutex for both locks. Better latency can be obtained by separating these if needed. Signed-off-by: Ezequiel

[PATCH 05/20] sta2x11: Add video_device and vb2_queue locks

Currently, this driver does not serialize its video4linux ioctls, which is a bug, as race conditions might appear. In addition, video_device and vb2_queue locks are now both mandatory. Add them, and implement wait_prepare and wait_finish. To stay on the safe side, this commit uses a single mutex

[PATCH 07/20] omap3isp: Add video_device and vb2_queue locks

video_device and vb2_queue locks are now both mandatory. Add them, remove driver ad-hoc locks, and implement wait_{prepare, finish}. To stay on the safe side, this commit uses a single mutex for both locks. Better latency can be obtained by separating these if needed. Signed-off-by: Ezequiel

[PATCH 08/20] mtk-mdp: Add locks for capture and output vb2_queues

Use the mutex in struct mtk_mdp_ctx to protect the capture and output vb2_queues. This allows to replace the ad-hoc wait_{prepare, finish} with vb2_ops_wait_{prepare, finish}. Signed-off-by: Ezequiel Garcia --- drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 20

[PATCH 03/20] v4l2-ioctl.c: use correct vb2_queue lock for m2m devices

From: Hans Verkuil For m2m devices the vdev->queue lock was always taken instead of the lock for the specific capture or output queue. Now that we pushed the locking down into __video_do_ioctl() we can pick the correct lock and improve the performance of m2m devices.

[RFC PATCH v2 00/20] v4l2 core: push ioctl lock down to ioctl handler

Here's a second spin of the series posted by Hans: https://www.mail-archive.com/linux-media@vger.kernel.org/msg131363.html This v2 adds the required driver modifications, fixing all drivers so they define a proper vb2_queue lock. A only exception to this is netup_unidvb. It isn't really obvious

[PATCH 02/20] v4l2-core: push taking ioctl mutex down to ioctl handler.

From: Hans Verkuil The ioctl serialization mutex (vdev->lock or q->lock for vb2 queues) was taken at the highest level in v4l2-dev.c. This prevents more fine-grained locking since at that level we cannot examine the ioctl arguments, we can only do that after video_usercopy is

[PATCH 01/20] pvrusb2: replace pvr2_v4l2_ioctl by video_ioctl2

From: Hans Verkuil This driver is the only V4L driver that does not set unlocked_ioctl to video_ioctl2. The only thing that pvr2_v4l2_ioctl does besides calling video_ioctl2 is calling pvr2_hdw_commit_ctl(). Add pvr2_hdw_commit_ctl() calls to the various ioctls that need

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Le vendredi 18 mai 2018 à 16:37 +0100, Dave Stevenson a écrit : > On 18 May 2018 at 16:05, Mauro Carvalho Chehab > wrote: > > Em Fri, 18 May 2018 15:27:24 +0300 > > > > > > > > > There, instead of an USB camera, the hardware is equipped with a > > > > MC-based ISP,

Re: i.MX6 IPU CSI analog video input on Ventana

On Fri, May 18, 2018 at 10:28 AM, Krzysztof Hałasa wrote: > Steve Longerbeam writes: > >> Yes, the CSI on i.MX6 does not deal well with unstable bt.656 sync codes, >> which results in vertical sync issues (scrolling or split images). The >> ADV7180 >> will

Re: [PATCHv2 0/4] gspca: convert to vb2gspca: convert to vb2

On 13 May 2018 at 06:47, Hans Verkuil wrote: > From: Hans Verkuil > > The first patch converts the gspca driver to the vb2 framework. > It was much easier to do than I expected and it saved almost 600 > lines of gspca driver code. > > The second patch

Re: i.MX6 IPU CSI analog video input on Ventana

Steve Longerbeam writes: > Yes, the CSI on i.MX6 does not deal well with unstable bt.656 sync codes, > which results in vertical sync issues (scrolling or split images). The > ADV7180 > will often shift the sync codes around in various situations (initial > power on, > see

Re: [PATCH v5 06/12] media: dt-bindings: add bindings for i.MX7 media driver

On Fri, May 18, 2018 at 10:28:00AM +0100, Rui Miguel Silva wrote: > Add bindings documentation for i.MX7 media drivers. > > Signed-off-by: Rui Miguel Silva > --- > .../devicetree/bindings/media/imx7.txt| 125 ++ > 1 file changed, 125 insertions(+) >

Re: [PATCH v5 07/12] ARM: dts: imx7s: add mipi phy power domain

On Fri, May 18, 2018 at 10:28:01AM +0100, Rui Miguel Silva wrote: > Add power domain index 0 related with mipi-phy to imx7s. > > Signed-off-by: Rui Miguel Silva > --- > arch/arm/boot/dts/imx7s.dtsi | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git

Re: [PATCH v5 08/12] ARM: dts: imx7s: add multiplexer controls

On Fri, May 18, 2018 at 10:28:02AM +0100, Rui Miguel Silva wrote: > The IOMUXC General Purpose Register has bitfield to control video bus > multiplexer to control the CSI input between the MIPI-CSI2 and parallel > interface. Add that register and mask. > > Signed-off-by: Rui Miguel Silva

Re: [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

Hi Neil, 2018-05-18 15:05 GMT+02:00 Neil Armstrong : > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly

Re: [PATCH v5 06/12] media: dt-bindings: add bindings for i.MX7 media driver

On Fri, 2018-05-18 at 10:28 +0100, Rui Miguel Silva wrote: > Add bindings documentation for i.MX7 media drivers. > > Signed-off-by: Rui Miguel Silva > --- > .../devicetree/bindings/media/imx7.txt| 125 ++ > 1 file changed, 125 insertions(+) >

Re: [PATCH] gpu: ipu-v3: Fix BT1120 interlaced CCIR codes

Hi Marek, On Sat, 2018-04-07 at 15:04 +0200, Marek Vasut wrote: > The BT1120 interlaced CCIR codes are the same as BT656 ones > and different than BT656 progressive CCIR codes, fix this. thank you for the patch, and sorry for the delay. > Signed-off-by: Marek Vasut > Cc: Steve

Re: [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On Fri, May 18, 2018 at 03:05:00PM +0200, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name > instead and will

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

On Sat, May 19, 2018 at 12:15 AM Nicolas Dufresne wrote: > Le vendredi 18 mai 2018 à 15:38 +0300, Laurent Pinchart a écrit : > > > Before libv4l, media support for a given device were limited to a few > > > apps that knew how to decode the format. There were even cases were

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

+Hu, Jerry W +Mani, Rajmohan +Sakari Ailus FYI On Fri, May 18, 2018 at 4:07 AM Mauro Carvalho Chehab < mchehab+sams...@kernel.org> wrote: > Hi all, > The goal of this e-mail is to schedule a meeting in order to discuss > improvements at the media subsystem in order to support complex camera >

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

On 18 May 2018 at 16:05, Mauro Carvalho Chehab wrote: > Em Fri, 18 May 2018 15:27:24 +0300 >> >> > There, instead of an USB camera, the hardware is equipped with a >> > MC-based ISP, connected to its camera. Currently, despite having >> > a Kernel driver for it, the

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Hi Mauro, On Friday, 18 May 2018 18:05:22 EEST Mauro Carvalho Chehab wrote: > Em Fri, 18 May 2018 15:27:24 +0300 Laurent Pinchart escreveu: > > On Thursday, 17 May 2018 22:07:08 EEST Mauro Carvalho Chehab wrote: [snip] > >> 1.2 V4L2 userspace aspects > >> -- > >> > >>

Re: [PATCH v6 1/2] media: ov2680: dt: Add bindings for OV2680

Hi Rob, On Fri 18 May 2018 at 14:18, Rob Herring wrote: On Wed, May 09, 2018 at 03:31:58PM +0100, Rui Miguel Silva wrote: Add device tree binding documentation for the OV2680 camera sensor. CC: devicet...@vger.kernel.org Signed-off-by: Rui Miguel Silva ---

Re: [PATCH] lirc.4: remove ioctls and feature bits which were never implemented

On Sun, May 06, 2018 at 12:34:53PM +0200, Michael Kerrisk (man-opages) wrote: > [CCing original author of this page] > > > On 04/23/2018 12:26 PM, Sean Young wrote: > > The lirc header file included ioctls and feature bits which were never > > implemented by any driver. They were removed in

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Hi Nicolas, On Friday, 18 May 2018 17:22:47 EEST Nicolas Dufresne wrote: > Le vendredi 18 mai 2018 à 11:15 +0300, Laurent Pinchart a écrit : > >> I need to clarify a little bit on why we disabled libv4l2 in GStreamer, > >> as it's not only for performance reason, there is couple of major issues >

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Le vendredi 18 mai 2018 à 15:38 +0300, Laurent Pinchart a écrit : > > Before libv4l, media support for a given device were limited to a few > > apps that knew how to decode the format. There were even cases were a > > proprietary app were required, as no open source decoders were available. > > >

Re: [PATCH v2 08/29] venus: hfi_venus: fix suspend function for venus 3xx versions

On Tue, May 15, 2018 at 5:11 PM Stanimir Varbanov < stanimir.varba...@linaro.org> wrote: > This fixes the suspend function for Venus 3xx versions by > add a check for WFI (wait for interrupt) bit. This bit > is on when the ARM9 is idle and entered in low power mode. > Signed-off-by: Stanimir

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Em Fri, 18 May 2018 15:27:24 +0300 Laurent Pinchart escreveu: > Hi Mauro, > > On Thursday, 17 May 2018 22:07:08 EEST Mauro Carvalho Chehab wrote: > > Hi all, > > > > The goal of this e-mail is to schedule a meeting in order to discuss > > improvements at the

Re: [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

Hi Neil, 2018-05-18 15:05 GMT+02:00 Neil Armstrong : > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the A minor nit, there is a "consensus" on tell cros-ec as "ChromeOS Embedded Controller" or "ChromeOS EC". Yes, I know that you can see in the

Re: [PATCHv13 02/28] uapi/linux/media.h: add request API

Hi Hans, Thank you for the patch. On Thursday, 3 May 2018 17:52:52 EEST Hans Verkuil wrote: > From: Hans Verkuil > > Define the public request API. > > This adds the new MEDIA_IOC_REQUEST_ALLOC ioctl to allocate a request > and two ioctls that operate on a request in

Re: [PATCHv13 22/28] Documentation: v4l: document request API

Hi Hans, Thank you for the patch. On Thursday, 3 May 2018 17:53:12 EEST Hans Verkuil wrote: > From: Alexandre Courbot > > Document the request API for V4L2 devices, and amend the documentation > of system calls influenced by it. > > Signed-off-by: Alexandre Courbot

[PATCH v3 9/9] media: rcar-vin: Add support for R-Car R8A77995 SoC

Add R-Car R8A77995 SoC to the rcar-vin supported ones. Signed-off-by: Jacopo Mondi Reviewed-by: Niklas Söderlund Reviewed-by: Laurent Pinchart --- drivers/media/platform/rcar-vin/rcar-core.c |

[PATCH v3 8/9] media: rcar-vin: Rename _rcar_info to rcar_info

Remove trailing underscore to align all rcar_group_route structure declarations. Signed-off-by: Jacopo Mondi --- drivers/media/platform/rcar-vin/rcar-core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[PATCH v3 7/9] media: rcar-vin: Handle parallel subdev in link_notify

Handle parallel subdevices in link_notify callback. If the notified link involves a parallel subdevice, do not change routing of the VIN-CSI-2 devices and mark the VIN instance as using a parallel input. If the CSI-2 link setup succeeds instead, mark the VIN instance as using CSI-2.

[PATCH v3 4/9] media: rcar-vin: Cache the mbus configuration flags

Media bus configuration flags and media bus type were so far a property of each VIN instance, as the subdevice they were connected to was immutable during the whole system life time. With the forth-coming introduction of parallel input devices support, a VIN instance can have the subdevice it is

[PATCH v3 5/9] media: rcar-vin: Parse parallel input on Gen3

The rcar-vin driver so far had a mutually exclusive code path for handling parallel and CSI-2 video input subdevices, with only the CSI-2 use case supporting media-controller. As we add support for parallel inputs to Gen3 media-controller compliant code path now parse both port@0 and port@1,

[PATCH v3 6/9] media: rcar-vin: Link parallel input media entities

When running with media-controller link the parallel input media entities with the VIN entities at 'complete' callback time. To create media links the v4l2_device should be registered first. Check if the device is already registered, to avoid double registrations. Signed-off-by: Jacopo Mondi

[PATCH v3 1/9] media: rcar-vin: Rename 'digital' to 'parallel'

As the term 'digital' is used all over the rcar-vin code in place of 'parallel', rename all the occurrencies. Signed-off-by: Jacopo Mondi --- drivers/media/platform/rcar-vin/rcar-core.c | 72 ++--- drivers/media/platform/rcar-vin/rcar-dma.c |

[PATCH v3 2/9] media: rcar-vin: Remove two empty lines

Remove un-necessary empty lines. Signed-off-by: Jacopo Mondi --- drivers/media/platform/rcar-vin/rcar-core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c index

[PATCH v3 3/9] media: rcar-vin: Create a group notifier

As CSI-2 subdevices are shared between several VIN instances, a shared notifier to collect the CSI-2 async subdevices is required. So far, the rcar-vin driver used the notifier of the last VIN instance to probe but with the forth-coming introduction of parallel input subdevices support in

[PATCH v3 0/9] rcar-vin: Add support for parallel input on Gen3

Hello, this series adds support for parallel video input to the Gen3 version of rcar-vin driver. Thanks to Niklas' review of v2, this new version allows the same VIN instance to have both a parallel and a CSI-2 subdevice connected, and to switch between them at runtime through the modification

Re: [PATCH v2 07/29] venus: hfi_venus: add halt AXI support for Venus 4xx

On Tue, May 15, 2018 at 5:12 PM Stanimir Varbanov < stanimir.varba...@linaro.org> wrote: > Add AXI halt support for version 4xx by using venus wrapper > registers. > Signed-off-by: Stanimir Varbanov > --- > drivers/media/platform/qcom/venus/hfi_venus.c | 17

Re: [ANN] Meeting to discuss improvements to support MC-based cameras on generic apps

Le vendredi 18 mai 2018 à 11:15 +0300, Laurent Pinchart a écrit : > > I need to clarify a little bit on why we disabled libv4l2 in > > GStreamer, > > as it's not only for performance reason, there is couple of major > > issues in the libv4l2 implementation that get's in way. Just a > > short > >

Re: [PATCH v3 1/2] media: imx: capture: refactor enum_/try_fmt

On Fri, 2018-05-18 at 15:56 +0200, Jan Luebbe wrote: > By checking and handling the internal IPU formats (ARGB or AYUV) first, > we don't need to check whether it's a bayer format, as we can default to > passing the input format on in all other cases. > > This simplifies handling the different

Re: [PATCH v3 2/2] media: imx: add support for RGB565_2X8 on parallel bus

On Fri, 2018-05-18 at 15:56 +0200, Jan Luebbe wrote: > The IPU can only capture RGB565 with two 8-bit cycles in bayer/generic > mode on the parallel bus, compared to a specific mode on MIPI CSI-2. > To handle this, we extend imx_media_pixfmt with a cycles per pixel > field, which is used for

Re: [PATCH v5 01/12] media: staging/imx: refactor imx media device probe

Hi Philipp, Thanks for the quick review. On Fri 18 May 2018 at 10:32, Philipp Zabel wrote: Hi Rui, thank you for refactoring, I think this is much better than having the pretend capture-subsytem device in the DT. I would like to get rid of the ipu_present flag, if it can be done

Re: [PATCH v6 1/2] media: ov2680: dt: Add bindings for OV2680

On Wed, May 09, 2018 at 03:31:58PM +0100, Rui Miguel Silva wrote: > Add device tree binding documentation for the OV2680 camera sensor. > > CC: devicet...@vger.kernel.org > Signed-off-by: Rui Miguel Silva > --- > .../devicetree/bindings/media/i2c/ov2680.txt | 46

Re: [PATCH v2 04/29] venus: hfi_cmds: add set_properties for 4xx version

On Tue, May 15, 2018 at 5:13 PM Stanimir Varbanov < stanimir.varba...@linaro.org> wrote: > Adds set_properties method to handle newer 4xx properties and > fall-back to 3xx for the rest. > Signed-off-by: Stanimir Varbanov > --- >

  1   2   >