Re: [PATCH v7 00/34] i.MX Media Driver

2017-06-01 Thread Steve Longerbeam 

Hi Tim,

On 06/01/2017 05:25 PM, Tim Harvey wrote:



Hi Steve,

I've applied adv7180 device-tree config for the Gateworks ventana
boards on top of your imx-media-staging-md-v15 github branch but am
not able to get it to work.

Here's my device-tree patch that adds adv7180 to the GW54xx connected
to IPU2_CSI1:
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts



I haven't studied your device-tree in detail yet, I'll try to have a
better look this weekend.






Here's my userspace test commands:

media-ctl -r # reset all links
export outputfmt="UYVY2X8/720x480"
# Setup links (ADV7180 IPU2_CSI1)
media-ctl -l '"adv7180 2-0020":0 -> "ipu2_csi1_mux":1[1]'
media-ctl -l '"ipu2_csi1_mux":2 -> "ipu2_csi1":0[1]'
media-ctl -l '"ipu2_csi1":1 -> "ipu2_vdic":0[1]'
media-ctl -l '"ipu2_vdic":2 -> "ipu2_ic_prp":0[1]'
media-ctl -l '"ipu2_ic_prp":2 -> "ipu2_ic_prpvf":0[1]'
media-ctl -l '"ipu2_ic_prpvf":1 -> "ipu2_ic_prpvf capture":0[1]'
# Configure pads
media-ctl -V "'adv7180 2-0020':0 [fmt:UYVY2X8/720x480]"
media-ctl -V "'ipu2_csi1_mux':2 [fmt:UYVY2X8/720x480 field:interlaced]"
media-ctl -V "'ipu2_csi1':1 [fmt:UYVY2X8/720x480 field:interlaced]"
media-ctl -V "'ipu2_vdic':2 [fmt:UYVY2X8/720x480 field:none]"
media-ctl -V "'ipu2_ic_prp':2 [fmt:AYUV32/720x480 field:none]"
media-ctl -V "'ipu2_ic_prpvf':1 [fmt:$outputfmt field:none]"
 no errors up to this point; streaming can now begin on
'ipu2_ic_prpvf capture'

# select input
v4l2-ctl --device /dev/video3 -i0 # 0=AIN1 1=AIN2 2=AIN3
VIDIOC_S_INPUT: failed: Inappropriate ioctl for device
 /sys/class/video4linux/v4l-subdev2/name is 'ipu2_ic_prpvf
capture' - is this not right?



Support for setting sensor inputs from the main video capture nodes
was long ago removed. Sorry about that, but there were objections to
reaching across the media graph to make this happen.

Until a VIDIOC_SUBDEV_S_INPUT is added to v4l2, you will just need to
send your analog signal to whichever ADV7180 input is active.





# select any supported YUV or RGB pixelformat on the capture device node
v4l2-ctl --device /dev/video3
--set-fmt-video=width=720,height=480,pixelformat=UYVY
v4l2-ctl --device /dev/video3 --stream-mmap --stream-to=/x.raw
--stream-count=1 # capture single raw-frame
[  904.870444] ipu2_ic_prpvf: EOF timeout
VIDIOC_DQBUF: failed: Input/output error
[  905.910702] ipu2_ic_prpvf: wait last EOF timeout
 not getting any frames

The last patchset of yours I had running on this board was your v3
patchset - any ideas?



Beyond maybe the input selection issue above, not really, your pipeline
config looks correct.

I have a script for the ADV7180 VDIC -> prpvf pipeline on IPU1 for the
SabreAuto, I will send to you separately to see if that helps.




As it looks like things have settled down with this patchset and it
sounds like it will get merged for 4.13 I'm going to start working on
a driver for the tda1997x HDMI receiver which is also on this board
connected to IPU1_CSI0.


Awesome, thanks.

Steve

Re: [PATCH v7 00/34] i.MX Media Driver

2017-06-01 Thread Tim Harvey 
On Wed, May 24, 2017 at 5:29 PM, Steve Longerbeam  wrote:
> In version 7:
>
> - video-mux: switched to Philipp's latest video-mux driver and updated
>   bindings docs, that makes use of the mmio-mux framework.
>
> - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
>   to video-mux driver, until mux framework is merged.
>
> - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
>   devices and modifies the video-mux device to become a consumer of the
>   video mmio-mux.
>
> - minor updates to Documentation/media/v4l-drivers/imx.rst.
>
> - ov5640: do nothing if entity stream count is greater than 1 in
>   ov5640_s_stream().
>
> - Previous versions of this driver had not tested the ability to enable
>   multiple independent streams, for instance enabling multiple output
>   pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
>   prpvf outputs. Marek Vasut tested this support and reported issues
>   with it.
>
>   v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
>   that walks both sink and source pads, so if there are multiple paths
>   enabled to video capture devices, controls would be added to the wrong
>   video capture device, and no controls added to the other enabled
>   capture devices.
>
>   These issues have been fixed. Control inheritance works correctly now
>   even with multiple enabled capture paths, and (for example)
>   simultaneous capture from prpenc and prpvf works also, and each with
>   independent scaling, CSC, and controls. For example prpenc can be
>   capturing with a 90 degree rotation, while prpvf is capturing with
>   vertical flip.
>
>   So the v4l2_pipeline_inherit_controls() patch has been dropped. The
>   new version of control inheritance could be made generically available,
>   but it would be more involved to incorporate it into v4l2-core.
>
> - A new function imx_media_fill_default_mbus_fields() is added to setup
>   colorimetry at sink pads, and these are propagated to source pads.
>
> - Ensure that the current sink and source rectangles meet alignment
>   restrictions before applying a new rotation control setting in
>   prp-enc/vf subdevices.
>
> - Chain the s_stream() subdev calls instead of implementing a custom
>   stream on/off function that attempts to call a fixed set of subdevices
>   in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
>   subdevice, since the correct MIPI CSI-2 startup sequence can be
>   enforced completely in s_stream(), and s_power() is no longer
>   required. This also paves the way for more arbitrary OF graphs
>   external to the i.MX6.
>
> - Converted the v4l2_subdev and media_entity ops structures to const.
>

Hi Steve,

I've applied adv7180 device-tree config for the Gateworks ventana
boards on top of your imx-media-staging-md-v15 github branch but am
not able to get it to work.

Here's my device-tree patch that adds adv7180 to the GW54xx connected
to IPU2_CSI1:
--- a/arch/arm/boot/dts/imx6q-gw54xx.dts
+++ b/arch/arm/boot/dts/imx6q-gw54xx.dts
@@ -18,6 +18,76 @@
compatible = "gw,imx6q-gw54xx", "gw,ventana", "fsl,imx6q";
 };

+ {
+   adv7180: camera@20 {
+   compatible = "adi,adv7180";
+   pinctrl-names = "default";
+   pinctrl-0 = <_adv7180>;
+   reg = <0x20>;
+   powerdown-gpios = < 31 GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <30 GPIO_ACTIVE_LOW>;
+   inputs = <0x00 0x01 0x02>;
+   input-names = "ADV7180 Composite on Ain1",
+ "ADV7180 Composite on Ain2",
+ "ADV7180 Composite on Ain3";
+
+   port {
+   adv7180_to_ipu2_csi1_mux: endpoint {
+   remote-endpoint =
<_csi1_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   };
+   };
+   };
+};
+
+_csi1_from_ipu2_csi1_mux {
+   bus-width = <8>;
+};
+
+_csi1_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu2_csi1_mux>;
+   bus-width = <8>;
+};
+
+_csi1 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu2_csi1>;
+
+   /* enable frame interval monitor on this port */
+   fim {
+   status = "okay";
+   };
+};
+
  {
status = "okay";
 };
+
+ {
+   video {
+   pinctrl_adv7180: adv7180grp {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_D30__GPIO3_IO30
 0x0001b0b0
+   MX6QDL_PAD_EIM_D31__GPIO3_IO31
 0x4001b0b0
+   >;
+   };
+
+   pinctrl_ipu2_csi1: ipu2_csi1grp { /* IPU2_CSI1: 8-bit input */
+   fsl,pins = <
+   MX6QDL_PAD_EIM_EB2__IPU2_CSI1_DATA190x1b0b0
+   MX6QDL_PAD_EIM_D16__IPU2_CSI1_DATA180x1b0b0

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-31 Thread Pavel Machek 
Hi!

> >If there's a need for this (there should not be, as the controls are exposed
> >to the user space through the sub-device nodes as the other drivers do), the
> >framework APIs need to be extended.
> 
> Right, this gets back to the media framework usability arguments. At least
> myself, Philipp, and Russell feel that automatic inheritance of a configured
> pipeline's controls to a video device adds to the usability.

For the record, usability can be pretty much fixed in v4l-utils... I
have patches that try ioctls on a list of fd's. Now we need a way to
find out which /dev/video* files belong to single camera. I believe
kernel already has required APIs, we just need to apply v4l-utils
patch to use them...

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Steve Longerbeam 

Hi Sakari,


On 05/29/2017 08:36 AM, Sakari Ailus wrote:

Hi Hans,

On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
   bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
   to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
   devices and modifies the video-mux device to become a consumer of the
   video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
   ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
   multiple independent streams, for instance enabling multiple output
   pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
   prpvf outputs. Marek Vasut tested this support and reported issues
   with it.

   v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
   that walks both sink and source pads, so if there are multiple paths
   enabled to video capture devices, controls would be added to the wrong
   video capture device, and no controls added to the other enabled
   capture devices.

   These issues have been fixed. Control inheritance works correctly now
   even with multiple enabled capture paths, and (for example)
   simultaneous capture from prpenc and prpvf works also, and each with
   independent scaling, CSC, and controls. For example prpenc can be
   capturing with a 90 degree rotation, while prpvf is capturing with
   vertical flip.

   So the v4l2_pipeline_inherit_controls() patch has been dropped. The
   new version of control inheritance could be made generically available,
   but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
   colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
   restrictions before applying a new rotation control setting in
   prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
   stream on/off function that attempts to call a fixed set of subdevices
   in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
   subdevice, since the correct MIPI CSI-2 startup sequence can be
   enforced completely in s_stream(), and s_power() is no longer
   required. This also paves the way for more arbitrary OF graphs
   external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.

What is the status as of v7?

 From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.

That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined to one
patch since patch 17 won't compile otherwise. Any idea when the multiplexer is
expected to be merged? (just curious)

I would really like to get this merged for 4.13, so did I miss anything?
 From what I can tell it is really just an Ack for patch 2/34.

The patchset re-initialises the control handler in the video node in its
media device link_setup callback, among other things. I don't think that
this as such should prevent including the driver in staging, but at the same
time my concern is what kind of guarantees can we give in terms of V4L2
framework support on things like this using the current API. I'd say "none".


Re-initializing a control handler in itself works fine (maybe we should
add a v4l2_ctrl_handler_reinit() ?).

I agree that calling free/init/add at this time (in link_setup and 
link_notify)

is a new way to use those APIs. The effect is that a video node's controls
can change post driver load.

There's nothing in Documentation/kapi/v4l2-controls.rst that states that
a video node's control list can't change at runtime. But as I said 
free/init/add

works just fine and can be called any time after a subdevice or video device
is registered.



If there's a need for this (there should not be, as the controls are exposed
to the user space through the sub-device nodes as the other drivers do), the
framework APIs need to be extended.


Right, this gets back to the media framework usability arguments. At least
myself, Philipp, and Russell feel that automatic inheritance of a configured
pipeline's controls to a video device adds to the usability.



I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as
part of

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Hans Verkuil 

On 05/29/2017 07:23 PM, Steve Longerbeam wrote:

Hi Hans, thanks for the reply...


On 05/29/2017 06:46 AM, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:




What is the status as of v7?

 From what I can tell patch 2/34 needs an Ack from Rob Herring,



Yes still missing that Ack. I think the issue is likely the Synopsys DW
mipi csi-2 bindings. Someone earlier noted that there is another driver
under devel for this Synopsys core, with another set of bindings.
But it was determined that in fact this is a different device with a
different register set.

  From what I remember of dealing with Synopsys cores in the past,
these cores are highly configurable using their coreBuilder tools. So
while the other device might stem from the same initial core from
Synopsys, it was probably built with different design parameters
compared to the core that exists in the i.MX6. So in essence it is a
different device.



patches
4-14 are out of scope for the media subsystem,


Ok. I did submit patches 4-14 to the right set of folks. Should I just
drop this set in the next submission if they have not changed?


No, please keep them. Just make a note in the cover letter that they go
through a different tree. I like seeing the whole set :-)


patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.


Ok.



That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined
to one
patch since patch 17 won't compile otherwise. Any idea when the
multiplexer is
expected to be merged? (just curious)


Philipp replied separately.



I would really like to get this merged for 4.13, so did I miss anything?
 From what I can tell it is really just an Ack for patch 2/34.


Agreed.


Can you split off the TODO file in its own patch? It was buried in the
big patch and I missed it because of that.

Take a look at Sakari's comment from today about another TODO item that
probably should be in the TODO file.

Regards,

Hans

Regards,

Hans

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Steve Longerbeam 

Hi Hans, thanks for the reply...


On 05/29/2017 06:46 AM, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:




What is the status as of v7?

From what I can tell patch 2/34 needs an Ack from Rob Herring,



Yes still missing that Ack. I think the issue is likely the Synopsys DW
mipi csi-2 bindings. Someone earlier noted that there is another driver
under devel for this Synopsys core, with another set of bindings.
But it was determined that in fact this is a different device with a
different register set.

From what I remember of dealing with Synopsys cores in the past,
these cores are highly configurable using their coreBuilder tools. So
while the other device might stem from the same initial core from
Synopsys, it was probably built with different design parameters
compared to the core that exists in the i.MX6. So in essence it is a
different device.



patches
4-14 are out of scope for the media subsystem,


Ok. I did submit patches 4-14 to the right set of folks. Should I just
drop this set in the next submission if they have not changed?


patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.


Ok.



That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined 
to one
patch since patch 17 won't compile otherwise. Any idea when the 
multiplexer is

expected to be merged? (just curious)


Philipp replied separately.



I would really like to get this merged for 4.13, so did I miss anything?
From what I can tell it is really just an Ack for patch 2/34.


Agreed.

Steve








Marek Vasut (1):
   media: imx: Drop warning upon multiple S_STREAM disable calls

Philipp Zabel (9):
   dt-bindings: Add bindings for video-multiplexer device
   ARM: dts: imx6qdl: add multiplexer controls
   ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their
 connections
   add mux and video interface bridge entity functions
   platform: add video-multiplexer subdevice driver
   platform: video-mux: include temporary mmio-mux support
   media: imx: csi: increase burst size for YUV formats
   media: imx: csi: add frame skipping support
   media: imx: csi: add sink selection rectangles

Russell King (3):
   media: imx: csi: add support for bayer formats
   media: imx: csi: add frame size/interval enumeration
   media: imx: capture: add frame sizes/interval enumeration

Steve Longerbeam (21):
   [media] dt-bindings: Add bindings for i.MX media driver
   [media] dt/bindings: Add bindings for OV5640
   ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
   ARM: dts: imx6qdl: add capture-subsystem device
   ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
   ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
   ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
   ARM: dts: imx6-sabreauto: create i2cmux for i2c3
   ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
   ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
   ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
   [media] add Omnivision OV5640 sensor driver
   media: Add userspace header file for i.MX
   media: Add i.MX media core driver
   media: imx: Add Capture Device Interface
   media: imx: Add CSI subdev driver
   media: imx: Add VDIC subdev driver
   media: imx: Add IC subdev drivers
   media: imx: Add MIPI CSI-2 Receiver subdev driver
   ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
   media: imx: set and propagate default field, colorimetry

  .../devicetree/bindings/media/i2c/ov5640.txt   |   45 +
  Documentation/devicetree/bindings/media/imx.txt|   74 +
  .../devicetree/bindings/media/video-mux.txt|   60 +
  Documentation/media/uapi/mediactl/media-types.rst  |   22 +
  Documentation/media/v4l-drivers/imx.rst|  590 ++
  arch/arm/boot/dts/imx6dl-sabrelite.dts |5 +
  arch/arm/boot/dts/imx6dl-sabresd.dts   |5 +
  arch/arm/boot/dts/imx6dl.dtsi  |  189 ++
  arch/arm/boot/dts/imx6q-sabrelite.dts  |5 +
  arch/arm/boot/dts/imx6q-sabresd.dts|5 +
  arch/arm/boot/dts/imx6q.dtsi   |  125 ++
  arch/arm/boot/dts/imx6qdl-sabreauto.dtsi   |  144 +-
  arch/arm/boot/dts/imx6qdl-sabrelite.dtsi   |  152 +-
  arch/arm/boot/dts/imx6qdl-sabresd.dtsi |  114 +-
  arch/arm/boot/dts/imx6qdl.dtsi |   20 +-
  arch/arm/configs/imx_v6_v7_defconfig   |   11 +
  drivers/media/i2c/Kconfig  |9 +
  drivers/media/i2c/Makefile |1 +
  drivers/media/i2c/ov5640.c | 2224

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Hans Verkuil 

On 05/29/2017 05:36 PM, Sakari Ailus wrote:

Hi Hans,

On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
   bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
   to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
   devices and modifies the video-mux device to become a consumer of the
   video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
   ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
   multiple independent streams, for instance enabling multiple output
   pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
   prpvf outputs. Marek Vasut tested this support and reported issues
   with it.

   v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
   that walks both sink and source pads, so if there are multiple paths
   enabled to video capture devices, controls would be added to the wrong
   video capture device, and no controls added to the other enabled
   capture devices.

   These issues have been fixed. Control inheritance works correctly now
   even with multiple enabled capture paths, and (for example)
   simultaneous capture from prpenc and prpvf works also, and each with
   independent scaling, CSC, and controls. For example prpenc can be
   capturing with a 90 degree rotation, while prpvf is capturing with
   vertical flip.

   So the v4l2_pipeline_inherit_controls() patch has been dropped. The
   new version of control inheritance could be made generically available,
   but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
   colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
   restrictions before applying a new rotation control setting in
   prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
   stream on/off function that attempts to call a fixed set of subdevices
   in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
   subdevice, since the correct MIPI CSI-2 startup sequence can be
   enforced completely in s_stream(), and s_power() is no longer
   required. This also paves the way for more arbitrary OF graphs
   external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.


What is the status as of v7?

 From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.

That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined to one
patch since patch 17 won't compile otherwise. Any idea when the multiplexer is
expected to be merged? (just curious)

I would really like to get this merged for 4.13, so did I miss anything?
 From what I can tell it is really just an Ack for patch 2/34.


The patchset re-initialises the control handler in the video node in its
media device link_setup callback, among other things. I don't think that
this as such should prevent including the driver in staging, but at the same
time my concern is what kind of guarantees can we give in terms of V4L2
framework support on things like this using the current API. I'd say "none".

If there's a need for this (there should not be, as the controls are exposed
to the user space through the sub-device nodes as the other drivers do), the
framework APIs need to be extended.

I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as
part of the patchset that would include a list of things left to do so
they're not forgotten.



A TODO file, that's a very good point. Yes, we need that.

Regards,

Hans

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Sakari Ailus 
Hi Hans,

On Mon, May 29, 2017 at 03:46:08PM +0200, Hans Verkuil wrote:
> Hi Steve,
> 
> On 05/25/2017 02:29 AM, Steve Longerbeam wrote:
> >In version 7:
> >
> >- video-mux: switched to Philipp's latest video-mux driver and updated
> >   bindings docs, that makes use of the mmio-mux framework.
> >
> >- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
> >   to video-mux driver, until mux framework is merged.
> >
> >- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
> >   devices and modifies the video-mux device to become a consumer of the
> >   video mmio-mux.
> >
> >- minor updates to Documentation/media/v4l-drivers/imx.rst.
> >
> >- ov5640: do nothing if entity stream count is greater than 1 in
> >   ov5640_s_stream().
> >
> >- Previous versions of this driver had not tested the ability to enable
> >   multiple independent streams, for instance enabling multiple output
> >   pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
> >   prpvf outputs. Marek Vasut tested this support and reported issues
> >   with it.
> >
> >   v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
> >   that walks both sink and source pads, so if there are multiple paths
> >   enabled to video capture devices, controls would be added to the wrong
> >   video capture device, and no controls added to the other enabled
> >   capture devices.
> >
> >   These issues have been fixed. Control inheritance works correctly now
> >   even with multiple enabled capture paths, and (for example)
> >   simultaneous capture from prpenc and prpvf works also, and each with
> >   independent scaling, CSC, and controls. For example prpenc can be
> >   capturing with a 90 degree rotation, while prpvf is capturing with
> >   vertical flip.
> >
> >   So the v4l2_pipeline_inherit_controls() patch has been dropped. The
> >   new version of control inheritance could be made generically available,
> >   but it would be more involved to incorporate it into v4l2-core.
> >
> >- A new function imx_media_fill_default_mbus_fields() is added to setup
> >   colorimetry at sink pads, and these are propagated to source pads.
> >
> >- Ensure that the current sink and source rectangles meet alignment
> >   restrictions before applying a new rotation control setting in
> >   prp-enc/vf subdevices.
> >
> >- Chain the s_stream() subdev calls instead of implementing a custom
> >   stream on/off function that attempts to call a fixed set of subdevices
> >   in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
> >   subdevice, since the correct MIPI CSI-2 startup sequence can be
> >   enforced completely in s_stream(), and s_power() is no longer
> >   required. This also paves the way for more arbitrary OF graphs
> >   external to the i.MX6.
> >
> >- Converted the v4l2_subdev and media_entity ops structures to const.
> 
> What is the status as of v7?
> 
> From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
> are all staging (so fine to be merged from my point of view).
> 
> I'm not sure if patch 26 (defconfig) should be applied while the imx
> driver is in staging. I would suggest that this patch is moved to the end
> of the series.
> 
> That leaves patches 15-19. I replied to patch 15 with a comment, patches
> 16-18 look good to me, although patches 17 and 18 should be combined to one
> patch since patch 17 won't compile otherwise. Any idea when the multiplexer is
> expected to be merged? (just curious)
> 
> I would really like to get this merged for 4.13, so did I miss anything?
> From what I can tell it is really just an Ack for patch 2/34.

The patchset re-initialises the control handler in the video node in its
media device link_setup callback, among other things. I don't think that
this as such should prevent including the driver in staging, but at the same
time my concern is what kind of guarantees can we give in terms of V4L2
framework support on things like this using the current API. I'd say "none".

If there's a need for this (there should not be, as the controls are exposed
to the user space through the sub-device nodes as the other drivers do), the
framework APIs need to be extended.

I think it'd be good to add a TODO file (such as the one in OMAP4ISS) as
part of the patchset that would include a list of things left to do so
they're not forgotten.

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Hans Verkuil 

On 05/29/2017 04:21 PM, Hans Verkuil wrote:

On 05/29/2017 04:15 PM, Philipp Zabel wrote:

On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
 bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
 to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
 devices and modifies the video-mux device to become a consumer of the
 video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
 ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
 multiple independent streams, for instance enabling multiple output
 pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
 prpvf outputs. Marek Vasut tested this support and reported issues
 with it.

 v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
 that walks both sink and source pads, so if there are multiple paths
 enabled to video capture devices, controls would be added to the wrong
 video capture device, and no controls added to the other enabled
 capture devices.

 These issues have been fixed. Control inheritance works correctly now
 even with multiple enabled capture paths, and (for example)
 simultaneous capture from prpenc and prpvf works also, and each with
 independent scaling, CSC, and controls. For example prpenc can be
 capturing with a 90 degree rotation, while prpvf is capturing with
 vertical flip.

 So the v4l2_pipeline_inherit_controls() patch has been dropped. The
 new version of control inheritance could be made generically available,
 but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
 colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
 restrictions before applying a new rotation control setting in
 prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
 stream on/off function that attempts to call a fixed set of subdevices
 in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
 subdevice, since the correct MIPI CSI-2 startup sequence can be
 enforced completely in s_stream(), and s_power() is no longer
 required. This also paves the way for more arbitrary OF graphs
 external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.


What is the status as of v7?

   From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.

That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined to one
patch since patch 17 won't compile otherwise.


Is this a problem? It won't break any builds as patch 17 depends on
CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the
two patches, though.


You are right, but it is weird. I think I would prefer to have these two
merged and the #ifdef CONFIG_MULTIPLEXER bits removed. Just a note in the
commit log that this should be converted to the multiplexer when that gets
merged would be enough.

Dead code in drivers/media should be avoided because that's what this
driver currently has.


Thanks for those updates! That really leaves just an Ack for patch 2/34.

Sooo close!

Regards,

Hans

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Hans Verkuil 

On 05/29/2017 04:15 PM, Philipp Zabel wrote:

On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote:

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
devices and modifies the video-mux device to become a consumer of the
video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
multiple independent streams, for instance enabling multiple output
pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
prpvf outputs. Marek Vasut tested this support and reported issues
with it.

v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
that walks both sink and source pads, so if there are multiple paths
enabled to video capture devices, controls would be added to the wrong
video capture device, and no controls added to the other enabled
capture devices.

These issues have been fixed. Control inheritance works correctly now
even with multiple enabled capture paths, and (for example)
simultaneous capture from prpenc and prpvf works also, and each with
independent scaling, CSC, and controls. For example prpenc can be
capturing with a 90 degree rotation, while prpvf is capturing with
vertical flip.

So the v4l2_pipeline_inherit_controls() patch has been dropped. The
new version of control inheritance could be made generically available,
but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
restrictions before applying a new rotation control setting in
prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
stream on/off function that attempts to call a fixed set of subdevices
in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
subdevice, since the correct MIPI CSI-2 startup sequence can be
enforced completely in s_stream(), and s_power() is no longer
required. This also paves the way for more arbitrary OF graphs
external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.


What is the status as of v7?

  From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.

That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined to one
patch since patch 17 won't compile otherwise.


Is this a problem? It won't break any builds as patch 17 depends on
CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the
two patches, though.


You are right, but it is weird. I think I would prefer to have these two
merged and the #ifdef CONFIG_MULTIPLEXER bits removed. Just a note in the
commit log that this should be converted to the multiplexer when that gets
merged would be enough.

Dead code in drivers/media should be avoided because that's what this
driver currently has.

Regards,

Hans




Any idea when the multiplexer is expected to be merged? (just curious)


I have no idea. v15 of the multiplexer framework patchset was posted on
2017-05-14, is still waiting for comments.


I would really like to get this merged for 4.13, so did I miss anything?


Seconded, and not that I can tell.


  From what I can tell it is really just an Ack for patch 2/34.


regards
Philipp

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Philipp Zabel 
On Mon, 2017-05-29 at 15:46 +0200, Hans Verkuil wrote:
> Hi Steve,
> 
> On 05/25/2017 02:29 AM, Steve Longerbeam wrote:
> > In version 7:
> > 
> > - video-mux: switched to Philipp's latest video-mux driver and updated
> >bindings docs, that makes use of the mmio-mux framework.
> > 
> > - mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
> >to video-mux driver, until mux framework is merged.
> > 
> > - mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
> >devices and modifies the video-mux device to become a consumer of the
> >video mmio-mux.
> > 
> > - minor updates to Documentation/media/v4l-drivers/imx.rst.
> > 
> > - ov5640: do nothing if entity stream count is greater than 1 in
> >ov5640_s_stream().
> > 
> > - Previous versions of this driver had not tested the ability to enable
> >multiple independent streams, for instance enabling multiple output
> >pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
> >prpvf outputs. Marek Vasut tested this support and reported issues
> >with it.
> > 
> >v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
> >that walks both sink and source pads, so if there are multiple paths
> >enabled to video capture devices, controls would be added to the wrong
> >video capture device, and no controls added to the other enabled
> >capture devices.
> > 
> >These issues have been fixed. Control inheritance works correctly now
> >even with multiple enabled capture paths, and (for example)
> >simultaneous capture from prpenc and prpvf works also, and each with
> >independent scaling, CSC, and controls. For example prpenc can be
> >capturing with a 90 degree rotation, while prpvf is capturing with
> >vertical flip.
> > 
> >So the v4l2_pipeline_inherit_controls() patch has been dropped. The
> >new version of control inheritance could be made generically available,
> >but it would be more involved to incorporate it into v4l2-core.
> > 
> > - A new function imx_media_fill_default_mbus_fields() is added to setup
> >colorimetry at sink pads, and these are propagated to source pads.
> > 
> > - Ensure that the current sink and source rectangles meet alignment
> >restrictions before applying a new rotation control setting in
> >prp-enc/vf subdevices.
> > 
> > - Chain the s_stream() subdev calls instead of implementing a custom
> >stream on/off function that attempts to call a fixed set of subdevices
> >in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
> >subdevice, since the correct MIPI CSI-2 startup sequence can be
> >enforced completely in s_stream(), and s_power() is no longer
> >required. This also paves the way for more arbitrary OF graphs
> >external to the i.MX6.
> > 
> > - Converted the v4l2_subdev and media_entity ops structures to const.
> 
> What is the status as of v7?
>
>  From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
> 4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
> are all staging (so fine to be merged from my point of view).
> 
> I'm not sure if patch 26 (defconfig) should be applied while the imx
> driver is in staging. I would suggest that this patch is moved to the end
> of the series.
> 
> That leaves patches 15-19. I replied to patch 15 with a comment, patches
> 16-18 look good to me, although patches 17 and 18 should be combined to one
> patch since patch 17 won't compile otherwise.

Is this a problem? It won't break any builds as patch 17 depends on
CONFIG_MULTIPLEXER, which doesn't exist yet. I'm fine with merging the
two patches, though.

> Any idea when the multiplexer is expected to be merged? (just curious)

I have no idea. v15 of the multiplexer framework patchset was posted on
2017-05-14, is still waiting for comments.

> I would really like to get this merged for 4.13, so did I miss anything?

Seconded, and not that I can tell.

>  From what I can tell it is really just an Ack for patch 2/34.

regards
Philipp

Re: [PATCH v7 00/34] i.MX Media Driver

2017-05-29 Thread Hans Verkuil 

Hi Steve,

On 05/25/2017 02:29 AM, Steve Longerbeam wrote:

In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
   bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
   to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
   devices and modifies the video-mux device to become a consumer of the
   video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
   ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
   multiple independent streams, for instance enabling multiple output
   pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
   prpvf outputs. Marek Vasut tested this support and reported issues
   with it.

   v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
   that walks both sink and source pads, so if there are multiple paths
   enabled to video capture devices, controls would be added to the wrong
   video capture device, and no controls added to the other enabled
   capture devices.

   These issues have been fixed. Control inheritance works correctly now
   even with multiple enabled capture paths, and (for example)
   simultaneous capture from prpenc and prpvf works also, and each with
   independent scaling, CSC, and controls. For example prpenc can be
   capturing with a 90 degree rotation, while prpvf is capturing with
   vertical flip.

   So the v4l2_pipeline_inherit_controls() patch has been dropped. The
   new version of control inheritance could be made generically available,
   but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
   colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
   restrictions before applying a new rotation control setting in
   prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
   stream on/off function that attempts to call a fixed set of subdevices
   in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
   subdevice, since the correct MIPI CSI-2 startup sequence can be
   enforced completely in s_stream(), and s_power() is no longer
   required. This also paves the way for more arbitrary OF graphs
   external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.


What is the status as of v7?

From what I can tell patch 2/34 needs an Ack from Rob Herring, patches
4-14 are out of scope for the media subsystem, patches 20-25 and 27-34
are all staging (so fine to be merged from my point of view).

I'm not sure if patch 26 (defconfig) should be applied while the imx
driver is in staging. I would suggest that this patch is moved to the end
of the series.

That leaves patches 15-19. I replied to patch 15 with a comment, patches
16-18 look good to me, although patches 17 and 18 should be combined to one
patch since patch 17 won't compile otherwise. Any idea when the multiplexer is
expected to be merged? (just curious)

I would really like to get this merged for 4.13, so did I miss anything?
From what I can tell it is really just an Ack for patch 2/34.

Regards,

Hans




Marek Vasut (1):
   media: imx: Drop warning upon multiple S_STREAM disable calls

Philipp Zabel (9):
   dt-bindings: Add bindings for video-multiplexer device
   ARM: dts: imx6qdl: add multiplexer controls
   ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their
 connections
   add mux and video interface bridge entity functions
   platform: add video-multiplexer subdevice driver
   platform: video-mux: include temporary mmio-mux support
   media: imx: csi: increase burst size for YUV formats
   media: imx: csi: add frame skipping support
   media: imx: csi: add sink selection rectangles

Russell King (3):
   media: imx: csi: add support for bayer formats
   media: imx: csi: add frame size/interval enumeration
   media: imx: capture: add frame sizes/interval enumeration

Steve Longerbeam (21):
   [media] dt-bindings: Add bindings for i.MX media driver
   [media] dt/bindings: Add bindings for OV5640
   ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
   ARM: dts: imx6qdl: add capture-subsystem device
   ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
   ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
   ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
   ARM: dts: imx6-sabreauto: create i2cmux for i2c3
   ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
   ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
   ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
   [media] add Omnivision

[PATCH v7 00/34] i.MX Media Driver

2017-05-24 Thread Steve Longerbeam 
In version 7:

- video-mux: switched to Philipp's latest video-mux driver and updated
  bindings docs, that makes use of the mmio-mux framework.

- mmio-mux: includes Philipp's temporary patch that adds mmio-mux support
  to video-mux driver, until mux framework is merged.

- mmio-mux: updates to device tree from Philipp that define the i.MX6 mux
  devices and modifies the video-mux device to become a consumer of the
  video mmio-mux.

- minor updates to Documentation/media/v4l-drivers/imx.rst.

- ov5640: do nothing if entity stream count is greater than 1 in
  ov5640_s_stream().

- Previous versions of this driver had not tested the ability to enable
  multiple independent streams, for instance enabling multiple output
  pads from the imx6-mipi-csi2 subdevice, or enabling both prpenc and
  prpvf outputs. Marek Vasut tested this support and reported issues
  with it.

  v4l2_pipeline_inherit_controls() used the media graph walk APIs, but
  that walks both sink and source pads, so if there are multiple paths
  enabled to video capture devices, controls would be added to the wrong
  video capture device, and no controls added to the other enabled
  capture devices.

  These issues have been fixed. Control inheritance works correctly now
  even with multiple enabled capture paths, and (for example)
  simultaneous capture from prpenc and prpvf works also, and each with
  independent scaling, CSC, and controls. For example prpenc can be
  capturing with a 90 degree rotation, while prpvf is capturing with
  vertical flip.

  So the v4l2_pipeline_inherit_controls() patch has been dropped. The
  new version of control inheritance could be made generically available,
  but it would be more involved to incorporate it into v4l2-core.

- A new function imx_media_fill_default_mbus_fields() is added to setup
  colorimetry at sink pads, and these are propagated to source pads.

- Ensure that the current sink and source rectangles meet alignment
  restrictions before applying a new rotation control setting in
  prp-enc/vf subdevices.

- Chain the s_stream() subdev calls instead of implementing a custom
  stream on/off function that attempts to call a fixed set of subdevices
  in a pipeline in the correct order. This also simplifies imx6-mipi-csi2
  subdevice, since the correct MIPI CSI-2 startup sequence can be
  enforced completely in s_stream(), and s_power() is no longer
  required. This also paves the way for more arbitrary OF graphs
  external to the i.MX6.

- Converted the v4l2_subdev and media_entity ops structures to const.


Marek Vasut (1):
  media: imx: Drop warning upon multiple S_STREAM disable calls

Philipp Zabel (9):
  dt-bindings: Add bindings for video-multiplexer device
  ARM: dts: imx6qdl: add multiplexer controls
  ARM: dts: imx6qdl: Add video multiplexers, mipi_csi, and their
connections
  add mux and video interface bridge entity functions
  platform: add video-multiplexer subdevice driver
  platform: video-mux: include temporary mmio-mux support
  media: imx: csi: increase burst size for YUV formats
  media: imx: csi: add frame skipping support
  media: imx: csi: add sink selection rectangles

Russell King (3):
  media: imx: csi: add support for bayer formats
  media: imx: csi: add frame size/interval enumeration
  media: imx: capture: add frame sizes/interval enumeration

Steve Longerbeam (21):
  [media] dt-bindings: Add bindings for i.MX media driver
  [media] dt/bindings: Add bindings for OV5640
  ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
  ARM: dts: imx6qdl: add capture-subsystem device
  ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
  ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
  ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
  ARM: dts: imx6-sabreauto: create i2cmux for i2c3
  ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
  ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
  ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
  [media] add Omnivision OV5640 sensor driver
  media: Add userspace header file for i.MX
  media: Add i.MX media core driver
  media: imx: Add Capture Device Interface
  media: imx: Add CSI subdev driver
  media: imx: Add VDIC subdev driver
  media: imx: Add IC subdev drivers
  media: imx: Add MIPI CSI-2 Receiver subdev driver
  ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
  media: imx: set and propagate default field, colorimetry

 .../devicetree/bindings/media/i2c/ov5640.txt   |   45 +
 Documentation/devicetree/bindings/media/imx.txt|   74 +
 .../devicetree/bindings/media/video-mux.txt|   60 +
 Documentation/media/uapi/mediactl/media-types.rst  |   22 +
 Documentation/media/v4l-drivers/imx.rst|  590 ++
 arch/arm/boot/dts/imx6dl-sabrelite.dts |5 +
 arch/arm/boot/dts/imx6dl-sabresd.dts   |5 +
 arch/arm/boot/dts/imx6dl.dtsi  |  189 ++