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/imx-mipi-csi2.c | 501 ++
2 files changed, 502 inse
On Fri, Jan 06, 2017 at 06:11:39PM -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
Applying: media: imx: Add MIPI CSI-2 Receiver subdev driver
.git/rebase-apply/patch:52
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static void imxcsi2_enable(struct imxcsi2_dev *csi2, bool enable)
> +{
> + if (enable) {
> + imxcsi2_write(csi2, 0x, CSI2_PHY_SHUTDOWNZ);
> + imxcsi2_write(csi2, 0x, CSI2_DPHY_RSTZ);
> +
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +++ b/drivers/staging/media/imx/imx-mipi-csi2.c
...
> +#define DEVICE_NAME "imx6-mipi-csi2"
Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-csi2 - could there be some consistency here please?
Thanks.
On 01/30/2017 04:31 PM, Russell King - ARM Linux wrote:
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
+++ b/drivers/staging/media/imx/imx-mipi-csi2.c
...
+#define DEVICE_NAME "imx6-mipi-csi2"
Why is the device/driver named imx6-mipi-csi2, but the module named
imx-mipi-cs
On Tue, 2017-01-31 at 00:01 +, Russell King - ARM Linux wrote:
[...]
> The iMX6 manuals call for a very specific seven sequence of initialisation
> for CSI2, which begins with:
>
> 1. reset the D-PHY.
> 2. place MIPI sensor in LP-11 state
> 3. perform D-PHY initialisation
> 4. configure CSI2 l
On 01/31/2017 01:49 AM, Philipp Zabel wrote:
On Tue, 2017-01-31 at 00:01 +, Russell King - ARM Linux wrote:
[...]
The iMX6 manuals call for a very specific seven sequence of initialisation
for CSI2, which begins with:
1. reset the D-PHY.
2. place MIPI sensor in LP-11 state
3. perform D-PH
Hi Steve,
On Tue, Jan 31, 2017 at 05:02:40PM -0800, Steve Longerbeam wrote:
> But this also puts a requirement on MIPI sensors that s_power(ON)
> should only place the D_PHY in LP-11, and _not_ start the clock lane.
> But perhaps that is correct behavior anyway.
If the CSI2 DPHY is held in reset
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
> +static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
> +struct v4l2_subdev_pad_config *cfg,
> +struct v4l2_subdev_format *sdformat)
> +{
> + struct imxcsi2_dev *csi2 = sd_to_dev(sd
On 02/01/2017 03:44 PM, Russell King - ARM Linux wrote:
On Fri, Jan 06, 2017 at 06:11:39PM -0800, Steve Longerbeam wrote:
+static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdf
On Fri, 2017-01-06 at 18:11 -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/imx-mi
On 02/02/2017 03:50 AM, Philipp Zabel wrote:
+ struct v4l2_subdev *src_sd;
+ struct v4l2_subdev *sink_sd[CSI2_NUM_SRC_PADS];
I see no reason to store pointers to the remote v4l2_subdevs.
+ intinput_pad;
+ struct clk *dphy_clk;
On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
> >Actually, this exact function already exists as dw_mipi_dsi_phy_write in
> >drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
> >register 0x44 might contain a field called HSFREQRANGE_SEL.
>
> Thanks for pointin
On Wed, 2017-02-08 at 15:23 -0800, Steve Longerbeam wrote:
[...]
> >> +
> >> +static int imxcsi2_get_fmt(struct v4l2_subdev *sd,
> >> + struct v4l2_subdev_pad_config *cfg,
> >> + struct v4l2_subdev_format *sdformat)
> >> +{
> >> + struct imxcsi2_dev *csi2 =
On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:
On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
Actually, this exact function already exists as dw_mipi_dsi_phy_write in
drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it looks like the D-PHY
register 0x44 might contain a f
On 02/09/2017 03:49 PM, Steve Longerbeam wrote:
On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:
On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
Actually, this exact function already exists as
dw_mipi_dsi_phy_write in
drivers/gpu/drm/rockchip/dw-mipi-dsi.c, and it
Hi Steve,
On Thu, 2017-02-09 at 15:51 -0800, Steve Longerbeam wrote:
>
> On 02/09/2017 03:49 PM, Steve Longerbeam wrote:
> >
> >
> > On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:
> >> On Wed, Feb 08, 2017 at 03:23:53PM -0800, Steve Longerbeam wrote:
> Actually, this exact function
(#!##* Thunderbird! resending text only)
Hi Philipp,
On 02/13/2017 01:20 AM, Philipp Zabel wrote:
Hi Steve,
On Thu, 2017-02-09 at 15:51 -0800, Steve Longerbeam wrote:
On 02/09/2017 03:49 PM, Steve Longerbeam wrote:
On 02/08/2017 03:42 PM, Russell King - ARM Linux wrote:
On Wed, Feb 08, 201
Hi Steve,
On Mon, 2017-02-13 at 15:20 -0800, Steve Longerbeam wrote:
[...]
> > It seems the OV5640 driver never puts its the CSI-2 lanes into stop
> > state while not streaming.
>
> Yes I found that as well.
>
> But good news, I finally managed to coax the OV5640's clock lane
> into LP-11 state!
19 matches
Mail list logo