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: Thu Mar 1 05:00:11 CET 2018 media-tree git hash:e3e389f931a14ddf43089c7db92fc5d74edf93a4 media_build

Re: [PATCH v4 2/2] media: video-i2c: add video-i2c driver

Hi Matt, I love your patch! Perhaps something to improve: [auto build test WARNING on linuxtv-media/master] [also build test WARNING on v4.16-rc3 next-20180228] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day

[PATCH] staging/imx: Fix inconsistent IS_ERR and PTR_ERR

Fix inconsistent IS_ERR and PTR_ERR in imx_csi_probe. The proper pointer to be passed as argument is pinctrl instead of priv->vdev. This issue was detected with the help of Coccinelle. Fixes: 52e17089d185 ("media: imx: Don't initialize vars that won't be used") Signed-off-by: Gustavo A. R. Silva

[PATCH] media: renesas-ceu: mark PM functions as __maybe_unused

The PM runtime operations are unused when CONFIG_PM is disabled, leading to a harmless warning: drivers/media/platform/renesas-ceu.c:1003:12: error: 'ceu_runtime_suspend' defined but not used [-Werror=unused-function] static int ceu_runtime_suspend(struct device *dev)

[PATCH 3/3] media: vb2-core: vb2_ops: document non-interrupt-cantext calling

Driver writers can benefit in knowing if/when callbacks are called in interrupt context. But it is not completely obvious here, so document it. Signed-off-by: Luca Ceresoli Cc: Laurent Pinchart Cc: Pawel Osciak Cc:

[PATCH 2/3] media: vb2-core: document the REQUEUEING state

VB2_BUF_STATE_REQUEUEING is accepted by vb2_buffer_done() but not documented, so add it along with notes about calls in interrupt context. Signed-off-by: Luca Ceresoli Cc: Laurent Pinchart Cc: Pawel Osciak Cc: Marek

[PATCH 1/3] media: vb2-core: vb2_buffer_done: consolidate docs

Documentation about what start_streaming() should do on failure are scattered in two places and mostly duplicated, so consolidate them in one of the two places. Signed-off-by: Luca Ceresoli Cc: Laurent Pinchart Cc: Pawel Osciak

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

Hi Kieran, On Wednesday, 28 February 2018 18:41:31 EET Kieran Bingham wrote: > Hi Laurent, > > This series has a pending question below: > > On 17/11/17 15:07, Kieran Bingham wrote: > > Hi Laurent, > > > > Just a query on your bikeshedding here. > > > > Choose your colours wisely :) > > > >

[PATCH v6 1/9] v4l: vsp1: Reword uses of 'fragment' as 'body'

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 fragment with a body, along with the corresponding pluralised

[PATCH v6 5/9] v4l: vsp1: Use reference counting for bodies

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 multiple display lists. Signed-off-by: Kieran Bingham

[PATCH v6 3/9] v4l: vsp1: Provide a body pool

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 TLB, and a large number of display list allocations adds pressure to this resource. Reduce TLB pressure on the IPMMUs by allocating

[PATCH v6 9/9] v4l: vsp1: Reduce display list body size

The display list originally allocated a body of 256 entries to store all of the register lists required for each frame. This has now been separated into fragments for constant stream setup, and runtime updates. Empirical testing shows that the body0 now uses a maximum of 41 registers for each

[PATCH v6 7/9] v4l: vsp1: Adapt entities to configure into a body

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() are removed in this process, thus it too is removed. A helper,

[PATCH v6 0/9] vsp1: TLB optimisation and DL caching

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 areas and dividing the area across multiple bodies represented as a

[PATCH v6 8/9] v4l: vsp1: Move video configuration to a cached dlb

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 now the last user of the pipe->dl object. Convert this function to

[PATCH v6 2/9] v4l: vsp1: Protect bodies against overflow

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. In preparation of this add a level of protection to catch any

[PATCH v6 4/9] v4l: vsp1: Convert display lists to use new body pool

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 pool containing three bodies, allowing a userspace update before

[PATCH v6 6/9] v4l: vsp1: Refactor display list configure operations

The entities provide a single .configure operation which configures the object into the target display list, based on the vsp1_entity_params selection. This restricts us to a single function prototype for both static configuration (the pre-stream INIT stage) and the dynamic runtime stages for

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

On Wed, 28 Feb 2018, Thierry Reding wrote: > Anyone that needs something other than normal mode should use the new > atomic PWM API. At the risk of revealing my true ignorance, what is the new atomic PWM API? Where? Examples of how one would convert old code over to the

Re: [PATCH v3 05/10] pwm: add PWM mode to pwm_config()

On Thu, Feb 22, 2018 at 02:01:16PM +0200, Claudiu Beznea wrote: > Add PWM mode to pwm_config() function. The drivers which uses pwm_config() > were adapted to this change. > > Signed-off-by: Claudiu Beznea > --- > arch/arm/mach-s3c24xx/mach-rx1950.c | 11

dvb: New unsupported version of Astrometa DVB-T2

Hi. I just purchased a new DVB-T2 USB dongle on Ebay[1]. This dongle reports itself as Astrometa DVB-T2, but it does not work with the current v4l-dvb kernel (tested with 2942273). After a teardown[2], I realized, that it has a different (and unknown, as the manufacturer removed the label)

[PATCH v2] media: stm32-dcmi: add JPEG support

Add DCMI JPEG support. Signed-off-by: Hugues Fruchet --- version 2: - Removed V4L2_FMT_FLAG_COMPRESSED flag setting already set by V4L2 core See https://www.mail-archive.com/linux-media@vger.kernel.org/msg126825.html drivers/media/platform/stm32/stm32-dcmi.c | 193

Re: [PATCH] media: stm32-dcmi: add JPEG support

Hi Hans, Yes depends on 'fix lock scheme', I'll send a v2 of this jpeg commit for unneeded V4L2_FMT_FLAG_COMPRESSED. Best regards, Hugues. On 02/26/2018 03:17 PM, Hans Verkuil wrote: > On 02/22/2018 10:51 AM, Hugues Fruchet wrote: >> Add DCMI JPEG support. > > Does this patch depend on the

Re: [PATCH v2] media: stm32-dcmi: fix lock scheme

Hi Hans, Problem was that lock was held while calling dmaengine APIs, which causes double lock issue when dma callback was called under context of dma_async_issue_pending() (see dcmi_start_dma() & below comments). Rest of changes are around spin_lock() changed to spin_lock_irq() for safer lock

Re: [PATCH v2 5/8] v4l: vsp1: Refactor display list configure operations

Hi Laurent, This series has a pending question below: On 17/11/17 15:07, Kieran Bingham wrote: > Hi Laurent, > > Just a query on your bikeshedding here. > > Choose your colours wisely :) > > -- > Kieran > > On 12/09/17 20:19, Laurent Pinchart wrote: >> Hi Kieran, >> >> On Tuesday, 12

Re: Patch review

Hi Laurent, Yes, that's correct. Thanks Guennadi On Wed, 28 Feb 2018, Laurent Pinchart wrote: > Hi Guennadi, > > On Wednesday, 28 February 2018 17:07:00 EET Guennadi Liakhovetski wrote: > > Hi, > > > > I know the "development process and responsibilities" was the main topic > > during the

[PATCH v2 0/2] media: Introduce Omnivision OV2680 driver

Add driver and bindings for the OV2680 2 megapixel CMOS 1/5" sensor, which has a single MIPI lane interface and output format of 10-bit Raw RGB. Features supported are described in PATCH 2/2. v1->v2: Fabio Estevam: - s/OV5640/OV2680 in PATCH 1/2 changelog Sakari Ailus: - add description

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

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 | 40 ++ 1 file changed, 40 insertions(+) create mode 100644

[PATCH v2 2/2] media: ov2680: Add Omnivision OV2680 sensor driver

This patch adds V4L2 sub-device driver for OV2680 image sensor. The OV2680 is a 1/5" CMOS color sensor from Omnivision. Supports output format: 10-bit Raw RGB. The OV2680 has a single lane MIPI interface. The driver exposes following V4L2 controls: - auto/manual exposure, - exposure, -

Re: Patch review

Hi Guennadi, On Wednesday, 28 February 2018 17:07:00 EET Guennadi Liakhovetski wrote: > Hi, > > I know the "development process and responsibilities" was the main topic > during the last media summit. Unfortunately I haven't attended it, from > the etherpad notes I also cannot quite conclude

Patch review

Hi, I know the "development process and responsibilities" was the main topic during the last media summit. Unfortunately I haven't attended it, from the etherpad notes I also cannot quite conclude what decisions have been made. Have any measures been discussed and agreed upon for cases, when

Re: [PATCH RFC] media: em28xx: don't use coherent buffer for DMA transfers

On Tue, Feb 27, 2018 at 12:42 PM, Mauro Carvalho Chehab wrote: > While coherent memory is cheap on x86, it has problems on > arm. So, stop using it. > > Signed-off-by: Mauro Carvalho Chehab > --- > > I wrote this patch in order to check if this

Re: [v5 2/2] media: dt-bindings: Add bindings for Dongwoon DW9807 voice coil

Hi Rob, Thanks for the review. On Tue, Feb 27, 2018 at 04:10:31PM -0600, Rob Herring wrote: > On Fri, Feb 23, 2018 at 10:13 AM, Andy Yeh wrote: > > From: Alan Chiang > > > > Dongwoon DW9807 is a voice coil lens driver. > > > > Also add a vendor

[GIT FIXES FOR 4.16] Remove LIRC_CAN_SEND_SCANCODE

Hi Mauro, Here is a fix to the documentation warning. LIRC_CAN_SEND_SCANCODE was introduced in v4.16 to signify that kernel IR encoders could be used for IR Tx; this lirc feature bit was found to trip up the lirc daemon, so it was removed again but not from the lirc header. See

[PATCH for v4.16] tegra-cec: reset rx_buf_cnt when start bit detected

If a start bit is detected, then reset the receive buffer counter to 0. This ensures that no stale data is in the buffer if a message is broken off midstream due to e.g. a Low Drive condition and then retransmitted. The only Rx interrupts we need to listen to are RX_REGISTER_FULL (i.e. a valid

Re: [v2] [media] Use common error handling code in 20 functions

Hello, On Wednesday, 28 February 2018 10:45:21 EET SF Markus Elfring wrote: > >> +put_isp: > >> + omap3isp_put(video->isp); > >> +delete_fh: > >> + v4l2_fh_del(>vfh); > >> + v4l2_fh_exit(>vfh); > >> + kfree(handle); > > > > Please prefix the error labels with error_. > > How often do you

Re: [v2] [media] Use common error handling code in 20 functions

>> +put_isp: >> +omap3isp_put(video->isp); >> +delete_fh: >> +v4l2_fh_del(>vfh); >> +v4l2_fh_exit(>vfh); >> +kfree(handle); > > Please prefix the error labels with error_. How often do you really need such an extra prefix? >> +++ b/drivers/media/usb/uvc/uvc_v4l2.c >> @@ -994,10