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 Jan 5 05:00:10 CET 2017 media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a media_build

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

從我的 iPad 傳送 > Daniel Stone 於 2017年1月5日 上午1:02 寫道： > > Hi Randy, > >> On 4 January 2017 at 16:29, Randy Li wrote: >> index 90d2cc8..23c8e99 100644 >> --- a/drivers/gpu/drm/drm_fourcc.c >> +++ b/drivers/gpu/drm/drm_fourcc.c >> @@ -165,6 +165,9 @@ const

Re: [PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

Hi Randy, On 4 January 2017 at 16:29, Randy Li wrote: > index 90d2cc8..23c8e99 100644 > --- a/drivers/gpu/drm/drm_fourcc.c > +++ b/drivers/gpu/drm/drm_fourcc.c > @@ -165,6 +165,9 @@ const struct drm_format_info *__drm_format_info(u32 > format) > { .format =

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

On Thu, Jan 05, 2017 at 12:31:27AM +0800, ayaka wrote: > > > On 01/04/2017 11:56 PM, Ville Syrjälä wrote: > > On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote: > >> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits > >> per channel video format. Rockchip's vop support this > >>

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

On 01/04/2017 11:56 PM, Ville Syrjälä wrote: On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote: P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only) as the input video format.

[PATCH v2 0/2] Add pixel formats for 10/16 bits YUV video

Those pixel formats mainly comes from Gstreamer and ffmpeg. Currently, the VOP(video output mixer) found on RK3288 and future support those 10 bits pixel formats are input. Also the decoder on RK3288 could use them as output. The fourcc is not enough to store the endian information for those

[PATCH v2 2/2] [media] v4l: Add 10/16-bits per channel YUV pixel formats

The formats added by this patch are: V4L2_PIX_FMT_P010 V4L2_PIX_FMT_P010M V4L2_PIX_FMT_P016 V4L2_PIX_FMT_P016M Currently, none of driver uses those format, but some video device has been confirmed with could as those format for video output. The Rockchip's new

[PATCH v2 1/2] drm_fourcc: Add new P010, P016 video format

P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per channel video format. Rockchip's vop support this video format(little endian only) as the input video format. P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per channel video format. Signed-off-by: Randy Li

Re: [PATCH 1/2] drm_fourcc: Add new P010 video format

On Mon, Jan 02, 2017 at 04:50:03PM +0800, Randy Li wrote: > P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits > per channel video format. Rockchip's vop support this > video format(little endian only) as the input video format. > > Signed-off-by: Randy Li > --- >

Re: [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

On Tue, Jan 3, 2017 at 6:57 PM, Steve Longerbeam wrote: > + camera: ov5642@3c { > + compatible = "ovti,ov5642"; > + pinctrl-names = "default"; > + pinctrl-0 = <_ov5642>; > + clocks = < IMX6QDL_CLK_CKO>; > +

Re: [PATCH v2 15/19] media: imx: Add MIPI CSI-2 Receiver subdev driver

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > Adds MIPI CSI-2 Receiver subdev driver. This subdev is required > for sensors with a MIPI CSI2 interface. > > Signed-off-by: Steve Longerbeam > --- > drivers/staging/media/imx/Makefile| 1 + >

Re: [PATCH v2 14/19] media: imx: Add Camera Interface subdev driver

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > This is the camera interface driver that provides the v4l2 > user interface. Frames can be received from various sources: > > - directly from SMFC for capturing unconverted images directly from > camera sensors. > > - from the IC pre-process

Re: [PATCH v2 13/19] media: imx: Add IC subdev drivers

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > This is a set of three media entity subdevice drivers for the i.MX > Image Converter. The i.MX IC module contains three independent > "tasks": > > - Pre-processing Encode task: video frames are routed directly from > the CSI and can be scaled,

Re: [PATCH v2 12/19] media: imx: Add SMFC subdev driver

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > This is a media entity subdevice driver for the i.MX Sensor Multi-FIFO > Controller module. Video frames are received from the CSI and can > be routed to various sinks including the i.MX Image Converter for > scaling, color-space conversion, motion

[PATCH] [media] v4l2-subdev.h: fix v4l2_subdev_pad_config documentation

The fields of v4l2_subdev_pad_config are not pointers. Fixes: 21c29de1d09 ("[media] v4l2-subdev.h: Improve documentation") Cc: Mauro Carvalho Chehab Signed-off-by: Baruch Siach --- include/media/v4l2-subdev.h | 6 +++--- 1 file changed, 3

Re: [PATCH v2 11/19] media: imx: Add CSI subdev driver

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > This is a media entity subdevice for the i.MX Camera > Serial Interface module. > > Signed-off-by: Steve Longerbeam > --- [snip] > diff --git a/drivers/staging/media/imx/imx-csi.c >

Re: [PATCH v2 10/19] media: Add i.MX media core driver

Hi Steve, On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > Add the core media driver for i.MX SOC. > > Signed-off-by: Steve Longerbeam > --- > Documentation/devicetree/bindings/media/imx.txt | 205 + v2 was sent before getting Rob's review comments, but

Re: [PATCH v2 09/19] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > Enables the ADV7180 decoder sensor. The ADV7180 connects to the > parallel-bus mux input on ipu1_csi0_mux. > > On the sabreauto, two analog video inputs are routed to the ADV7180, > composite on Ain1, and composite on Ain3. Those inputs are

Re: [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. > > The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux. > > The OV5640 connects to the input port on the MIPI CSI-2 receiver on > mipi_csi. It is set

Re: [PATCH v2 04/19] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

Hi Steve, On 01/03/2017 10:57 PM, Steve Longerbeam wrote: > Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor. > Both hang off the same i2c2 bus, so they require different (and non- > default) i2c slave addresses. > > The OV5642 connects to the parallel-bus mux input port

Re: [PATCH v6 0/5] davinci: VPIF: add DT support

+ Mauro On Tuesday 03 January 2017 02:42 PM, Laurent Pinchart wrote: > Hi Sekhar, > > On Tuesday 03 Jan 2017 14:33:00 Sekhar Nori wrote: >> On Friday 16 December 2016 03:17 PM, Hans Verkuil wrote: >>> On 07/12/16 19:30, Kevin Hilman wrote: Prepare the groundwork for adding DT support for

Re: [PATCH] uapi: use wildcards to list files

Le 03/01/2017 à 22:37, Arnd Bergmann a écrit : > On Tuesday, January 3, 2017 3:35:44 PM CET Nicolas Dichtel wrote: >> Regularly, when a new header is created in include/uapi/, the developer >> forgets to add it in the corresponding Kbuild file. This error is usually >> detected after the release

Re: [PATCH] media: entity: Catch unbalanced media_pipeline_stop calls

Hi Kieran, Thanks for the patch! On Tue, Jan 03, 2017 at 05:05:58PM +, Kieran Bingham wrote: > On 03/01/17 13:36, Laurent Pinchart wrote: > > Hi Kieran, > > > > Thank you for the patch. > > > > On Tuesday 03 Jan 2017 13:12:11 Kieran Bingham wrote: > >> Drivers must not perform unbalanced

Re: [PATCH] dt: bindings: Add support for CSI1 bus

Hi Rob, Thanks for the review. On Tue, Jan 03, 2017 at 02:38:54PM -0600, Rob Herring wrote: > On Wed, Dec 28, 2016 at 07:30:36PM +0100, Pavel Machek wrote: > > From: Sakari Ailus > > > > In the vast majority of cases the bus type is known to the driver(s) > > since a

Re: [PATCHv2 4/4] s5p-cec: add hpd-notifier support, move out of staging

On 03.01.2017 09:11, Hans Verkuil wrote: > On 01/03/2017 09:00 AM, Andrzej Hajda wrote: >> Is there a reason to split registration into two steps? >> Wouldn't be better to integrate hpd_notifier_get into >> cec_register_hpd_notifier. > One problem is that hpd_notifier_get can fail, whereas >