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

2017-02-22 Thread Steve Longerbeam 



On 02/22/2017 04:06 PM, Steve Longerbeam wrote:



On 02/17/2017 03:06 AM, Russell King - ARM Linux wrote:

On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

+static void csi2_dphy_init(struct csi2_dev *csi2)
+{
+/*
+ * FIXME: 0x14 is derived from a fixed D-PHY reference
+ * clock from the HSI_TX PLL, and a fixed target lane max
+ * bandwidth of 300 Mbps. This value should be derived


If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?


I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.

Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters.  (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters.  gcd() doesn't
help you in this instance.)


Hi Russell,

As I mentioned, I've added code to imx6-mipi-csi2 to determine the
sources link frequency via V4L2_CID_LINK_FREQ. If you were to implement
this control and return 912 Mbps-per-lane,


argh, I mean return 912 / 2.

Steve

 the D-PHY will be programmed

correctly for the IMX219 (at least, that is the theory anyway).

Alternatively, I could up the default in imx6-mipi-csi2 to 950
Mbps. I will have to test that to make sure it still works with
OV5640 and tc358743.

Steve

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

2017-02-22 Thread Steve Longerbeam 



On 02/17/2017 03:06 AM, Russell King - ARM Linux wrote:

On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

+static void csi2_dphy_init(struct csi2_dev *csi2)
+{
+   /*
+* FIXME: 0x14 is derived from a fixed D-PHY reference
+* clock from the HSI_TX PLL, and a fixed target lane max
+* bandwidth of 300 Mbps. This value should be derived


If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?


I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.

Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters.  (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters.  gcd() doesn't
help you in this instance.)


Hi Russell,

As I mentioned, I've added code to imx6-mipi-csi2 to determine the
sources link frequency via V4L2_CID_LINK_FREQ. If you were to implement
this control and return 912 Mbps-per-lane, the D-PHY will be programmed
correctly for the IMX219 (at least, that is the theory anyway).

Alternatively, I could up the default in imx6-mipi-csi2 to 950
Mbps. I will have to test that to make sure it still works with
OV5640 and tc358743.

Steve

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

2017-02-22 Thread Steve Longerbeam 



On 02/22/2017 03:38 PM, Steve Longerbeam wrote:



On 02/17/2017 03:38 AM, Philipp Zabel wrote:

On Fri, 2017-02-17 at 11:06 +, Russell King - ARM Linux wrote:

On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

+static void csi2_dphy_init(struct csi2_dev *csi2)
+{
+/*
+ * FIXME: 0x14 is derived from a fixed D-PHY reference
+ * clock from the HSI_TX PLL, and a fixed target lane max
+ * bandwidth of 300 Mbps. This value should be derived


If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?


I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.


I had code to calculate the number of needed lanes from the bit rate and
link frequency. I did not actually change the D-PHY register value.
And as you pointed out, calculating the number of lanes is not useful
without input from the sensor driver, as some lane configurations might
not be supported.


Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters.  (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters.  gcd() doesn't
help you in this instance.)


The tc358743 also currently only implements a fixed rate (of 594 Mbps).


I've analyzed the OV5640 video modes, and they generate the following
"sysclk"'s in Mhz:

210
280
420
560
840

But I don't know whether this is equivalent to bit rate. Is it the same
as Mbps-per-lane? If so, this could be indicated to the sink by
implementing V4L2_CID_LINK_FREQ in the ov5640.c sensor driver.



er, rather, if I knew what this "sysclk" value was, I could use it
to convert to a link frequency and return it in V4L2_CID_LINK_FREQ.

Steve


The Mbps-per-lane value would then be link_freq * 2, and then
Mbps-per-lane could be used to lookup the correct "hsfreqsel"
value to program the D-PHY.

I've added this to imx6-mipi-csi2.c. If the source didn't implement
V4L2_CID_LINK_FREQ then it uses a default 849 Mbps-per-lane.


Steve

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

2017-02-22 Thread Steve Longerbeam 



On 02/17/2017 03:38 AM, Philipp Zabel wrote:

On Fri, 2017-02-17 at 11:06 +, Russell King - ARM Linux wrote:

On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

+static void csi2_dphy_init(struct csi2_dev *csi2)
+{
+   /*
+* FIXME: 0x14 is derived from a fixed D-PHY reference
+* clock from the HSI_TX PLL, and a fixed target lane max
+* bandwidth of 300 Mbps. This value should be derived


If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?


I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.


I had code to calculate the number of needed lanes from the bit rate and
link frequency. I did not actually change the D-PHY register value.
And as you pointed out, calculating the number of lanes is not useful
without input from the sensor driver, as some lane configurations might
not be supported.


Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters.  (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters.  gcd() doesn't
help you in this instance.)


The tc358743 also currently only implements a fixed rate (of 594 Mbps).


I've analyzed the OV5640 video modes, and they generate the following
"sysclk"'s in Mhz:

210
280
420
560
840

But I don't know whether this is equivalent to bit rate. Is it the same
as Mbps-per-lane? If so, this could be indicated to the sink by
implementing V4L2_CID_LINK_FREQ in the ov5640.c sensor driver.

The Mbps-per-lane value would then be link_freq * 2, and then
Mbps-per-lane could be used to lookup the correct "hsfreqsel"
value to program the D-PHY.

I've added this to imx6-mipi-csi2.c. If the source didn't implement
V4L2_CID_LINK_FREQ then it uses a default 849 Mbps-per-lane.


Steve

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

2017-02-17 Thread Steve Longerbeam 



On 02/17/2017 06:16 AM, Philipp Zabel wrote:

On Fri, 2017-02-17 at 11:47 +0100, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:

+static void csi2_dphy_init(struct csi2_dev *csi2)
+{
+   /*
+* FIXME: 0x14 is derived from a fixed D-PHY reference
+* clock from the HSI_TX PLL, and a fixed target lane max
+* bandwidth of 300 Mbps. This value should be derived


If the table in https://community.nxp.com/docs/DOC-94312 is correct,
this should be 850 Mbps. Where does this 300 Mbps value come from?


I got it, the dptdin_map value for 300 Mbps is 0x14 in the Rockchip DSI
driver. But that value is written to the register as HSFREQRANGE_SEL(x):

#define HSFREQRANGE_SEL(val)(((val) & 0x3f) << 1)


Ah you are right, 0x14 would be a "testdin" value of 0x0a, which from
the Rockchip table would be 950 MHz per lane.

But thanks for pointing the table at
https://community.nxp.com/docs/DOC-94312. That table is what
should be referenced in the above comment (850 MHz per lane
for a 27MHz reference clock). I will update the comment based
on that table.

Steve





which is 0x28. Further, the Rockchip D-PHY probably is another version,
as its max_mbps goes up to 1500.

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

2017-02-17 Thread Philipp Zabel 
On Fri, 2017-02-17 at 11:47 +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> > for sensors with a MIPI CSI2 interface.
> > 
> > Signed-off-by: Steve Longerbeam 
> > ---
> >  drivers/staging/media/imx/Makefile |   1 +
> >  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 +

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

2017-02-17 Thread Philipp Zabel 
On Fri, 2017-02-17 at 11:06 +, Russell King - ARM Linux wrote:
> On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:
> > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > > +static void csi2_dphy_init(struct csi2_dev *csi2)
> > > +{
> > > + /*
> > > +  * FIXME: 0x14 is derived from a fixed D-PHY reference
> > > +  * clock from the HSI_TX PLL, and a fixed target lane max
> > > +  * bandwidth of 300 Mbps. This value should be derived
> > 
> > If the table in https://community.nxp.com/docs/DOC-94312 is correct,
> > this should be 850 Mbps. Where does this 300 Mbps value come from?
> 
> I thought you had some code to compute the correct value, although
> I guess we've lost the ability to know how fast the sensor is going
> to drive the link.

I had code to calculate the number of needed lanes from the bit rate and
link frequency. I did not actually change the D-PHY register value.
And as you pointed out, calculating the number of lanes is not useful
without input from the sensor driver, as some lane configurations might
not be supported.

> Note that the IMX219 currently drives the data lanes at 912Mbps almost
> exclusively, as I've yet to finish working out how to derive the PLL
> parameters.  (I have something that works, but it currently takes on
> the order of 100k iterations to derive the parameters.  gcd() doesn't
> help you in this instance.)

The tc358743 also currently only implements a fixed rate (of 594 Mbps).

regards
Philipp

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

2017-02-17 Thread Russell King - ARM Linux 
On Fri, Feb 17, 2017 at 11:47:59AM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > +static void csi2_dphy_init(struct csi2_dev *csi2)
> > +{
> > +   /*
> > +* FIXME: 0x14 is derived from a fixed D-PHY reference
> > +* clock from the HSI_TX PLL, and a fixed target lane max
> > +* bandwidth of 300 Mbps. This value should be derived
> 
> If the table in https://community.nxp.com/docs/DOC-94312 is correct,
> this should be 850 Mbps. Where does this 300 Mbps value come from?

I thought you had some code to compute the correct value, although
I guess we've lost the ability to know how fast the sensor is going
to drive the link.

Note that the IMX219 currently drives the data lanes at 912Mbps almost
exclusively, as I've yet to finish working out how to derive the PLL
parameters.  (I have something that works, but it currently takes on
the order of 100k iterations to derive the parameters.  gcd() doesn't
help you in this instance.)

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

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

2017-02-17 Thread Philipp Zabel 
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/Makefile |   1 +
>  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_TESTCLR  BIT(0)
> +#define PHY_TESTCLK  BIT(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 +

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

2017-02-16 Thread Steve Longerbeam 



On 02/16/2017 02:28 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:25PM -0800, Steve Longerbeam wrote:

Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
for sensors with a MIPI CSI2 interface.

Signed-off-by: Steve Longerbeam 


Just like I reported on the 30th January:

.git/rebase-apply/patch:236: trailing whitespace.
 *
warning: 1 line adds whitespace errors.

This needs fixing.



Fixed.

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

2017-02-16 Thread Russell King - ARM Linux 
On Wed, Feb 15, 2017 at 06:19:25PM -0800, Steve Longerbeam wrote:
> Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
> for sensors with a MIPI CSI2 interface.
> 
> Signed-off-by: Steve Longerbeam 

Just like I reported on the 30th January:

.git/rebase-apply/patch:236: trailing whitespace.
 *
warning: 1 line adds whitespace errors.

This needs fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[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);
+