Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

2017-02-15 Thread Laurent Pinchart
Hi Rob,

On Wednesday 15 Feb 2017 16:08:22 Rob Herring wrote:
> On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
> > This makes the example more or less correspond with the da850-evm
> > hardware setup.
> > 
> > Signed-off-by: Bartosz Golaszewski 
> > ---
> > 
> >  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 +
> >  1 file changed, 29 insertions(+), 6 deletions(-)
> 
> Spoke too soon...
> 
> > diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt index
> > 9c7510b..543f6f3 100644
> > --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> > @@ -28,19 +28,27 @@ I2C-connected TVP5147 decoder:
> > reg = <0x217000 0x1000>;
> > interrupts = <92>;
> > 
> > -   port {
> > -   vpif_ch0: endpoint@0 {
> > +   port@0 {
> > +   vpif_input_ch0: endpoint@0 {
> > reg = <0>;
> > bus-width = <8>;
> > -   remote-endpoint = <>;
> > +   remote-endpoint = <_in>;
> > };
> > 
> > -   vpif_ch1: endpoint@1 {
> > +   vpif_input_ch1: endpoint@1 {
> > reg = <1>;
> > bus-width = <8>;
> > data-shift = <8>;
> > };
> > };
> > +
> > +   port@1 {
> 
> The binding doc says nothing about supporting a 2nd port.
> 
> > +   vpif_output_ch0: endpoint@0 {
> > +   reg = <0>;
> 
> Don't need reg here.

And the node should then be named endpoint, not endpoint@0.

> > +   bus-width = <8>;
> > +   remote-endpoint = <_out>;
> > +   };
> > +   };
> > };

-- 
Regards,

Laurent Pinchart



cron job: media_tree daily build: WARNINGS

2017-02-15 Thread Hans Verkuil
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 Feb 16 05:00:15 CET 2017
media-tree git hash:9eeb0ed0f30938f31a3d9135a88b9502192c18dd
media_build git hash:   785cdf7f0798964681b33aad44fc2ff4d734733d
v4l-utils git hash: 77797c40cefaa03449c39c913842b119c94b16f3
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: WARNINGS
linux-3.12.67-i686: WARNINGS
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: WARNINGS
linux-3.12.67-x86_64: WARNINGS
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html


Re: [PATCH v4 32/36] media: imx: csi/fim: add support for frame intervals

2017-02-15 Thread Steve Longerbeam

Sorry, I forgot to change authorship on this patch. It should
be authored by Russell King .

Steve

On 02/15/2017 06:19 PM, Steve Longerbeam wrote:

Add support to CSI for negotiation of frame intervals, and use this
information to configure the frame interval monitor.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/imx-media-csi.c | 36 ---
  drivers/staging/media/imx/imx-media-fim.c | 28 +---
  drivers/staging/media/imx/imx-media.h |  2 +-
  3 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index b0aac82..040cca6 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -56,6 +56,7 @@ struct csi_priv {
  
  	struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];

const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
+   struct v4l2_fract frame_interval;
struct v4l2_rect crop;
  
  	/* the video device at IDMAC output pad */

@@ -565,7 +566,8 @@ static int csi_start(struct csi_priv *priv)
  
  	/* start the frame interval monitor */

if (priv->fim) {
-   ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
+   ret = imx_media_fim_set_stream(priv->fim,
+  >frame_interval, true);
if (ret)
goto idmac_stop;
}
@@ -580,7 +582,8 @@ static int csi_start(struct csi_priv *priv)
  
  fim_off:

if (priv->fim)
-   imx_media_fim_set_stream(priv->fim, priv->sensor, false);
+   imx_media_fim_set_stream(priv->fim,
+>frame_interval, false);
  idmac_stop:
if (priv->dest == IPU_CSI_DEST_IDMAC)
csi_idmac_stop(priv);
@@ -594,11 +597,36 @@ static void csi_stop(struct csi_priv *priv)
  
  	/* stop the frame interval monitor */

if (priv->fim)
-   imx_media_fim_set_stream(priv->fim, priv->sensor, false);
+   imx_media_fim_set_stream(priv->fim,
+>frame_interval, false);
  
  	ipu_csi_disable(priv->csi);

  }
  
+static int csi_g_frame_interval(struct v4l2_subdev *sd,

+   struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+
+   fi->interval = priv->frame_interval;
+
+   return 0;
+}
+
+static int csi_s_frame_interval(struct v4l2_subdev *sd,
+   struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad == CSI_SRC_PAD_IDMAC || fi->pad == CSI_SRC_PAD_DIRECT)
+   fi->interval = priv->frame_interval;
+
+   priv->frame_interval = fi->interval;
+
+   return 0;
+}
+
  static int csi_s_stream(struct v4l2_subdev *sd, int enable)
  {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
@@ -1187,6 +1215,8 @@ static struct v4l2_subdev_core_ops csi_core_ops = {
  };
  
  static struct v4l2_subdev_video_ops csi_video_ops = {

+   .g_frame_interval = csi_g_frame_interval,
+   .s_frame_interval = csi_s_frame_interval,
.s_stream = csi_s_stream,
  };
  
diff --git a/drivers/staging/media/imx/imx-media-fim.c b/drivers/staging/media/imx/imx-media-fim.c

index acc7e39..a6ed57e 100644
--- a/drivers/staging/media/imx/imx-media-fim.c
+++ b/drivers/staging/media/imx/imx-media-fim.c
@@ -67,26 +67,18 @@ struct imx_media_fim {
  };
  
  static void update_fim_nominal(struct imx_media_fim *fim,

-  struct imx_media_subdev *sensor)
+  const struct v4l2_fract *fi)
  {
-   struct v4l2_streamparm parm;
-   struct v4l2_fract tpf;
-   int ret;
-
-   parm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
-   ret = v4l2_subdev_call(sensor->sd, video, g_parm, );
-   tpf = parm.parm.capture.timeperframe;
-
-   if (ret || tpf.denominator == 0) {
-   dev_dbg(fim->sd->dev, "no tpf from sensor, FIM disabled\n");
+   if (fi->denominator == 0) {
+   dev_dbg(fim->sd->dev, "no frame interval, FIM disabled\n");
fim->enabled = false;
return;
}
  
-	fim->nominal = DIV_ROUND_CLOSEST(1000 * 1000 * tpf.numerator,

-tpf.denominator);
+   fim->nominal = DIV_ROUND_CLOSEST_ULL(100ULL * (u64)fi->numerator,
+fi->denominator);
  
-	dev_dbg(fim->sd->dev, "sensor FI=%lu usec\n", fim->nominal);

+   dev_dbg(fim->sd->dev, "FI=%lu usec\n", fim->nominal);
  }
  
  static void reset_fim(struct imx_media_fim *fim, bool curval)

@@ -130,8 +122,8 @@ 

[PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver

2017-02-15 Thread Steve Longerbeam
Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
 Documentation/devicetree/bindings/media/imx.txt | 66 +
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..fd5af50
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,66 @@
+Freescale i.MX Media Video Device
+=
+
+Video Media Controller node
+---
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports  : Should contain a list of phandles pointing to camera
+   sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+   compatible = "fsl,capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+};
+
+fim child node
+--
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+specified as . The channel number
+must be 0 or 1. The flags can be
+IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+IRQ_TYPE_EDGE_BOTH, and specify which input
+capture signal edge will trigger the input
+capture event. If an input capture channel is
+specified, the FIM will use this method to
+measure frame intervals instead of via the EOF
+interrupt. The input capture method is much
+preferred over EOF as it is not subject to
+interrupt latency errors. However it requires
+routing the VSYNC or FIELD output signals of
+the camera sensor to one of the i.MX input
+capture pads (SD1_DAT0, SD1_DAT1), which also
+gives up support for SD1.
+
+
+mipi_csi2 node
+--
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible   : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
+- reg   : physical base address and length of the register set;
+- clocks   : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+  (the DPHY clock), video_27m, and eim_podf;
+- clock-names  : must contain "dphy", "cfg", "pix";
+
+Optional properties:
+- interrupts   : must contain two level-triggered interrupts,
+  in order: 100 and 101;
-- 
2.7.4



[PATCH v4 04/36] ARM: dts: imx6qdl: add capture-subsystem device

2017-02-15 Thread Steve Longerbeam
Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl.dtsi | 5 +
 arch/arm/boot/dts/imx6q.dtsi  | 5 +
 2 files changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 371288a..f1743fc 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -100,6 +100,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index b833b0d..4cc6579 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -206,6 +206,11 @@
};
};
 
+   capture-subsystem {
+   compatible = "fsl,imx-capture-subsystem";
+   ports = <_csi0>, <_csi1>, <_csi0>, <_csi1>;
+   };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <_di0>, <_di1>, <_di0>, <_di1>;
-- 
2.7.4



[PATCH v4 00/36] i.MX Media Driver

2017-02-15 Thread Steve Longerbeam
In version 4:

Changes suggested by Philipp Zabel  and
Jean-Michel Hautbois :

- split out VDIC from imx-ic-prpvf into a distinct VDIC subdev.

Changes suggested by Philipp Zabel :

- Re-org of pre-process entities. Created an ipuX_ic_prp entity
  that receives on a single sink pad from the CSIs and the VDIC.
  Two source pads route to ipuX_ic_prpenc and ipuX_ic_prpvf. The
  code for ipuX_ic_prpenc and ipuX_ic_prpvf is now identical, which
  adds rotation to ipuX_ic_prpvf.

- renamed media node in DT to capture-subsystem, compatible string to
  "fsl,imx-capture-subsystem".

- the ov564x subdevs get the xclk rate from clk_get_rate() instead of
  attempting to change the rate. "xclk" property in ov564x DT nodes is
  removed.

- changed "pix" clock to IMX6QDL_CLK_EIM_PODF in mipi_csi node.

- added comptible string "snps,dw-mipi-csi2" to mipi_csi node in DT.

- silenced many of the v4l2_info()'s.

- move conversion of ALTERNATE field type to SEQ_BT/TB to output pad
  of ipuX_csiY entity.

- added bounds checks to set_fmt in ipuX_csiY and ipuX_vdic entities.

- Get rid of SMFC entity. CSI frame output via SMFC and IDMAC channel
  is now built into the CSI entities via a new source pad. So CSI
  entities now have two source pads : direct and IDMAC.

- the IPU internal pads (direct between subunuits, not via IDMAC channels),
  should only accept the pixel formats used internally by the IPU:
  MEDIA_BUS_FMT_AYUV8_1X32 and MEDIA_BUS_FMT_ARGB_1X32.

- export V4L2_EVENT_IMX_EOF_TIMEOUT as V4L2_EVENT_FRAME_TIMEOUT for
  general use.

- export imx_media_inherit_controls() as v4l2_pipeline_inherit_controls()
  for general use.

- completely removed dma_buf ring support. There is no capture interface
  or ic-pp subdevs any longer. The CSI and ic-prp enc/vf subdevs now attach
  directly to a capture device node from their IDMAC (non-direct) source pads.


Changes suggested by Javier Martinez Canillas :

- add missing MODULE_DEVICE_TABLE() to video mux subdev.


Changes suggested by Hans Verkuil :

- entity function type MEDIA_ENT_F_MUX renamed to MEDIA_ENT_F_VID_MUX.

- removed use of g_mbus_config subdev op. Sensor bus config is instead
  gotten from the sensor DT node via v4l2_of_parse_endpoint().

- use v4l2_ctrl_handler_setup() for restoring current control values
  in the ov564x subdevs, rather than a custom control cache.


Changes suggested by Russell King :

- re-ordered clock lane and data lane # assignments in device tree.

- fixed module unload.

- propagate the return code from ipu_ic_task_idma_init(), don't start
  streaming if it returned error!


Changes suggested by Laurent Pinchart :

- ov5640 subdev is improved and moved to drivers/media/i2c, along with
  binding docs. The ov5642 subdev has been dropped for now.

- regulator DT properties are now required in ov5640 subdev, and resewt/power
  GPIOs are optional. Created dummy regulator nodes in imx6qdl-sabrelite.dtsi
  for the ov5640 node (the ov5640 regulators are fixed regulators on the
  OV5640 module for sabrelite).

- removed use of endpoint ID in device tree as a way to specify a MIPI CSI-2
  virtual channel for the OV5640. The ov5640 subdev now hard-codes the
  virtual channel to 1 until a new subdev API becomes available to allow
  run-time virtual channel selection.


Other changes:

- v4l2-compliance fixes.

- since dma_buf ring support is gone, the VDIC subdev is modified to
  potentially receive frames from a future output device node on its
  IDMAC sink pad.

- fixed mbus pixel format enumeration and selection. The source pads
  and capture device select the correct formats based on the sink
  formats. For example the capture device can only report and allow
  selecting an RGB format if the attached source pad's format is RGB.
  Likewise for YUV space, with the added benefit that the capture
  device can select a YUV planar format in this case, and the attached
  subdev will comply and output planar.

- stripped out sensor input OF properties and parsing for now. It is
  problematic since there is currently no subdev op so that the bridge
  can retrieve this information and use for VIDIOC_{ENUM|S|G}_INPUT.

- modified imx6-mipi-csi2 subdev to comply strictly with the MIPI CSI-2
  startup sequence described in the i.MX6 reference manual.



Philipp Zabel (6):
  ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their
connections
  add mux and video interface bridge entity functions
  platform: add video-multiplexer subdevice driver
  media: imx: csi: fix crop rectangle changes in set_fmt
  media: imx: csi: add frame skipping support
  media: imx: csi: fix crop rectangle reset in sink set_fmt

Russell King (3):
  media: imx: add support for bayer formats
  media: imx: csi: add support for bayer formats
  media: imx: mipi-csi2: enable setting 

[PATCH v4 02/36] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node

2017-02-15 Thread Steve Longerbeam
Add to the MIPI CSI2 receiver node: compatible strings,
interrupt sources, and clocks.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 61569c8..aac70b9 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1125,7 +1125,14 @@
};
 
mipi_csi: mipi@021dc000 {
+   compatible = "fsl,imx6-mipi-csi2", 
"snps,dw-mipi-csi2";
reg = <0x021dc000 0x4000>;
+   interrupts = <0 100 0x04>, <0 101 0x04>;
+   clocks = < IMX6QDL_CLK_HSI_TX>,
+< IMX6QDL_CLK_VIDEO_27M>,
+< IMX6QDL_CLK_EIM_PODF>;
+   clock-names = "dphy", "cfg", "pix";
+   status = "disabled";
};
 
mipi_dsi: mipi@021e {
-- 
2.7.4



[PATCH v4 06/36] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

2017-02-15 Thread Steve Longerbeam
Adds 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 on ipu1_csi0_mux.

The OV5640 connects to the input port on the MIPI CSI-2 receiver on
mipi_csi.

The OV5642 node is disabled temporarily while the subdev driver is
cleaned up and submitted later.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
 arch/arm/boot/dts/imx6q-sabrelite.dts|   5 ++
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 148 +++
 3 files changed, 158 insertions(+)

diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
b/arch/arm/boot/dts/imx6dl-sabrelite.dts
index 0f06ca5..cfd5110 100644
--- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
@@ -48,3 +48,8 @@
model = "Freescale i.MX6 DualLite SABRE Lite Board";
compatible = "fsl,imx6dl-sabrelite", "fsl,imx6dl";
 };
+
+_csi1_from_ipu1_csi1_mux {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabrelite.dts 
b/arch/arm/boot/dts/imx6q-sabrelite.dts
index 66d10d8..e00fc06 100644
--- a/arch/arm/boot/dts/imx6q-sabrelite.dts
+++ b/arch/arm/boot/dts/imx6q-sabrelite.dts
@@ -52,3 +52,8 @@
  {
status = "okay";
 };
+
+_csi1_from_mipi_vc1 {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 795b5a5..7958a0c 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -39,6 +39,8 @@
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
  */
+
+#include 
 #include 
 #include 
 
@@ -94,6 +96,42 @@
pinctrl-0 = <_can_xcvr>;
gpio = < 2 GPIO_ACTIVE_LOW>;
};
+
+   reg_1p5v: regulator@4 {
+   compatible = "regulator-fixed";
+   reg = <4>;
+   regulator-name = "1P5V";
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-always-on;
+   };
+
+   reg_1p8v: regulator@5 {
+   compatible = "regulator-fixed";
+   reg = <5>;
+   regulator-name = "1P8V";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+   };
+
+   reg_2p8v: regulator@6 {
+   compatible = "regulator-fixed";
+   reg = <6>;
+   regulator-name = "2P8V";
+   regulator-min-microvolt = <280>;
+   regulator-max-microvolt = <280>;
+   regulator-always-on;
+   };
+   };
+
+   mipi_xclk: mipi_xclk {
+   compatible = "pwm-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2200>;
+   clock-output-names = "mipi_pwm3";
+   pwms = < 0 45>; /* 1 / 45 ns = 22 MHz */
+   status = "okay";
};
 
gpio-keys {
@@ -220,6 +258,22 @@
};
 };
 
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+   data-shift = <12>; /* Lines 19:12 used */
+   hsync-active = <1>;
+   vync-active = <1>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_audmux>;
@@ -299,6 +353,53 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   ov5640: camera@40 {
+   compatible = "ovti,ov5640";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5640>;
+   reg = <0x40>;
+   clocks = <_xclk>;
+   clock-names = "xclk";
+   DOVDD-supply = <_1p8v>;
+   AVDD-supply = <_2p8v>;
+   DVDD-supply = <_1p5v>;
+   reset-gpios = < 5 GPIO_ACTIVE_LOW>; /* NANDF_D5 */
+   pwdn-gpios = < 9 GPIO_ACTIVE_HIGH>; /* NANDF_WP_B */
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ov5640_to_mipi_csi2: endpoint {
+   remote-endpoint = <_csi2_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+   };
+
+   ov5642: camera@42 {
+   compatible = 

[PATCH v4 03/36] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

This patch adds the device tree graph connecting the input multiplexers
to the IPU CSIs and the MIPI-CSI2 gasket on i.MX6. The MIPI_IPU
multiplexers are added as children of the iomuxc-gpr syscon device node.
On i.MX6Q/D two two-input multiplexers in front of IPU1 CSI0 and IPU2
CSI1 allow to select between CSI0/1 parallel input pads and the MIPI
CSI-2 virtual channels 0/3.
On i.MX6DL/S two five-input multiplexers in front of IPU1 CSI0 and IPU1
CSI1 allow to select between CSI0/1 parallel input pads and any of the
four MIPI CSI-2 virtual channels.

Signed-off-by: Philipp Zabel 

--

- Removed some dangling/unused endpoints (ipu2_csi0_from_csi2ipu)
- Renamed the mipi virtual channel endpoint labels, from "mipi_csiX_..."
  to "mipi_vcX...".
- Added input endpoint anchors to the video muxes for the connections
  from parallel sensors.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6dl.dtsi  | 180 +
 arch/arm/boot/dts/imx6q.dtsi   | 116 ++
 arch/arm/boot/dts/imx6qdl.dtsi |  10 ++-
 3 files changed, 305 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 1ade195..371288a 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -181,6 +181,186 @@
  "di0", "di1";
 };
 
+ {
+   ipu1_csi0_mux: ipu1_csi0_mux@34 {
+   compatible = "video-multiplexer";
+   reg = <0x34>;
+   bit-mask = <0x7>;
+   bit-shift = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   port@0 {
+   reg = <0>;
+
+   ipu1_csi0_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <_vc0_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   ipu1_csi0_mux_from_mipi_vc1: endpoint {
+   remote-endpoint = <_vc1_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   ipu1_csi0_mux_from_mipi_vc2: endpoint {
+   remote-endpoint = <_vc2_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   ipu1_csi0_mux_from_mipi_vc3: endpoint {
+   remote-endpoint = <_vc3_to_ipu1_csi0_mux>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   ipu1_csi0_mux_from_parallel_sensor: endpoint {
+   };
+   };
+
+   port@5 {
+   reg = <5>;
+
+   ipu1_csi0_mux_to_ipu1_csi0: endpoint {
+   remote-endpoint = 
<_csi0_from_ipu1_csi0_mux>;
+   };
+   };
+   };
+
+   ipu1_csi1_mux: ipu1_csi1_mux@34 {
+   compatible = "video-multiplexer";
+   reg = <0x34>;
+   bit-mask = <0x7>;
+   bit-shift = <3>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "okay";
+
+   port@0 {
+   reg = <0>;
+
+   ipu1_csi1_mux_from_mipi_vc0: endpoint {
+   remote-endpoint = <_vc0_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   ipu1_csi1_mux_from_mipi_vc1: endpoint {
+   remote-endpoint = <_vc1_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   ipu1_csi1_mux_from_mipi_vc2: endpoint {
+   remote-endpoint = <_vc2_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port@3 {
+   reg = <3>;
+
+   ipu1_csi1_mux_from_mipi_vc3: endpoint {
+   remote-endpoint = <_vc3_to_ipu1_csi1_mux>;
+   };
+   };
+
+   port@4 {
+   reg = <4>;
+
+   ipu1_csi1_mux_from_parallel_sensor: endpoint {
+   };
+   };
+
+   port@5 {
+   reg = <5>;
+
+   ipu1_csi1_mux_to_ipu1_csi1: endpoint {
+   remote-endpoint = 
<_csi1_from_ipu1_csi1_mux>;
+   };
+   };
+   };
+};
+
+_csi1 {
+   ipu1_csi1_from_ipu1_csi1_mux: endpoint 

[PATCH v4 05/36] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround

2017-02-15 Thread Steve Longerbeam
There is a pin conflict with GPIO_6. This pin functions as a power
input pin to the OV5642 camera sensor, but ENET uses it as the h/w
workaround for erratum ERR006687, to wake-up the ARM cores on normal
RX and TX packet done events. So we need to remove the h/w workaround
to support the OV5642. The result is that the CPUidle driver will no
longer allow entering the deep idle states on the sabrelite.

This is a partial revert of

commit 6261c4c8f13e ("ARM: dts: imx6qdl-sabrelite: use GPIO_6 for FEC
interrupt.")
commit a28eeb43ee57 ("ARM: dts: imx6: tag boards that have the HW workaround
for ERR006687")

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 4 
 1 file changed, 4 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
index 1f9076e..795b5a5 100644
--- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi
@@ -271,9 +271,6 @@
txd1-skew-ps = <0>;
txd2-skew-ps = <0>;
txd3-skew-ps = <0>;
-   interrupts-extended = < 6 IRQ_TYPE_LEVEL_HIGH>,
- < 0 119 IRQ_TYPE_LEVEL_HIGH>;
-   fsl,err006687-workaround-present;
status = "okay";
 };
 
@@ -374,7 +371,6 @@
MX6QDL_PAD_RGMII_RX_CTL__RGMII_RX_CTL   0x1b030
/* Phy reset */
MX6QDL_PAD_EIM_D23__GPIO3_IO23  0x000b0
-   MX6QDL_PAD_GPIO_6__ENET_IRQ 0x000b1
>;
};
 
-- 
2.7.4



[PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors

2017-02-15 Thread Steve Longerbeam
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.

Until the OV5652 sensor module compatible with the SabreSD becomes
available for testing, the ov5642 node is currently disabled.
---
 arch/arm/boot/dts/imx6dl-sabresd.dts   |   5 ++
 arch/arm/boot/dts/imx6q-sabresd.dts|   5 ++
 arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 -
 3 files changed, 123 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx6dl-sabresd.dts 
b/arch/arm/boot/dts/imx6dl-sabresd.dts
index 1e45f2f..9607afe 100644
--- a/arch/arm/boot/dts/imx6dl-sabresd.dts
+++ b/arch/arm/boot/dts/imx6dl-sabresd.dts
@@ -15,3 +15,8 @@
model = "Freescale i.MX6 DualLite SABRE Smart Device Board";
compatible = "fsl,imx6dl-sabresd", "fsl,imx6dl";
 };
+
+_csi1_from_ipu1_csi1_mux {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6q-sabresd.dts 
b/arch/arm/boot/dts/imx6q-sabresd.dts
index 9cbdfe7..527772b 100644
--- a/arch/arm/boot/dts/imx6q-sabresd.dts
+++ b/arch/arm/boot/dts/imx6q-sabresd.dts
@@ -23,3 +23,8 @@
  {
status = "okay";
 };
+
+_csi1_from_mipi_vc1 {
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
index 55ef535..f4e13c6 100644
--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -10,6 +10,7 @@
  * http://www.gnu.org/copyleft/gpl.html
  */
 
+#include 
 #include 
 #include 
 
@@ -146,6 +147,36 @@
};
 };
 
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+   data-shift = <12>; /* Lines 19:12 used */
+   hsync-active = <1>;
+   vsync-active = <1>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+};
+
+_csi {
+   status = "okay";
+
+   port@0 {
+   reg = <0>;
+
+   mipi_csi2_in: endpoint {
+   remote-endpoint = <_to_mipi_csi2>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_audmux>;
@@ -214,7 +245,32 @@
0x8014 /* 4:FN_DMICCDAT */
0x /* 5:Default */
>;
-   };
+   };
+
+   ov5642: camera@3c {
+   compatible = "ovti,ov5642";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5642>;
+   clocks = < IMX6QDL_CLK_CKO>;
+   clock-names = "xclk";
+   reg = <0x3c>;
+   DOVDD-supply = <_reg>; /* 1.8v */
+   AVDD-supply = <_reg>;  /* 2.8v, rev C board is VGEN3
+   rev B board is VGEN5 */
+   DVDD-supply = <_reg>;  /* 1.5v*/
+   pwdn-gpios = < 16 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 17 GPIO_ACTIVE_LOW>;
+   status = "disabled";
+
+   port {
+   ov5642_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   hsync-active = <1>;
+   vsync-active = <1>;
+   };
+   };
+   };
 };
 
  {
@@ -223,6 +279,32 @@
pinctrl-0 = <_i2c2>;
status = "okay";
 
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5640>;
+   reg = <0x3c>;
+   clocks = < IMX6QDL_CLK_CKO>;
+   clock-names = "xclk";
+   DOVDD-supply = <_reg>; /* 1.8v */
+   AVDD-supply = <_reg>;  /* 2.8v, rev C board is VGEN3
+   rev B board is VGEN5 */
+   DVDD-supply = <_reg>;  /* 1.5v*/
+   pwdn-gpios = < 19 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+
+   port {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ov5640_to_mipi_csi2: endpoint {
+   remote-endpoint = <_csi2_in>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+   };
+
pmic: pfuze100@08 {
compatible = "fsl,pfuze100";
reg = <0x08>;
@@ -426,6 +508,36 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1csi0grp {
+   fsl,pins = <
+  

[PATCH v4 12/36] add mux and video interface bridge entity functions

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

Signed-off-by: Philipp Zabel 

- renamed MEDIA_ENT_F_MUX to MEDIA_ENT_F_VID_MUX

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/mediactl/media-types.rst | 22 ++
 include/uapi/linux/media.h|  6 ++
 2 files changed, 28 insertions(+)

diff --git a/Documentation/media/uapi/mediactl/media-types.rst 
b/Documentation/media/uapi/mediactl/media-types.rst
index 3e03dc2..023be29 100644
--- a/Documentation/media/uapi/mediactl/media-types.rst
+++ b/Documentation/media/uapi/mediactl/media-types.rst
@@ -298,6 +298,28 @@ Types and flags used to represent the media graph elements
  received on its sink pad and outputs the statistics data on
  its source pad.
 
+-  ..  row 29
+
+   ..  _MEDIA-ENT-F-MUX:
+
+   -  ``MEDIA_ENT_F_MUX``
+
+   - Video multiplexer. An entity capable of multiplexing must have at
+ least two sink pads and one source pad, and must pass the video
+ frame(s) received from the active sink pad to the source pad. Video
+ frame(s) from the inactive sink pads are discarded.
+
+-  ..  row 30
+
+   ..  _MEDIA-ENT-F-VID-IF-BRIDGE:
+
+   -  ``MEDIA_ENT_F_VID_IF_BRIDGE``
+
+   - Video interface bridge. A video interface bridge entity must have at
+ least one sink pad and one source pad. It receives video frame(s) on
+ its sink pad in one bus format (HDMI, eDP, MIPI CSI-2, ...) and
+ converts them and outputs them on its source pad in another bus format
+ (eDP, MIPI CSI-2, parallel, ...).
 
 ..  tabularcolumns:: |p{5.5cm}|p{12.0cm}|
 
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 4890787..fac96c6 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -105,6 +105,12 @@ struct media_device_info {
 #define MEDIA_ENT_F_PROC_VIDEO_STATISTICS  (MEDIA_ENT_F_BASE + 0x4006)
 
 /*
+ * Switch and bridge entitites
+ */
+#define MEDIA_ENT_F_VID_MUX(MEDIA_ENT_F_BASE + 0x5001)
+#define MEDIA_ENT_F_VID_IF_BRIDGE  (MEDIA_ENT_F_BASE + 0x5002)
+
+/*
  * Connectors
  */
 /* It is a responsibility of the entity drivers to add connectors and links */
-- 
2.7.4



[PATCH v4 08/36] ARM: dts: imx6-sabreauto: create i2cmux for i2c3

2017-02-15 Thread Steve Longerbeam
The sabreauto uses a steering pin to select between the SDA signal on
i2c3 bus, and a data-in pin for an SPI NOR chip. Use i2cmux to control
this steering pin. Idle state of the i2cmux selects SPI NOR. This is not
a classic way to use i2cmux, since one side of the mux selects something
other than an i2c bus, but it works and is probably the cleanest
solution. Note that if one thread is attempting to access SPI NOR while
another thread is accessing i2c3, the SPI NOR access will fail since the
i2cmux has selected the SDA pin rather than SPI NOR data-in. This couldn't
be avoided in any case, the board is not designed to allow concurrent
i2c3 and SPI NOR functions (and the default device-tree does not enable
SPI NOR anyway).

Devices hanging off i2c3 should now be defined under i2cmux, so
that the steering pin can be properly controlled to access those
devices. The port expanders (MAX7310) are thus moved into i2cmux.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 65 +---
 1 file changed, 44 insertions(+), 21 deletions(-)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 52390ba..cace88c 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -108,6 +108,44 @@
default-brightness-level = <7>;
status = "okay";
};
+
+   i2cmux {
+   compatible = "i2c-mux-gpio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3mux>;
+   mux-gpios = < 4 0>;
+   i2c-parent = <>;
+   idle-state = <0>;
+
+   i2c@1 {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   reg = <1>;
+
+   max7310_a: gpio@30 {
+   compatible = "maxim,max7310";
+   reg = <0x30>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   max7310_b: gpio@32 {
+   compatible = "maxim,max7310";
+   reg = <0x32>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+
+   max7310_c: gpio@34 {
+   compatible = "maxim,max7310";
+   reg = <0x34>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   };
+   };
+   };
 };
 
  {
@@ -291,27 +329,6 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c3>;
status = "okay";
-
-   max7310_a: gpio@30 {
-   compatible = "maxim,max7310";
-   reg = <0x30>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-
-   max7310_b: gpio@32 {
-   compatible = "maxim,max7310";
-   reg = <0x32>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
-
-   max7310_c: gpio@34 {
-   compatible = "maxim,max7310";
-   reg = <0x34>;
-   gpio-controller;
-   #gpio-cells = <2>;
-   };
 };
 
  {
@@ -419,6 +436,12 @@
>;
};
 
+   pinctrl_i2c3mux: i2c3muxgrp {
+   fsl,pins = <
+   MX6QDL_PAD_EIM_A24__GPIO5_IO04 0x0b0b1
+   >;
+   };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT   0x1b0b1
-- 
2.7.4



[PATCH v4 10/36] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture

2017-02-15 Thread Steve Longerbeam
Add pinctrl groups for both GPT input capture channels.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 967c3b8..495709f 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -457,6 +457,18 @@
>;
};
 
+   pinctrl_gpt_input_capture0: gptinputcapture0grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT0__GPT_CAPTURE1   0x1b0b0
+   >;
+   };
+
+   pinctrl_gpt_input_capture1: gptinputcapture1grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD1_DAT1__GPT_CAPTURE2   0x1b0b0
+   >;
+   };
+
pinctrl_spdif: spdifgrp {
fsl,pins = <
MX6QDL_PAD_KEY_COL3__SPDIF_IN 0x1b0b0
-- 
2.7.4



[PATCH v4 09/36] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b

2017-02-15 Thread Steve Longerbeam
The reset pin to the port expander chip (MAX7310) is controlled by a gpio,
so define a reset-gpios property to control it. There are three MAX7310's
on the SabreAuto CPU card (max7310_[abc]), but all use the same pin for
their reset. Since all can't acquire the same pin, assign it to max7310_b,
that chip is needed by more functions (usb and adv7180).

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index cace88c..967c3b8 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -136,6 +136,9 @@
reg = <0x32>;
gpio-controller;
#gpio-cells = <2>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_max7310>;
+   reset-gpios = < 15 GPIO_ACTIVE_LOW>;
};
 
max7310_c: gpio@34 {
@@ -442,6 +445,12 @@
>;
};
 
+   pinctrl_max7310: max7310grp {
+   fsl,pins = <
+   MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0
+   >;
+   };
+
pinctrl_pwm3: pwm1grp {
fsl,pins = <
MX6QDL_PAD_SD4_DAT1__PWM3_OUT   0x1b0b1
-- 
2.7.4



[PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline

2017-02-15 Thread Steve Longerbeam
v4l2_pipeline_inherit_controls() will add the v4l2 controls from
all subdev entities in a pipeline to a given video device.

Signed-off-by: Steve Longerbeam 
---
 drivers/media/v4l2-core/v4l2-mc.c | 48 +++
 include/media/v4l2-mc.h   | 25 
 2 files changed, 73 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index 303980b..09d4d97 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -238,6 +239,53 @@ int v4l_vb2q_enable_media_source(struct vb2_queue *q)
 }
 EXPORT_SYMBOL_GPL(v4l_vb2q_enable_media_source);
 
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   struct media_entity *entity;
+   struct media_graph graph;
+   struct v4l2_subdev *sd;
+   int ret;
+
+   ret = media_graph_walk_init(, mdev);
+   if (ret)
+   return ret;
+
+   media_graph_walk_start(, start_entity);
+
+   while ((entity = media_graph_walk_next())) {
+   if (!is_media_entity_v4l2_subdev(entity))
+   continue;
+
+   sd = media_entity_to_v4l2_subdev(entity);
+
+   ret = v4l2_ctrl_add_handler(vfd->ctrl_handler,
+   sd->ctrl_handler,
+   NULL);
+   if (ret)
+   break;
+   }
+
+   media_graph_walk_cleanup();
+   return ret;
+}
+EXPORT_SYMBOL_GPL(__v4l2_pipeline_inherit_controls);
+
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity)
+{
+   struct media_device *mdev = start_entity->graph_obj.mdev;
+   int ret;
+
+   mutex_lock(>graph_mutex);
+   ret = __v4l2_pipeline_inherit_controls(vfd, start_entity);
+   mutex_unlock(>graph_mutex);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(v4l2_pipeline_inherit_controls);
+
 /* 
-
  * Pipeline power management
  *
diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
index 2634d9d..9848e77 100644
--- a/include/media/v4l2-mc.h
+++ b/include/media/v4l2-mc.h
@@ -171,6 +171,17 @@ void v4l_disable_media_source(struct video_device *vdev);
  */
 int v4l_vb2q_enable_media_source(struct vb2_queue *q);
 
+/**
+ * v4l2_pipeline_inherit_controls - Add the v4l2 controls from all
+ * subdev entities in a pipeline to
+ * the given video device.
+ * @vfd: the video device
+ * @start_entity: Starting entity
+ */
+int __v4l2_pipeline_inherit_controls(struct video_device *vfd,
+struct media_entity *start_entity);
+int v4l2_pipeline_inherit_controls(struct video_device *vfd,
+  struct media_entity *start_entity);
 
 /**
  * v4l2_pipeline_pm_use - Update the use count of an entity
@@ -231,6 +242,20 @@ static inline int v4l_vb2q_enable_media_source(struct 
vb2_queue *q)
return 0;
 }
 
+static inline int __v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
+static inline int v4l2_pipeline_inherit_controls(
+   struct video_device *vfd,
+   struct media_entity *start_entity)
+{
+   return 0;
+}
+
 static inline int v4l2_pipeline_pm_use(struct media_entity *entity, int use)
 {
return 0;
-- 
2.7.4



[PATCH v4 17/36] media: Add userspace header file for i.MX

2017-02-15 Thread Steve Longerbeam
This adds a header file for use by userspace programs wanting to interact
with the i.MX media driver. It defines custom v4l2 controls and events
generated by the i.MX v4l2 subdevices.

Signed-off-by: Steve Longerbeam 
---
 include/uapi/media/Kbuild |  1 +
 include/uapi/media/imx.h  | 29 +
 2 files changed, 30 insertions(+)
 create mode 100644 include/uapi/media/imx.h

diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
index aafaa5a..fa78958 100644
--- a/include/uapi/media/Kbuild
+++ b/include/uapi/media/Kbuild
@@ -1 +1,2 @@
 # UAPI Header export list
+header-y += imx.h
diff --git a/include/uapi/media/imx.h b/include/uapi/media/imx.h
new file mode 100644
index 000..1fdd1c1
--- /dev/null
+++ b/include/uapi/media/imx.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2014-2015 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version
+ */
+
+#ifndef __UAPI_MEDIA_IMX_H__
+#define __UAPI_MEDIA_IMX_H__
+
+/*
+ * events from the subdevs
+ */
+#define V4L2_EVENT_IMX_CLASS  V4L2_EVENT_PRIVATE_START
+#define V4L2_EVENT_IMX_NFB4EOF(V4L2_EVENT_IMX_CLASS + 1)
+#define V4L2_EVENT_IMX_FRAME_INTERVAL (V4L2_EVENT_IMX_CLASS + 2)
+
+enum imx_ctrl_id {
+   V4L2_CID_IMX_MOTION = (V4L2_CID_USER_IMX_BASE + 0),
+   V4L2_CID_IMX_FIM_ENABLE,
+   V4L2_CID_IMX_FIM_NUM,
+   V4L2_CID_IMX_FIM_TOLERANCE_MIN,
+   V4L2_CID_IMX_FIM_TOLERANCE_MAX,
+   V4L2_CID_IMX_FIM_NUM_SKIP,
+};
+
+#endif
-- 
2.7.4



[PATCH v4 15/36] platform: add video-multiplexer subdevice driver

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

This driver can handle SoC internal and external video bus multiplexers,
controlled either by register bit fields or by a GPIO. The subdevice
passes through frame interval and mbus configuration of the active input
to the output side.

Signed-off-by: Sascha Hauer 
Signed-off-by: Philipp Zabel 

--

- fixed a cut error in vidsw_remove(): v4l2_async_register_subdev()
  should be unregister.

- added media_entity_cleanup() and v4l2_device_unregister_subdev()
  to vidsw_remove().

- added missing MODULE_DEVICE_TABLE().
  Suggested-by: Javier Martinez Canillas 

- there was a line left over from a previous iteration that negated
  the new way of determining the pad count just before it which
  has been removed (num_pads = of_get_child_count(np)).

- Philipp Zabel has developed a set of patches that allow adding
  to the subdev async notifier waiting list using a chaining method
  from the async registered callbacks (v4l2_of_subdev_registered()
  and the prep patches for that). For now, I've removed the use of
  v4l2_of_subdev_registered() for the vidmux driver's registered
  callback. This doesn't affect the functionality of this driver,
  but allows for it to be merged now, before adding the chaining
  support.

Signed-off-by: Steve Longerbeam 
---
 .../bindings/media/video-multiplexer.txt   |  59 +++
 drivers/media/platform/Kconfig |   8 +
 drivers/media/platform/Makefile|   2 +
 drivers/media/platform/video-multiplexer.c | 474 +
 4 files changed, 543 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/media/video-multiplexer.txt
 create mode 100644 drivers/media/platform/video-multiplexer.c

diff --git a/Documentation/devicetree/bindings/media/video-multiplexer.txt 
b/Documentation/devicetree/bindings/media/video-multiplexer.txt
new file mode 100644
index 000..9d133d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/video-multiplexer.txt
@@ -0,0 +1,59 @@
+Video Multiplexer
+=
+
+Video multiplexers allow to select between multiple input ports. Video received
+on the active input port is passed through to the output port. Muxes described
+by this binding may be controlled by a syscon register bitfield or by a GPIO.
+
+Required properties:
+- compatible : should be "video-multiplexer"
+- reg: should be register base of the register containing the control bitfield
+- bit-mask: bitmask of the control bitfield in the control register
+- bit-shift: bit offset of the control bitfield in the control register
+- gpios: alternatively to reg, bit-mask, and bit-shift, a single GPIO phandle
+  may be given to switch between two inputs
+- #address-cells: should be <1>
+- #size-cells: should be <0>
+- port@*: at least three port nodes containing endpoints connecting to the
+  source and sink devices according to of_graph bindings. The last port is
+  the output port, all others are inputs.
+
+Example:
+
+syscon {
+   compatible = "syscon", "simple-mfd";
+
+   mux {
+   compatible = "video-multiplexer";
+   /* Single bit (1 << 19) in syscon register 0x04: */
+   reg = <0x04>;
+   bit-mask = <1>;
+   bit-shift = <19>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+
+   mux_in0: endpoint {
+   remote-endpoint = <_source0_out>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+
+   mux_in1: endpoint {
+   remote-endpoint = <_source1_out>;
+   };
+   };
+
+   port@2 {
+   reg = <2>;
+
+   mux_out: endpoint {
+   remote-endpoint = <_interface_in>;
+   };
+   };
+   };
+};
diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index c9106e1..3d60d4c 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -74,6 +74,14 @@ config VIDEO_M32R_AR_M64278
  To compile this driver as a module, choose M here: the
  module will be called arv.
 
+config VIDEO_MULTIPLEXER
+   tristate "Video Multiplexer"
+   depends on VIDEO_V4L2_SUBDEV_API && MEDIA_CONTROLLER
+   help
+ This driver provides support for SoC internal N:1 video bus
+ multiplexers controlled by register bitfields as well as external
+ 2:1 video multiplexers controlled by a single GPIO.
+
 config VIDEO_OMAP3
tristate "OMAP 3 Camera support"
depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API && ARCH_OMAP3
diff --git 

[PATCH v4 11/36] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder

2017-02-15 Thread Steve Longerbeam
Enables the ADV7180 decoder sensor. The ADV7180 connects to the
parallel-bus mux input on ipu1_csi0_mux.

The ADV7180 power pin is via max7310_b port expander.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 58 
 1 file changed, 58 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi 
b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
index 495709f..f03057b 100644
--- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi
@@ -124,6 +124,21 @@
#size-cells = <0>;
reg = <1>;
 
+   adv7180: camera@21 {
+   compatible = "adi,adv7180";
+   reg = <0x21>;
+   powerdown-gpios = <_b 2 
GPIO_ACTIVE_LOW>;
+   interrupt-parent = <>;
+   interrupts = <27 0x8>;
+
+   port {
+   adv7180_to_ipu1_csi0_mux: endpoint {
+   remote-endpoint = 
<_csi0_mux_from_parallel_sensor>;
+   bus-width = <8>;
+   };
+   };
+   };
+
max7310_a: gpio@30 {
compatible = "maxim,max7310";
reg = <0x30>;
@@ -151,6 +166,25 @@
};
 };
 
+_csi0_from_ipu1_csi0_mux {
+   bus-width = <8>;
+};
+
+_csi0_mux_from_parallel_sensor {
+   remote-endpoint = <_to_ipu1_csi0_mux>;
+   bus-width = <8>;
+};
+
+_csi0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_ipu1_csi0>;
+
+   /* enable frame interval monitor on this port */
+   fim {
+   status = "okay";
+   };
+};
+
  {
assigned-clocks = < IMX6QDL_PLL4_BYPASS_SRC>,
  < IMX6QDL_PLL4_BYPASS>,
@@ -445,6 +479,30 @@
>;
};
 
+   pinctrl_ipu1_csi0: ipu1csi0grp {
+   fsl,pins = <
+   MX6QDL_PAD_CSI0_DAT4__IPU1_CSI0_DATA04   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT5__IPU1_CSI0_DATA05   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT6__IPU1_CSI0_DATA06   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT7__IPU1_CSI0_DATA07   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT8__IPU1_CSI0_DATA08   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT9__IPU1_CSI0_DATA09   0x1b0b0
+   MX6QDL_PAD_CSI0_DAT10__IPU1_CSI0_DATA10  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT11__IPU1_CSI0_DATA11  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT12__IPU1_CSI0_DATA12  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT13__IPU1_CSI0_DATA13  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT14__IPU1_CSI0_DATA14  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT15__IPU1_CSI0_DATA15  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT16__IPU1_CSI0_DATA16  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT17__IPU1_CSI0_DATA17  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT18__IPU1_CSI0_DATA18  0x1b0b0
+   MX6QDL_PAD_CSI0_DAT19__IPU1_CSI0_DATA19  0x1b0b0
+   MX6QDL_PAD_CSI0_PIXCLK__IPU1_CSI0_PIXCLK 0x1b0b0
+   MX6QDL_PAD_CSI0_MCLK__IPU1_CSI0_HSYNC0x1b0b0
+   MX6QDL_PAD_CSI0_VSYNC__IPU1_CSI0_VSYNC   0x1b0b0
+   >;
+   };
+
pinctrl_max7310: max7310grp {
fsl,pins = <
MX6QDL_PAD_SD2_DAT0__GPIO1_IO15 0x1b0b0
-- 
2.7.4



[PATCH v4 16/36] UAPI: Add media UAPI Kbuild file

2017-02-15 Thread Steve Longerbeam
Add an empty UAPI Kbuild file for media UAPI headers.

Signed-off-by: Steve Longerbeam 
---
 include/uapi/Kbuild   | 1 +
 include/uapi/media/Kbuild | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 include/uapi/media/Kbuild

diff --git a/include/uapi/Kbuild b/include/uapi/Kbuild
index 245aa6e..9a51957 100644
--- a/include/uapi/Kbuild
+++ b/include/uapi/Kbuild
@@ -6,6 +6,7 @@
 header-y += asm-generic/
 header-y += linux/
 header-y += sound/
+header-y += media/
 header-y += mtd/
 header-y += rdma/
 header-y += video/
diff --git a/include/uapi/media/Kbuild b/include/uapi/media/Kbuild
new file mode 100644
index 000..aafaa5a
--- /dev/null
+++ b/include/uapi/media/Kbuild
@@ -0,0 +1 @@
+# UAPI Header export list
-- 
2.7.4



[PATCH v4 13/36] [media] v4l2: add a frame timeout event

2017-02-15 Thread Steve Longerbeam
Add a new FRAME_TIMEOUT event to signal that a video capture or
output device has timed out waiting for reception or transmit
completion of a video frame.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/uapi/v4l/vidioc-dqevent.rst | 5 +
 Documentation/media/videodev2.h.rst.exceptions  | 1 +
 include/uapi/linux/videodev2.h  | 1 +
 3 files changed, 7 insertions(+)

diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst 
b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index 8d663a7..dd77d9b 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -197,6 +197,11 @@ call.
the regions changes. This event has a struct
:c:type:`v4l2_event_motion_det`
associated with it.
+* - ``V4L2_EVENT_FRAME_TIMEOUT``
+  - 7
+  - This event is triggered when the video capture or output device
+   has timed out waiting for the reception or transmit completion of
+   a frame of video.
 * - ``V4L2_EVENT_PRIVATE_START``
   - 0x0800
   - Base event number for driver-private events.
diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index e11a0d0..5b0f767 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -459,6 +459,7 @@ replace define V4L2_EVENT_CTRL event-type
 replace define V4L2_EVENT_FRAME_SYNC event-type
 replace define V4L2_EVENT_SOURCE_CHANGE event-type
 replace define V4L2_EVENT_MOTION_DET event-type
+replace define V4L2_EVENT_FRAME_TIMEOUT event-type
 replace define V4L2_EVENT_PRIVATE_START event-type
 
 replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 46e8a2e3..e174c45 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
 #define V4L2_EVENT_FRAME_SYNC  4
 #define V4L2_EVENT_SOURCE_CHANGE   5
 #define V4L2_EVENT_MOTION_DET  6
+#define V4L2_EVENT_FRAME_TIMEOUT   7
 #define V4L2_EVENT_PRIVATE_START   0x0800
 
 /* Payload for V4L2_EVENT_VSYNC */
-- 
2.7.4



[PATCH v4 18/36] media: Add i.MX media core driver

2017-02-15 Thread Steve Longerbeam
Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 
---
 Documentation/media/v4l-drivers/imx.rst   | 542 +
 drivers/staging/media/Kconfig |   2 +
 drivers/staging/media/Makefile|   1 +
 drivers/staging/media/imx/Kconfig |   7 +
 drivers/staging/media/imx/Makefile|   6 +
 drivers/staging/media/imx/TODO|  36 ++
 drivers/staging/media/imx/imx-media-dev.c | 487 +++
 drivers/staging/media/imx/imx-media-fim.c | 471 +++
 drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++
 drivers/staging/media/imx/imx-media-of.c  | 267 
 drivers/staging/media/imx/imx-media-utils.c   | 701 ++
 drivers/staging/media/imx/imx-media.h | 297 +
 include/media/imx.h   |  15 +
 include/uapi/linux/v4l2-controls.h|   4 +
 14 files changed, 3185 insertions(+)
 create mode 100644 Documentation/media/v4l-drivers/imx.rst
 create mode 100644 drivers/staging/media/imx/Kconfig
 create mode 100644 drivers/staging/media/imx/Makefile
 create mode 100644 drivers/staging/media/imx/TODO
 create mode 100644 drivers/staging/media/imx/imx-media-dev.c
 create mode 100644 drivers/staging/media/imx/imx-media-fim.c
 create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
 create mode 100644 drivers/staging/media/imx/imx-media-of.c
 create mode 100644 drivers/staging/media/imx/imx-media-utils.c
 create mode 100644 drivers/staging/media/imx/imx-media.h
 create mode 100644 include/media/imx.h

diff --git a/Documentation/media/v4l-drivers/imx.rst 
b/Documentation/media/v4l-drivers/imx.rst
new file mode 100644
index 000..f085e43
--- /dev/null
+++ b/Documentation/media/v4l-drivers/imx.rst
@@ -0,0 +1,542 @@
+i.MX Video Capture Driver
+=
+
+Introduction
+
+
+The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
+handles the flow of image frames to and from capture devices and
+display devices.
+
+For image capture, the IPU contains the following internal subunits:
+
+- Image DMA Controller (IDMAC)
+- Camera Serial Interface (CSI)
+- Image Converter (IC)
+- Sensor Multi-FIFO Controller (SMFC)
+- Image Rotator (IRT)
+- Video De-Interlacing or Combining Block (VDIC)
+
+The IDMAC is the DMA controller for transfer of image frames to and from
+memory. Various dedicated DMA channels exist for both video capture and
+display paths. During transfer, the IDMAC is also capable of vertical
+image flip, 8x8 block transfer (see IRT description), pixel component
+re-ordering (for example UYVY to YUYV) within the same colorspace, and
+even packed <--> planar conversion. It can also perform a simple
+de-interlacing by interleaving even and odd lines during transfer
+(without motion compensation which requires the VDIC).
+
+The CSI is the backend capture unit that interfaces directly with
+camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
+
+The IC handles color-space conversion, resizing (downscaling and
+upscaling), horizontal flip, and 90/270 degree rotation operations.
+
+There are three independent "tasks" within the IC that can carry out
+conversions concurrently: pre-process encoding, pre-process viewfinder,
+and post-processing. Within each task, conversions are split into three
+sections: downsizing section, main section (upsizing, flip, colorspace
+conversion, and graphics plane combining), and rotation section.
+
+The IPU time-shares the IC task operations. The time-slice granularity
+is one burst of eight pixels in the downsizing section, one image line
+in the main processing section, one image frame in the rotation section.
+
+The SMFC is composed of four independent FIFOs that each can transfer
+captured frames from sensors directly to memory concurrently via four
+IDMAC channels.
+
+The IRT carries out 90 and 270 degree image rotation operations. The
+rotation operation is carried out on 8x8 pixel blocks at a time. This
+operation is supported by the IDMAC which handles the 8x8 block transfer
+along with block reordering, in coordination with vertical flip.
+
+The VDIC handles the conversion of interlaced video to progressive, with
+support for different motion compensation modes (low, medium, and high
+motion). The deinterlaced output frames from the VDIC can be sent to the
+IC pre-process viewfinder task for further conversions. The VDIC also
+contains a Combiner that combines two image planes, with alpha blending
+and color keying.
+
+In addition to the IPU internal subunits, there are also two units
+outside the IPU that are also involved in video capture on i.MX:
+
+- MIPI CSI-2 Receiver for camera sensors with the MIPI CSI-2 bus
+  interface. This is a Synopsys DesignWare core.
+- Two video multiplexers for selecting among multiple sensor inputs
+  to send 

[PATCH v4 19/36] media: imx: Add Capture Device Interface

2017-02-15 Thread Steve Longerbeam
This is the capture device interface driver that provides the v4l2
user interface. Frames can be received from various sources:

- directly from CSI for capturing unconverted images directly from
  camera sensors.

- from the IC pre-process encode task.

- from the IC pre-process viewfinder task.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/Makefile|   2 +-
 drivers/staging/media/imx/imx-media-capture.c | 654 ++
 2 files changed, 655 insertions(+), 1 deletion(-)
 create mode 100644 drivers/staging/media/imx/imx-media-capture.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index ba8e4fb..4606a3a 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -3,4 +3,4 @@ imx-media-common-objs := imx-media-utils.o imx-media-fim.o
 
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
-
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
diff --git a/drivers/staging/media/imx/imx-media-capture.c 
b/drivers/staging/media/imx/imx-media-capture.c
new file mode 100644
index 000..fbf6067
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-capture.c
@@ -0,0 +1,654 @@
+/*
+ * Video Capture Subdev for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2012-2016 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imx-media.h"
+
+struct capture_priv {
+   struct imx_media_video_dev vdev;
+
+   struct v4l2_subdev*src_sd;
+   int   src_sd_pad;
+   struct device *dev;
+
+   struct media_pipeline mp;
+   struct imx_media_dev  *md;
+
+   struct media_pad  vdev_pad;
+
+   struct mutex  mutex;   /* capture device mutex */
+
+   /* the videobuf2 queue */
+   struct vb2_queue   q;
+   /* list of ready imx_media_buffer's from q */
+   struct list_head   ready_q;
+   /* protect ready_q */
+   spinlock_t q_lock;
+
+   /* controls inherited from subdevs */
+   struct v4l2_ctrl_handler ctrl_hdlr;
+
+   /* misc status */
+   bool  stop;  /* streaming is stopping */
+};
+
+#define to_capture_priv(v) container_of(v, struct capture_priv, vdev)
+
+/* In bytes, per queue */
+#define VID_MEM_LIMIT  SZ_64M
+
+static struct vb2_ops capture_qops;
+
+/*
+ * Video ioctls follow
+ */
+
+static int vidioc_querycap(struct file *file, void *fh,
+  struct v4l2_capability *cap)
+{
+   struct capture_priv *priv = video_drvdata(file);
+
+   strncpy(cap->driver, "imx-media-capture", sizeof(cap->driver) - 1);
+   strncpy(cap->card, "imx-media-capture", sizeof(cap->card) - 1);
+   snprintf(cap->bus_info, sizeof(cap->bus_info),
+"platform:%s", dev_name(priv->dev));
+
+   return 0;
+}
+
+static int capture_enum_fmt_vid_cap(struct file *file, void *fh,
+   struct v4l2_fmtdesc *f)
+{
+   u32 fourcc;
+   int ret;
+
+   ret = imx_media_enum_format(, NULL, f->index, true, true);
+   if (ret)
+   return ret;
+
+   f->pixelformat = fourcc;
+
+   return 0;
+}
+
+static int capture_g_fmt_vid_cap(struct file *file, void *fh,
+struct v4l2_format *f)
+{
+   struct capture_priv *priv = video_drvdata(file);
+
+   *f = priv->vdev.fmt;
+
+   return 0;
+}
+
+static int capture_try_fmt_vid_cap(struct file *file, void *fh,
+  struct v4l2_format *f)
+{
+   struct capture_priv *priv = video_drvdata(file);
+   struct v4l2_subdev_format fmt_src;
+   const struct imx_media_pixfmt *cc, *src_cc;
+   u32 fourcc;
+   int ret;
+
+   fourcc = f->fmt.pix.pixelformat;
+   cc = imx_media_find_format(fourcc, 0, true, true);
+   if (!cc) {
+   imx_media_enum_format(, NULL, 0, true, true);
+   cc = imx_media_find_format(fourcc, 0, true, true);
+   }
+
+   /*
+* user frame dimensions are the same as src_sd's pad.
+*/
+   fmt_src.pad = priv->src_sd_pad;
+   fmt_src.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+   ret = v4l2_subdev_call(priv->src_sd, pad, get_fmt, NULL, _src);
+   if (ret)
+   return ret;
+
+   /*
+* but we can allow planar pixel formats if the src_sd's
+* pad configured a YUV format
+*/
+   src_cc = imx_media_find_format(0, 

[PATCH v4 21/36] media: imx: Add VDIC subdev driver

2017-02-15 Thread Steve Longerbeam
This is a media entity subdevice driver for the i.MX Video De-Interlacing
or Combining Block. So far this entity does not implement the Combining
function but only motion compensated deinterlacing. Video frames are
received from the CSI and are routed to the IC PRPVF entity.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/Makefile |   1 +
 drivers/staging/media/imx/imx-media-vdic.c | 886 +
 2 files changed, 887 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx-media-vdic.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index c054490..1f01520 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -4,5 +4,6 @@ imx-media-common-objs := imx-media-utils.o imx-media-fim.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
 
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
diff --git a/drivers/staging/media/imx/imx-media-vdic.c 
b/drivers/staging/media/imx/imx-media-vdic.c
new file mode 100644
index 000..5bb21e9
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -0,0 +1,886 @@
+/*
+ * V4L2 Deinterlacer Subdev for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2017 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imx-media.h"
+
+/*
+ * This subdev implements two different video pipelines:
+ *
+ * CSI -> VDIC
+ *
+ * In this pipeline, the CSI sends a single interlaced field F(n-1)
+ * directly to the VDIC (and optionally the following field F(n)
+ * can be sent to memory via IDMAC channel 13). This pipeline only works
+ * in VDIC's high motion mode, which only requires a single field for
+ * processing. The other motion modes (low and medium) require three
+ * fields, so this pipeline does not work in those modes. Also, it is
+ * not clear how this pipeline can deal with the various field orders
+ * (sequential BT/TB, interlaced BT/TB).
+ *
+ * MEM -> CH8,9,10 -> VDIC
+ *
+ * In this pipeline, previous field F(n-1), current field F(n), and next
+ * field F(n+1) are transferred to the VDIC via IDMAC channels 8,9,10.
+ * These memory buffers can come from a video output or mem2mem device.
+ * All motion modes are supported by this pipeline.
+ *
+ * The "direct" CSI->VDIC pipeline requires no DMA, but it can only be
+ * used in high motion mode.
+ */
+
+struct vdic_priv;
+
+struct vdic_pipeline_ops {
+   int (*setup)(struct vdic_priv *priv);
+   void (*start)(struct vdic_priv *priv);
+   void (*stop)(struct vdic_priv *priv);
+   void (*disable)(struct vdic_priv *priv);
+};
+
+/*
+ * Min/Max supported width and heights.
+ */
+#define MIN_W   176
+#define MIN_H   144
+#define MAX_W_VDIC  968
+#define MAX_H_VDIC 2048
+#define W_ALIGN4 /* multiple of 16 pixels */
+#define H_ALIGN1 /* multiple of 2 lines */
+#define S_ALIGN1 /* multiple of 2 */
+
+struct vdic_priv {
+   struct device*dev;
+   struct ipu_soc   *ipu;
+   struct imx_media_dev *md;
+   struct v4l2_subdev   sd;
+   int ipu_id;
+
+   /* IPU units we require */
+   struct ipu_vdi *vdi;
+
+   struct media_pad pad[VDIC_NUM_PADS];
+   int active_input_pad;
+
+   struct ipuv3_channel *vdi_in_ch_p; /* F(n-1) transfer channel */
+   struct ipuv3_channel *vdi_in_ch;   /* F(n) transfer channel */
+   struct ipuv3_channel *vdi_in_ch_n; /* F(n+1) transfer channel */
+
+   /* pipeline operations */
+   struct vdic_pipeline_ops *ops;
+
+   /* current and previous input buffers indirect path */
+   struct imx_media_buffer *curr_in_buf;
+   struct imx_media_buffer *prev_in_buf;
+
+   /*
+* translated field type, input line stride, and field size
+* for indirect path
+*/
+   u32 fieldtype;
+   u32 in_stride;
+   u32 field_size;
+
+   /* the source (a video device or subdev) */
+   struct media_entity *src;
+   /* the sink that will receive the progressive out buffers */
+   struct v4l2_subdev *sink_sd;
+
+   /* the attached sensor at stream on */
+   struct imx_media_subdev *sensor;
+
+   /* the video standard from sensor at time of streamon */
+   v4l2_std_id std;
+
+   struct v4l2_mbus_framefmt format_mbus[VDIC_NUM_PADS];
+   const struct imx_media_pixfmt *cc[VDIC_NUM_PADS];
+
+   /* the video device at IDMAC input pad */
+   struct imx_media_video_dev 

[PATCH v4 26/36] media: imx: add support for bayer formats

2017-02-15 Thread Steve Longerbeam
From: Russell King 

Add the bayer formats to imx-media's list of supported pixel and bus
formats.

Signed-off-by: Russell King 

- added a bayer boolean to struct imx_media_pixfmt.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-utils.c | 68 +
 drivers/staging/media/imx/imx-media.h   |  1 +
 2 files changed, 69 insertions(+)

diff --git a/drivers/staging/media/imx/imx-media-utils.c 
b/drivers/staging/media/imx/imx-media-utils.c
index 55603d9..6855560 100644
--- a/drivers/staging/media/imx/imx-media-utils.c
+++ b/drivers/staging/media/imx/imx-media-utils.c
@@ -61,6 +61,74 @@ static const struct imx_media_pixfmt imx_media_formats[] = {
.cs = IPUV3_COLORSPACE_RGB,
.bpp= 32,
.ipufmt = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SBGGR8,
+   .codes  = {MEDIA_BUS_FMT_SBGGR8_1X8},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 8,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGBRG8,
+   .codes  = {MEDIA_BUS_FMT_SGBRG8_1X8},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 8,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGRBG8,
+   .codes  = {MEDIA_BUS_FMT_SGRBG8_1X8},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 8,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SRGGB8,
+   .codes  = {MEDIA_BUS_FMT_SRGGB8_1X8},
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 8,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SBGGR16,
+   .codes  = {
+   MEDIA_BUS_FMT_SBGGR10_1X10,
+   MEDIA_BUS_FMT_SBGGR12_1X12,
+   MEDIA_BUS_FMT_SBGGR14_1X14,
+   MEDIA_BUS_FMT_SBGGR16_1X16
+   },
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGBRG16,
+   .codes  = {
+   MEDIA_BUS_FMT_SGBRG10_1X10,
+   MEDIA_BUS_FMT_SGBRG12_1X12,
+   MEDIA_BUS_FMT_SGBRG14_1X14,
+   MEDIA_BUS_FMT_SGBRG16_1X16,
+   },
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SGRBG16,
+   .codes  = {
+   MEDIA_BUS_FMT_SGRBG10_1X10,
+   MEDIA_BUS_FMT_SGRBG12_1X12,
+   MEDIA_BUS_FMT_SGRBG14_1X14,
+   MEDIA_BUS_FMT_SGRBG16_1X16,
+   },
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
+   }, {
+   .fourcc = V4L2_PIX_FMT_SRGGB16,
+   .codes  = {
+   MEDIA_BUS_FMT_SRGGB10_1X10,
+   MEDIA_BUS_FMT_SRGGB12_1X12,
+   MEDIA_BUS_FMT_SRGGB14_1X14,
+   MEDIA_BUS_FMT_SRGGB16_1X16,
+   },
+   .cs = IPUV3_COLORSPACE_RGB,
+   .bpp= 16,
+   .bayer  = true,
},
/*** non-mbus formats start here ***/
{
diff --git a/drivers/staging/media/imx/imx-media.h 
b/drivers/staging/media/imx/imx-media.h
index 3d4f3c7..ae3af0d 100644
--- a/drivers/staging/media/imx/imx-media.h
+++ b/drivers/staging/media/imx/imx-media.h
@@ -91,6 +91,7 @@ struct imx_media_pixfmt {
int bpp; /* total bpp */
enum ipu_color_space cs;
boolplanar;  /* is a planar format */
+   boolbayer;   /* is a raw bayer format */
boolipufmt;  /* is one of the IPU internal formats */
 };
 
-- 
2.7.4



[PATCH v4 20/36] media: imx: Add CSI subdev driver

2017-02-15 Thread Steve Longerbeam
This is a media entity subdevice for the i.MX Camera
Sensor Interface module.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/Kconfig |   13 +
 drivers/staging/media/imx/Makefile|2 +
 drivers/staging/media/imx/imx-media-csi.c | 1220 +
 3 files changed, 1235 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx-media-csi.c

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index 722ed55..e27ad6d 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -5,3 +5,16 @@ config VIDEO_IMX_MEDIA
  Say yes here to enable support for video4linux media controller
  driver for the i.MX5/6 SOC.
 
+if VIDEO_IMX_MEDIA
+menu "i.MX5/6 Media Sub devices"
+
+config VIDEO_IMX_CSI
+   tristate "i.MX5/6 Camera Sensor Interface driver"
+   depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
+   select VIDEOBUF2_DMA_CONTIG
+   default y
+   ---help---
+ A video4linux camera sensor interface driver for i.MX5/6.
+
+endmenu
+endif
diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 4606a3a..c054490 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -4,3 +4,5 @@ imx-media-common-objs := imx-media-utils.o imx-media-fim.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
+
+obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
new file mode 100644
index 000..0343fc3
--- /dev/null
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -0,0 +1,1220 @@
+/*
+ * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2014-2016 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imx-media.h"
+
+/*
+ * Min/Max supported width and heights.
+ *
+ * We allow planar output, so we have to align width by 16 pixels
+ * to meet IDMAC alignment requirements.
+ *
+ * TODO: move this into pad format negotiation, if capture device
+ * has not requested planar formats, we should allow 8 pixel
+ * alignment.
+ */
+#define MIN_W   176
+#define MIN_H   144
+#define MAX_W  4096
+#define MAX_H  4096
+#define W_ALIGN4 /* multiple of 16 pixels */
+#define H_ALIGN1 /* multiple of 2 lines */
+#define S_ALIGN1 /* multiple of 2 */
+
+struct csi_priv {
+   struct device *dev;
+   struct ipu_soc *ipu;
+   struct imx_media_dev *md;
+   struct v4l2_subdev sd;
+   struct media_pad pad[CSI_NUM_PADS];
+   int active_output_pad;
+   int csi_id;
+   int smfc_id;
+
+   struct ipuv3_channel *idmac_ch;
+   struct ipu_smfc *smfc;
+   struct ipu_csi *csi;
+
+   struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
+   const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
+   struct v4l2_rect crop;
+
+   /* the video device at IDMAC output pad */
+   struct imx_media_video_dev *vdev;
+
+   /* active vb2 buffers to send to video dev sink */
+   struct imx_media_buffer *active_vb2_buf[2];
+   struct imx_media_dma_buf underrun_buf;
+
+   int ipu_buf_num;  /* ipu double buffer index: 0-1 */
+
+   /* the sink for the captured frames */
+   struct media_entity *sink;
+   enum ipu_csi_dest dest;
+   /* the source subdev */
+   struct v4l2_subdev *src_sd;
+
+   /* the mipi virtual channel number at link validate */
+   int vc_num;
+
+   /* the attached sensor at stream on */
+   struct imx_media_subdev *sensor;
+
+   spinlock_t irqlock; /* protect eof_irq handler */
+   struct timer_list eof_timeout_timer;
+   int eof_irq;
+   int nfb4eof_irq;
+
+   struct v4l2_ctrl_handler ctrl_hdlr;
+   struct imx_media_fim *fim;
+
+   bool power_on;  /* power is on */
+   bool stream_on; /* streaming is on */
+   bool last_eof;  /* waiting for last EOF at stream off */
+   struct completion last_eof_comp;
+};
+
+static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
+{
+   return container_of(sdev, struct csi_priv, sd);
+}
+
+static void csi_idmac_put_ipu_resources(struct csi_priv *priv)
+{
+   if (!IS_ERR_OR_NULL(priv->idmac_ch))
+   ipu_idmac_put(priv->idmac_ch);
+   priv->idmac_ch = NULL;
+
+   if (!IS_ERR_OR_NULL(priv->smfc))
+   ipu_smfc_put(priv->smfc);
+   priv->smfc = NULL;
+}
+
+static int 

[PATCH v4 24/36] [media] add Omnivision OV5640 sensor driver

2017-02-15 Thread Steve Longerbeam
This driver is based on ov5640_mipi.c from Freescale imx_3.10.17_1.0.0_beta
branch, modified heavily to bring forward to latest interfaces and code
cleanup.

Signed-off-by: Steve Longerbeam 
---
 .../devicetree/bindings/media/i2c/ov5640.txt   |   43 +
 drivers/media/i2c/Kconfig  |7 +
 drivers/media/i2c/Makefile |1 +
 drivers/media/i2c/ov5640.c | 2109 
 4 files changed, 2160 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
 create mode 100644 drivers/media/i2c/ov5640.c

diff --git a/Documentation/devicetree/bindings/media/i2c/ov5640.txt 
b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
new file mode 100644
index 000..4607bbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/ov5640.txt
@@ -0,0 +1,43 @@
+* Omnivision OV5640 MIPI CSI-2 sensor
+
+Required Properties:
+- compatible: should be "ovti,ov5640"
+- clocks: reference to the xclk input clock.
+- clock-names: should be "xclk".
+- DOVDD-supply: Digital I/O voltage supply, 1.8 volts
+- AVDD-supply: Analog voltage supply, 2.8 volts
+- DVDD-supply: Digital core voltage supply, 1.5 volts
+
+Optional Properties:
+- reset-gpios: reference to the GPIO connected to the reset pin, if any.
+- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
+
+The device node must contain one 'port' child node for its digital output
+video port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt.
+
+Example:
+
+ {
+   ov5640: camera@3c {
+   compatible = "ovti,ov5640";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5640>;
+   reg = <0x3c>;
+   clocks = < IMX6QDL_CLK_CKO>;
+   clock-names = "xclk";
+   DOVDD-supply = <_reg>; /* 1.8v */
+   AVDD-supply = <_reg>;  /* 2.8v */
+   DVDD-supply = <_reg>;  /* 1.5v */
+   pwdn-gpios = < 19 GPIO_ACTIVE_HIGH>;
+   reset-gpios = < 20 GPIO_ACTIVE_LOW>;
+
+   port {
+   ov5640_to_mipi_csi2: endpoint {
+   remote-endpoint = <_csi2_from_ov5640>;
+   clock-lanes = <0>;
+   data-lanes = <1 2>;
+   };
+   };
+   };
+};
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index cee1dae..bf67661 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -531,6 +531,13 @@ config VIDEO_OV2659
  To compile this driver as a module, choose M here: the
  module will be called ov2659.
 
+config VIDEO_OV5640
+   tristate "OmniVision OV5640 sensor support"
+   depends on GPIOLIB && VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
+   ---help---
+ This is a V4L2 sensor-level driver for the Omnivision
+ OV5640 camera sensor with a MIPI CSI-2 interface.
+
 config VIDEO_OV7640
tristate "OmniVision OV7640 sensor support"
depends on I2C && VIDEO_V4L2
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index 5bc7bbe..3a9d73a 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o
 obj-$(CONFIG_VIDEO_SONY_BTF_MPX) += sony-btf-mpx.o
 obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o
 obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o
+obj-$(CONFIG_VIDEO_OV5640) += ov5640.o
 obj-$(CONFIG_VIDEO_OV7640) += ov7640.o
 obj-$(CONFIG_VIDEO_OV7670) += ov7670.o
 obj-$(CONFIG_VIDEO_OV9650) += ov9650.o
diff --git a/drivers/media/i2c/ov5640.c b/drivers/media/i2c/ov5640.c
new file mode 100644
index 000..b3535af
--- /dev/null
+++ b/drivers/media/i2c/ov5640.c
@@ -0,0 +1,2109 @@
+/*
+ * Copyright (C) 2011-2013 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2014-2017 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* min/typical/max system clock (xclk) frequencies */
+#define OV5640_XCLK_MIN  600
+#define OV5640_XCLK_MAX 2400
+
+/*
+ * FIXME: there is no subdev API to set the MIPI CSI-2
+ * virtual channel yet, so this is hardcoded for now.
+ */
+#define OV5640_MIPI_VC 1
+
+#define OV5640_DEFAULT_SLAVE_ID 0x3c
+
+#define OV5640_REG_CHIP_ID 0x300a
+#define OV5640_REG_PAD_OUTPUT000x3019
+#define OV5640_REG_SC_PLL_CTRL00x3034
+#define 

[PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver

2017-02-15 Thread Steve Longerbeam
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 +
 drivers/staging/media/imx/imx6-mipi-csi2.c | 573 +
 2 files changed, 574 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx6-mipi-csi2.c

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 878a126..3569625 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
 
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
+obj-$(CONFIG_VIDEO_IMX_CSI) += imx6-mipi-csi2.o
diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
new file mode 100644
index 000..23dca80
--- /dev/null
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -0,0 +1,573 @@
+/*
+ * MIPI CSI-2 Receiver Subdev for Freescale i.MX6 SOC.
+ *
+ * Copyright (c) 2012-2017 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "imx-media.h"
+
+/*
+ * there must be 5 pads: 1 input pad from sensor, and
+ * the 4 virtual channel output pads
+ */
+#define CSI2_SINK_PAD   0
+#define CSI2_NUM_SINK_PADS  1
+#define CSI2_NUM_SRC_PADS   4
+#define CSI2_NUM_PADS   5
+
+struct csi2_dev {
+   struct device  *dev;
+   struct v4l2_subdev  sd;
+   struct media_pad   pad[CSI2_NUM_PADS];
+   struct v4l2_mbus_framefmt format_mbus;
+   struct clk *dphy_clk;
+   struct clk *cfg_clk;
+   struct clk *pix_clk; /* what is this? */
+   void __iomem   *base;
+   struct v4l2_of_bus_mipi_csi2 bus;
+   boolon;
+   boolstream_on;
+   boolsrc_linked;
+   boolsink_linked[CSI2_NUM_SRC_PADS];
+};
+
+#define DEVICE_NAME "imx6-mipi-csi2"
+
+/* Register offsets */
+#define CSI2_VERSION0x000
+#define CSI2_N_LANES0x004
+#define CSI2_PHY_SHUTDOWNZ  0x008
+#define CSI2_DPHY_RSTZ  0x00c
+#define CSI2_RESETN 0x010
+#define CSI2_PHY_STATE  0x014
+#define PHY_STOPSTATEDATA_BIT   4
+#define PHY_STOPSTATEDATA(n)BIT(PHY_STOPSTATEDATA_BIT + (n))
+#define PHY_RXCLKACTIVEHS   BIT(8)
+#define PHY_RXULPSCLKNOTBIT(9)
+#define PHY_STOPSTATECLKBIT(10)
+#define CSI2_DATA_IDS_1 0x018
+#define CSI2_DATA_IDS_2 0x01c
+#define CSI2_ERR1   0x020
+#define CSI2_ERR2   0x024
+#define CSI2_MSK1   0x028
+#define CSI2_MSK2   0x02c
+#define CSI2_PHY_TST_CTRL0  0x030
+#define PHY_TESTCLRBIT(0)
+#define PHY_TESTCLKBIT(1)
+#define CSI2_PHY_TST_CTRL1  0x034
+#define PHY_TESTEN BIT(16)
+#define CSI2_SFT_RESET  0xf00
+
+static inline struct csi2_dev *sd_to_dev(struct v4l2_subdev *sdev)
+{
+   return container_of(sdev, struct csi2_dev, sd);
+}
+
+static void csi2_enable(struct csi2_dev *csi2, bool enable)
+{
+   if (enable) {
+   writel(0x1, csi2->base + CSI2_PHY_SHUTDOWNZ);
+   writel(0x1, csi2->base + CSI2_DPHY_RSTZ);
+   writel(0x1, csi2->base + CSI2_RESETN);
+   } else {
+   writel(0x0, csi2->base + CSI2_PHY_SHUTDOWNZ);
+   writel(0x0, csi2->base + CSI2_DPHY_RSTZ);
+   writel(0x0, csi2->base + CSI2_RESETN);
+   }
+}
+
+static void csi2_set_lanes(struct csi2_dev *csi2)
+{
+   int lanes = csi2->bus.num_data_lanes;
+
+   writel(lanes - 1, csi2->base + CSI2_N_LANES);
+}
+
+static void dw_mipi_csi2_phy_write(struct csi2_dev *csi2,
+  u32 test_code, u32 test_data)
+{
+   /* Clear PHY test interface */
+   writel(PHY_TESTCLR, csi2->base + CSI2_PHY_TST_CTRL0);
+   writel(0x0, csi2->base + CSI2_PHY_TST_CTRL1);
+   writel(0x0, csi2->base + CSI2_PHY_TST_CTRL0);
+
+   /* Raise test interface strobe signal */
+   writel(PHY_TESTCLK, csi2->base + CSI2_PHY_TST_CTRL0);
+
+   /* Configure address write on falling edge and lower strobe signal */
+   writel(PHY_TESTEN | test_code, csi2->base + CSI2_PHY_TST_CTRL1);
+   writel(0x0, csi2->base + CSI2_PHY_TST_CTRL0);
+
+   /* Configure data write on rising edge and raise strobe signal */
+   writel(test_data, csi2->base + CSI2_PHY_TST_CTRL1);
+   writel(PHY_TESTCLK, csi2->base + CSI2_PHY_TST_CTRL0);
+

[PATCH v4 27/36] media: imx: csi: add support for bayer formats

2017-02-15 Thread Steve Longerbeam
From: Russell King 

Bayer formats must be treated as generic data and passthrough mode must
be used.  Add the correct setup for these formats.

Signed-off-by: Russell King 

- added check to csi_link_validate() to verify that destination is
  IDMAC output pad when passthrough conditions exist: bayer formats
  and 16-bit parallel buses.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 50 ++-
 1 file changed, 42 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 0343fc3..ae24b42 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -2,6 +2,7 @@
  * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
  *
  * Copyright (c) 2014-2016 Mentor Graphics Inc.
+ * Copyright (C) 2017 Pengutronix, Philipp Zabel 
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License as published by
@@ -271,10 +272,11 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
struct imx_media_video_dev *vdev = priv->vdev;
struct v4l2_of_endpoint *sensor_ep;
struct v4l2_mbus_framefmt *infmt;
-   unsigned int burst_size;
struct ipu_image image;
+   u32 passthrough_bits;
dma_addr_t phys[2];
bool passthrough;
+   u32 burst_size;
int ret;
 
infmt = >format_mbus[CSI_SINK_PAD];
@@ -301,15 +303,38 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
 
/*
-* If the sensor uses 16-bit parallel CSI bus, we must handle
-* the data internally in the IPU as 16-bit generic, aka
-* passthrough mode.
+* Check for conditions that require the IPU to handle the
+* data internally as generic data, aka passthrough mode:
+* - raw bayer formats
+* - the sensor bus is 16-bit parallel
 */
-   passthrough = (sensor_ep->bus_type != V4L2_MBUS_CSI2 &&
-  sensor_ep->bus.parallel.bus_width >= 16);
+   switch (image.pix.pixelformat) {
+   case V4L2_PIX_FMT_SBGGR8:
+   case V4L2_PIX_FMT_SGBRG8:
+   case V4L2_PIX_FMT_SGRBG8:
+   case V4L2_PIX_FMT_SRGGB8:
+   burst_size = 8;
+   passthrough = true;
+   passthrough_bits = 8;
+   break;
+   case V4L2_PIX_FMT_SBGGR16:
+   case V4L2_PIX_FMT_SGBRG16:
+   case V4L2_PIX_FMT_SGRBG16:
+   case V4L2_PIX_FMT_SRGGB16:
+   burst_size = 4;
+   passthrough = true;
+   passthrough_bits = 16;
+   break;
+   default:
+   passthrough = (sensor_ep->bus_type != V4L2_MBUS_CSI2 &&
+  sensor_ep->bus.parallel.bus_width >= 16);
+   passthrough_bits = 16;
+   break;
+   }
 
if (passthrough)
-   ipu_cpmem_set_format_passthrough(priv->idmac_ch, 16);
+   ipu_cpmem_set_format_passthrough(priv->idmac_ch,
+passthrough_bits);
 
/*
 * Set the channel for the direct CSI-->memory via SMFC
@@ -695,6 +720,7 @@ static int csi_link_validate(struct v4l2_subdev *sd,
 struct v4l2_subdev_format *sink_fmt)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   const struct imx_media_pixfmt *incc;
struct v4l2_of_endpoint *sensor_ep;
bool is_csi2;
int ret;
@@ -713,8 +739,16 @@ static int csi_link_validate(struct v4l2_subdev *sd,
}
 
sensor_ep = >sensor->sensor_ep;
-
is_csi2 = (sensor_ep->bus_type == V4L2_MBUS_CSI2);
+   incc = priv->cc[CSI_SINK_PAD];
+
+   if (priv->dest != IPU_CSI_DEST_IDMAC &&
+   (incc->bayer || (!is_csi2 &&
+sensor_ep->bus.parallel.bus_width >= 16))) {
+   v4l2_err(>sd,
+"bayer/16-bit parallel buses must go to IDMAC pad\n");
+   return -EINVAL;
+   }
 
if (is_csi2) {
int vc_num = 0;
-- 
2.7.4



[PATCH v4 25/36] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers

2017-02-15 Thread Steve Longerbeam
Enable i.MX v4l2 media staging driver. For video capture on i.MX, the
video multiplexer subdev is required. On the SabreAuto, the ADV7180
video decoder is required along with i2c-mux-gpio. The Sabrelite
and SabreSD require the OV5640 and the SabreLite requires PWM clocks
for the OV5640.

Increase max zoneorder to allow larger video buffer allocations.

Signed-off-by: Steve Longerbeam 
---
 arch/arm/configs/imx_v6_v7_defconfig | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/imx_v6_v7_defconfig 
b/arch/arm/configs/imx_v6_v7_defconfig
index cbe7faf..daeb164 100644
--- a/arch/arm/configs/imx_v6_v7_defconfig
+++ b/arch/arm/configs/imx_v6_v7_defconfig
@@ -51,6 +51,7 @@ CONFIG_PREEMPT_VOLUNTARY=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_CMA=y
+CONFIG_FORCE_MAX_ZONEORDER=14
 CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
 CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
@@ -174,13 +175,13 @@ CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MMA8450=y
 CONFIG_SERIO_SERPORT=m
 # CONFIG_LEGACY_PTYS is not set
-# CONFIG_DEVKMEM is not set
 CONFIG_SERIAL_IMX=y
 CONFIG_SERIAL_IMX_CONSOLE=y
 CONFIG_SERIAL_FSL_LPUART=y
 CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
 # CONFIG_I2C_COMPAT is not set
 CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_MUX=y
 CONFIG_I2C_MUX_GPIO=y
 # CONFIG_I2C_HELPER_AUTO is not set
 CONFIG_I2C_ALGOPCF=m
@@ -194,11 +195,11 @@ CONFIG_GPIO_SYSFS=y
 CONFIG_GPIO_MC9S08DZ60=y
 CONFIG_GPIO_PCA953X=y
 CONFIG_GPIO_STMPE=y
-CONFIG_POWER_SUPPLY=y
 CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_IMX=y
 CONFIG_POWER_RESET_SYSCON=y
 CONFIG_POWER_RESET_SYSCON_POWEROFF=y
+CONFIG_POWER_SUPPLY=y
 CONFIG_SENSORS_GPIO_FAN=y
 CONFIG_SENSORS_IIO_HWMON=y
 CONFIG_THERMAL=y
@@ -221,14 +222,20 @@ CONFIG_REGULATOR_PFUZE100=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_MEDIA_CAMERA_SUPPORT=y
 CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_MEDIA_CONTROLLER=y
+CONFIG_VIDEO_V4L2_SUBDEV_API=y
 CONFIG_RC_DEVICES=y
 CONFIG_IR_GPIO_CIR=y
 CONFIG_MEDIA_USB_SUPPORT=y
 CONFIG_USB_VIDEO_CLASS=m
 CONFIG_V4L_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_MULTIPLEXER=y
 CONFIG_SOC_CAMERA=y
 CONFIG_V4L_MEM2MEM_DRIVERS=y
 CONFIG_VIDEO_CODA=y
+# CONFIG_MEDIA_SUBDRV_AUTOSELECT is not set
+CONFIG_VIDEO_ADV7180=m
+CONFIG_VIDEO_OV5640=m
 CONFIG_SOC_CAMERA_OV2640=y
 CONFIG_IMX_IPUV3_CORE=y
 CONFIG_DRM=y
@@ -338,6 +345,9 @@ CONFIG_FSL_EDMA=y
 CONFIG_IMX_SDMA=y
 CONFIG_MXS_DMA=y
 CONFIG_STAGING=y
+CONFIG_STAGING_MEDIA=y
+CONFIG_VIDEO_IMX_MEDIA=y
+CONFIG_COMMON_CLK_PWM=y
 CONFIG_IIO=y
 CONFIG_VF610_ADC=y
 CONFIG_MPL3115=y
-- 
2.7.4



[PATCH v4 32/36] media: imx: csi/fim: add support for frame intervals

2017-02-15 Thread Steve Longerbeam
Add support to CSI for negotiation of frame intervals, and use this
information to configure the frame interval monitor.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 36 ---
 drivers/staging/media/imx/imx-media-fim.c | 28 +---
 drivers/staging/media/imx/imx-media.h |  2 +-
 3 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index b0aac82..040cca6 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -56,6 +56,7 @@ struct csi_priv {
 
struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
+   struct v4l2_fract frame_interval;
struct v4l2_rect crop;
 
/* the video device at IDMAC output pad */
@@ -565,7 +566,8 @@ static int csi_start(struct csi_priv *priv)
 
/* start the frame interval monitor */
if (priv->fim) {
-   ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
+   ret = imx_media_fim_set_stream(priv->fim,
+  >frame_interval, true);
if (ret)
goto idmac_stop;
}
@@ -580,7 +582,8 @@ static int csi_start(struct csi_priv *priv)
 
 fim_off:
if (priv->fim)
-   imx_media_fim_set_stream(priv->fim, priv->sensor, false);
+   imx_media_fim_set_stream(priv->fim,
+>frame_interval, false);
 idmac_stop:
if (priv->dest == IPU_CSI_DEST_IDMAC)
csi_idmac_stop(priv);
@@ -594,11 +597,36 @@ static void csi_stop(struct csi_priv *priv)
 
/* stop the frame interval monitor */
if (priv->fim)
-   imx_media_fim_set_stream(priv->fim, priv->sensor, false);
+   imx_media_fim_set_stream(priv->fim,
+>frame_interval, false);
 
ipu_csi_disable(priv->csi);
 }
 
+static int csi_g_frame_interval(struct v4l2_subdev *sd,
+   struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+
+   fi->interval = priv->frame_interval;
+
+   return 0;
+}
+
+static int csi_s_frame_interval(struct v4l2_subdev *sd,
+   struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad == CSI_SRC_PAD_IDMAC || fi->pad == CSI_SRC_PAD_DIRECT)
+   fi->interval = priv->frame_interval;
+
+   priv->frame_interval = fi->interval;
+
+   return 0;
+}
+
 static int csi_s_stream(struct v4l2_subdev *sd, int enable)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
@@ -1187,6 +1215,8 @@ static struct v4l2_subdev_core_ops csi_core_ops = {
 };
 
 static struct v4l2_subdev_video_ops csi_video_ops = {
+   .g_frame_interval = csi_g_frame_interval,
+   .s_frame_interval = csi_s_frame_interval,
.s_stream = csi_s_stream,
 };
 
diff --git a/drivers/staging/media/imx/imx-media-fim.c 
b/drivers/staging/media/imx/imx-media-fim.c
index acc7e39..a6ed57e 100644
--- a/drivers/staging/media/imx/imx-media-fim.c
+++ b/drivers/staging/media/imx/imx-media-fim.c
@@ -67,26 +67,18 @@ struct imx_media_fim {
 };
 
 static void update_fim_nominal(struct imx_media_fim *fim,
-  struct imx_media_subdev *sensor)
+  const struct v4l2_fract *fi)
 {
-   struct v4l2_streamparm parm;
-   struct v4l2_fract tpf;
-   int ret;
-
-   parm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
-   ret = v4l2_subdev_call(sensor->sd, video, g_parm, );
-   tpf = parm.parm.capture.timeperframe;
-
-   if (ret || tpf.denominator == 0) {
-   dev_dbg(fim->sd->dev, "no tpf from sensor, FIM disabled\n");
+   if (fi->denominator == 0) {
+   dev_dbg(fim->sd->dev, "no frame interval, FIM disabled\n");
fim->enabled = false;
return;
}
 
-   fim->nominal = DIV_ROUND_CLOSEST(1000 * 1000 * tpf.numerator,
-tpf.denominator);
+   fim->nominal = DIV_ROUND_CLOSEST_ULL(100ULL * (u64)fi->numerator,
+fi->denominator);
 
-   dev_dbg(fim->sd->dev, "sensor FI=%lu usec\n", fim->nominal);
+   dev_dbg(fim->sd->dev, "FI=%lu usec\n", fim->nominal);
 }
 
 static void reset_fim(struct imx_media_fim *fim, bool curval)
@@ -130,8 +122,8 @@ static void send_fim_event(struct imx_media_fim *fim, 
unsigned long error)
 
 /*
  * Monitor an averaged frame interval. If the average deviates too much
- * from the sensor's 

[PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

The cropping rectangle was being modified by the output pad's
set_fmt, which is the wrong pad to do this. The crop rectangle
should not be modified by the output pad set_fmt. It instead
should be reset to the full input frame when the input pad format
is set.

The output pad set_fmt should set width/height to the current
crop dimensions, or 1/2 the crop width/height to enable
downscaling.

So the other part of this patch is to enable downscaling if
the output pad dimension(s) are 1/2 the crop dimension(s) at
csi_setup() time.

Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 35 ---
 1 file changed, 23 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index ae24b42..3cb97e2 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -531,6 +531,10 @@ static int csi_setup(struct csi_priv *priv)
 
ipu_csi_set_window(priv->csi, >crop);
 
+   ipu_csi_set_downsize(priv->csi,
+priv->crop.width == 2 * outfmt->width,
+priv->crop.height == 2 * outfmt->height);
+
ipu_csi_init_interface(priv->csi, _mbus_cfg, _fmt);
 
ipu_csi_set_dest(priv->csi, priv->dest);
@@ -890,15 +894,15 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
switch (sdformat->pad) {
case CSI_SRC_PAD_DIRECT:
case CSI_SRC_PAD_IDMAC:
-   crop.left = priv->crop.left;
-   crop.top = priv->crop.top;
-   crop.width = sdformat->format.width;
-   crop.height = sdformat->format.height;
-   ret = csi_try_crop(priv, , sensor);
-   if (ret)
-   return ret;
-   sdformat->format.width = crop.width;
-   sdformat->format.height = crop.height;
+   if (sdformat->format.width < priv->crop.width * 3 / 4)
+   sdformat->format.width = priv->crop.width / 2;
+   else
+   sdformat->format.width = priv->crop.width;
+
+   if (sdformat->format.height < priv->crop.height * 3 / 4)
+   sdformat->format.height = priv->crop.height / 2;
+   else
+   sdformat->format.height = priv->crop.height;
 
if (sdformat->pad == CSI_SRC_PAD_IDMAC) {
cc = imx_media_find_format(0, sdformat->format.code,
@@ -948,6 +952,14 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
}
break;
case CSI_SINK_PAD:
+   crop.left = 0;
+   crop.top = 0;
+   crop.width = sdformat->format.width;
+   crop.height = sdformat->format.height;
+   ret = csi_try_crop(priv, , sensor);
+   if (ret)
+   return ret;
+
cc = imx_media_find_format(0, sdformat->format.code,
   true, false);
if (!cc) {
@@ -965,9 +977,8 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
} else {
priv->format_mbus[sdformat->pad] = sdformat->format;
priv->cc[sdformat->pad] = cc;
-   /* Update the crop window if this is an output pad  */
-   if (sdformat->pad == CSI_SRC_PAD_DIRECT ||
-   sdformat->pad == CSI_SRC_PAD_IDMAC)
+   /* Reset the crop window if this is the input pad */
+   if (sdformat->pad == CSI_SINK_PAD)
priv->crop = crop;
}
 
-- 
2.7.4



[PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates

2017-02-15 Thread Steve Longerbeam
From: Russell King 

Setting and getting frame rates is part of the negotiation mechanism
between subdevs.  The lack of support means that a frame rate at the
sensor can't be negotiated through the subdev path.

Add support at MIPI CSI2 level for handling this part of the
negotiation.

Signed-off-by: Russell King 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx6-mipi-csi2.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/staging/media/imx/imx6-mipi-csi2.c 
b/drivers/staging/media/imx/imx6-mipi-csi2.c
index 23dca80..c62f14e 100644
--- a/drivers/staging/media/imx/imx6-mipi-csi2.c
+++ b/drivers/staging/media/imx/imx6-mipi-csi2.c
@@ -34,6 +34,7 @@ struct csi2_dev {
struct v4l2_subdev  sd;
struct media_pad   pad[CSI2_NUM_PADS];
struct v4l2_mbus_framefmt format_mbus;
+   struct v4l2_fract  frame_interval;
struct clk *dphy_clk;
struct clk *cfg_clk;
struct clk *pix_clk; /* what is this? */
@@ -397,6 +398,30 @@ static int csi2_set_fmt(struct v4l2_subdev *sd,
return 0;
 }
 
+static int csi2_g_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   fi->interval = csi2->frame_interval;
+
+   return 0;
+}
+
+static int csi2_s_frame_interval(struct v4l2_subdev *sd,
+struct v4l2_subdev_frame_interval *fi)
+{
+   struct csi2_dev *csi2 = sd_to_dev(sd);
+
+   /* Output pads mirror active input pad, no limits on input pads */
+   if (fi->pad != CSI2_SINK_PAD)
+   fi->interval = csi2->frame_interval;
+
+   csi2->frame_interval = fi->interval;
+
+   return 0;
+}
+
 /*
  * retrieve our pads parsed from the OF graph by the media device
  */
@@ -430,6 +455,8 @@ static struct v4l2_subdev_core_ops csi2_core_ops = {
 
 static struct v4l2_subdev_video_ops csi2_video_ops = {
.s_stream = csi2_s_stream,
+   .g_frame_interval = csi2_g_frame_interval,
+   .s_frame_interval = csi2_s_frame_interval,
 };
 
 static struct v4l2_subdev_pad_ops csi2_pad_ops = {
-- 
2.7.4



[PATCH v4 31/36] media: imx: csi: add __csi_get_fmt

2017-02-15 Thread Steve Longerbeam
Add __csi_get_fmt() and use it to return the correct mbus format
(active or try) in get_fmt. Use it in other places as well.

Signed-off-by: Steve Longerbeam 
Suggested-by: Russell King 
---
 drivers/staging/media/imx/imx-media-csi.c | 52 ---
 1 file changed, 40 insertions(+), 12 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 63555dc..b0aac82 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -788,7 +788,20 @@ static int csi_eof_isr(struct v4l2_subdev *sd, u32 status, 
bool *handled)
return 0;
 }
 
-static int csi_try_crop(struct csi_priv *priv, struct v4l2_rect *crop,
+static struct v4l2_mbus_framefmt *
+__csi_get_fmt(struct csi_priv *priv, struct v4l2_subdev_pad_config *cfg,
+ unsigned int pad, enum v4l2_subdev_format_whence which)
+{
+   if (which == V4L2_SUBDEV_FORMAT_TRY)
+   return v4l2_subdev_get_try_format(>sd, cfg, pad);
+   else
+   return >format_mbus[pad];
+}
+
+static int csi_try_crop(struct csi_priv *priv,
+   struct v4l2_rect *crop,
+   struct v4l2_subdev_pad_config *cfg,
+   enum v4l2_subdev_format_whence which,
struct imx_media_subdev *sensor)
 {
struct v4l2_of_endpoint *sensor_ep;
@@ -796,7 +809,7 @@ static int csi_try_crop(struct csi_priv *priv, struct 
v4l2_rect *crop,
v4l2_std_id std;
int ret;
 
-   infmt = >format_mbus[CSI_SINK_PAD];
+   infmt = __csi_get_fmt(priv, cfg, CSI_SINK_PAD, which);
sensor_ep = >sensor_ep;
 
crop->width = min_t(__u32, infmt->width, crop->width);
@@ -852,11 +865,16 @@ static int csi_get_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *sdformat)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   struct v4l2_mbus_framefmt *fmt;
 
if (sdformat->pad >= CSI_NUM_PADS)
return -EINVAL;
 
-   sdformat->format = priv->format_mbus[sdformat->pad];
+   fmt = __csi_get_fmt(priv, cfg, sdformat->pad, sdformat->which);
+   if (!fmt)
+   return -EINVAL;
+
+   sdformat->format = *fmt;
 
return 0;
 }
@@ -880,8 +898,6 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
if (priv->stream_on)
return -EBUSY;
 
-   infmt = >format_mbus[CSI_SINK_PAD];
-
sensor = imx_media_find_sensor(priv->md, >sd.entity);
if (IS_ERR(sensor)) {
v4l2_err(>sd, "no sensor attached\n");
@@ -895,6 +911,8 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
switch (sdformat->pad) {
case CSI_SRC_PAD_DIRECT:
case CSI_SRC_PAD_IDMAC:
+   infmt = __csi_get_fmt(priv, cfg, CSI_SINK_PAD, sdformat->which);
+
if (sdformat->format.width < priv->crop.width * 3 / 4)
sdformat->format.width = priv->crop.width / 2;
else
@@ -957,7 +975,8 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
crop.top = 0;
crop.width = sdformat->format.width;
crop.height = sdformat->format.height;
-   ret = csi_try_crop(priv, , sensor);
+   ret = csi_try_crop(priv, , cfg,
+  sdformat->which, sensor);
if (ret)
return ret;
 
@@ -1004,7 +1023,9 @@ static int csi_get_selection(struct v4l2_subdev *sd,
if (sel->pad >= CSI_NUM_PADS || sel->pad == CSI_SINK_PAD)
return -EINVAL;
 
-   infmt = >format_mbus[CSI_SINK_PAD];
+   infmt = __csi_get_fmt(priv, cfg, CSI_SINK_PAD, sel->which);
+   if (!infmt)
+   return -EINVAL;
 
switch (sel->target) {
case V4L2_SEL_TGT_CROP_BOUNDS:
@@ -1014,7 +1035,14 @@ static int csi_get_selection(struct v4l2_subdev *sd,
sel->r.height = infmt->height;
break;
case V4L2_SEL_TGT_CROP:
-   sel->r = priv->crop;
+   if (sel->which == V4L2_SUBDEV_FORMAT_TRY) {
+   struct v4l2_rect *try_crop =
+   v4l2_subdev_get_try_crop(>sd,
+cfg, sel->pad);
+   sel->r = *try_crop;
+   } else {
+   sel->r = priv->crop;
+   }
break;
default:
return -EINVAL;
@@ -1028,7 +1056,6 @@ static int csi_set_selection(struct v4l2_subdev *sd,
 struct v4l2_subdev_selection *sel)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
-   struct v4l2_mbus_framefmt *outfmt;
struct imx_media_subdev *sensor;
int ret;
 
@@ -1058,15 +1085,16 @@ static int csi_set_selection(struct v4l2_subdev *sd,
return 

[PATCH v4 35/36] media: imx: csi: fix crop rectangle reset in sink set_fmt

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

The csi_try_crop call in set_fmt should compare the cropping rectangle
to the currently set input format, not to the previous input format.

Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 6284f99..3e6b607 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -937,15 +937,13 @@ __csi_get_fmt(struct csi_priv *priv, struct 
v4l2_subdev_pad_config *cfg,
 static int csi_try_crop(struct csi_priv *priv,
struct v4l2_rect *crop,
struct v4l2_subdev_pad_config *cfg,
-   enum v4l2_subdev_format_whence which,
+   struct v4l2_mbus_framefmt *infmt,
struct imx_media_subdev *sensor)
 {
struct v4l2_of_endpoint *sensor_ep;
-   struct v4l2_mbus_framefmt *infmt;
v4l2_std_id std;
int ret;
 
-   infmt = __csi_get_fmt(priv, cfg, CSI_SINK_PAD, which);
sensor_ep = >sensor_ep;
 
crop->width = min_t(__u32, infmt->width, crop->width);
@@ -1142,8 +1140,7 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
crop.top = 0;
crop.width = sdformat->format.width;
crop.height = sdformat->format.height;
-   ret = csi_try_crop(priv, , cfg,
-  sdformat->which, sensor);
+   ret = csi_try_crop(priv, , cfg, >format, sensor);
if (ret)
return ret;
 
@@ -1225,6 +1222,7 @@ static int csi_set_selection(struct v4l2_subdev *sd,
 struct v4l2_subdev_selection *sel)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   struct v4l2_mbus_framefmt *infmt;
struct imx_media_subdev *sensor;
int ret;
 
@@ -1254,7 +1252,8 @@ static int csi_set_selection(struct v4l2_subdev *sd,
return 0;
}
 
-   ret = csi_try_crop(priv, >r, cfg, sel->which, sensor);
+   infmt = __csi_get_fmt(priv, cfg, CSI_SINK_PAD, sel->which);
+   ret = csi_try_crop(priv, >r, cfg, infmt, sensor);
if (ret)
return ret;
 
-- 
2.7.4



[PATCH v4 34/36] media: imx: csi: add frame skipping support

2017-02-15 Thread Steve Longerbeam
From: Philipp Zabel 

The CSI can skip any out of up to 6 input frames, allowing to reduce the
frame rate at the output pads by small fractions.

Signed-off-by: Philipp Zabel 
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-media-csi.c | 119 +-
 1 file changed, 115 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 1d4e746..6284f99 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -9,6 +9,7 @@
  * the Free Software Foundation; either version 2 of the License, or
  * (at your option) any later version.
  */
+#include 
 #include 
 #include 
 #include 
@@ -40,6 +41,18 @@
 #define H_ALIGN1 /* multiple of 2 lines */
 #define S_ALIGN1 /* multiple of 2 */
 
+/*
+ * struct csi_skip_desc - CSI frame skipping descriptor
+ * @keep - number of frames kept per max_ratio frames
+ * @max_ratio - width of skip_smfc, written to MAX_RATIO bitfield
+ * @skip_smfc - skip pattern written to the SKIP_SMFC bitfield
+ */
+struct csi_skip_desc {
+   u8 keep;
+   u8 max_ratio;
+   u8 skip_smfc;
+};
+
 struct csi_priv {
struct device *dev;
struct ipu_soc *ipu;
@@ -58,6 +71,7 @@ struct csi_priv {
const struct imx_media_pixfmt *cc[CSI_NUM_PADS];
struct v4l2_fract frame_interval;
struct v4l2_rect crop;
+   const struct csi_skip_desc *skip[CSI_NUM_PADS - 1];
 
/* the video device at IDMAC output pad */
struct imx_media_video_dev *vdev;
@@ -512,10 +526,12 @@ static int csi_setup(struct csi_priv *priv)
struct v4l2_mbus_config sensor_mbus_cfg;
struct v4l2_of_endpoint *sensor_ep;
struct v4l2_mbus_framefmt if_fmt;
+   const struct csi_skip_desc *skip;
 
infmt = >format_mbus[CSI_SINK_PAD];
outfmt = >format_mbus[priv->active_output_pad];
sensor_ep = >sensor->sensor_ep;
+   skip = priv->skip[priv->active_output_pad - 1];
 
/* compose mbus_config from sensor endpoint */
sensor_mbus_cfg.type = sensor_ep->bus_type;
@@ -540,6 +556,9 @@ static int csi_setup(struct csi_priv *priv)
 
ipu_csi_set_dest(priv->csi, priv->dest);
 
+   ipu_csi_set_skip_smfc(priv->csi, skip->skip_smfc, skip->max_ratio - 1,
+ 0);
+
ipu_csi_dump(priv->csi);
 
return 0;
@@ -603,26 +622,115 @@ static void csi_stop(struct csi_priv *priv)
ipu_csi_disable(priv->csi);
 }
 
+static const struct csi_skip_desc csi_skip[12] = {
+   { 1, 1, 0x00 }, /* Keep all frames */
+   { 5, 6, 0x10 }, /* Skip every sixth frame */
+   { 4, 5, 0x08 }, /* Skip every fifth frame */
+   { 3, 4, 0x04 }, /* Skip every fourth frame */
+   { 2, 3, 0x02 }, /* Skip every third frame */
+   { 3, 5, 0x0a }, /* Skip frames 1 and 3 of every 5 */
+   { 1, 2, 0x01 }, /* Skip every second frame */
+   { 2, 5, 0x0b }, /* Keep frames 1 and 4 of every 5 */
+   { 1, 3, 0x03 }, /* Keep one in three frames */
+   { 1, 4, 0x07 }, /* Keep one in four frames */
+   { 1, 5, 0x0f }, /* Keep one in five frames */
+   { 1, 6, 0x1f }, /* Keep one in six frames */
+};
+
+static void csi_apply_skip_interval(const struct csi_skip_desc *skip,
+   struct v4l2_fract *interval)
+{
+   unsigned int div;
+
+   interval->numerator *= skip->max_ratio;
+   interval->denominator *= skip->keep;
+
+   /* Reduce fraction to lowest terms */
+   div = gcd(interval->numerator, interval->denominator);
+   if (div > 1) {
+   interval->numerator /= div;
+   interval->denominator /= div;
+   }
+}
+
 static int csi_g_frame_interval(struct v4l2_subdev *sd,
struct v4l2_subdev_frame_interval *fi)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
 
+   if (fi->pad >= CSI_NUM_PADS)
+   return -EINVAL;
+
fi->interval = priv->frame_interval;
 
+   if (fi->pad != CSI_SINK_PAD)
+   csi_apply_skip_interval(priv->skip[fi->pad - 1], >interval);
+
return 0;
 }
 
+/*
+ * Find the skip pattern to produce the output frame interval closest to the
+ * requested one, for the given input frame interval. Updates the output frame
+ * interval to the exact value.
+ */
+static const struct csi_skip_desc *csi_find_best_skip(struct v4l2_fract *in,
+ struct v4l2_fract *out)
+{
+   const struct csi_skip_desc *skip = _skip[0], *best_skip = skip;
+   u32 min_err = UINT_MAX;
+   u64 want_us;
+   int i;
+
+   /* Default to 1:1 ratio */
+   if (out->numerator == 0 || out->denominator == 0 ||
+   in->numerator == 0 || in->denominator == 0)
+   return best_skip;
+
+   want_us = 

[PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation

2017-02-15 Thread Steve Longerbeam
The previous API and negotiation of mbus codes and pixel formats
was broken, and has been completely redone.

The negotiation of media bus codes should be as follows:

CSI:

sink pad direct src pad  IDMAC src pad
 -
RGB (any)IPU RGB   RGB (any)
YUV (any)IPU YUV   YUV (any)
Bayer  N/A must be same bayer code as sink

VDIC:

direct sink padIDMAC sink paddirect src pad
-------
IPU YUV only   YUV (any) IPU YUV only

PRP:

direct sink paddirect src pads
------
IPU (any)  same as sink code

PRP ENC/VF:

direct sink padIDMAC src pads
-----
IPU (any)  any RGB or YUV

Given the above, a new internal API is created:

enum codespace_sel {
   CS_SEL_YUV = 0, /* find or enumerate only YUV codes */
   CS_SEL_RGB, /* find or enumerate only RGB codes */
   CS_SEL_ANY, /* find or enumerate both YUV and RGB codes */
};

/* Find and enumerate fourcc pixel formats */
const struct imx_media_pixfmt *
imx_media_find_format(u32 fourcc, enum codespace_sel cs_sel);
int imx_media_enum_format(u32 *fourcc, u32 index, enum codespace_sel cs_sel);

/* Find and enumerate media bus codes */
const struct imx_media_pixfmt *
imx_media_find_mbus_format(u32 code, enum codespace_sel cs_sel,
  bool allow_bayer);
int imx_media_enum_mbus_format(u32 *code, u32 index, enum codespace_sel cs_sel,
  bool allow_bayer);

/* Find and enumerate IPU internal media bus codes */
const struct imx_media_pixfmt *
imx_media_find_ipu_format(u32 code, enum codespace_sel cs_sel);
int imx_media_enum_ipu_format(u32 *code, u32 index, enum codespace_sel cs_sel);

The tables have been split into separate tables for YUV and RGB formats
to support the implementation of the above.

The subdev's .enum_mbus_code() and .set_fmt() operations have
been rewritten using the above APIs.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prp.c|  72 --
 drivers/staging/media/imx/imx-ic-prpencvf.c   |  53 ++--
 drivers/staging/media/imx/imx-media-capture.c |  77 +++---
 drivers/staging/media/imx/imx-media-csi.c | 107 +---
 drivers/staging/media/imx/imx-media-utils.c   | 357 +++---
 drivers/staging/media/imx/imx-media-vdic.c| 100 +---
 drivers/staging/media/imx/imx-media.h |  27 +-
 7 files changed, 528 insertions(+), 265 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prp.c 
b/drivers/staging/media/imx/imx-ic-prp.c
index 3683f7c..b9ee8fb 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -96,16 +96,6 @@ static void prp_stop(struct prp_priv *priv)
 {
 }
 
-static int prp_enum_mbus_code(struct v4l2_subdev *sd,
- struct v4l2_subdev_pad_config *cfg,
- struct v4l2_subdev_mbus_code_enum *code)
-{
-   if (code->pad >= PRP_NUM_PADS)
-   return -EINVAL;
-
-   return imx_media_enum_ipu_format(NULL, >code, code->index, true);
-}
-
 static struct v4l2_mbus_framefmt *
 __prp_get_fmt(struct prp_priv *priv, struct v4l2_subdev_pad_config *cfg,
  unsigned int pad, enum v4l2_subdev_format_whence which)
@@ -118,6 +108,33 @@ __prp_get_fmt(struct prp_priv *priv, struct 
v4l2_subdev_pad_config *cfg,
return >format_mbus[pad];
 }
 
+static int prp_enum_mbus_code(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_mbus_code_enum *code)
+{
+   struct prp_priv *priv = sd_to_priv(sd);
+   struct v4l2_mbus_framefmt *infmt;
+   int ret = 0;
+
+   switch (code->pad) {
+   case PRP_SINK_PAD:
+   ret = imx_media_enum_ipu_format(>code, code->index,
+   CS_SEL_ANY);
+   break;
+   case PRP_SRC_PAD_PRPENC:
+   case PRP_SRC_PAD_PRPVF:
+   if (code->index != 0)
+   return -EINVAL;
+   infmt = __prp_get_fmt(priv, cfg, PRP_SINK_PAD, code->which);
+   code->code = infmt->code;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   return ret;
+}
+
 static int prp_get_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_pad_config *cfg,
   struct v4l2_subdev_format *sdformat)
@@ -152,23 +169,28 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
if (priv->stream_on)
return -EBUSY;
 
-   cc = imx_media_find_ipu_format(0, sdformat->format.code, true);
-   if (!cc) {
-   imx_media_enum_ipu_format(NULL, , 0, true);
-   cc = imx_media_find_ipu_format(0, code, true);
-   

[PATCH v4 30/36] media: imx: update capture dev format on IDMAC output pad set_fmt

2017-02-15 Thread Steve Longerbeam
When configuring the IDMAC output pad formats (in ipu_csi,
ipu_ic_prpenc, and ipu_ic_prpvf subdevs), the attached capture
device format must also be updated.

Signed-off-by: Steve Longerbeam 
Suggested-by: Philipp Zabel 
---
 drivers/staging/media/imx/imx-ic-prpencvf.c | 9 +
 drivers/staging/media/imx/imx-media-csi.c   | 9 +
 2 files changed, 18 insertions(+)

diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index 2be8845..6e45975 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -739,6 +739,7 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *sdformat)
 {
struct prp_priv *priv = sd_to_priv(sd);
+   struct imx_media_video_dev *vdev = priv->vdev;
const struct imx_media_pixfmt *cc;
struct v4l2_mbus_framefmt *infmt;
u32 code;
@@ -800,6 +801,14 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
} else {
priv->format_mbus[sdformat->pad] = sdformat->format;
priv->cc[sdformat->pad] = cc;
+   if (sdformat->pad == PRPENCVF_SRC_PAD) {
+   /*
+* update the capture device format if this is
+* the IDMAC output pad
+*/
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
+ >format, cc);
+   }
}
 
return 0;
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 3cb97e2..63555dc 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -866,6 +866,7 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
   struct v4l2_subdev_format *sdformat)
 {
struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   struct imx_media_video_dev *vdev = priv->vdev;
const struct imx_media_pixfmt *cc, *incc;
struct v4l2_mbus_framefmt *infmt;
struct imx_media_subdev *sensor;
@@ -980,6 +981,14 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
/* Reset the crop window if this is the input pad */
if (sdformat->pad == CSI_SINK_PAD)
priv->crop = crop;
+   else if (sdformat->pad == CSI_SRC_PAD_IDMAC) {
+   /*
+* update the capture device format if this is
+* the IDMAC output pad
+*/
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
+ >format, cc);
+   }
}
 
return 0;
-- 
2.7.4



[PATCH v4 36/36] media: imx: propagate sink pad formats to source pads

2017-02-15 Thread Steve Longerbeam
Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/imx-ic-prp.c  | 11 ++-
 drivers/staging/media/imx/imx-ic-prpencvf.c | 22 ++
 drivers/staging/media/imx/imx-media-csi.c   | 26 +-
 drivers/staging/media/imx/imx-media-vdic.c  | 15 ++-
 4 files changed, 55 insertions(+), 19 deletions(-)

diff --git a/drivers/staging/media/imx/imx-ic-prp.c 
b/drivers/staging/media/imx/imx-ic-prp.c
index b9ee8fb..5c57d2b 100644
--- a/drivers/staging/media/imx/imx-ic-prp.c
+++ b/drivers/staging/media/imx/imx-ic-prp.c
@@ -196,8 +196,17 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
-   priv->format_mbus[sdformat->pad] = sdformat->format;
+   struct v4l2_mbus_framefmt *f =
+   >format_mbus[sdformat->pad];
+
+   *f = sdformat->format;
priv->cc[sdformat->pad] = cc;
+
+   /* propagate format to source pads */
+   if (sdformat->pad == PRP_SINK_PAD) {
+   priv->format_mbus[PRP_SRC_PAD_PRPENC] = *f;
+   priv->format_mbus[PRP_SRC_PAD_PRPVF] = *f;
+   }
}
 
return 0;
diff --git a/drivers/staging/media/imx/imx-ic-prpencvf.c 
b/drivers/staging/media/imx/imx-ic-prpencvf.c
index dd9d499..c43f85f 100644
--- a/drivers/staging/media/imx/imx-ic-prpencvf.c
+++ b/drivers/staging/media/imx/imx-ic-prpencvf.c
@@ -806,16 +806,22 @@ static int prp_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
-   priv->format_mbus[sdformat->pad] = sdformat->format;
+   struct v4l2_mbus_framefmt *f =
+   >format_mbus[sdformat->pad];
+   struct v4l2_mbus_framefmt *outf =
+   >format_mbus[PRPENCVF_SRC_PAD];
+
+   *f = sdformat->format;
priv->cc[sdformat->pad] = cc;
-   if (sdformat->pad == PRPENCVF_SRC_PAD) {
-   /*
-* update the capture device format if this is
-* the IDMAC output pad
-*/
-   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
- >format, cc);
+
+   /* propagate format to source pad */
+   if (sdformat->pad == PRPENCVF_SINK_PAD) {
+   outf->width = f->width;
+   outf->height = f->height;
}
+
+   /* update the capture device format from output pad */
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, outf, cc);
}
 
return 0;
diff --git a/drivers/staging/media/imx/imx-media-csi.c 
b/drivers/staging/media/imx/imx-media-csi.c
index 3e6b607..9d9ec03 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -1161,19 +1161,27 @@ static int csi_set_fmt(struct v4l2_subdev *sd,
if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY) {
cfg->try_fmt = sdformat->format;
} else {
+   struct v4l2_mbus_framefmt *f_direct, *f_idmac;
+
priv->format_mbus[sdformat->pad] = sdformat->format;
priv->cc[sdformat->pad] = cc;
-   /* Reset the crop window if this is the input pad */
-   if (sdformat->pad == CSI_SINK_PAD)
+
+   f_direct = >format_mbus[CSI_SRC_PAD_DIRECT];
+   f_idmac = >format_mbus[CSI_SRC_PAD_IDMAC];
+
+   if (sdformat->pad == CSI_SINK_PAD) {
+   /* reset the crop window */
priv->crop = crop;
-   else if (sdformat->pad == CSI_SRC_PAD_IDMAC) {
-   /*
-* update the capture device format if this is
-* the IDMAC output pad
-*/
-   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix,
- >format, cc);
+
+   /* propagate format to source pads */
+   f_direct->width = crop.width;
+   f_direct->height = crop.height;
+   f_idmac->width = crop.width;
+   f_idmac->height = crop.height;
}
+
+   /* update the capture device format from IDMAC output pad */
+   imx_media_mbus_fmt_to_pix_fmt(>fmt.fmt.pix, f_idmac, cc);
}
 
return 0;
diff --git a/drivers/staging/media/imx/imx-media-vdic.c 
b/drivers/staging/media/imx/imx-media-vdic.c
index 61e6017..55fb522 100644
--- a/drivers/staging/media/imx/imx-media-vdic.c
+++ b/drivers/staging/media/imx/imx-media-vdic.c
@@ -649,8 

[PATCH v4 22/36] media: imx: Add IC subdev drivers

2017-02-15 Thread Steve Longerbeam
This is a set of four media entity subdevice drivers for the i.MX
Image Converter:

- Pre-process Router: Takes input frames from CSI0, CSI1, or VDIC.
  Two output pads enable either or both of the preprocess tasks
  below. If the input is from one of the CSIs, both proprocess task
  links can be enabled to process frames from that CSI simultaneously.
  If the input is the VDIC, only the Pre-processing Viewfinder task
  link can be enabled.

- Pre-processing Encode task: video frames are routed directly from
  the CSI and can be scaled, color-space converted, and rotated.
  Scaled output is limited to 1024x1024 resolution. Output frames
  are routed to the capture device.

- Pre-processing Viewfinder task: this task can perform the same
  conversions as the pre-process encode task, but in addition can
  be used for hardware motion compensated deinterlacing. Frames can
  come either directly from the CSI or from the VDIC. Scaled output
  is limited to 1024x1024 resolution. Output frames are routed to
  the capture device.

Signed-off-by: Steve Longerbeam 
---
 drivers/staging/media/imx/Makefile  |2 +
 drivers/staging/media/imx/imx-ic-common.c   |  113 +++
 drivers/staging/media/imx/imx-ic-prp.c  |  427 ++
 drivers/staging/media/imx/imx-ic-prpencvf.c | 1116 +++
 drivers/staging/media/imx/imx-ic.h  |   38 +
 5 files changed, 1696 insertions(+)
 create mode 100644 drivers/staging/media/imx/imx-ic-common.c
 create mode 100644 drivers/staging/media/imx/imx-ic-prp.c
 create mode 100644 drivers/staging/media/imx/imx-ic-prpencvf.c
 create mode 100644 drivers/staging/media/imx/imx-ic.h

diff --git a/drivers/staging/media/imx/Makefile 
b/drivers/staging/media/imx/Makefile
index 1f01520..878a126 100644
--- a/drivers/staging/media/imx/Makefile
+++ b/drivers/staging/media/imx/Makefile
@@ -1,9 +1,11 @@
 imx-media-objs := imx-media-dev.o imx-media-internal-sd.o imx-media-of.o
 imx-media-common-objs := imx-media-utils.o imx-media-fim.o
+imx-media-ic-objs := imx-ic-common.o imx-ic-prp.o imx-ic-prpencvf.o
 
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-capture.o
 obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-vdic.o
+obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-ic.o
 
 obj-$(CONFIG_VIDEO_IMX_CSI) += imx-media-csi.o
diff --git a/drivers/staging/media/imx/imx-ic-common.c 
b/drivers/staging/media/imx/imx-ic-common.c
new file mode 100644
index 000..cfdd490
--- /dev/null
+++ b/drivers/staging/media/imx/imx-ic-common.c
@@ -0,0 +1,113 @@
+/*
+ * V4L2 Image Converter Subdev for Freescale i.MX5/6 SOC
+ *
+ * Copyright (c) 2014-2016 Mentor Graphics Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+#include "imx-media.h"
+#include "imx-ic.h"
+
+#define IC_TASK_PRP IC_NUM_TASKS
+#define IC_NUM_OPS  (IC_NUM_TASKS + 1)
+
+static struct imx_ic_ops *ic_ops[IC_NUM_OPS] = {
+   [IC_TASK_PRP]= _ic_prp_ops,
+   [IC_TASK_ENCODER]= _ic_prpencvf_ops,
+   [IC_TASK_VIEWFINDER] = _ic_prpencvf_ops,
+};
+
+static int imx_ic_probe(struct platform_device *pdev)
+{
+   struct imx_media_internal_sd_platformdata *pdata;
+   struct imx_ic_priv *priv;
+   int ret;
+
+   priv = devm_kzalloc(>dev, sizeof(*priv), GFP_KERNEL);
+   if (!priv)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, >sd);
+   priv->dev = >dev;
+
+   /* get our ipu_id, grp_id and IC task id */
+   pdata = priv->dev->platform_data;
+   priv->ipu_id = pdata->ipu_id;
+   switch (pdata->grp_id) {
+   case IMX_MEDIA_GRP_ID_IC_PRP:
+   priv->task_id = IC_TASK_PRP;
+   break;
+   case IMX_MEDIA_GRP_ID_IC_PRPENC:
+   priv->task_id = IC_TASK_ENCODER;
+   break;
+   case IMX_MEDIA_GRP_ID_IC_PRPVF:
+   priv->task_id = IC_TASK_VIEWFINDER;
+   break;
+   default:
+   return -EINVAL;
+   }
+
+   v4l2_subdev_init(>sd, ic_ops[priv->task_id]->subdev_ops);
+   v4l2_set_subdevdata(>sd, priv);
+   priv->sd.internal_ops = ic_ops[priv->task_id]->internal_ops;
+   priv->sd.entity.ops = ic_ops[priv->task_id]->entity_ops;
+   priv->sd.entity.function = MEDIA_ENT_F_PROC_VIDEO_SCALER;
+   priv->sd.dev = >dev;
+   priv->sd.owner = THIS_MODULE;
+   priv->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE | V4L2_SUBDEV_FL_HAS_EVENTS;
+   priv->sd.grp_id = pdata->grp_id;
+   strncpy(priv->sd.name, pdata->sd_name, sizeof(priv->sd.name));
+
+   ret = ic_ops[priv->task_id]->init(priv);
+   if (ret)
+   return ret;
+
+   ret = 

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

2017-02-15 Thread Stefan Bruens
Hi Antti,

first thanks for for the review. Note the t230c_attach is mostly a copy of the 
t330_attach (which is very similar to the t680c_attach), so any of your 
comments should probably applied to the other attach functions to have a 
common coding style.

On Mittwoch, 15. Februar 2017 10:27:09 CET Antti Palosaari wrote:
> On 02/15/2017 03:51 AM, Stefan Brüns wrote:
[...]
> > diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> > b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 02dbc6c45423..729496e5a52e
> > 100644
> > --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
> > +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
> > @@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter
> > *adap)> 
> > return ret;
> >  
> >  }
> > 
> > +static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
> > +{
> > +   struct dvbsky_state *state = adap_to_priv(adap);
> > +   struct dvb_usb_device *d = adap_to_d(adap);
> > +   int ret = 0;
> 
> you could return ret completely as you don't assign its value runtime

Sure, so something like:

  ...
  return 0;
fail_foo:
  xxx;
fail bar:
  yyy;
  return -ENODEV;

Some of the other attach functions assign ret = -ENODEV and then goto one of 
the fail_foo: labels.

 
> > +   struct i2c_adapter *i2c_adapter;
> > +   struct i2c_client *client_demod, *client_tuner;
> > +   struct i2c_board_info info;
> > +   struct si2168_config si2168_config;
> > +   struct si2157_config si2157_config;
> > +
> > +   /* attach demod */
> > +   memset(_config, 0, sizeof(si2168_config));
> 
> prefer sizeof dst

You mean sizeof(struct si2168_config) ?
 
> > +   si2168_config.i2c_adapter = _adapter;
> > +   si2168_config.fe = >fe[0];
> > +   si2168_config.ts_mode = SI2168_TS_PARALLEL;
> > +   si2168_config.ts_clock_inv = 1;
> 
> it has boolean type

Sure
 
> > +   memset(, 0, sizeof(struct i2c_board_info));
> > +   strlcpy(info.type, "si2168", I2C_NAME_SIZE);
> 
> I would prefer sizeof dst here too.

Most occurences of similar code in media/usb/ use I2C_NAME_SIZE, found two 
occurences of "strlcpy(buf, ..., sizeof(buf)), but of course I can change 
this.
 
> > +   info.addr = 0x64;
> > +   info.platform_data = _config;
> > +
> > +   request_module(info.type);
> 
> Use module name here. Even it is same than device id on that case, it is
> not always the case.

While si2157 driver has several supported chip types, si2168 only supports 
si2168 (several revisions). Both request_module("foobar") and 
request_module(info.type) are common in media/usb/. Change nevertheless?
 
> > +   client_demod = i2c_new_device(>i2c_adap, );
> > +   if (client_demod == NULL ||
> > +   client_demod->dev.driver == NULL)
> 
> You did not ran checkpatch.pl for that patch? or doesn't it complain
> anymore about these?

Checkpatch did not complain.
 
[...]
> > @@ -858,6 +946,9 @@ static const struct usb_device_id dvbsky_id_table[] =
> > {
> > 
> > { DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_S2_R4,
> > 
> > _s960_props, "Terratec Cinergy S2 Rev.4",
> > RC_MAP_DVBSKY) },
> > 
> > +   { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
> > +   _t230c_props, "Mygica T230C DVB-T/T2/C",
> 
> Drop supported DTV standard names from device name. Also it is MyGica
> not Mygica.

The print on the stick says: "MyGica(R) DVB-T2", label on the backside says 
"T230C". According to the USB descriptors it is a "Geniatech" 
"EyeTV Stick". According to the box it is a "MyGica(R)" "Mini DVB-T2 USB Stick 
T230C"

Would "MyGica DVB-T2 T230C" be ok?
 
Kind regards,

Stefan

-- 
Stefan Brüns  /  Bergstraße 21  /  52062 Aachen
home: +49 241 53809034 mobile: +49 151 50412019
work: +49 2405 49936-424


[PATCH] staging: media: use octal permissions

2017-02-15 Thread dc

Replace all instances of permission macros with octal permissions

Signed-off-by: David Cako 
---
 drivers/staging/media/lirc/lirc_parallel.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c  
b/drivers/staging/media/lirc/lirc_parallel.c

index 0a43bac2b..94d2c61 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -756,17 +756,17 @@ MODULE_DESCRIPTION("Infrared receiver driver for  
parallel ports.");

 MODULE_AUTHOR("Christoph Bartelmus");
 MODULE_LICENSE("GPL");

-module_param(io, int, S_IRUGO);
+module_param(io, int, 0444);
 MODULE_PARM_DESC(io, "I/O address base (0x3bc, 0x378 or 0x278)");

-module_param(irq, int, S_IRUGO);
+module_param(irq, int, 0444);
 MODULE_PARM_DESC(irq, "Interrupt (7 or 5)");

-module_param(tx_mask, int, S_IRUGO);
+module_param(tx_mask, int, 0444);
 MODULE_PARM_DESC(tx_mask, "Transmitter mask (default: 0x01)");

-module_param(debug, bool, S_IRUGO | S_IWUSR);
+module_param(debug, bool, 0644);
 MODULE_PARM_DESC(debug, "Enable debugging messages");

-module_param(check_pselecd, bool, S_IRUGO | S_IWUSR);
+module_param(check_pselecd, bool, 0644);
 MODULE_PARM_DESC(check_pselecd, "Check for printer (default: 0)");
--
2.7.4





Re: [PATCH 3/4] smiapp: Get clock rate if it's not available through DT

2017-02-15 Thread kbuild test robot
Hi Sakari,

[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc8]
[cannot apply to linuxtv-media/master next-20170215]
[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-ci/linux/commits/Sakari-Ailus/smiapp-cleanups-clock-control-changes/20170214-010429
config: x86_64-randconfig-it0-02160426 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   drivers/media/i2c/smiapp/smiapp-core.c: In function 'smiapp_probe':
>> drivers/media/i2c/smiapp/smiapp-core.c:2909:6: warning: format '%lu' expects 
>> argument of type 'long unsigned int', but argument 3 has type 'uint32_t' 
>> [-Wformat=]
 sensor->hwcfg->ext_clk, rate);
 ^

vim +2909 drivers/media/i2c/smiapp/smiapp-core.c

88ea1579 Sakari Ailus 2017-02-13  2893  if 
(sensor->hwcfg->ext_clk) {
88ea1579 Sakari Ailus 2017-02-13  2894  unsigned long 
rate;
88ea1579 Sakari Ailus 2017-02-13  2895  
88ea1579 Sakari Ailus 2017-02-13  2896  rval = 
clk_set_rate(sensor->ext_clk,
88ea1579 Sakari Ailus 2017-02-13  2897  
sensor->hwcfg->ext_clk);
3ecb8664 Sakari Ailus 2016-09-12  2898  if (rval < 0) {
3ecb8664 Sakari Ailus 2016-09-12  2899  
dev_err(>dev,
3ecb8664 Sakari Ailus 2016-09-12  2900  
"unable to set clock freq to %u\n",
3ecb8664 Sakari Ailus 2016-09-12  2901  
sensor->hwcfg->ext_clk);
3ecb8664 Sakari Ailus 2016-09-12  2902  return 
rval;
3ecb8664 Sakari Ailus 2016-09-12  2903  }
3ecb8664 Sakari Ailus 2016-09-12  2904  
87cb6c6a Sakari Ailus 2017-02-13  2905  rate = 
clk_get_rate(sensor->ext_clk);
87cb6c6a Sakari Ailus 2017-02-13  2906  if (rate != 
sensor->hwcfg->ext_clk) {
87cb6c6a Sakari Ailus 2017-02-13  2907  
dev_err(>dev,
88ea1579 Sakari Ailus 2017-02-13  2908  
"can't set clock freq, asked for %lu but got %lu\n",
87cb6c6a Sakari Ailus 2017-02-13 @2909  
sensor->hwcfg->ext_clk, rate);
87cb6c6a Sakari Ailus 2017-02-13  2910  return 
rval;
87cb6c6a Sakari Ailus 2017-02-13  2911  }
88ea1579 Sakari Ailus 2017-02-13  2912  } else {
88ea1579 Sakari Ailus 2017-02-13  2913  
sensor->hwcfg->ext_clk = clk_get_rate(sensor->ext_clk);
88ea1579 Sakari Ailus 2017-02-13  2914  
dev_dbg(>dev, "obtained clock freq %u\n",
88ea1579 Sakari Ailus 2017-02-13  2915  
sensor->hwcfg->ext_clk);
88ea1579 Sakari Ailus 2017-02-13  2916  }
88ea1579 Sakari Ailus 2017-02-13  2917  } else if 
(sensor->hwcfg->ext_clk) {

:: The code at line 2909 was first introduced by commit
:: 87cb6c6a8fdcfc1d0327e6c826165f0ba1b5eff0 smiapp: Verify clock frequency 
after setting it, prevent changing it

:: TO: Sakari Ailus <sakari.ai...@linux.intel.com>
:: CC: 0day robot <fengguang...@intel.com>

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip


Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

2017-02-15 Thread Rob Herring
On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
> This makes the example more or less correspond with the da850-evm
> hardware setup.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 
> ++
>  1 file changed, 29 insertions(+), 6 deletions(-)

Spoke too soon...

> 
> diff --git a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt 
> b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> index 9c7510b..543f6f3 100644
> --- a/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> +++ b/Documentation/devicetree/bindings/media/ti,da850-vpif.txt
> @@ -28,19 +28,27 @@ I2C-connected TVP5147 decoder:
>   reg = <0x217000 0x1000>;
>   interrupts = <92>;
>  
> - port {
> - vpif_ch0: endpoint@0 {
> + port@0 {
> + vpif_input_ch0: endpoint@0 {
>   reg = <0>;
>   bus-width = <8>;
> - remote-endpoint = <>;
> + remote-endpoint = <_in>;
>   };
>  
> - vpif_ch1: endpoint@1 {
> + vpif_input_ch1: endpoint@1 {
>   reg = <1>;
>   bus-width = <8>;
>   data-shift = <8>;
>   };
>   };
> +
> + port@1 {

The binding doc says nothing about supporting a 2nd port. 


> + vpif_output_ch0: endpoint@0 {
> + reg = <0>;

Don't need reg here.

> + bus-width = <8>;
> + remote-endpoint = <_out>;
> + };
> + };
>   };


Re: [PATCH 03/10] media: dt-bindings: vpif: extend the example with an output port

2017-02-15 Thread Rob Herring
On Tue, Feb 07, 2017 at 05:41:16PM +0100, Bartosz Golaszewski wrote:
> This makes the example more or less correspond with the da850-evm
> hardware setup.
> 
> Signed-off-by: Bartosz Golaszewski 
> ---
>  .../devicetree/bindings/media/ti,da850-vpif.txt| 35 
> ++
>  1 file changed, 29 insertions(+), 6 deletions(-)

Acked-by: Rob Herring  


Re: [PATCH 01/10] media: dt-bindings: vpif: fix whitespace errors

2017-02-15 Thread Rob Herring
On Tue, Feb 07, 2017 at 05:41:14PM +0100, Bartosz Golaszewski wrote:
> Signed-off-by: Bartosz Golaszewski 
> ---
>  Documentation/devicetree/bindings/media/ti,da850-vpif.txt | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

Acked-by: Rob Herring  


[PATCH v2] [media] dw2102: don't do DMA on stack

2017-02-15 Thread Jonathan McDowell
(Apologies, the original version of this patch had a stray, unused,
"buf_mutex" definition left over from an earlier version before I
switched to the existing data_mutex.)

I upgraded my media box today from 4.4.48 to 4.9.10 and hit WARNINGs in
the dw2102 driver for my TechnoTrend TT-connect S2-4600, one in
su3000_power_ctrl() and the other in tt_s2_4600_frontend_attach(). Both
were due to the use of buffers on the stack as parameters to
dvb_usb_generic_rw() and the resulting attempt to do DMA with them. The
device was non-functional as a result.

Patch below switches this driver over to using a buffer within the
device state structure, as has been done with other DVB-USB drivers.
Tested against 4.9.10 but applies to Linus' master cleanly.

Signed-off-by: Jonathan McDowell 
Cc: 

-
diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 2c720cb..861c15a 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -68,6 +68,7 @@
 struct dw2102_state {
u8 initialized;
u8 last_lock;
+   u8 data[MAX_XFER_SIZE + 4];
struct i2c_client *i2c_client_demod;
struct i2c_client *i2c_client_tuner;
 
@@ -662,62 +663,69 @@ static int su3000_i2c_transfer(struct i2c_adapter *adap, 
struct i2c_msg msg[],
int num)
 {
struct dvb_usb_device *d = i2c_get_adapdata(adap);
-   u8 obuf[0x40], ibuf[0x40];
+   struct dw2102_state *state = (struct dw2102_state *)d->priv;
 
if (!d)
return -ENODEV;
if (mutex_lock_interruptible(>i2c_mutex) < 0)
return -EAGAIN;
+   if (mutex_lock_interruptible(>data_mutex) < 0) {
+   mutex_unlock(>i2c_mutex);
+   return -EAGAIN;
+   }
 
switch (num) {
case 1:
switch (msg[0].addr) {
case SU3000_STREAM_CTRL:
-   obuf[0] = msg[0].buf[0] + 0x36;
-   obuf[1] = 3;
-   obuf[2] = 0;
-   if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 0, 0) < 0)
+   state->data[0] = msg[0].buf[0] + 0x36;
+   state->data[1] = 3;
+   state->data[2] = 0;
+   if (dvb_usb_generic_rw(d, state->data, 3,
+   state->data, 0, 0) < 0)
err("i2c transfer failed.");
break;
case DW2102_RC_QUERY:
-   obuf[0] = 0x10;
-   if (dvb_usb_generic_rw(d, obuf, 1, ibuf, 2, 0) < 0)
+   state->data[0] = 0x10;
+   if (dvb_usb_generic_rw(d, state->data, 1,
+   state->data, 2, 0) < 0)
err("i2c transfer failed.");
-   msg[0].buf[1] = ibuf[0];
-   msg[0].buf[0] = ibuf[1];
+   msg[0].buf[1] = state->data[0];
+   msg[0].buf[0] = state->data[1];
break;
default:
/* always i2c write*/
-   obuf[0] = 0x08;
-   obuf[1] = msg[0].addr;
-   obuf[2] = msg[0].len;
+   state->data[0] = 0x08;
+   state->data[1] = msg[0].addr;
+   state->data[2] = msg[0].len;
 
-   memcpy([3], msg[0].buf, msg[0].len);
+   memcpy(>data[3], msg[0].buf, msg[0].len);
 
-   if (dvb_usb_generic_rw(d, obuf, msg[0].len + 3,
-   ibuf, 1, 0) < 0)
+   if (dvb_usb_generic_rw(d, state->data, msg[0].len + 3,
+   state->data, 1, 0) < 0)
err("i2c transfer failed.");
 
}
break;
case 2:
/* always i2c read */
-   obuf[0] = 0x09;
-   obuf[1] = msg[0].len;
-   obuf[2] = msg[1].len;
-   obuf[3] = msg[0].addr;
-   memcpy([4], msg[0].buf, msg[0].len);
-
-   if (dvb_usb_generic_rw(d, obuf, msg[0].len + 4,
-   ibuf, msg[1].len + 1, 0) < 0)
+   state->data[0] = 0x09;
+   state->data[1] = msg[0].len;
+   state->data[2] = msg[1].len;
+   state->data[3] = msg[0].addr;
+   memcpy(>data[4], msg[0].buf, msg[0].len);
+
+   if (dvb_usb_generic_rw(d, state->data, msg[0].len + 4,
+   state->data, msg[1].len + 1, 0) < 0)
err("i2c transfer failed.");
 
-   memcpy(msg[1].buf, [1], msg[1].len);
+   

[PATCH] [media] dw2102: don't do DMA on stack

2017-02-15 Thread Jonathan McDowell
I upgraded my media box today from 4.4.48 to 4.9.10 and hit WARNINGs in
the dw2102 driver for my TechnoTrend TT-connect S2-4600, one in
su3000_power_ctrl() and the other in tt_s2_4600_frontend_attach(). Both
were due to the use of buffers on the stack as parameters to
dvb_usb_generic_rw() and the resulting attempt to do DMA with them.

Patch below switches this driver over to using a buffer within the
device state structure, as has been done with other DVB-USB drivers.
Tested against 4.9.10 but applies to Linus' master cleanly.

Signed-off-by: Jonathan McDowell 
Cc: 

-
diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 2c720cb..1dde34f 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -68,6 +68,8 @@
 struct dw2102_state {
u8 initialized;
u8 last_lock;
+   u8 data[MAX_XFER_SIZE + 4];
+   struct mutex buf_mutex;
struct i2c_client *i2c_client_demod;
struct i2c_client *i2c_client_tuner;
 
@@ -662,62 +664,69 @@ static int su3000_i2c_transfer(struct i2c_adapter *adap, 
struct i2c_msg msg[],
int num)
 {
struct dvb_usb_device *d = i2c_get_adapdata(adap);
-   u8 obuf[0x40], ibuf[0x40];
+   struct dw2102_state *state = (struct dw2102_state *)d->priv;
 
if (!d)
return -ENODEV;
if (mutex_lock_interruptible(>i2c_mutex) < 0)
return -EAGAIN;
+   if (mutex_lock_interruptible(>data_mutex) < 0) {
+   mutex_unlock(>i2c_mutex);
+   return -EAGAIN;
+   }
 
switch (num) {
case 1:
switch (msg[0].addr) {
case SU3000_STREAM_CTRL:
-   obuf[0] = msg[0].buf[0] + 0x36;
-   obuf[1] = 3;
-   obuf[2] = 0;
-   if (dvb_usb_generic_rw(d, obuf, 3, ibuf, 0, 0) < 0)
+   state->data[0] = msg[0].buf[0] + 0x36;
+   state->data[1] = 3;
+   state->data[2] = 0;
+   if (dvb_usb_generic_rw(d, state->data, 3,
+   state->data, 0, 0) < 0)
err("i2c transfer failed.");
break;
case DW2102_RC_QUERY:
-   obuf[0] = 0x10;
-   if (dvb_usb_generic_rw(d, obuf, 1, ibuf, 2, 0) < 0)
+   state->data[0] = 0x10;
+   if (dvb_usb_generic_rw(d, state->data, 1,
+   state->data, 2, 0) < 0)
err("i2c transfer failed.");
-   msg[0].buf[1] = ibuf[0];
-   msg[0].buf[0] = ibuf[1];
+   msg[0].buf[1] = state->data[0];
+   msg[0].buf[0] = state->data[1];
break;
default:
/* always i2c write*/
-   obuf[0] = 0x08;
-   obuf[1] = msg[0].addr;
-   obuf[2] = msg[0].len;
+   state->data[0] = 0x08;
+   state->data[1] = msg[0].addr;
+   state->data[2] = msg[0].len;
 
-   memcpy([3], msg[0].buf, msg[0].len);
+   memcpy(>data[3], msg[0].buf, msg[0].len);
 
-   if (dvb_usb_generic_rw(d, obuf, msg[0].len + 3,
-   ibuf, 1, 0) < 0)
+   if (dvb_usb_generic_rw(d, state->data, msg[0].len + 3,
+   state->data, 1, 0) < 0)
err("i2c transfer failed.");
 
}
break;
case 2:
/* always i2c read */
-   obuf[0] = 0x09;
-   obuf[1] = msg[0].len;
-   obuf[2] = msg[1].len;
-   obuf[3] = msg[0].addr;
-   memcpy([4], msg[0].buf, msg[0].len);
-
-   if (dvb_usb_generic_rw(d, obuf, msg[0].len + 4,
-   ibuf, msg[1].len + 1, 0) < 0)
+   state->data[0] = 0x09;
+   state->data[1] = msg[0].len;
+   state->data[2] = msg[1].len;
+   state->data[3] = msg[0].addr;
+   memcpy(>data[4], msg[0].buf, msg[0].len);
+
+   if (dvb_usb_generic_rw(d, state->data, msg[0].len + 4,
+   state->data, msg[1].len + 1, 0) < 0)
err("i2c transfer failed.");
 
-   memcpy(msg[1].buf, [1], msg[1].len);
+   memcpy(msg[1].buf, >data[1], msg[1].len);
break;
default:
warn("more than 2 i2c messages at a time is not handled yet.");
break;
}
+  

Re: Cine CT V6.1 code change request

2017-02-15 Thread Martin Herrman
2017-02-15 8:55 GMT+01:00 Hans Verkuil :

Hi Hans,

Thanks for the quick response!

> I'm not sure what this media_build directory is. It certainly is
> outdated. The latest media_build is here: 
> https://git.linuxtv.org/media_build.git/

And thanks for sharing!

> Can you show that line and the surrounding lines? I.e. the whole menu
> entry?

Of course, here it is:

if STAGING
menu "Media devices in staging"

config STAGING_BROKEN
bool "Enable drivers that are known to not compile"
default n
--- help ---
 Say N here, except if you will be fixing the drivers
 compilation.

menuconfig STAGING_MEDIA

> Most likely because the media build you use is outdated.

I cloned the latest repository and build it, all went fine, however.. (read on)

> Which driver?

This is my device:

02:00.0 Multimedia controller: Digital Devices GmbH Octopus DVB Adapter
Subsystem: Digital Devices GmbH Cine CT V6.1 DVB adapter
Flags: bus master, fast devsel, latency 0, IRQ 32
Memory at fbcf (64-bit, non-prefetchable) [size=64K]
Capabilities: [50] Power Management version 3
Capabilities: [70] MSI: Enable+ Count=1/2 Maskable- 64bit+
Capabilities: [90] Express Endpoint, MSI 00
Capabilities: [100] Vendor Specific Information: ID= Rev=0 Len=00c 
Kernel driver in use: ddbridge
Kernel modules: ddbridge

I am using the following modules:

[htpc@htpc ~]$ lsmod | grep dd
tda18212dd 20480  2
stv0367dd  24576  2
ddbridge   90112  29
cxd209920480  1 ddbridge
dvb_core  102400  1 ddbridge

The ddbridge and cxd2099 are in the latest media_build, but the
stv0367dd and tda18212dd are missing (however, the stv0367 and
tda18212 are available). How hard is it to add these two?

Regards,

Martin

> Regards,
>
> Hans
>


[PATCH 6/6] [media] go7007: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/usb/go7007/go7007-v4l2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/go7007/go7007-v4l2.c 
b/drivers/media/usb/go7007/go7007-v4l2.c
index 4eaba0c..ed5ec97 100644
--- a/drivers/media/usb/go7007/go7007-v4l2.c
+++ b/drivers/media/usb/go7007/go7007-v4l2.c
@@ -792,14 +792,13 @@ static int vidioc_subscribe_event(struct v4l2_fh *fh,
 {
 
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/* Allow for up to 30 events (1 second for NTSC) to be
 * stored. */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 
-- 
2.9.3



[PATCH 3/6] [media] solo6x10: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move the function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
index 25a2137..25f9f2e 100644
--- a/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/media/pci/solo6x10/solo6x10-v4l2-enc.c
@@ -1140,14 +1140,13 @@ static int solo_subscribe_event(struct v4l2_fh *fh,
 {
 
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/* Allow for up to 30 events (1 second for NTSC) to be
 * stored. */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 static const struct v4l2_file_operations solo_enc_fops = {
-- 
2.9.3



[PATCH 2/6] [media] ivtv: improve subscribe_event handling

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

Simplify logic and call v4l2_ctrl_subscribe_event() directly instead
of copying its content over to ivtv_subscribe_event().

Signed-off-by: Gustavo Padovan 
---
 drivers/media/pci/ivtv/ivtv-ioctl.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtv-ioctl.c 
b/drivers/media/pci/ivtv/ivtv-ioctl.c
index f956188..670462d 100644
--- a/drivers/media/pci/ivtv/ivtv-ioctl.c
+++ b/drivers/media/pci/ivtv/ivtv-ioctl.c
@@ -1506,10 +1506,8 @@ static int ivtv_subscribe_event(struct v4l2_fh *fh, 
const struct v4l2_event_subs
case V4L2_EVENT_VSYNC:
case V4L2_EVENT_EOS:
return v4l2_event_subscribe(fh, sub, 0, NULL);
-   case V4L2_EVENT_CTRL:
-   return v4l2_event_subscribe(fh, sub, 0, _ctrl_sub_ev_ops);
default:
-   return -EINVAL;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
 }
 
-- 
2.9.3



[PATCH 1/6] [media] vb2: only check ret if we assigned it

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

Move the ret check to the right level under if (pb). It is not
used by the code before that point if pb is NULL.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/v4l2-core/videobuf2-core.c | 14 --
 1 file changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index 7c1d390..94afbbf9 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -984,11 +984,12 @@ static int __qbuf_userptr(struct vb2_buffer *vb, const 
void *pb)
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, planes);
-   if (ret)
-   return ret;
+   if (ret)
+   return ret;
+   }
 
for (plane = 0; plane < vb->num_planes; ++plane) {
/* Skip the plane if already verified */
@@ -1101,11 +1102,12 @@ static int __qbuf_dmabuf(struct vb2_buffer *vb, const 
void *pb)
 
memset(planes, 0, sizeof(planes[0]) * vb->num_planes);
/* Copy relevant information provided by the userspace */
-   if (pb)
+   if (pb) {
ret = call_bufop(vb->vb2_queue, fill_vb2_buffer,
 vb, pb, planes);
-   if (ret)
-   return ret;
+   if (ret)
+   return ret;
+   }
 
for (plane = 0; plane < vb->num_planes; ++plane) {
struct dma_buf *dbuf = dma_buf_get(planes[plane].m.fd);
-- 
2.9.3



[PATCH 4/6] [media] tw5864: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this function to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/pci/tw5864/tw5864-video.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw5864/tw5864-video.c 
b/drivers/media/pci/tw5864/tw5864-video.c
index 9421216..6d5ed8e 100644
--- a/drivers/media/pci/tw5864/tw5864-video.c
+++ b/drivers/media/pci/tw5864/tw5864-video.c
@@ -664,15 +664,14 @@ static int tw5864_subscribe_event(struct v4l2_fh *fh,
  const struct v4l2_event_subscription *sub)
 {
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_MOTION_DET:
/*
 * Allow for up to 30 events (1 second for NTSC) to be stored.
 */
return v4l2_event_subscribe(fh, sub, 30, NULL);
+   default:
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
-   return -EINVAL;
 }
 
 static void tw5864_frame_interval_set(struct tw5864_input *input)
-- 
2.9.3



[PATCH 5/6] [media] vivid: improve subscribe event handling

2017-02-15 Thread Gustavo Padovan
From: Gustavo Padovan 

We already check for the V4L2_EVENT_CTRL inside
v4l2_ctrl_subscribe_event() so just move this fuction to the default:
branch of the switch and let it does the job for us.

Signed-off-by: Gustavo Padovan 
---
 drivers/media/platform/vivid/vivid-vid-out.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/platform/vivid/vivid-vid-out.c 
b/drivers/media/platform/vivid/vivid-vid-out.c
index 7ba52ee..1a33730 100644
--- a/drivers/media/platform/vivid/vivid-vid-out.c
+++ b/drivers/media/platform/vivid/vivid-vid-out.c
@@ -1172,14 +1172,12 @@ int vidioc_subscribe_event(struct v4l2_fh *fh,
const struct v4l2_event_subscription *sub)
 {
switch (sub->type) {
-   case V4L2_EVENT_CTRL:
-   return v4l2_ctrl_subscribe_event(fh, sub);
case V4L2_EVENT_SOURCE_CHANGE:
if (fh->vdev->vfl_dir == VFL_DIR_RX)
return v4l2_src_change_event_subscribe(fh, sub);
break;
default:
-   break;
+   return v4l2_ctrl_subscribe_event(fh, sub);
}
return -EINVAL;
 }
-- 
2.9.3



Re: [xawtv3] Request: Support for FM RDS

2017-02-15 Thread Markus Rechberger
Hi,

On Wed, Feb 15, 2017 at 5:28 PM, Devin Heitmueller
 wrote:
> Hi George,
>
> The big problem is that almost none of the hardware tuners out there
> which support FM have support for RDS.  You generally need an extra
> chip, and very few devices have it (IIRC, none of the ones that are
> supported in Linux have been available in retail for a number of
> years).
>

Sundtek MediaTV Pro has support for RDS and we also manufacture
dedicated radio units from time to time.

Best Regards,
Markus Rechberger

> Don't get me wrong - I would like to see RDS supported as well - but I
> couldn't find a single tuner product shipping in retail that supports
> it.
>
> In short, it's a hardware limitation, not a problem with the
> linux-media driver stack.
>
> Devin
>
> On Wed, Feb 15, 2017 at 11:07 AM, George Pojar  wrote:
>> FM RDS would be a great feature in radio console application. It would
>> be nice to see what the name of the song is that is playing (that is,
>> if the station supports RDS).
>
>
>
> --
> Devin J. Heitmueller - Kernel Labs
> http://www.kernellabs.com


Re: [PATCH] staging:bcm2048 : Add parentheses around variable x

2017-02-15 Thread Tabrez Khan
On Fri, Feb 3, 2017 at 3:42 PM, Dan Carpenter  wrote:
> On Sat, Dec 03, 2016 at 03:14:26PM +0530, Tabrez khan wrote:
>> Add parentheses around variable x for the readability purpose.
>>
>
> It's not really about readability...
>
> regards,
> dan carpenter
>
 I will resend it again.

-- 
Regards
Tabrez Khan


Re: [PATCH v3 6/7] dt-bindings: media: Add Renesas R-Car DRIF binding

2017-02-15 Thread Rob Herring
On Tue, Feb 07, 2017 at 03:02:36PM +, Ramesh Shanmugasundaram wrote:
> Add binding documentation for Renesas R-Car Digital Radio Interface
> (DRIF) controller.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
>  .../devicetree/bindings/media/renesas,drif.txt | 186 
> +
>  1 file changed, 186 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/renesas,drif.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/renesas,drif.txt 
> b/Documentation/devicetree/bindings/media/renesas,drif.txt
> new file mode 100644
> index 000..6315609
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/renesas,drif.txt
> @@ -0,0 +1,186 @@
> +Renesas R-Car Gen3 Digital Radio Interface controller (DRIF)
> +
> +
> +R-Car Gen3 DRIF is a SPI like receive only slave device. A general
> +representation of DRIF interfacing with a master device is shown below.
> +
> ++-++-+
> +| |-SCK--->|CLK  |
> +|   Master|-SS>|SYNC  DRIFn (slave)  |
> +| |-SD0--->|D0   |
> +| |-SD1--->|D1   |
> ++-++-+
> +
> +As per the datasheet, each DRIF channel (drifn) is made up of two internal
> +channels (drifn0 & drifn1). These two internal channels share the common
> +CLK & SYNC. Each internal channel has its own dedicated resources like
> +irq, dma channels, address space & clock. This internal split is not
> +visible to the external master device.
> +
> +The device tree model represents each internal channel as a separate node.
> +The internal channels sharing the CLK & SYNC are tied together by their
> +phandles using a new property called "renesas,bonding". For the rest of
> +the documentation, unless explicitly stated, the word channel implies an
> +internal channel.
> +
> +When both internal channels are enabled they need to be managed together
> +as one (i.e.) they cannot operate alone as independent devices. Out of the
> +two, one of them needs to act as a primary device that accepts common
> +properties of both the internal channels. This channel is identified by a
> +new property called "renesas,primary-bond".
> +
> +To summarize,
> +   - When both the internal channels that are bonded together are enabled,
> + the zeroth channel is selected as primary-bond. This channels accepts
> + properties common to all the members of the bond.
> +   - When only one of the bonded channels need to be enabled, the property
> + "renesas,bonding" or "renesas,primary-bond" will have no effect. That
> + enabled channel can act alone as any other independent device.
> +
> +Required properties of an internal channel:
> +---
> +- compatible: "renesas,r8a7795-drif" if DRIF controller is a part of R8A7795 
> SoC.
> +   "renesas,rcar-gen3-drif" for a generic R-Car Gen3 compatible 
> device.
> +   When compatible with the generic version, nodes must list the
> +   SoC-specific version corresponding to the platform first
> +   followed by the generic version.
> +- reg: offset and length of that channel.
> +- interrupts: associated with that channel.
> +- clocks: phandle and clock specifier of that channel.
> +- clock-names: clock input name string: "fck".
> +- dmas: phandles to the DMA channels.
> +- dma-names: names of the DMA channel: "rx".
> +- renesas,bonding: phandle to the other channel.
> +
> +Optional properties of an internal channel:
> +---
> +- power-domains: phandle to the respective power domain.
> +
> +Required properties of an internal channel when:
> + - It is the only enabled channel of the bond (or)
> + - If it acts as primary among enabled bonds
> +
> +- pinctrl-0: pin control group to be used for this channel.
> +- pinctrl-names: must be "default".
> +- renesas,primary-bond: empty property indicating the channel acts as primary
> + among the bonded channels.
> +- port: child port node of a channel that defines the local and remote
> + endpoints. The remote endpoint is assumed to be a third party tuner
> + device endpoint.
> +
> +Optional endpoint property:
> +---
> +- renesas,sync-active  : Indicates sync signal polarity, 0/1 for low/high
> +  respectively. This property maps to SYNCAC bit in the
> +  hardware manual. The default is 1 (active high)

Why does this belong in the endpoint? I'd prefer to not have vendor 
specific properties in endpoints. Is this a property of the tuner or 
DRIF? 

> +
> +Example
> +
> +
> +SoC 

Re: [PATCH] omap3isp: add support for CSI1 bus

2017-02-15 Thread Pavel Machek
On Wed 2017-02-15 17:57:46, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Feb 15, 2017 at 11:23:01AM +0100, Pavel Machek wrote:
> > It seems csiphy_routing_cfg_3430 is not called at all. I added
> > printks, but they don't trigger. If you have an idea what is going on
> > there, it would help...
> 
> You added printk to csiphy_routing_cfg_3630 instead of csiphy_routing_cfg_3430
> and N900 has OMAP3430. Function should be called when you start (or
> stop) using the camera:
> 
> csiphy_routing_cfg_3430(...)
> csiphy_routing_cfg(...)
> omap3isp_csiphy_config(...)
> omap3isp_csiphy_acquire(...) & omap3isp_csiphy_release(...)
> ccp2_s_stream(...)

Take another look, I believe I added printk to both of them.

Thanks for the expected backtrace, that should help figuring it out.

> -- Sebastian
> 
> > diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
> > b/drivers/media/platform/omap3isp/ispcsiphy.c
> > index 6b814e1..fe9303a 100644
> > --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> > +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> > @@ -30,6 +30,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy 
> > *phy,
> > u32 reg;
> > u32 shift, mode;
> >  
> > +   printk("routing cfg 3630: iface %d, %d\n", iface, 
> > ISP_INTERFACE_CCP2B_PHY1);
> > +   
> > regmap_read(phy->isp->syscon, phy->isp->syscon_offset, );
> >  
> > switch (iface) {
> > @@ -74,6 +76,9 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy 
> > *phy, u32 iface, bool on,
> > u32 csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
> > | OMAP343X_CONTROL_CSIRXFE_RESET;
> >  
> > +   /* FIXME: can this be used instead of if (isp->revision) in ispccp2.c? 
> > */
> > +   
> > +   printk("routing cfg: iface %d, %d\n", iface, ISP_INTERFACE_CCP2B_PHY1);
> > /* Only the CCP2B on PHY1 is configurable. */
> > if (iface != ISP_INTERFACE_CCP2B_PHY1)
> > return;
> > @@ -105,6 +110,7 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
> >enum isp_interface_type iface, bool on,
> >bool ccp2_strobe)
> >  {
> > +   printk("csiphy_routing_cfg\n");
> > if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
> > return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
> > if (phy->isp->phy_type == ISP_PHY_TYPE_3430)



-- 
(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 v3 2/7] dt-bindings: media: Add MAX2175 binding description

2017-02-15 Thread Rob Herring
On Tue, Feb 07, 2017 at 03:02:32PM +, Ramesh Shanmugasundaram wrote:
> Add device tree binding documentation for MAX2175 Rf to bits tuner
> device.
> 
> Signed-off-by: Ramesh Shanmugasundaram 
> 
> ---
>  .../devicetree/bindings/media/i2c/max2175.txt  | 61 
> ++
>  .../devicetree/bindings/property-units.txt |  1 +
>  2 files changed, 62 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/max2175.txt

Acked-by: Rob Herring 


Re: [PATCH] omap3isp: add support for CSI1 bus

2017-02-15 Thread Sebastian Reichel
Hi,

On Wed, Feb 15, 2017 at 11:23:01AM +0100, Pavel Machek wrote:
> It seems csiphy_routing_cfg_3430 is not called at all. I added
> printks, but they don't trigger. If you have an idea what is going on
> there, it would help...

You added printk to csiphy_routing_cfg_3630 instead of csiphy_routing_cfg_3430
and N900 has OMAP3430. Function should be called when you start (or
stop) using the camera:

csiphy_routing_cfg_3430(...)
csiphy_routing_cfg(...)
omap3isp_csiphy_config(...)
omap3isp_csiphy_acquire(...) & omap3isp_csiphy_release(...)
ccp2_s_stream(...)

-- Sebastian

> diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
> b/drivers/media/platform/omap3isp/ispcsiphy.c
> index 6b814e1..fe9303a 100644
> --- a/drivers/media/platform/omap3isp/ispcsiphy.c
> +++ b/drivers/media/platform/omap3isp/ispcsiphy.c
> @@ -30,6 +30,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
>   u32 reg;
>   u32 shift, mode;
>  
> + printk("routing cfg 3630: iface %d, %d\n", iface, 
> ISP_INTERFACE_CCP2B_PHY1);
> + 
>   regmap_read(phy->isp->syscon, phy->isp->syscon_offset, );
>  
>   switch (iface) {
> @@ -74,6 +76,9 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, 
> u32 iface, bool on,
>   u32 csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
>   | OMAP343X_CONTROL_CSIRXFE_RESET;
>  
> + /* FIXME: can this be used instead of if (isp->revision) in ispccp2.c? 
> */
> + 
> + printk("routing cfg: iface %d, %d\n", iface, ISP_INTERFACE_CCP2B_PHY1);
>   /* Only the CCP2B on PHY1 is configurable. */
>   if (iface != ISP_INTERFACE_CCP2B_PHY1)
>   return;
> @@ -105,6 +110,7 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
>  enum isp_interface_type iface, bool on,
>  bool ccp2_strobe)
>  {
> + printk("csiphy_routing_cfg\n");
>   if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
>   return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
>   if (phy->isp->phy_type == ISP_PHY_TYPE_3430)


signature.asc
Description: PGP signature


Re: [xawtv3] Request: Support for FM RDS

2017-02-15 Thread Devin Heitmueller
Hi George,

The big problem is that almost none of the hardware tuners out there
which support FM have support for RDS.  You generally need an extra
chip, and very few devices have it (IIRC, none of the ones that are
supported in Linux have been available in retail for a number of
years).

Don't get me wrong - I would like to see RDS supported as well - but I
couldn't find a single tuner product shipping in retail that supports
it.

In short, it's a hardware limitation, not a problem with the
linux-media driver stack.

Devin

On Wed, Feb 15, 2017 at 11:07 AM, George Pojar  wrote:
> FM RDS would be a great feature in radio console application. It would
> be nice to see what the name of the song is that is playing (that is,
> if the station supports RDS).



-- 
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com


[xawtv3] Request: Support for FM RDS

2017-02-15 Thread George Pojar
FM RDS would be a great feature in radio console application. It would
be nice to see what the name of the song is that is playing (that is,
if the station supports RDS).


[GIT PULL FOR v4.11] RC deadlocks

2017-02-15 Thread Sean Young
Hi Mauro,

Two deadlocks which would be nice to have fixed for v4.11. Both were
introduced by the wakeup changes; I guess that teaches me for working
without lockdep enabled.

Thanks,
Sean

The following changes since commit 9eeb0ed0f30938f31a3d9135a88b9502192c18dd:

  [media] mtk-vcodec: fix build warnings without DEBUG (2017-02-08 12:08:20 
-0200)

are available in the git repository at:

  git://linuxtv.org/syoung/media_tree.git for-v4.11d

for you to fetch changes up to 79522eaacc1bc691b419a1c9006da1e494bba5c6:

  [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes (2017-02-13 
13:21:44 +)


Heiner Kallweit (1):
  [media] rc: nuvoton: fix deadlock in nvt_write_wakeup_codes

Sean Young (1):
  [media] lirc: fix dead lock between open and wakeup_filter

 drivers/media/rc/lirc_dev.c| 4 ++--
 drivers/media/rc/nuvoton-cir.c | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)


Re: [PATCH v2 1/2] Add Documentation for Media Device, Video Device, and Synopsys DW MIPI CSI-2 Host

2017-02-15 Thread Ramiro Oliveira
Hi Rob,

Sorry for the late reply, but I just now found your reply.

Thanks for your feedback.

On 12/19/2016 5:38 PM, Rob Herring wrote:
> On Mon, Dec 12, 2016 at 03:00:35PM +, Ramiro Oliveira wrote:
>> Create device tree bindings documentation for Media and Video Device, as well
>> as the DW MIPI CSI-2 Host.
>>
>> Signed-off-by: Ramiro Oliveira 
>> ---
>>  .../devicetree/bindings/media/snps,dw-mipi-csi.txt |  37 
>>  .../devicetree/bindings/media/snps,plat-ipk.txt| 105 
>> +
>>  2 files changed, 142 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>>  create mode 100644 Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>>
>> diff --git a/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt 
>> b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> new file mode 100644
>> index 000..1caa652
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,dw-mipi-csi.txt
>> @@ -0,0 +1,37 @@
>> +Synopsys DesignWare CSI-2 Host controller
>> +
>> +Description
>> +---
>> +
>> +This HW block is used to receive image coming from an MIPI CSI-2 compatible
>> +camera.
>> +
>> +Required properties:
>> +- compatible: shall be "snps,dw-mipi-csi"
> 
> You don't have to add them, but this will need SoC specific compatible 
> strings. Please add a note to that effect.
> 

I'm not sure what you mean with this, can you give me an example?

>> +- reg   : physical base address and size of the device memory 
>> mapped
>> +  registers;
>> +- interrupts: CSI-2 Host interrupt
>> +- data-lanes: Number of lanes to be used
>> +- output-type   : Core output to be used (IPI-> 0 or IDI->1 or BOTH->2) 
>> These
>> +  values choose which of the Core outputs will be used, it can be Image Data
>> +  Interface or Image Pixel Interface.
> 
> This is output to a parallel camera interface (e.g. an SoC camera 
> subsystem)? 
> 

These are the outpus of the Synopsys CSI-2 Host controller, both parallel like
you said, one (IDI) formatted as the MIPI CSI-2 recommends and the other is a
video stream.

>> +- phys, phy-names: List of one PHY specifier and identifier string (as 
>> defined
>> +  in Documentation/devicetree/bindings/phy/phy-bindings.txt). This PHY is a 
>> MIPI
>> +  DPHY working in RX mode.
> 
> phy-names is pointless when there is only 1.
> 

Ok. I'll remove it

>> +
>> +Optional properties(if in IPI mode):
>> +- ipi-mode  : Mode to be used when in IPI(Camera -> 0 or Automatic -> 1)
>> +  This property defines if the controller will use the video timings 
>> available
>> +  in the video stream or if it will use pre-defined ones.
> 
> "pre-defined" doesn't sound like the same thing as "automatic"?
> 

It shouldn't be automatic, but Controller instead. I'll correct it.

>> +- ipi-color-mode: Bus depth to be used in IPI (48 bits -> 0 or 16 bits -> 1)
>> +  This property defines the width of the IPI bus.
>> +- ipi-auto-flush: Data auto-flush (1 -> Yes or 0 -> No). This property 
>> defines
>> +  if the data is automatically flushed in each vsync or if this process is 
>> done
>> +  manually
>> +- virtual-channel: Virtual channel where data is present when in IPI mode. 
>> This
>> +  property chooses the virtual channel which IPI will use to retrieve the 
>> video
>> +  stream.
> 
> All these properties seem like they should be common properties or are 
> these interfaces something Synopsys specific? Or perhaps the interface 
> is Synopsys specific, but determined by the CSI2 mode?
> 
> I think you need to define graph ports for the IPI and IDI interfaces 
> and the connections. Then perhaps these properties become endpoint 
> properties.
> 

Like I said above, IDI is formatted as recommend by the CSI-2 spec, and IPI is a
video stream, with the standard video signals.

Although you can use both outputs simultaneously, the majority of the setups
will only use one, so I'm not sure that creating graph ports for both is
necessary, but I can do it if you think it's best.

>> +
>> +The per-board settings:
>> + - port sub-node describing a single endpoint connected to the dw-mipi-csi
> 
> Wouldn't the port connect to the camera?
> 

Yes, it should be camera instead

>> +   as described in video-interfaces.txt[1].
>> diff --git a/Documentation/devicetree/bindings/media/snps,plat-ipk.txt 
>> b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> new file mode 100644
>> index 000..50e9279
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/media/snps,plat-ipk.txt
>> @@ -0,0 +1,105 @@
>> +Synopsys DesignWare CSI-2 Host IPK Media Device
>> +
>> +The Synopsys DesignWare CSI-2 Host IPK subsystem comprises of multiple
>> +sub-devices represented by separate device tree nodes. Currently this 
>> includes:
>> +plat-ipk, video-device, and dw-mipi-csi.
>> +
>> +The sub-subdevices are defined as child nodes of the common 'camera' node 
>> which
>> +also 

Re: [regression] dvb_usb_cxusb (was Re: ir-keytable: infinite loops, segfaults)

2017-02-15 Thread Sean Young
On Wed, Feb 08, 2017 at 10:30:30PM +1100, Vincent McIntyre wrote:
> Hi
> 
> I have been working with Sean on figuring out the protocol used by a
> dvico remote.
> I thought the patch he sent was at fault but I backed it out and tried again.
> 
> I've attached a full dmesg but the core of it is when dvb_usb_cxusb
> tries to load:
> 
> [7.858907] WARNING: You are using an experimental version of the
> media stack.
> As the driver is backported to an older kernel, it doesn't 
> offer
> enough quality for its usage in production.
> Use it with care.
>Latest git patches (needed if you report a bug to
> linux-media@vger.kernel.org):
> 47b037a0512d9f8675ec2693bed46c8ea6a884ab [media]
> v4l2-async: failing functions shouldn't have side effects
> 79a2eda80c6dab79790c308d9f50ecd2e5021ba3 [media]
> mantis_dvb: fix some error codes in mantis_dvb_init()
> c2987aaf0c9c2bcb0d4c5902d61473d9aa018a3d [media]
> exynos-gsc: Avoid spamming the log on VIDIOC_TRY_FMT
> [7.861968] dvb_usb_af9035 1-4:1.0: prechip_version=83
> chip_version=02 chip_type=9135
> [7.887476] dvb_usb_cxusb: disagrees about version of symbol

Sorry about not getting back to you sooner, life got in the way. The
problem here is that the dvb-usb-cxusb did not get selected, so it
was not recompiled.

The problem is that DVB_USB_CXUSB Kconfig has this line:
select DVB_SI2168 if MEDIA_SUBDRV_AUTOSELECT
The make_kconfig.pl script transforms this into a dependency, but 
DVB_SI2168 is only available when compiling against kernel 4.7 or later. 
I think only one select line needs to match, so I created this patch.

Please apply this patch against media_build, you might need to do make
clean before building again.

Thanks,

Sean


From: Sean Young 
Date: Wed, 15 Feb 2017 14:58:00 +
Subject: [PATCH] only one select Kconfig needs to match

---
 v4l/scripts/make_kconfig.pl | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl
index ba8c134..a11f820 100755
--- a/v4l/scripts/make_kconfig.pl
+++ b/v4l/scripts/make_kconfig.pl
@@ -169,6 +169,7 @@ sub depends($$)
push @{$depends{$key}}, $deps;
 }
 
+my %selectdepends = ();
 sub selects($$$)
 {
my $key = shift;
@@ -181,7 +182,7 @@ sub selects($$$)
# Transform "select X if Y" into "depends on !Y || X"
$select = "!($if) || ($select)";
}
-   push @{$depends{$key}}, $select;
+   push @{$selectdepends{$key}}, $select;
 }
 
 # Needs:
@@ -228,6 +229,23 @@ sub checkdeps()
return 0;
}
}
+   my $selectdeps = $selectdepends{$key};
+   if ($selectdeps) {
+   my $found = 0;
+   foreach (@$selectdeps) {
+   next if($_ eq '');
+   if (eval(toperl($_))) {
+   $found = 1;
+   last;
+   }
+   }
+   if ($found == 0) {
+   print "Disabling $key, select dependency '$_' 
not met\n" if $debug;
+   $allconfig{$key} = 0;
+   return 0;
+   }
+   }
+
return 1;
}
 
-- 
2.7.4



Re: [PATCH v1.1 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

2017-02-15 Thread Benoit Parrot

For: ov2569.c, am437x/am437x-vpfe.c and ti-cal/cal.c:

Acked-by: Benoit Parrot 


Sakari Ailus  wrote on Tue [2017-Feb-14 09:12:32 
+0200]:
> Switch users of the v4l2_of_ APIs to the more generic v4l2_fwnode_ APIs.
> 
> Existing OF matching continues to be supported. omap3isp and smiapp
> drivers are converted to fwnode matching as well.
> 
> Signed-off-by: Sakari Ailus 
> ---
> Resending because of a mis-copied e-mail address.
> 
>  drivers/media/i2c/Kconfig  |  9 
>  drivers/media/i2c/adv7604.c|  7 +--
>  drivers/media/i2c/mt9v032.c|  7 +--
>  drivers/media/i2c/ov2659.c |  8 +--
>  drivers/media/i2c/s5c73m3/s5c73m3-core.c   |  7 +--
>  drivers/media/i2c/s5k5baf.c|  6 +--
>  drivers/media/i2c/smiapp/Kconfig   |  1 +
>  drivers/media/i2c/smiapp/smiapp-core.c | 29 ++-
>  drivers/media/i2c/tc358743.c   | 11 ++--
>  drivers/media/i2c/tvp514x.c|  6 +--
>  drivers/media/i2c/tvp5150.c|  7 +--
>  drivers/media/i2c/tvp7002.c|  6 +--
>  drivers/media/platform/Kconfig |  3 ++
>  drivers/media/platform/am437x/Kconfig  |  1 +
>  drivers/media/platform/am437x/am437x-vpfe.c|  8 +--
>  drivers/media/platform/atmel/Kconfig   |  1 +
>  drivers/media/platform/atmel/atmel-isc.c   |  8 +--
>  drivers/media/platform/exynos4-is/Kconfig  |  2 +
>  drivers/media/platform/exynos4-is/media-dev.c  |  6 +--
>  drivers/media/platform/exynos4-is/mipi-csis.c  |  6 +--
>  drivers/media/platform/omap3isp/isp.c  | 71 
> +-
>  drivers/media/platform/pxa_camera.c|  7 +--
>  drivers/media/platform/rcar-vin/Kconfig|  1 +
>  drivers/media/platform/rcar-vin/rcar-core.c|  6 +--
>  drivers/media/platform/soc_camera/Kconfig  |  1 +
>  drivers/media/platform/soc_camera/atmel-isi.c  |  7 +--
>  drivers/media/platform/soc_camera/soc_camera.c |  2 +-
>  drivers/media/platform/ti-vpe/cal.c| 11 ++--
>  drivers/media/platform/xilinx/Kconfig  |  1 +
>  drivers/media/platform/xilinx/xilinx-vipp.c| 59 +++--
>  include/media/v4l2-fwnode.h|  4 +-
>  31 files changed, 175 insertions(+), 134 deletions(-)
> 
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index cee1dae..6b2423a 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -210,6 +210,7 @@ config VIDEO_ADV7604
>   depends on GPIOLIB || COMPILE_TEST
>   select HDMI
>   select MEDIA_CEC_EDID
> + select V4L2_FWNODE
>   ---help---
> Support for the Analog Devices ADV7604 video decoder.
>  
> @@ -324,6 +325,7 @@ config VIDEO_TC358743
>   tristate "Toshiba TC358743 decoder"
>   depends on VIDEO_V4L2 && I2C && VIDEO_V4L2_SUBDEV_API
>   select HDMI
> + select V4L2_FWNODE
>   ---help---
> Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge.
>  
> @@ -333,6 +335,7 @@ config VIDEO_TC358743
>  config VIDEO_TVP514X
>   tristate "Texas Instruments TVP514x video decoder"
>   depends on VIDEO_V4L2 && I2C
> + select V4L2_FWNODE
>   ---help---
> This is a Video4Linux2 sensor-level driver for the TI TVP5146/47
> decoder. It is currently working with the TI OMAP3 camera
> @@ -344,6 +347,7 @@ config VIDEO_TVP514X
>  config VIDEO_TVP5150
>   tristate "Texas Instruments TVP5150 video decoder"
>   depends on VIDEO_V4L2 && I2C
> + select V4L2_FWNODE
>   ---help---
> Support for the Texas Instruments TVP5150 video decoder.
>  
> @@ -353,6 +357,7 @@ config VIDEO_TVP5150
>  config VIDEO_TVP7002
>   tristate "Texas Instruments TVP7002 video decoder"
>   depends on VIDEO_V4L2 && I2C
> + select V4L2_FWNODE
>   ---help---
> Support for the Texas Instruments TVP7002 video decoder.
>  
> @@ -524,6 +529,7 @@ config VIDEO_OV2659
>   tristate "OmniVision OV2659 sensor support"
>   depends on VIDEO_V4L2 && I2C
>   depends on MEDIA_CAMERA_SUPPORT
> + select V4L2_FWNODE
>   ---help---
> This is a Video4Linux2 sensor-level driver for the OmniVision
> OV2659 camera.
> @@ -616,6 +622,7 @@ config VIDEO_MT9V032
>   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
>   depends on MEDIA_CAMERA_SUPPORT
>   select REGMAP_I2C
> + select V4L2_FWNODE
>   ---help---
> This is a Video4Linux2 sensor-level driver for the Micron
> MT9V032 752x480 CMOS sensor.
> @@ -663,6 +670,7 @@ config VIDEO_S5K4ECGX
>  config VIDEO_S5K5BAF
>   tristate "Samsung S5K5BAF sensor support"
>   depends on I2C && VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API
> + select V4L2_FWNODE
>   ---help---
> This is a V4L2 sensor-level driver for Samsung S5K5BAF 2M
> 

Re: Bug#854100: libdvbv5-0: fails to tune / scan

2017-02-15 Thread Mauro Carvalho Chehab
Em Wed, 15 Feb 2017 11:13:18 -0200
Mauro Carvalho Chehab  escreveu:

> Hi Gregor,
> 
> Em Mon, 13 Feb 2017 08:04:48 -0200
> Mauro Carvalho Chehab  escreveu:
> 
> > Em Fri, 10 Feb 2017 22:02:01 +0100
> > Gregor Jasny  escreveu:
> > 
> > > Hello Mauro & DVB-S maintainers,
> > > 
> > > could you please have a look at the bug report below? Marcel was so kind
> > > to bisect the problem to the following commit:
> > > 
> > > https://git.linuxtv.org/v4l-utils.git/commit/?id=d982b0d03b1f929269104bb716c9d4b50c945125
> > 
> > Sorry for not handling it earlier. I took vacations on Jan, and had a pile
> > of patches to handle after my return. I had to priorize them, as we're
> > close to a Kernel merge window.
> > 
> > Now that Linus postponed the merge window, I had some time to dig into
> > it.
> > 
> > > 
> > > Bug report against libdvbv5 is here:
> > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854100
> > 
> > There was a bug at the logic that was checking if the frequency was
> > at the range of the local oscillators. This patch should be addressing
> > it:
> > 
> > https://git.linuxtv.org/v4l-utils.git/commit/?id=5380ad44de416a41b4972e8a9c147ce42b0e3ba0
> > 
> > With that, the logic now seems to be working fine:
> > 
> > $ ./utils/dvb/dvbv5-scan ~/Intelsat-34 --lnbf universal -vv
> > Using LNBf UNIVERSAL
> > Universal, Europe
> > 10800 to 11800 MHz, LO: 9750 MHz
> > 11600 to 12700 MHz, LO: 10600 MHz
> > ...
> > Seeking for LO for 12.17 MHz frequency
> > LO setting 0: 10.80 MHz to 11.80 MHz
> > LO setting 1: 11.60 MHz to 12.70 MHz
> > Multi-LO LNBf. using LO setting 1 at 10600.00 MHz
> > frequency: 12170.00 MHz, high_band: 1
> > L-Band frequency: 1570.00 MHz (offset = 10600.00 MHz)
> > 
> > I can't really test it here, as my satellite dish uses a different
> > type of LNBf, but, from the above logs, the bug should be fixed.
> > 
> > Marcel,
> > 
> > Could you please test? The patch is already upstream.
> > I added a debug patch after it, in order to help LNBf issues
> > (enabled by using "-vv" command line parameters).
> 
> I added both patches to stable-1.12 branch. I also added a small
> patch there adding support for an extra LNBf model at the DVB
> Satellite table. Such change is not disruptive, as it just
> adds a new element on an already-existing table.
> 
> Btw, I found another bug there. Starting to look on it right now.
> 
> There's something wrong with translations there. It seems that
> something is causing i18n to print its headers instead of doing
> the right thing. 
> 
> I'm enclosing the results at the end of this e-mail, with 
> pt_BR translation, with is currently the only one available.
> 
> I think you should wait for this bug to get fixed before releasing
> a new -stable release.

Bug fixed and pushed to stable-1.12 directory. I also updated
there the pt_BR translation for libdvbv5.

-- 
Thanks,
Mauro


Re: [Patch 2/2] media: ti-vpe: vpe: allow use of user specified stride

2017-02-15 Thread Benoit Parrot
Tomi Valkeinen  wrote on Wed [2017-Feb-15 13:22:42 
+0200]:
> Hi,
> 
> On 13/02/17 15:06, Benoit Parrot wrote:
> > Bytesperline/stride was always overwritten by VPE to the most
> > adequate value based on needed alignment.
> > 
> > However in order to make use of arbitrary size DMA buffer it
> > is better to use the user space provide stride instead.
> > 
> > The driver will still calculate an appropriate stride but will
> > use the provided one when it is larger than the calculated one.
> > 
> > Signed-off-by: Benoit Parrot 
> > ---
> >  drivers/media/platform/ti-vpe/vpe.c | 28 
> >  1 file changed, 20 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> > b/drivers/media/platform/ti-vpe/vpe.c
> > index 2dd67232b3bc..c47151495b6f 100644
> > --- a/drivers/media/platform/ti-vpe/vpe.c
> > +++ b/drivers/media/platform/ti-vpe/vpe.c
> > @@ -1597,6 +1597,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
> > v4l2_format *f,
> > struct v4l2_plane_pix_format *plane_fmt;
> > unsigned int w_align;
> > int i, depth, depth_bytes, height;
> > +   unsigned int stride = 0;
> >  
> > if (!fmt || !(fmt->types & type)) {
> > vpe_err(ctx->dev, "Fourcc format (0x%08x) invalid.\n",
> > @@ -1683,16 +1684,27 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, 
> > struct v4l2_format *f,
> > plane_fmt = >plane_fmt[i];
> > depth = fmt->vpdma_fmt[i]->depth;
> >  
> > -   if (i == VPE_LUMA)
> > -   plane_fmt->bytesperline = (pix->width * depth) >> 3;
> > -   else
> > -   plane_fmt->bytesperline = pix->width;
> > +   stride = (pix->width * fmt->vpdma_fmt[VPE_LUMA]->depth) >> 3;
> > +   if (stride > plane_fmt->bytesperline)
> > +   plane_fmt->bytesperline = stride;
> 
> The old code calculates different bytes per line for luma and chroma,
> but the new one calculates only for luma. Is that correct?

The previous method which happened to produce the correct value was
not proper as the spec for NV12/NV16 states that the chroma bytes per
line/stride should be the same as the LUMA stride only the number of
lines might differ which affect how the sizeimage component is
calculated. This patch takes that into account.

Benoit

> 
>  Tomi
> 





Re: Bug#854100: libdvbv5-0: fails to tune / scan

2017-02-15 Thread Mauro Carvalho Chehab
Hi Gregor,

Em Mon, 13 Feb 2017 08:04:48 -0200
Mauro Carvalho Chehab  escreveu:

> Em Fri, 10 Feb 2017 22:02:01 +0100
> Gregor Jasny  escreveu:
> 
> > Hello Mauro & DVB-S maintainers,
> > 
> > could you please have a look at the bug report below? Marcel was so kind
> > to bisect the problem to the following commit:
> > 
> > https://git.linuxtv.org/v4l-utils.git/commit/?id=d982b0d03b1f929269104bb716c9d4b50c945125
> 
> Sorry for not handling it earlier. I took vacations on Jan, and had a pile
> of patches to handle after my return. I had to priorize them, as we're
> close to a Kernel merge window.
> 
> Now that Linus postponed the merge window, I had some time to dig into
> it.
> 
> > 
> > Bug report against libdvbv5 is here:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854100
> 
> There was a bug at the logic that was checking if the frequency was
> at the range of the local oscillators. This patch should be addressing
> it:
>   
> https://git.linuxtv.org/v4l-utils.git/commit/?id=5380ad44de416a41b4972e8a9c147ce42b0e3ba0
> 
> With that, the logic now seems to be working fine:
> 
> $ ./utils/dvb/dvbv5-scan ~/Intelsat-34 --lnbf universal -vv
> Using LNBf UNIVERSAL
>   Universal, Europe
>   10800 to 11800 MHz, LO: 9750 MHz
>   11600 to 12700 MHz, LO: 10600 MHz
> ...
> Seeking for LO for 12.17 MHz frequency
> LO setting 0: 10.80 MHz to 11.80 MHz
> LO setting 1: 11.60 MHz to 12.70 MHz
> Multi-LO LNBf. using LO setting 1 at 10600.00 MHz
> frequency: 12170.00 MHz, high_band: 1
> L-Band frequency: 1570.00 MHz (offset = 10600.00 MHz)
> 
> I can't really test it here, as my satellite dish uses a different
> type of LNBf, but, from the above logs, the bug should be fixed.
> 
> Marcel,
> 
> Could you please test? The patch is already upstream.
> I added a debug patch after it, in order to help LNBf issues
> (enabled by using "-vv" command line parameters).

I added both patches to stable-1.12 branch. I also added a small
patch there adding support for an extra LNBf model at the DVB
Satellite table. Such change is not disruptive, as it just
adds a new element on an already-existing table.

Btw, I found another bug there. Starting to look on it right now.

There's something wrong with translations there. It seems that
something is causing i18n to print its headers instead of doing
the right thing. 

I'm enclosing the results at the end of this e-mail, with 
pt_BR translation, with is currently the only one available.

I think you should wait for this bug to get fixed before releasing
a new -stable release.

Thanks,
Mauro

---

$ LANG=pt_BR.utf8 dvbv5-scan -l
Por favor selecione o modelo do LNBf  abaixo:
UNIVERSAL
Universal, Europe
Project-Id-Version: libdvbv5 1.7.0
Report-Msgid-Bugs-To: linux-media@vger.Kernel.org
POT-Creation-Date: 2016-01-24 08:42+0100
PO-Revision-Date: 2015-05-13 19:33-0300
Last-Translator: Mauro Carvalho Chehab 
Language-Team: Brazilian Portuguese
Language: pt_BR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Plural-Forms: nplurals=2; plural=(n > 1);
X-Generator: Poedit 1.7.5
X-Poedit-KeywordsList: _;N_
X-Poedit-Basepath: ../
X-Poedit-SourceCharset: UTF-8
X-Poedit-SearchPath-0: lib/libdvbv5
10800 to 11800 MHz, LO: 9750 MHz
Project-Id-Version: libdvbv5 1.7.0
Report-Msgid-Bugs-To: linux-media@vger.Kernel.org
POT-Creation-Date: 2016-01-24 08:42+0100
PO-Revision-Date: 2015-05-13 19:33-0300
Last-Translator: Mauro Carvalho Chehab 
Language-Team: Brazilian Portuguese
Language: pt_BR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Plural-Forms: nplurals=2; plural=(n > 1);
X-Generator: Poedit 1.7.5
X-Poedit-KeywordsList: _;N_
X-Poedit-Basepath: ../
X-Poedit-SourceCharset: UTF-8
X-Poedit-SearchPath-0: lib/libdvbv5
11600 to 12700 MHz, LO: 10600 MHz

DBS
Expressvu, North America
Project-Id-Version: libdvbv5 1.7.0
Report-Msgid-Bugs-To: linux-media@vger.Kernel.org
POT-Creation-Date: 2016-01-24 08:42+0100
PO-Revision-Date: 2015-05-13 19:33-0300
Last-Translator: Mauro Carvalho Chehab 
Language-Team: Brazilian Portuguese
Language: pt_BR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Plural-Forms: nplurals=2; plural=(n > 1);
X-Generator: Poedit 1.7.5
X-Poedit-KeywordsList: _;N_
X-Poedit-Basepath: ../
X-Poedit-SourceCharset: UTF-8
X-Poedit-SearchPath-0: lib/libdvbv5
12200 to 12700 MHz, LO: 11250 MHz

EXTENDED
Astra 1E, European Universal Ku (extended)
Project-Id-Version: libdvbv5 1.7.0
Report-Msgid-Bugs-To: linux-media@vger.Kernel.org
POT-Creation-Date: 2016-01-24 08:42+0100
PO-Revision-Date: 2015-05-13 19:33-0300
Last-Translator: Mauro Carvalho Chehab 
Language-Team: Brazilian Portuguese
Language: pt_BR
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Re: [patch] staging: bcm2835-camera: free first element in array

2017-02-15 Thread walter harms


Am 15.02.2017 13:25, schrieb Dan Carpenter:
> We should free gdev[0] so the > should be >=.
> 
> Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
> driver.")
> Signed-off-by: Dan Carpenter 
> 
> diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
> b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> index ca15a698e018..9bcd8e546a14 100644
> --- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> +++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
> @@ -1998,7 +1998,7 @@ static int __init bm2835_mmal_init(void)
>  free_dev:
>   kfree(dev);
>  
> - for ( ; camera > 0; camera--) {
> + for ( ; camera >= 0; camera--) {
>   bcm2835_cleanup_instance(gdev[camera]);
>   gdev[camera] = NULL;
>   }

since we already know that programmers are bad in counting backwards ...

is is possible to change that into std. loop like:

 for(i=0, i< camera; i++ {
bcm2835_cleanup_instance(gdev[i]);
gdev[i] = NULL;
}

this is way a much more common pattern.


just my 2 cents,
re,
 wh



[patch] staging: bcm2835-camera: free first element in array

2017-02-15 Thread Dan Carpenter
We should free gdev[0] so the > should be >=.

Fixes: 7b3ad5abf027 ("staging: Import the BCM2835 MMAL-based V4L2 camera 
driver.")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c 
b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
index ca15a698e018..9bcd8e546a14 100644
--- a/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
+++ b/drivers/staging/media/platform/bcm2835/bcm2835-camera.c
@@ -1998,7 +1998,7 @@ static int __init bm2835_mmal_init(void)
 free_dev:
kfree(dev);
 
-   for ( ; camera > 0; camera--) {
+   for ( ; camera >= 0; camera--) {
bcm2835_cleanup_instance(gdev[camera]);
gdev[camera] = NULL;
}


Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

2017-02-15 Thread Mark Brown
On Tue, Feb 14, 2017 at 09:59:55PM +0200, Laurent Pinchart wrote:
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:

> > ADF was probably the best example in this. KMS also took a while until all
> > the fbdev wheels have been properly reinvented (some are still the same old
> > squeaky onces as fbdev had, e.g. fbcon).

> > And I don't think destaging ION is going to be hard, just a bit of
> > work (could be a nice gsoc or whatever).

> Oh, technically speaking, it would be pretty simple. The main issue is to 
> decide whether we want to commit to the existing ION API. I don't :-)

Right, we need to figure out what people should be doing and let them
work on it.  At the minute anyone who wants to use this stuff in
mainline is kind of stuck as attempts to add ION drivers get pushback

   https://lkml.org/lkml/2016/11/7/806

but so do attempts to do something different (there was a statement in
that thread that new ION drivers could be added if we could ever figure
out bindings but I'm not sure there's any prospect of that).  There's no
clear direction for people to follow if they want to make progress.


signature.asc
Description: PGP signature


Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

2017-02-15 Thread Pali Rohár
On Wednesday 15 February 2017 00:05:03 Sakari Ailus wrote:
> Hi Pavel,
> 
> On Tue, Feb 14, 2017 at 02:40:04PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus 
> > 
> > Required added multiplier (and divisor) calculation did not take into
> > account the existing divisor when checking the values against the
> > minimum divisor. Do just that.
> > 
> > Signed-off-by: Sakari Ailus 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> 
> I need to understand again why did I write this patch. :-)
> 
> Could you send me the smiapp driver output with debug level messages
> enabled, please?
> 
> I think the problem was with the secondary sensor.
> 

Hi, search for emails and threads:
Message-Id: <1364719448-29894-1-git-send-email-sakari.ai...@iki.fi>
Message-ID: <5728ed34.3060...@gmail.com>

I think I already resent those information again :-)

-- 
Pali Rohár
pali.ro...@gmail.com


Re: [RFC 08/13] smiapp-pll: Take existing divisor into account in minimum divisor check

2017-02-15 Thread Pavel Machek
On Wed 2017-02-15 00:05:03, Sakari Ailus wrote:
> Hi Pavel,
> 
> On Tue, Feb 14, 2017 at 02:40:04PM +0100, Pavel Machek wrote:
> > From: Sakari Ailus 
> > 
> > Required added multiplier (and divisor) calculation did not take into
> > account the existing divisor when checking the values against the
> > minimum divisor. Do just that.
> > 
> > Signed-off-by: Sakari Ailus 
> > Signed-off-by: Ivaylo Dimitrov 
> > Signed-off-by: Pavel Machek 
> 
> I need to understand again why did I write this patch. :-)

Can you just trust your former self?

> Could you send me the smiapp driver output with debug level messages
> enabled, please?

> I think the problem was with the secondary sensor.

I believe it was with the main sensor, actually. Anyway, here are the
messages.

[0.791290] smiapp 2-0010: could not get clock (-517)
[2.705352] smiapp 2-0010: GPIO lookup for consumer xshutdown
[2.705352] smiapp 2-0010: using device tree for GPIO lookup
[2.705413] smiapp 2-0010: using lookup tables for GPIO lookup
[2.705413] smiapp 2-0010: lookup for GPIO xshutdown failed
[2.875244] smiapp 2-0010: lane_op_clock_ratio: 1
[2.875274] smiapp 2-0010: binning: 1x1
[2.875274] smiapp 2-0010: min / max pre_pll_clk_div: 1 / 4
[2.875305] smiapp 2-0010: pre-pll check: min / max
pre_pll_clk_div: 1 / 1
[2.875305] smiapp 2-0010: mul 25 / div 2
[2.875305] smiapp 2-0010: pll_op check: min / max pre_pll_clk_div:
1 / 1
[2.875335] smiapp 2-0010: pre_pll_clk_div 1
[2.875335] smiapp 2-0010: more_mul_max: max_pll_multiplier check:
1
[2.875335] smiapp 2-0010: more_mul_max: max_pll_op_freq_hz check:
1
[2.875335] smiapp 2-0010: more_mul_max: max_op_sys_clk_div check:
1
[2.875366] smiapp 2-0010: more_mul_max: min_pll_multiplier check:
1
[2.875366] smiapp 2-0010: more_mul_min: min_pll_op_freq_hz check:
1
[2.875366] smiapp 2-0010: more_mul_min: min_pll_multiplier check:
1
[2.875396] smiapp 2-0010: more_mul_factor: 1
[2.875396] smiapp 2-0010: more_mul_factor: min_op_sys_clk_div: 1
[2.875396] smiapp 2-0010: final more_mul: 1
[2.875427] smiapp 2-0010: op_sys_clk_div: 2
[2.875427] smiapp 2-0010: op_pix_clk_div: 10
[2.875427] smiapp 2-0010: pre_pll_clk_div 1
[2.875457] smiapp 2-0010: pll_multiplier  25
[2.875457] smiapp 2-0010: vt_sys_clk_div  2
[2.875457] smiapp 2-0010: vt_pix_clk_div  10
[2.875457] smiapp 2-0010: ext_clk_freq_hz   960
[2.875488] smiapp 2-0010: pll_ip_clk_freq_hz960
[2.875488] smiapp 2-0010: pll_op_clk_freq_hz24000
[2.875488] smiapp 2-0010: vt_sys_clk_freq_hz12000
[2.875518] smiapp 2-0010: vt_pix_clk_freq_hz1200
[2.876068] smiapp 2-0010: lane_op_clock_ratio: 1
[2.876068] smiapp 2-0010: binning: 1x1
[2.876098] smiapp 2-0010: min / max pre_pll_clk_div: 1 / 4
[2.876098] smiapp 2-0010: pre-pll check: min / max
pre_pll_clk_div: 1 / 1
[2.876098] smiapp 2-0010: mul 25 / div 2
[2.876129] smiapp 2-0010: pll_op check: min / max pre_pll_clk_div:
1 / 1
[2.876129] smiapp 2-0010: pre_pll_clk_div 1
[2.876129] smiapp 2-0010: more_mul_max: max_pll_multiplier check:
1
[2.876159] smiapp 2-0010: more_mul_max: max_pll_op_freq_hz check:
1
[2.876159] smiapp 2-0010: more_mul_max: max_op_sys_clk_div check:
1
[2.876159] smiapp 2-0010: more_mul_max: min_pll_multiplier check:
1
[2.876190] smiapp 2-0010: more_mul_min: min_pll_op_freq_hz check:
1
[2.876190] smiapp 2-0010: more_mul_min: min_pll_multiplier check:
1
[2.876190] smiapp 2-0010: more_mul_factor: 1
[2.876190] smiapp 2-0010: more_mul_factor: min_op_sys_clk_div: 1
[2.876220] smiapp 2-0010: final more_mul: 1
[2.876220] smiapp 2-0010: op_sys_clk_div: 2
[2.876220] smiapp 2-0010: op_pix_clk_div: 10
[2.876251] smiapp 2-0010: pre_pll_clk_div 1
[2.876251] smiapp 2-0010: pll_multiplier  25
[2.876251] smiapp 2-0010: vt_sys_clk_div  2
[2.876251] smiapp 2-0010: vt_pix_clk_div  10
[2.876281] smiapp 2-0010: ext_clk_freq_hz   960
[2.876281] smiapp 2-0010: pll_ip_clk_freq_hz960
[2.876281] smiapp 2-0010: pll_op_clk_freq_hz24000
[2.876312] smiapp 2-0010: vt_sys_clk_freq_hz12000
[2.876312] smiapp 2-0010: vt_pix_clk_freq_hz1200
...
[4.728973] udevd[216]: starting version 175
[8.031494] smiapp 2-0010: lane_op_clock_ratio: 1
[8.031524] smiapp 2-0010: binning: 1x1
[8.031524] smiapp 2-0010: min / max pre_pll_clk_div: 1 / 4
[8.031524] smiapp 2-0010: pre-pll check: min / max
pre_pll_clk_div: 1 / 1
[8.031555] smiapp 2-0010: mul 25 / div 2
[8.031555] smiapp 2-0010: pll_op check: min / max pre_pll_clk_div:
1 / 1
[8.031555] smiapp 2-0010: pre_pll_clk_div 1
[8.031585] smiapp 2-0010: more_mul_max: max_pll_multiplier check:
1
[8.031585] smiapp 2-0010: more_mul_max: max_pll_op_freq_hz check:

Re: [Patch 2/2] media: ti-vpe: vpe: allow use of user specified stride

2017-02-15 Thread Tomi Valkeinen
Hi,

On 13/02/17 15:06, Benoit Parrot wrote:
> Bytesperline/stride was always overwritten by VPE to the most
> adequate value based on needed alignment.
> 
> However in order to make use of arbitrary size DMA buffer it
> is better to use the user space provide stride instead.
> 
> The driver will still calculate an appropriate stride but will
> use the provided one when it is larger than the calculated one.
> 
> Signed-off-by: Benoit Parrot 
> ---
>  drivers/media/platform/ti-vpe/vpe.c | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/platform/ti-vpe/vpe.c 
> b/drivers/media/platform/ti-vpe/vpe.c
> index 2dd67232b3bc..c47151495b6f 100644
> --- a/drivers/media/platform/ti-vpe/vpe.c
> +++ b/drivers/media/platform/ti-vpe/vpe.c
> @@ -1597,6 +1597,7 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
> v4l2_format *f,
>   struct v4l2_plane_pix_format *plane_fmt;
>   unsigned int w_align;
>   int i, depth, depth_bytes, height;
> + unsigned int stride = 0;
>  
>   if (!fmt || !(fmt->types & type)) {
>   vpe_err(ctx->dev, "Fourcc format (0x%08x) invalid.\n",
> @@ -1683,16 +1684,27 @@ static int __vpe_try_fmt(struct vpe_ctx *ctx, struct 
> v4l2_format *f,
>   plane_fmt = >plane_fmt[i];
>   depth = fmt->vpdma_fmt[i]->depth;
>  
> - if (i == VPE_LUMA)
> - plane_fmt->bytesperline = (pix->width * depth) >> 3;
> - else
> - plane_fmt->bytesperline = pix->width;
> + stride = (pix->width * fmt->vpdma_fmt[VPE_LUMA]->depth) >> 3;
> + if (stride > plane_fmt->bytesperline)
> + plane_fmt->bytesperline = stride;

The old code calculates different bytes per line for luma and chroma,
but the new one calculates only for luma. Is that correct?

 Tomi



signature.asc
Description: OpenPGP digital signature


Re: [RFC 06/13] v4l2-async: per notifier locking

2017-02-15 Thread Pavel Machek
Hi!

> > From: Sebastian Reichel 
> > 
> > Without this, camera support breaks boot on N900.
> 
> That's kind of vague. I just checked my original patch and it looks
> like I did not bother to write a proper patch description. I suggest
> to make this
> 
> "Fix v4l2-async locking, so that v4l2_async_notifiers can be used
> recursively. This is important for sensors, that are only reachable
> by the image signal processor through some intermediate device."
> 
> You should probably move move this patch directly before the
> video-bus-switch patch, since its a preparation for it.
> 
> Also this is missing my SoB:
> 
> Signed-off-by: Sebastian Reichel 

Thanks, done.
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] smiapp: add CCP2 support

2017-02-15 Thread Pavel Machek
Hi!

> > > I pushed the two DT patches here:
> > > 
> > > 
> > 
> > Thanks for a branch. If you could the two patches that look ok there,
> > it would mean less work for me, I could just mark those two as applied
> > here.
> 
> I think a verb could be missing from the sentence. :-) I'll send a pull
> request for the entire set, containing more than just the DT changes. Feel
> free to base yours on top of this.
> 
> A word of warning: I have patches to replace the V4L2 OF framework by V4L2
> fwnode. The preliminary set (which is still missing V4L2 OF removal) is
> here, I'll post a refresh soon:
> 
> 
> 
> Let's see what the order ends up to be in the end. If the fwnode set is
> applicable first, then I'd like to rebase the lane parsing changes on top of
> that rather than the other way around --- it's easier that way.
> 
> > 
> > Core changes for CSI2 support are needed.
> 
> CCP2? We could get these and the smiapp and possibly also the omap3isp
> patches in first, to avoid having to manage a large patchset. What do you
> think?

Well... anything that reduces the ammount of patches I need to
maintain to keep camera working is welcome.

> > There are core changes in notifier locking, and subdev support.
> > 
> > I need video-bus-switch, at least for testing.
> > 
> > I need subdev support for omap3isp, so that we can attach flash and
> > focus devices.
> > 
> > Finally dts support on N900 can be enabled.
> 
> Yes! 8-)
> 
> I don't know if any euros were saved by using that video bus switch but it
> sure has caused a lot of hassle (and perhaps some gray hair) for software
> engineers. X-)

Yes, switch is one of the problems. OTOH... Nokia did a great thing by
creating phone with reasonable design...

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] omap3isp: add support for CSI1 bus

2017-02-15 Thread Pavel Machek
Hi!

> > +   if (enable) {
> > +   csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ |
> > + OMAP343X_CONTROL_CSIRXFE_RESET;
> > +
> > +   if (buscfg->phy_layer)
> > +   csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
> > +
> > +   if (buscfg->strobe_clk_pol)
> > +   csirxfe |= OMAP343X_CONTROL_CSIRXFE_CSIB_INV;
> > +   } else
> > +   csirxfe = 0;
> 
> You need curly braces for the else statement too.
> 
> > +
> > +   regmap_write(isp->syscon, isp->syscon_offset, csirxfe);
> 
> Isn't this already configured by csiphy_routing_cfg_3430(), called through 
> omap3isp_csiphy_acquire() ? You'll need to add support for the strobe/clock 
> polarity there, but the rest should already be handled.

It seems csiphy_routing_cfg_3430 is not called at all. I added
printks, but they don't trigger. If you have an idea what is going on
there, it would help...
Pavel

diff --git a/drivers/media/platform/omap3isp/ispcsiphy.c 
b/drivers/media/platform/omap3isp/ispcsiphy.c
index 6b814e1..fe9303a 100644
--- a/drivers/media/platform/omap3isp/ispcsiphy.c
+++ b/drivers/media/platform/omap3isp/ispcsiphy.c
@@ -30,6 +30,8 @@ static void csiphy_routing_cfg_3630(struct isp_csiphy *phy,
u32 reg;
u32 shift, mode;
 
+   printk("routing cfg 3630: iface %d, %d\n", iface, 
ISP_INTERFACE_CCP2B_PHY1);
+   
regmap_read(phy->isp->syscon, phy->isp->syscon_offset, );
 
switch (iface) {
@@ -74,6 +76,9 @@ static void csiphy_routing_cfg_3430(struct isp_csiphy *phy, 
u32 iface, bool on,
u32 csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ
| OMAP343X_CONTROL_CSIRXFE_RESET;
 
+   /* FIXME: can this be used instead of if (isp->revision) in ispccp2.c? 
*/
+   
+   printk("routing cfg: iface %d, %d\n", iface, ISP_INTERFACE_CCP2B_PHY1);
/* Only the CCP2B on PHY1 is configurable. */
if (iface != ISP_INTERFACE_CCP2B_PHY1)
return;
@@ -105,6 +110,7 @@ static void csiphy_routing_cfg(struct isp_csiphy *phy,
   enum isp_interface_type iface, bool on,
   bool ccp2_strobe)
 {
+   printk("csiphy_routing_cfg\n");
if (phy->isp->phy_type == ISP_PHY_TYPE_3630 && on)
return csiphy_routing_cfg_3630(phy, iface, ccp2_strobe);
if (phy->isp->phy_type == ISP_PHY_TYPE_3430)



-- 
(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] omap3isp: add support for CSI1 bus

2017-02-15 Thread Pavel Machek
Hi!

> > diff --git a/drivers/media/platform/omap3isp/isp.c
> > b/drivers/media/platform/omap3isp/isp.c index 0321d84..88bc7c6 100644
> > --- a/drivers/media/platform/omap3isp/isp.c
> > +++ b/drivers/media/platform/omap3isp/isp.c
> > @@ -2024,21 +2024,92 @@ enum isp_of_phy {
> > ISP_OF_PHY_CSIPHY2,
> >  };
> > 
> > -static int isp_of_parse_node(struct device *dev, struct device_node *node,
> > -struct isp_async_subdev *isd)
> > +void __isp_of_parse_node_csi1(struct device *dev,
> > +  struct isp_ccp2_cfg *buscfg,
> > +  struct v4l2_of_endpoint *vep)
> 
> This function isn't use anywhere else, you can merge it with 
> isp_of_parse_node_csi1().

I'd prefer not to. First, it will be used separately in future, and
second, expresions would be uglier.

> > +{
> > +   buscfg->lanecfg.clk.pos = vep->bus.mipi_csi1.clock_lane;
> > +   buscfg->lanecfg.clk.pol =
> > +   vep->bus.mipi_csi1.lane_polarity[0];
> > +   dev_dbg(dev, "clock lane polarity %u, pos %u\n",
> > +   buscfg->lanecfg.clk.pol,
> > +   buscfg->lanecfg.clk.pos);
> > +
> > +   buscfg->lanecfg.data[0].pos = vep->bus.mipi_csi2.data_lanes[0];
> > +   buscfg->lanecfg.data[0].pol =
> > +   vep->bus.mipi_csi2.lane_polarities[1];
> 
> bus.mipi_csi2 ?

Good catch. Fixed.

> > -   ret = v4l2_of_parse_endpoint(node, );
> > -   if (ret)
> > -   return ret;
> > +   if (vep->base.port == ISP_OF_PHY_CSIPHY1)
> > +   buscfg->interface = ISP_INTERFACE_CSI2C_PHY1;
> > +   else
> > +   buscfg->interface = ISP_INTERFACE_CSI2A_PHY2;
> 
> I would keep this code in the caller to avoid code duplication with 
> isp_of_parse_node_csi1().

Take a closer look. Code in _csi1 is different.

> > break;
> > 
> > default:
> > +   return -1;
> 
> Please use the appropriate error code.

Ok.

> > +   return 0;
> > +}
> > +
> > +static int isp_of_parse_node_endpoint(struct device *dev,
> > + struct device_node *node,
> > + struct isp_async_subdev *isd)
> > +{
> > +   struct isp_bus_cfg *buscfg;
> > +   struct v4l2_of_endpoint vep;
> > +   int ret;
> > +
> > +   isd->bus = devm_kzalloc(dev, sizeof(*isd->bus), GFP_KERNEL);
> 
> Why do you now need to allocate this manually ?

bus is now a pointer.

> > +   dev_dbg(dev, "parsing endpoint %s, interface %u\n", node->full_name,
> > +   vep.base.port);
> > +
> > +   if (isp_endpoint_to_buscfg(dev, vep, buscfg))
> 
> I'm fine splitting the CSI1/CSI2 parsing code to separate functions, but I 
> don't think there's a need to split isp_endpoint_to_buscfg(). You can keep 
> that part inline.

I'd prefer smaller functions here. I tried to read the original and it
was not too easy.

> > diff --git a/drivers/media/platform/omap3isp/ispccp2.c
> > b/drivers/media/platform/omap3isp/ispccp2.c index ca09523..4edb55a 100644
> > --- a/drivers/media/platform/omap3isp/ispccp2.c
> > +++ b/drivers/media/platform/omap3isp/ispccp2.c
> > @@ -160,6 +163,33 @@ static int ccp2_if_enable(struct isp_ccp2_device *ccp2,
> > u8 enable) return ret;
> > }
> > 
> > +   if (isp->revision == ISP_REVISION_2_0) {
> 
> The isp_csiphy.c code checks phy->isp->phy_type for the same purpose, 
> shouldn't you use that too ?

Do you want me to do phy->isp->phy_type == ISP_PHY_TYPE_3430 check
here? Can do...

> > +   buscfg = &((struct isp_bus_cfg *)sensor->host_priv)->bus.ccp2;
> > +
> > +
> 
> One blank line is enough.

Ok.

> > +   if (enable) {
> > +   csirxfe = OMAP343X_CONTROL_CSIRXFE_PWRDNZ |
> > + OMAP343X_CONTROL_CSIRXFE_RESET;
> > +
> > +   if (buscfg->phy_layer)
> > +   csirxfe |= OMAP343X_CONTROL_CSIRXFE_SELFORM;
> > +
> > +   if (buscfg->strobe_clk_pol)
> > +   csirxfe |= OMAP343X_CONTROL_CSIRXFE_CSIB_INV;
> > +   } else
> > +   csirxfe = 0;
> 
> You need curly braces for the else statement too.

Easy enough.

> > +
> > +   regmap_write(isp->syscon, isp->syscon_offset, csirxfe);
> 
> Isn't this already configured by csiphy_routing_cfg_3430(), called through 
> omap3isp_csiphy_acquire() ? You'll need to add support for the strobe/clock 
> polarity there, but the rest should already be handled.

Let me check...

> > @@ -69,11 +69,15 @@
> >   * @V4L2_MBUS_PARALLEL:parallel interface with hsync and vsync
> >   * @V4L2_MBUS_BT656:   parallel interface with embedded 
> > synchronisation, can
> >   * also be used for BT.1120
> > + * @V4L2_MBUS_CSI1:MIPI CSI-1 serial interface
> > + * @V4L2_MBUS_CCP2:CCP2 (Compact Camera Port 2)
> 
> It would help if you could provide, in comments or in the commit message, a 
> few pointers to information about CSI-1 and CCP2.

There's not much good information :-(.


Re: [PATCH v3 00/24] i.MX Media Driver

2017-02-15 Thread Philipp Zabel
Hi Steve,

On Tue, 2017-02-14 at 18:27 -0800, Steve Longerbeam wrote:
[...]
> >
> > # Provide an EDID to the HDMI source
> > v4l2-ctl -d /dev/v4l-subdev2 --set-edid=file=edid-1080p.hex
> 
> I can probably generate this Intel hex file myself from sysfs
> edid outputs, but for convenience do you mind sending me this
> file? I have a 1080p HDMI source I can plug into the tc358743.

I copied the EDID off of some random 1080p HDMI monitor,
probably using something like:

xxd -g1 /sys/class/drm/card0-HDMI-A-1/edid | cut -c 9-56

--8<--
 00 ff ff ff ff ff ff 00 09 d1 89 78 45 54 00 00
 2a 14 01 03 80 35 1e 78 2e b8 45 a1 59 55 9f 28
 0d 50 54 a5 6b 80 81 c0 81 00 81 80 a9 c0 b3 00
 d1 c0 01 01 01 01 02 3a 80 18 71 38 2d 40 58 2c
 45 00 13 2a 21 00 00 1e 00 00 00 ff 00 4e 41 41
 30 36 32 39 36 53 4c 30 0a 20 00 00 00 fd 00 32
 4c 1e 53 11 00 0a 20 20 20 20 20 20 00 00 00 fc
 00 42 65 6e 51 20 47 4c 32 34 34 30 48 0a 01 18
 02 03 22 f1 4f 90 05 04 03 02 01 11 12 13 14 06
 07 15 16 1f 23 09 07 07 65 03 0c 00 10 00 83 01
 00 00 02 3a 80 18 71 38 2d 40 58 2c 45 00 13 2a
 21 00 00 1f 01 1d 80 18 71 1c 16 20 58 2c 25 00
 13 2a 21 00 00 9f 01 1d 00 72 51 d0 1e 20 6e 28
 55 00 13 2a 21 00 00 1e 8c 0a d0 8a 20 e0 2d 10
 10 3e 96 00 13 2a 21 00 00 18 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 eb
-->8--

> The other problem here is that my version of v4l2-ctl, built from
> master branch of g...@github.com:gjasny/v4l-utils.git, does not
> support taking a subdev node:
> 
> root@mx6q:~# v4l2-ctl -d /dev/v4l-subdev15 --get-edid=format=hex
> VIDIOC_QUERYCAP: failed: Inappropriate ioctl for device
> /dev/v4l-subdev15: not a v4l2 node
> 
> Is this something you added yourself, or where can I find this version
> of v4l2-ctrl?

Ah right, I still have no proper fix for that. v4l-ctl bails out if it
can't VIDIOC_QUERYCAP, which is an ioctl not supported on subdevices.
I have just patched it out locally:

--8<--
diff --git a/utils/v4l2-ctl/v4l2-ctl.cpp b/utils/v4l2-ctl/v4l2-ctl.cpp
index 886a91d093ae..fa15a49375ae 100644
--- a/utils/v4l2-ctl/v4l2-ctl.cpp
+++ b/utils/v4l2-ctl/v4l2-ctl.cpp
@@ -1214,10 +1214,7 @@ int main(int argc, char **argv)
}
 
verbose = options[OptVerbose];
-   if (doioctl(fd, VIDIOC_QUERYCAP, )) {
-   fprintf(stderr, "%s: not a v4l2 node\n", device);
-   exit(1);
-   }
+   doioctl(fd, VIDIOC_QUERYCAP, );
capabilities = vcap.capabilities;
if (capabilities & V4L2_CAP_DEVICE_CAPS)
capabilities = vcap.device_caps;
-->8--

Note that setting the EDID is not necessary if you can force the mode on
your HDMI source.

regards
Philipp



КЛИЕНСКИЕ БАЗЫ тел +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Viber\whatsapp\telegram +79139230330 Узнайте подробнее!!!

2017-02-15 Thread linux-media@vger.kernel.org


Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

2017-02-15 Thread Benjamin Gaignard
2017-02-14 20:59 GMT+01:00 Laurent Pinchart :
> Hi Daniel,
>
> On Tuesday 14 Feb 2017 20:44:44 Daniel Vetter wrote:
>> On Tue, Feb 14, 2017 at 8:39 PM, Laurent Pinchart wrote:
>> > On Tuesday 14 Feb 2017 20:33:58 Daniel Vetter wrote:
>> >> On Mon, Feb 13, 2017 at 3:45 PM, Benjamin Gaignard wrote:
>> >>> This is the core of simple allocator module.
>> >>> It aim to offert one common ioctl to allocate specific memory.
>> >>>
>> >>> version 2:
>> >>> - rebased on 4.10-rc7
>> >>>
>> >>> Signed-off-by: Benjamin Gaignard 
>> >>
>> >> Why not ION? It's a bit a broken record question, but if there is a
>> >> clear answer it should be in the patch ...
>> >
>> > There's a bit of love & hate relationship between Linux developers and
>> > ION. The API has shortcomings, and attempts to fix the issues went
>> > nowhere. As Laura explained, starting from a blank slate (obviously
>> > keeping in mind the lessons learnt so far with ION and other similar APIs)
>> > and then adding a wrapper to expose ION on Android systems (at least as an
>> > interim measure) was thought to be a better option. I still believe it is,
>> > but we seem to lack traction. The problem has been around for so long that
>> > I feel everybody has lost hope.
>> >
>> > I don't think this is unsolvable, but we need to regain motivation. In my
>> > opinion the first step would be to define the precise extent of the
>> > problem we want to solve.
>>
>> I'm not sure anyone really tried hard enough (in the same way no one
>> tried hard enough to destage android syncpts, until last year). And
>> anything new should at least very clearly explain why ION (even with
>> the various todo items we collected at a few conferences) won't work,
>> and how exactly the new allocator is different from ION. I don't think
>> we need a full design doc (like you say, buffer allocation is hard,
>> we'll get it wrong anyway), but at least a proper comparison with the
>> existing thing. Plus explanation why we can't reuse the uabi.
>
> I've explained several of my concerns (including open questions that need
> answers) in another reply to this patch, let's discuss them there to avoid
> splitting the discussion.
>
>> Because ime when you rewrite something, you generally get one thing
>> right (the one thing that pissed you off about the old solution), plus
>> lots and lots of things that the old solution got right, wrong
>> (because it's all lost in the history).
>
> History, repeating mistakes, all that. History never repeats itself though. We
> might make similar or identical mistakes, but there's no fatality, unless we
> decide not to try before even starting :-)
>
>> ADF was probably the best example in this. KMS also took a while until all
>> the fbdev wheels have been properly reinvented (some are still the same old
>> squeaky onces as fbdev had, e.g. fbcon).
>>
>> And I don't think destaging ION is going to be hard, just a bit of
>> work (could be a nice gsoc or whatever).
>
> Oh, technically speaking, it would be pretty simple. The main issue is to
> decide whether we want to commit to the existing ION API. I don't :-)

I think that Laura have give her felling about ION when commenting the previous
version of this patchset:
https://lkml.org/lkml/2017/1/25/76

>
> --
> Regards,
>
> Laurent Pinchart


Re: next build: 9 warnings 0 failures (next/next-20170215)

2017-02-15 Thread Hans Verkuil
On 02/15/2017 09:39 AM, Arnd Bergmann wrote:
> On Wed, Feb 15, 2017 at 9:30 AM, Hans Verkuil  wrote:
>> On 02/15/2017 09:24 AM, Arnd Bergmann wrote:
>>> On Wed, Feb 15, 2017 at 9:02 AM, Olof's autobuilder  wrote:
> 
   1 drivers/media/platform/coda/imx-vdoa.c:333:571: warning: passing 
 argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
 pointer target type [-Wdiscarded-qualifiers]
   1 drivers/media/platform/coda/imx-vdoa.c:333:625: warning: passing 
 argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
 pointer target type [-Wdiscarded-qualifiers]
   1 drivers/usb/gadget/udc/atmel_usba_udc.c:636:38: warning: 'ept_cfg' 
 may be used uninitialized in this function [-Wmaybe-uninitialized]
   2 drivers/media/platform/coda/imx-vdoa.c:333:181: warning: passing 
 argument 1 of '__platform_driver_register' discards 'const' qualifier from 
 pointer target type [-Wdiscarded-qualifiers]
>>>
>>> This was "[media] coda/imx-vdoa: platform_driver should not be const",
>>> https://patchwork.linuxtv.org/patch/39288/ Hans already marked this as
>>> 'merged', so I assume it's on its way in, but just hasn't appeared in
>>> linux-next as of today.
>>
>> It's part of a pull request for 4.12 for Mauro to pick up. If this should
>> go into 4.10 or 4.11, then Greg should take this particular patch. Mauro is 
>> moving
>> to a new house this week and won't have time (or quite possibly even network
>> connectivity).
> 
> Ok, good to know, thanks for your quick reply. I checked the commit
> that caused the
> warning, d2fe28feaebb ("[media] coda/imx-vdoa: constify structs"), and
> it is currently
> part of git://linuxtv.org/media_tree.git#master . My fix should go on
> top of this branch
> and picked up by whoever is going to send it during the merge window.
> As I'm reverting
> half of Mauro's patch, we can't merge it through any other tree at the moment.

OK, we'll take care of this in that case.

I hope I'll remember this :-)

Regards,

Hans


Re: [RFC simple allocator v2 1/2] Create Simple Allocator module

2017-02-15 Thread Benjamin Gaignard
2017-02-14 20:30 GMT+01:00 Laurent Pinchart :
> Hi Benjamin,
>
> Thank you for the patch. I've CC'ed the linux-api mailing list.
>
> On Monday 13 Feb 2017 15:45:05 Benjamin Gaignard wrote:
>> This is the core of simple allocator module.
>> It aim to offert one common ioctl to allocate specific memory.
>>
>> version 2:
>> - rebased on 4.10-rc7
>>
>> Signed-off-by: Benjamin Gaignard 
>> ---
>>  Documentation/simple-allocator.txt  |  81 +++
>>  drivers/Kconfig |   2 +
>>  drivers/Makefile|   1 +
>>  drivers/simpleallocator/Kconfig |  10 ++
>>  drivers/simpleallocator/Makefile|   1 +
>>  drivers/simpleallocator/simple-allocator-priv.h |  33 +
>>  drivers/simpleallocator/simple-allocator.c  | 180 +
>>  include/uapi/linux/simple-allocator.h   |  35 +
>>  8 files changed, 343 insertions(+)
>>  create mode 100644 Documentation/simple-allocator.txt
>>  create mode 100644 drivers/simpleallocator/Kconfig
>>  create mode 100644 drivers/simpleallocator/Makefile
>>  create mode 100644 drivers/simpleallocator/simple-allocator-priv.h
>>  create mode 100644 drivers/simpleallocator/simple-allocator.c
>>  create mode 100644 include/uapi/linux/simple-allocator.h
>>
>> diff --git a/Documentation/simple-allocator.txt
>> b/Documentation/simple-allocator.txt new file mode 100644
>> index 000..89ba883
>> --- /dev/null
>> +++ b/Documentation/simple-allocator.txt
>> @@ -0,0 +1,81 @@
>> +Simple Allocator Framework
>
> There's nothing simple in buffer allocation, otherwise we would have solved
> the problem a long time ago. Let's not use a misleading name.

Simple was not about the problem, it was about the using only one ioctl.
Anyway a better name is needed: "Limited allocation API", "Basic
allocator framework" ?
suggestions are welcomes

>
>> +Simple Allocator offer a single ioctl SA_IOC_ALLOC to allocate buffers
>> +on dedicated memory regions and export them as a dmabuf file descriptor.
>> +Using dmabuf file descriptor allow to share this memory between processes
>> +and/or import it into other frameworks like v4l2 or drm/kms (prime).
>> +When userland wants to free the memory only a call to close() in needed
>> +so it could done even without knowing that buffer has been allocated by
>> +simple allocator ioctl.
>> +
>> +Each memory regions will be seen as a filein /dev/.
>> +For example CMA regions will exposed has /dev/cmaX.
>
> Why do you need multiple devices ? Furthermore, given how central this API
> will become, I believe it needs very strict review, and would be a candidate
> for a syscall.

I believe that having a device per memory regions is simple than have having,
like ION, heaps which request to add masks (or heap ids) to select them.
My goal here is not to have a a central device /dev/simple_allocator
where allcoations
are dispatched over heaps but only a common ioctl to make userland life easier.
Maybe I should regroup all the device under the same directory: /dev/simple/ ?

>
> Without diving into details yet, there are a few particular points I'm
> concerned about.
>
> - What is the scope of this API ? What problems do you want to solve, plan to
> solve in the future, and consider as out of scope ?

My problem is to be able to allocate a buffer in contiguous memory
(CMA) when using
a software decoder and Weston. This will save the copy between decoder
and display
because display only accepted contiguous memory.
Wayland dmabuf protocol can't allocate buffers so I need an other way
to get access to CMA.
I also other use cases where I need to allocate memory in special
memory region for secure
purpose.

For those both cases I need an API to allocate memory from userland so
I decided to
propose a common ioctl which may be used for even more memory regions.

>
> - How should we handle permissions and resource limits ? Is file-based
> permission on a device node a good model ? How do we prevent or at least
> mitigate memory-related DoS ?

Since each memory region will be represented by a device we could set per
device permissions for example with SELinux policy.

>
> - How should such a central allocator API interact with containers and
> virtualization in general ?

I'm not expert enough in container and virtualization but I know they could have
access to some files/directories to store data so I guess it will
possible for them
to call (for example) /dev/cma0  to allocate memory

> - What model do we want to expose to applications to select a memory type ?
> You still haven't convinced me that we should expose memory pools explicitly
> to application (à la ION), and I believe a usage/constraint model would be
> better.

Memory type selection should be solved by something more smarter than my code.
My goal here is only to provided a common way to perform allocations.
If  "Unix Device Memory 

Re: next build: 9 warnings 0 failures (next/next-20170215)

2017-02-15 Thread Arnd Bergmann
On Wed, Feb 15, 2017 at 9:30 AM, Hans Verkuil  wrote:
> On 02/15/2017 09:24 AM, Arnd Bergmann wrote:
>> On Wed, Feb 15, 2017 at 9:02 AM, Olof's autobuilder  wrote:

>>>   1 drivers/media/platform/coda/imx-vdoa.c:333:571: warning: passing 
>>> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
>>> pointer target type [-Wdiscarded-qualifiers]
>>>   1 drivers/media/platform/coda/imx-vdoa.c:333:625: warning: passing 
>>> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
>>> pointer target type [-Wdiscarded-qualifiers]
>>>   1 drivers/usb/gadget/udc/atmel_usba_udc.c:636:38: warning: 'ept_cfg' 
>>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>>>   2 drivers/media/platform/coda/imx-vdoa.c:333:181: warning: passing 
>>> argument 1 of '__platform_driver_register' discards 'const' qualifier from 
>>> pointer target type [-Wdiscarded-qualifiers]
>>
>> This was "[media] coda/imx-vdoa: platform_driver should not be const",
>> https://patchwork.linuxtv.org/patch/39288/ Hans already marked this as
>> 'merged', so I assume it's on its way in, but just hasn't appeared in
>> linux-next as of today.
>
> It's part of a pull request for 4.12 for Mauro to pick up. If this should
> go into 4.10 or 4.11, then Greg should take this particular patch. Mauro is 
> moving
> to a new house this week and won't have time (or quite possibly even network
> connectivity).

Ok, good to know, thanks for your quick reply. I checked the commit
that caused the
warning, d2fe28feaebb ("[media] coda/imx-vdoa: constify structs"), and
it is currently
part of git://linuxtv.org/media_tree.git#master . My fix should go on
top of this branch
and picked up by whoever is going to send it during the merge window.
As I'm reverting
half of Mauro's patch, we can't merge it through any other tree at the moment.

 Arnd


Re: next build: 9 warnings 0 failures (next/next-20170215)

2017-02-15 Thread Hans Verkuil
On 02/15/2017 09:24 AM, Arnd Bergmann wrote:
> On Wed, Feb 15, 2017 at 9:02 AM, Olof's autobuilder  wrote:
>> Here are the build results from automated periodic testing.
> 
>>
>> Warnings:   9
> 
> It seems we're closing in on zero again, with just two build regressions
> against 4.10 in linux-next. I did patches for both, and they made it into
> maintainer trees but not yet into linux-next
> 
>> Warnings:
>>
>>   1 drivers/iio/adc/rcar-gyroadc.c:398:26: warning: 'adcmode' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>   1 drivers/iio/adc/rcar-gyroadc.c:426:22: warning: 'sample_width' may 
>> be used uninitialized in this function [-Wmaybe-uninitialized]
>>   1 drivers/iio/adc/rcar-gyroadc.c:428:23: warning: 'channels' may be 
>> used uninitialized in this function [-Wmaybe-uninitialized]
>>   1 drivers/iio/adc/rcar-gyroadc.c:429:27: warning: 'num_channels' may 
>> be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> This was "iio: adc: handle unknow of_device_id data",
> http://lkml.iu.edu/hypermail/linux/kernel/1702.0/02707.html
> 
> Jonathan applied it into 'fixes-togreg-post-rc1', which is probably
> enough, though I'd expect that Greg would take it earlier as it
> addresses a (harmless) regression in -next.
> 
>>   1 drivers/media/platform/coda/imx-vdoa.c:333:571: warning: passing 
>> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
>> pointer target type [-Wdiscarded-qualifiers]
>>   1 drivers/media/platform/coda/imx-vdoa.c:333:625: warning: passing 
>> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
>> pointer target type [-Wdiscarded-qualifiers]
>>   1 drivers/usb/gadget/udc/atmel_usba_udc.c:636:38: warning: 'ept_cfg' 
>> may be used uninitialized in this function [-Wmaybe-uninitialized]
>>   2 drivers/media/platform/coda/imx-vdoa.c:333:181: warning: passing 
>> argument 1 of '__platform_driver_register' discards 'const' qualifier from 
>> pointer target type [-Wdiscarded-qualifiers]
> 
> This was "[media] coda/imx-vdoa: platform_driver should not be const",
> https://patchwork.linuxtv.org/patch/39288/ Hans already marked this as
> 'merged', so I assume it's on its way in, but just hasn't appeared in
> linux-next as of today.

It's part of a pull request for 4.12 for Mauro to pick up. If this should
go into 4.10 or 4.11, then Greg should take this particular patch. Mauro is 
moving
to a new house this week and won't have time (or quite possibly even network
connectivity).

Regards,

Hans


Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

2017-02-15 Thread Antti Palosaari

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the other devices supported by the driver,
but uses the Si2141 tuner.
Several DVB-T (MPEG2) and DVB-T2 (H.265) channels were tested, as well as
the include remote control.

Signed-off-by: Stefan Brüns 
---
v2: add support to the dvbsky driver instead of cxusb, correct RC
model
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 91 +++
 2 files changed, 92 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 02dbc6c45423..729496e5a52e 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
return ret;
 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;

it has boolean type


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);

I would prefer sizeof dst here too.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);
Use module name here. Even it is same than device id on that case, it is 
not always the case.



+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain 
anymore about these?



+   goto fail_demod_device;
+   if (!try_module_get(client_demod->dev.driver->owner))
+   goto fail_demod_module;
+
+   /* attach tuner */
+   memset(_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe[0];
+   si2157_config.if_port = 0;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
+   info.addr = 0x60;
+   info.platform_data = _config;
+
+   request_module("si2157");
+   client_tuner = i2c_new_device(i2c_adapter, );
+   if (client_tuner == NULL ||
+   client_tuner->dev.driver == NULL)
+   goto fail_tuner_device;
+   if (!try_module_get(client_tuner->dev.driver->owner))
+   goto fail_tuner_module;
+
+   state->i2c_client_demod = client_demod;
+   state->i2c_client_tuner = client_tuner;
+   return ret;
+fail_tuner_module:
+   i2c_unregister_device(client_tuner);
+fail_tuner_device:
+   module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+   i2c_unregister_device(client_demod);
+fail_demod_device:
+   ret = -ENODEV;
+   return ret;
+}
+
+
 static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
 {
dvbsky_gpio_ctrl(d, 0x04, 1);
@@ -830,6 +892,32 @@ static struct dvb_usb_device_properties dvbsky_t330_props 
= {
}
 };

+static struct dvb_usb_device_properties mygica_t230c_props = {
+   .driver_name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .adapter_nr = adapter_nr,
+   .size_of_priv = sizeof(struct dvbsky_state),
+
+   .generic_bulk_ctrl_endpoint = 0x01,
+   .generic_bulk_ctrl_endpoint_response = 0x81,
+   .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+   .i2c_algo = _i2c_algo,
+   .frontend_attach  = dvbsky_mygica_t230c_attach,
+   .init = dvbsky_init,
+   .get_rc_config= dvbsky_get_rc_config,
+   .streaming_ctrl   = 

Re: next build: 9 warnings 0 failures (next/next-20170215)

2017-02-15 Thread Arnd Bergmann
On Wed, Feb 15, 2017 at 9:02 AM, Olof's autobuilder  wrote:
> Here are the build results from automated periodic testing.

>
> Warnings:   9

It seems we're closing in on zero again, with just two build regressions
against 4.10 in linux-next. I did patches for both, and they made it into
maintainer trees but not yet into linux-next

> Warnings:
>
>   1 drivers/iio/adc/rcar-gyroadc.c:398:26: warning: 'adcmode' may be used 
> uninitialized in this function [-Wmaybe-uninitialized]
>   1 drivers/iio/adc/rcar-gyroadc.c:426:22: warning: 'sample_width' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>   1 drivers/iio/adc/rcar-gyroadc.c:428:23: warning: 'channels' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]
>   1 drivers/iio/adc/rcar-gyroadc.c:429:27: warning: 'num_channels' may be 
> used uninitialized in this function [-Wmaybe-uninitialized]

This was "iio: adc: handle unknow of_device_id data",
http://lkml.iu.edu/hypermail/linux/kernel/1702.0/02707.html

Jonathan applied it into 'fixes-togreg-post-rc1', which is probably
enough, though I'd expect that Greg would take it earlier as it
addresses a (harmless) regression in -next.

>   1 drivers/media/platform/coda/imx-vdoa.c:333:571: warning: passing 
> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
> pointer target type [-Wdiscarded-qualifiers]
>   1 drivers/media/platform/coda/imx-vdoa.c:333:625: warning: passing 
> argument 1 of 'platform_driver_unregister' discards 'const' qualifier from 
> pointer target type [-Wdiscarded-qualifiers]
>   1 drivers/usb/gadget/udc/atmel_usba_udc.c:636:38: warning: 'ept_cfg' 
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>   2 drivers/media/platform/coda/imx-vdoa.c:333:181: warning: passing 
> argument 1 of '__platform_driver_register' discards 'const' qualifier from 
> pointer target type [-Wdiscarded-qualifiers]

This was "[media] coda/imx-vdoa: platform_driver should not be const",
https://patchwork.linuxtv.org/patch/39288/ Hans already marked this as
'merged', so I assume it's on its way in, but just hasn't appeared in
linux-next as of today.

I think there were a couple of other new build warnings in the
kernelci builder, I'll have another look when today's linux-next build
results come in from there.

Arnd


Re: [PATCH v3 1/2] v4l: Add camera voice coil lens control class, current control

2017-02-15 Thread Pavel Machek
Hi!

> On 02/15/17 00:47, Pavel Machek wrote:
> > On Tue 2017-02-14 14:20:22, Sakari Ailus wrote:
> >> Add a V4L2 control class for voice coil lens driver devices. These are
> >> simple devices that are used to move a camera lens from its resting
> >> position.
> >>
> >> Signed-off-by: Sakari Ailus 
> > 
> > Looks good to me.
> > 
> > I wonder... should we somehow expose the range of diopters to
> > userspace? I believe userland camera application will need that
> > information.
> 
> It'd certainly be useful to be able to provide more information.
> 
> The question is: where to store it, and how? It depends on the voice
> coil, the spring constant, the lens and the distance of the lens from
> the sensor --- at least. Probably the sensor size as well.
> 
> On voice coil lenses it is also somewhat inexact.

I was thinking read-only attribute providing minimum and maximum
diopters in case there's linear relationship as on N900.

+#define V4L2_CID_VOICE_DIOPTERS_AT_REST (V4L2_CID_VOICE_COIL_CLASS_BASE + 2)
+#define V4L2_CID_VOICE_DIOPTERS_AT_MAX (V4L2_CID_VOICE_COIL_CLASS_BASE + 3)

?

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