Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1582252 > unrolled thread
| Started by | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| First post | 2017-02-16 03:30 +0100 |
| Last post | 2017-03-01 01:50 +0100 |
| Articles | 20 on this page of 98 — 8 participants |
Back to article view | Back to linux.kernel
[PATCH v4 00/36] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 05/36] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 17/36] media: Add userspace header file for i.MX Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 17/36] media: Add userspace header file for i.MX Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-16 12:40 +0100
Re: [PATCH v4 17/36] media: Add userspace header file for i.MX Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 01:00 +0100
[PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 11:30 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 19:10 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 12:00 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-17 12:20 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 12:40 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 00:50 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 00:50 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 01:10 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 01:20 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 15:20 +0100
Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-17 19:30 +0100
[PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 12:10 +0100
Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 19:20 +0100
[PATCH v4 35/36] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 27/36] media: imx: csi: add support for bayer formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-16 12:40 +0100
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-23 01:00 +0100
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-23 10:20 +0100
Re: [PATCH v4 33/36] media: imx: redo pixel format enumeration and negotiation Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-24 02:50 +0100
[PATCH v4 26/36] media: imx: add support for bayer formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors Fabio Estevam <festevam@gmail.com> - 2017-02-17 02:00 +0100
Re: [PATCH v4 07/36] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-17 02:00 +0100
[PATCH v4 10/36] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 06/36] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-18 02:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-18 10:30 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-18 18:30 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-18 19:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <steve_longerbeam@mentor.com> - 2017-02-18 02:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-20 23:10 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-21 00:00 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-21 00:50 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-21 13:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-21 23:30 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-22 00:40 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-21 01:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-21 10:00 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-21 01:20 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-21 13:40 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-21 14:30 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-21 16:40 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-21 17:10 +0100
Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and getting of frame rates Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-21 17:20 +0100
[PATCH v4 13/36] [media] v4l2: add a frame timeout event Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 31/36] media: imx: csi: add __csi_get_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 12/36] add mux and video interface bridge entity functions Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 12/36] add mux and video interface bridge entity functions Pavel Machek <pavel@ucw.cz> - 2017-02-19 22:40 +0100
Re: [PATCH v4 12/36] add mux and video interface bridge entity functions Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-22 18:30 +0100
[PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 14/36] [media] v4l2-mc: add a function to inherit controls from a pipeline Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:00 +0100
[PATCH v4 15/36] platform: add video-multiplexer subdevice driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver Pavel Machek <pavel@ucw.cz> - 2017-02-19 23:20 +0100
Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-21 10:20 +0100
Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver Pavel Machek <pavel@ucw.cz> - 2017-02-24 21:10 +0100
Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver Rob Herring <robh@kernel.org> - 2017-02-27 15:50 +0100
Re: [PATCH v4 15/36] platform: add video-multiplexer subdevice driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-01 01:30 +0100
[PATCH v4 21/36] media: imx: Add VDIC subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 32/36] media: imx: csi/fim: add support for frame intervals Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
Re: [PATCH v4 32/36] media: imx: csi/fim: add support for frame intervals Steve Longerbeam <steve_longerbeam@mentor.com> - 2017-02-16 03:40 +0100
[PATCH v4 09/36] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:30 +0100
[PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:40 +0100
Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-16 13:00 +0100
Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 20:30 +0100
Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver Rob Herring <robh@kernel.org> - 2017-02-27 15:50 +0100
Re: [PATCH v4 01/36] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-01 01:40 +0100
[PATCH v4 04/36] ARM: dts: imx6qdl: add capture-subsystem device Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 03:40 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 11:30 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 19:00 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 12:40 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 19:40 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-16 14:10 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 14:50 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-17 02:40 +0100
Re: [PATCH v4 18/36] media: Add i.MX media core driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 09:40 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-16 23:30 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-17 00:10 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 11:50 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-17 12:00 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 12:30 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-02-18 18:40 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 12:50 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-17 13:30 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-17 13:40 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-02-17 16:10 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Sakari Ailus <sakari.ailus@iki.fi> - 2017-02-18 13:10 +0100
Re: [PATCH v4 00/36] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-02-16 23:30 +0100
Re: [PATCH v4 24/36] [media] add Omnivision OV5640 sensor driver Rob Herring <robh@kernel.org> - 2017-02-27 15:50 +0100
Re: [PATCH v4 24/36] [media] add Omnivision OV5640 sensor driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-01 01:50 +0100
Page 1 of 5 [1] 2 3 4 5 Next page →
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 03:30 +0100 |
| Subject | [PATCH v4 00/36] i.MX Media Driver |
| Message-ID | <tbjZv-8cO-3@gated-at.bofh.it> |
In version 4:
Changes suggested by Philipp Zabel <p.zabel@pengutronix.de> and
Jean-Michel Hautbois <jean-michel.hautbois@veo-labs.com>:
- split out VDIC from imx-ic-prpvf into a distinct VDIC subdev.
Changes suggested by Philipp Zabel <p.zabel@pengutronix.de>:
- 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_ARGB8888_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 <javier@dowhile0.org>:
- add missing MODULE_DEVICE_TABLE() to video mux subdev.
Changes suggested by Hans Verkuil <hverkuil@xs4all.nl>:
- 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 <linux@armlinux.org.uk>:
- 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 <laurent.pinchart@ideasonboard.com>:
- 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 and getting of frame rates
Steve Longerbeam (27):
[media] dt-bindings: Add bindings for i.MX media driver
ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node
ARM: dts: imx6qdl: add capture-subsystem device
ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround
ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
ARM: dts: imx6-sabreauto: create i2cmux for i2c3
ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b
ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture
ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
[media] v4l2: add a frame timeout event
[media] v4l2-mc: add a function to inherit controls from a pipeline
UAPI: Add media UAPI Kbuild file
media: Add userspace header file for i.MX
media: Add i.MX media core driver
media: imx: Add Capture Device Interface
media: imx: Add CSI subdev driver
media: imx: Add VDIC subdev driver
media: imx: Add IC subdev drivers
media: imx: Add MIPI CSI-2 Receiver subdev driver
[media] add Omnivision OV5640 sensor driver
ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers
media: imx: update capture dev format on IDMAC output pad set_fmt
media: imx: csi: add __csi_get_fmt
media: imx: csi/fim: add support for frame intervals
media: imx: redo pixel format enumeration and negotiation
media: imx: propagate sink pad formats to source pads
.../devicetree/bindings/media/i2c/ov5640.txt | 43 +
Documentation/devicetree/bindings/media/imx.txt | 66 +
.../bindings/media/video-multiplexer.txt | 59 +
Documentation/media/uapi/mediactl/media-types.rst | 22 +
Documentation/media/uapi/v4l/vidioc-dqevent.rst | 5 +
Documentation/media/v4l-drivers/imx.rst | 542 +++++
Documentation/media/videodev2.h.rst.exceptions | 1 +
arch/arm/boot/dts/imx6dl-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6dl-sabresd.dts | 5 +
arch/arm/boot/dts/imx6dl.dtsi | 185 ++
arch/arm/boot/dts/imx6q-sabrelite.dts | 5 +
arch/arm/boot/dts/imx6q-sabresd.dts | 5 +
arch/arm/boot/dts/imx6q.dtsi | 121 ++
arch/arm/boot/dts/imx6qdl-sabreauto.dtsi | 144 +-
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 152 +-
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 114 +-
arch/arm/boot/dts/imx6qdl.dtsi | 17 +-
arch/arm/configs/imx_v6_v7_defconfig | 14 +-
drivers/media/i2c/Kconfig | 7 +
drivers/media/i2c/Makefile | 1 +
drivers/media/i2c/ov5640.c | 2109 ++++++++++++++++++++
drivers/media/platform/Kconfig | 8 +
drivers/media/platform/Makefile | 2 +
drivers/media/platform/video-multiplexer.c | 474 +++++
drivers/media/v4l2-core/v4l2-mc.c | 48 +
drivers/staging/media/Kconfig | 2 +
drivers/staging/media/Makefile | 1 +
drivers/staging/media/imx/Kconfig | 20 +
drivers/staging/media/imx/Makefile | 12 +
drivers/staging/media/imx/TODO | 36 +
drivers/staging/media/imx/imx-ic-common.c | 113 ++
drivers/staging/media/imx/imx-ic-prp.c | 458 +++++
drivers/staging/media/imx/imx-ic-prpencvf.c | 1138 +++++++++++
drivers/staging/media/imx/imx-ic.h | 38 +
drivers/staging/media/imx/imx-media-capture.c | 671 +++++++
drivers/staging/media/imx/imx-media-csi.c | 1483 ++++++++++++++
drivers/staging/media/imx/imx-media-dev.c | 487 +++++
drivers/staging/media/imx/imx-media-fim.c | 463 +++++
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 | 930 +++++++++
drivers/staging/media/imx/imx-media-vdic.c | 915 +++++++++
drivers/staging/media/imx/imx-media.h | 305 +++
drivers/staging/media/imx/imx6-mipi-csi2.c | 600 ++++++
include/media/imx.h | 15 +
include/media/v4l2-mc.h | 25 +
include/uapi/Kbuild | 1 +
include/uapi/linux/media.h | 6 +
include/uapi/linux/v4l2-controls.h | 4 +
include/uapi/linux/videodev2.h | 1 +
include/uapi/media/Kbuild | 2 +
include/uapi/media/imx.h | 29 +
52 files changed, 12496 insertions(+), 29 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/i2c/ov5640.txt
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
create mode 100644 Documentation/devicetree/bindings/media/video-multiplexer.txt
create mode 100644 Documentation/media/v4l-drivers/imx.rst
create mode 100644 drivers/media/i2c/ov5640.c
create mode 100644 drivers/media/platform/video-multiplexer.c
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-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
create mode 100644 drivers/staging/media/imx/imx-media-capture.c
create mode 100644 drivers/staging/media/imx/imx-media-csi.c
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-vdic.c
create mode 100644 drivers/staging/media/imx/imx-media.h
create mode 100644 drivers/staging/media/imx/imx6-mipi-csi2.c
create mode 100644 include/media/imx.h
create mode 100644 include/uapi/media/Kbuild
create mode 100644 include/uapi/media/imx.h
--
2.7.4
[toc] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 03:30 +0100 |
| Subject | [PATCH v4 05/36] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround |
| Message-ID | <tbjZw-8cO-31@gated-at.bofh.it> |
| In reply to | #1582252 |
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 <steve_longerbeam@mentor.com>
---
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 = <&gpio1 6 IRQ_TYPE_LEVEL_HIGH>,
- <&intc 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
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 03:30 +0100 |
| Subject | [PATCH v4 17/36] media: Add userspace header file for i.MX |
| Message-ID | <tbjZw-8cO-33@gated-at.bofh.it> |
| In reply to | #1582252 |
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 <steve_longerbeam@mentor.com>
---
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 0000000..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
[toc] | [prev] | [next] | [standalone]
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Date | 2017-02-16 12:40 +0100 |
| Subject | Re: [PATCH v4 17/36] media: Add userspace header file for i.MX |
| Message-ID | <tbszL-5Ab-1@gated-at.bofh.it> |
| In reply to | #1582254 |
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> 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 <steve_longerbeam@mentor.com>
> ---
> 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 0000000..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)
These events are still i.MX specific. I think they shouldn't be.
> +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
regards
Philipp
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-23 01:00 +0100 |
| Subject | Re: [PATCH v4 17/36] media: Add userspace header file for i.MX |
| Message-ID | <tdOZb-11s-7@gated-at.bofh.it> |
| In reply to | #1582487 |
On 02/16/2017 03:33 AM, Philipp Zabel wrote: > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: >> >> +/* >> + * 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) > > These events are still i.MX specific. I think they shouldn't be. Done, I've exported them to V4L2_EVENT_FRAME_INTERVAL_ERROR V4L2_EVENT_NEW_FRAME_BEFORE_EOF Steve
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 03:30 +0100 |
| Subject | [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbjZv-8cO-17@gated-at.bofh.it> |
| In reply to | #1582252 |
Adds MIPI CSI-2 Receiver subdev driver. This subdev is required
for sensors with a MIPI CSI2 interface.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
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 0000000..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 <linux/clk.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/irq.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-of.h>
+#include <media/v4l2-subdev.h>
+#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;
+ bool on;
+ bool stream_on;
+ bool src_linked;
+ bool sink_linked[CSI2_NUM_SRC_PADS];
+};
+
+#define DEVICE_NAME "imx6-mipi-csi2"
+
+/* Register offsets */
+#define CSI2_VERSION 0x000
+#define CSI2_N_LANES 0x004
+#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_RXULPSCLKNOT BIT(9)
+#define PHY_STOPSTATECLK BIT(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 + 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);
+
+ /* Clear strobe signal */
+ writel(0x0, csi2->base + CSI2_PHY_TST_CTRL0);
+}
+
+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
+ * from the dphy_clk rate and the desired max lane bandwidth.
+ * See drivers/gpu/drm/rockchip/dw-mipi-dsi.c for more info
+ * on how this value is derived.
+ */
+ dw_mipi_csi2_phy_write(csi2, 0x44, 0x14);
+}
+
+/*
+ * Waits for ultra-low-power state on D-PHY clock lane. This is currently
+ * unused and may not be needed at all, but keep around just in case.
+ */
+static int __maybe_unused csi2_dphy_wait_ulp(struct csi2_dev *csi2)
+{
+ u32 reg;
+ int ret;
+
+ /* wait for ULP on clock lane */
+ ret = readl_poll_timeout(csi2->base + CSI2_PHY_STATE, reg,
+ !(reg & PHY_RXULPSCLKNOT), 0, 500000);
+ if (ret) {
+ v4l2_err(&csi2->sd, "ULP timeout, phy_state = 0x%08x\n", reg);
+ return ret;
+ }
+
+ /* wait until no errors on bus */
+ ret = readl_poll_timeout(csi2->base + CSI2_ERR1, reg,
+ reg == 0x0, 0, 500000);
+ if (ret) {
+ v4l2_err(&csi2->sd, "stable bus timeout, err1 = 0x%08x\n", reg);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Waits for low-power LP-11 state (aka STOPSTATE) on data and clock
+ * lanes.
+ */
+static int csi2_dphy_wait_stopstate(struct csi2_dev *csi2)
+{
+ u32 mask, reg;
+ int ret;
+
+ mask = PHY_STOPSTATECLK |
+ ((csi2->bus.num_data_lanes - 1) << PHY_STOPSTATEDATA_BIT);
+
+ ret = readl_poll_timeout(csi2->base + CSI2_PHY_STATE, reg,
+ (reg & mask) == mask, 0, 500000);
+ if (ret) {
+ v4l2_err(&csi2->sd, "LP-11 timeout, phy_state = 0x%08x\n", reg);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * Wait for active clock on the clock lane.
+ *
+ * FIXME: Currently unused, but it should be! It should be called
+ * from csi2_s_stream() below, at stream ON, but the required sequence
+ * of MIPI CSI-2 startup does not allow for an opportunity for this to
+ * be called. The sequence as specified in the i.MX6 reference manual
+ * is as follows:
+ *
+ * 1. Deassert presetn signal (global reset).
+ * It's not clear what this "global reset" signal is (maybe APB
+ * global reset), but in any case this step corresponds to
+ * csi2_s_power(ON) here.
+ *
+ * 2. Configure MIPI Camera Sensor to put all Tx lanes in PL-11 state.
+ * This must be carried out by the MIPI sensor's s_power(ON) subdev
+ * op.
+ *
+ * 3. D-PHY initialization.
+ * 4. CSI2 Controller programming (Set N_LANES, deassert PHY_SHUTDOWNZ,
+ * deassert PHY_RSTZ, deassert CSI2_RESETN).
+ * 5. Read the PHY status register (PHY_STATE) to confirm that all data and
+ * clock lanes of the D-PHY are in Stop State.
+ * These steps (3,4,5) are carried out by csi2_s_stream(ON) here.
+ *
+ * 6. Configure the MIPI Camera Sensor to start transmitting a clock on the
+ * D-PHY clock lane.
+ * This must be carried out by the MIPI sensor's s_stream(ON) subdev
+ * op.
+ *
+ * 7. CSI2 Controller programming - Read the PHY status register (PHY_STATE)
+ * to confirm that the D-PHY is receiving a clock on the D-PHY clock lane.
+ * This is implemented by this unused function, and _should_ be called
+ * by csi2_s_stream(ON) here, but csi2_s_stream(ON) has been taken up
+ * by steps 3,4,5 above already.
+ *
+ * In summary, a temporary solution would require a hard-coded delay in the
+ * MIPI sensor's s_stream(ON) op, to allow time for a stable clock lane.
+ *
+ * A longer term solution might be to create a new subdev op, perhaps
+ * called prepare_stream, that can be implemented here, and would be
+ * assigned steps 3,4,5. Then csi2_s_stream(ON) would become available
+ * as step 7.
+ */
+static int __maybe_unused csi2_dphy_wait_clock_lane(struct csi2_dev *csi2)
+{
+ u32 reg;
+ int ret;
+
+ ret = readl_poll_timeout(csi2->base + CSI2_PHY_STATE, reg,
+ (reg & PHY_RXCLKACTIVEHS), 0, 500000);
+ if (ret) {
+ v4l2_err(&csi2->sd, "clock lane timeout, phy_state = 0x%08x\n",
+ reg);
+ return ret;
+ }
+
+ return 0;
+}
+
+/*
+ * V4L2 subdev operations.
+ */
+
+/* Startup Sequence Step 1 */
+static int csi2_s_power(struct v4l2_subdev *sd, int on)
+{
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+ int ret;
+
+ if (on && !csi2->on) {
+ dev_dbg(csi2->dev, "power ON\n");
+ ret = clk_prepare_enable(csi2->cfg_clk);
+ if (ret)
+ return ret;
+ ret = clk_prepare_enable(csi2->dphy_clk);
+ if (ret)
+ goto cfg_clk_off;
+ } else if (!on && csi2->on) {
+ dev_dbg(csi2->dev, "power OFF\n");
+ clk_disable_unprepare(csi2->dphy_clk);
+ clk_disable_unprepare(csi2->cfg_clk);
+ }
+
+ csi2->on = on;
+
+ return 0;
+
+cfg_clk_off:
+ clk_disable_unprepare(csi2->cfg_clk);
+ return ret;
+}
+
+/* Startup Sequence Steps 3, 4, 5 */
+static int csi2_s_stream(struct v4l2_subdev *sd, int enable)
+{
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+ int i, ret = 0;
+
+ if (!csi2->src_linked)
+ return -EPIPE;
+ for (i = 0; i < CSI2_NUM_SRC_PADS; i++) {
+ if (csi2->sink_linked[i])
+ break;
+ }
+ if (i >= CSI2_NUM_SRC_PADS)
+ return -EPIPE;
+
+ if (enable && !csi2->stream_on) {
+ dev_dbg(csi2->dev, "stream ON\n");
+
+ ret = clk_prepare_enable(csi2->pix_clk);
+ if (ret)
+ return ret;
+
+ /* Step 3 */
+ csi2_dphy_init(csi2);
+ /* Step 4 */
+ csi2_set_lanes(csi2);
+ csi2_enable(csi2, true);
+
+ /* Step 5 */
+ ret = csi2_dphy_wait_stopstate(csi2);
+ if (ret) {
+ csi2_enable(csi2, false);
+ clk_disable_unprepare(csi2->pix_clk);
+ return ret;
+ }
+ } else if (!enable && csi2->stream_on) {
+ dev_dbg(csi2->dev, "stream OFF\n");
+ csi2_enable(csi2, false);
+ clk_disable_unprepare(csi2->pix_clk);
+ }
+
+ csi2->stream_on = enable;
+ return 0;
+}
+
+static int csi2_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+ struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+ struct v4l2_subdev *remote_sd;
+
+ dev_dbg(csi2->dev, "link setup %s -> %s", remote->entity->name,
+ local->entity->name);
+
+ remote_sd = media_entity_to_v4l2_subdev(remote->entity);
+
+ if (local->flags & MEDIA_PAD_FL_SOURCE) {
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (csi2->sink_linked[local->index])
+ return -EBUSY;
+ csi2->sink_linked[local->index] = true;
+ } else {
+ csi2->sink_linked[local->index] = false;
+ }
+ } else {
+ if (flags & MEDIA_LNK_FL_ENABLED) {
+ if (csi2->src_linked)
+ return -EBUSY;
+ csi2->src_linked = true;
+ } else {
+ csi2->src_linked = false;
+ }
+ }
+
+ return 0;
+}
+
+static int csi2_get_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+ struct v4l2_mbus_framefmt *fmt;
+
+ if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY)
+ fmt = v4l2_subdev_get_try_format(&csi2->sd, cfg,
+ sdformat->pad);
+ else
+ fmt = &csi2->format_mbus;
+
+ sdformat->format = *fmt;
+
+ return 0;
+}
+
+static int csi2_set_fmt(struct v4l2_subdev *sd,
+ struct v4l2_subdev_pad_config *cfg,
+ struct v4l2_subdev_format *sdformat)
+{
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+
+ if (sdformat->pad >= CSI2_NUM_PADS)
+ return -EINVAL;
+
+ if (csi2->stream_on)
+ return -EBUSY;
+
+ /* Output pads mirror active input pad, no limits on input pads */
+ if (sdformat->pad != CSI2_SINK_PAD)
+ sdformat->format = csi2->format_mbus;
+
+ if (sdformat->which == V4L2_SUBDEV_FORMAT_TRY)
+ cfg->try_fmt = sdformat->format;
+ else
+ csi2->format_mbus = sdformat->format;
+
+ return 0;
+}
+
+/*
+ * retrieve our pads parsed from the OF graph by the media device
+ */
+static int csi2_registered(struct v4l2_subdev *sd)
+{
+ struct csi2_dev *csi2 = sd_to_dev(sd);
+ int i, ret;
+
+ for (i = 0; i < CSI2_NUM_PADS; i++) {
+ csi2->pad[i].flags = (i == CSI2_SINK_PAD) ?
+ MEDIA_PAD_FL_SINK : MEDIA_PAD_FL_SOURCE;
+ }
+
+ /* set a default mbus format */
+ ret = imx_media_init_mbus_fmt(&csi2->format_mbus,
+ 640, 480, 0, V4L2_FIELD_NONE, NULL);
+ if (ret)
+ return ret;
+
+ return media_entity_pads_init(&sd->entity, CSI2_NUM_PADS, csi2->pad);
+}
+
+static struct media_entity_operations csi2_entity_ops = {
+ .link_setup = csi2_link_setup,
+ .link_validate = v4l2_subdev_link_validate,
+};
+
+static struct v4l2_subdev_core_ops csi2_core_ops = {
+ .s_power = csi2_s_power,
+};
+
+static struct v4l2_subdev_video_ops csi2_video_ops = {
+ .s_stream = csi2_s_stream,
+};
+
+static struct v4l2_subdev_pad_ops csi2_pad_ops = {
+ .get_fmt = csi2_get_fmt,
+ .set_fmt = csi2_set_fmt,
+};
+
+static struct v4l2_subdev_ops csi2_subdev_ops = {
+ .core = &csi2_core_ops,
+ .video = &csi2_video_ops,
+ .pad = &csi2_pad_ops,
+};
+
+static struct v4l2_subdev_internal_ops csi2_internal_ops = {
+ .registered = csi2_registered,
+};
+
+static int csi2_parse_endpoints(struct csi2_dev *csi2)
+{
+ struct device_node *node = csi2->dev->of_node;
+ struct device_node *epnode;
+ struct v4l2_of_endpoint ep;
+
+ epnode = of_graph_get_endpoint_by_regs(node, 0, -1);
+ if (!epnode) {
+ v4l2_err(&csi2->sd, "failed to get sink endpoint node\n");
+ return -EINVAL;
+ }
+
+ v4l2_of_parse_endpoint(epnode, &ep);
+ of_node_put(epnode);
+
+ if (ep.bus_type != V4L2_MBUS_CSI2) {
+ v4l2_err(&csi2->sd, "invalid bus type, must be MIPI CSI2\n");
+ return -EINVAL;
+ }
+
+ csi2->bus = ep.bus.mipi_csi2;
+
+ dev_dbg(csi2->dev, "data lanes: %d\n", csi2->bus.num_data_lanes);
+ dev_dbg(csi2->dev, "flags: 0x%08x\n", csi2->bus.flags);
+ return 0;
+}
+
+static int csi2_probe(struct platform_device *pdev)
+{
+ struct csi2_dev *csi2;
+ struct resource *res;
+ int ret;
+
+ csi2 = devm_kzalloc(&pdev->dev, sizeof(*csi2), GFP_KERNEL);
+ if (!csi2)
+ return -ENOMEM;
+
+ csi2->dev = &pdev->dev;
+
+ v4l2_subdev_init(&csi2->sd, &csi2_subdev_ops);
+ v4l2_set_subdevdata(&csi2->sd, &pdev->dev);
+ csi2->sd.internal_ops = &csi2_internal_ops;
+ csi2->sd.entity.ops = &csi2_entity_ops;
+ csi2->sd.dev = &pdev->dev;
+ csi2->sd.owner = THIS_MODULE;
+ csi2->sd.flags = V4L2_SUBDEV_FL_HAS_DEVNODE;
+ strcpy(csi2->sd.name, DEVICE_NAME);
+ csi2->sd.entity.function = MEDIA_ENT_F_VID_IF_BRIDGE;
+ csi2->sd.grp_id = IMX_MEDIA_GRP_ID_CSI2;
+
+ ret = csi2_parse_endpoints(csi2);
+ if (ret)
+ return ret;
+
+ csi2->cfg_clk = devm_clk_get(&pdev->dev, "cfg");
+ if (IS_ERR(csi2->cfg_clk)) {
+ v4l2_err(&csi2->sd, "failed to get cfg clock\n");
+ ret = PTR_ERR(csi2->cfg_clk);
+ return ret;
+ }
+
+ csi2->dphy_clk = devm_clk_get(&pdev->dev, "dphy");
+ if (IS_ERR(csi2->dphy_clk)) {
+ v4l2_err(&csi2->sd, "failed to get dphy clock\n");
+ ret = PTR_ERR(csi2->dphy_clk);
+ return ret;
+ }
+
+ csi2->pix_clk = devm_clk_get(&pdev->dev, "pix");
+ if (IS_ERR(csi2->pix_clk)) {
+ v4l2_err(&csi2->sd, "failed to get pixel clock\n");
+ ret = PTR_ERR(csi2->pix_clk);
+ return ret;
+ }
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res) {
+ v4l2_err(&csi2->sd, "failed to get platform resources\n");
+ return -ENODEV;
+ }
+
+ csi2->base = devm_ioremap(&pdev->dev, res->start, PAGE_SIZE);
+ if (!csi2->base) {
+ v4l2_err(&csi2->sd, "failed to map CSI-2 registers\n");
+ return -ENOMEM;
+ }
+
+ platform_set_drvdata(pdev, &csi2->sd);
+
+ return v4l2_async_register_subdev(&csi2->sd);
+}
+
+static int csi2_remove(struct platform_device *pdev)
+{
+ struct v4l2_subdev *sd = platform_get_drvdata(pdev);
+
+ csi2_s_power(sd, 0);
+
+ v4l2_async_unregister_subdev(sd);
+ media_entity_cleanup(&sd->entity);
+
+ return 0;
+}
+
+static const struct of_device_id csi2_dt_ids[] = {
+ { .compatible = "fsl,imx6-mipi-csi2", },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, csi2_dt_ids);
+
+static struct platform_driver csi2_driver = {
+ .driver = {
+ .name = DEVICE_NAME,
+ .of_match_table = csi2_dt_ids,
+ },
+ .probe = csi2_probe,
+ .remove = csi2_remove,
+};
+
+module_platform_driver(csi2_driver);
+
+MODULE_DESCRIPTION("i.MX5/6 MIPI CSI-2 Receiver driver");
+MODULE_AUTHOR("Steve Longerbeam <steve_longerbeam@mentor.com>");
+MODULE_LICENSE("GPL");
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-02-16 11:30 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbru2-4Oj-5@gated-at.bofh.it> |
| In reply to | #1582255 |
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 <steve_longerbeam@mentor.com> 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.
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 19:10 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbyFc-1Cv-31@gated-at.bofh.it> |
| In reply to | #1582442 |
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 <steve_longerbeam@mentor.com> > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Date | 2017-02-17 12:00 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbOqD-3eL-27@gated-at.bofh.it> |
| In reply to | #1582255 |
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 <steve_longerbeam@mentor.com>
> ---
> 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 0000000..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 <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <media/v4l2-device.h>
> +#include <media/v4l2-of.h>
> +#include <media/v4l2-subdev.h>
> +#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;
> + bool on;
> + bool stream_on;
> + bool src_linked;
> + bool sink_linked[CSI2_NUM_SRC_PADS];
> +};
> +
> +#define DEVICE_NAME "imx6-mipi-csi2"
> +
> +/* Register offsets */
> +#define CSI2_VERSION 0x000
> +#define CSI2_N_LANES 0x004
> +#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_RXULPSCLKNOT BIT(9)
> +#define PHY_STOPSTATECLK BIT(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 + 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);
> +
> + /* Clear strobe signal */
> + writel(0x0, csi2->base + CSI2_PHY_TST_CTRL0);
> +}
> +
> +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?
regards
Philipp
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-02-17 12:20 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbOJY-3B2-23@gated-at.bofh.it> |
| In reply to | #1583322 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Date | 2017-02-17 12:40 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbP3j-3HN-3@gated-at.bofh.it> |
| In reply to | #1583340 |
On Fri, 2017-02-17 at 11:06 +0000, 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
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-23 00:50 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tdOPw-Vy-3@gated-at.bofh.it> |
| In reply to | #1583355 |
On 02/17/2017 03:38 AM, Philipp Zabel wrote:
> On Fri, 2017-02-17 at 11:06 +0000, 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
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-23 00:50 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tdOPw-Vy-9@gated-at.bofh.it> |
| In reply to | #1586557 |
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 +0000, 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
>
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-23 01:10 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tdP8S-1kb-5@gated-at.bofh.it> |
| In reply to | #1583340 |
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
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-23 01:20 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tdPix-1nW-3@gated-at.bofh.it> |
| In reply to | #1586566 |
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
[toc] | [prev] | [next] | [standalone]
| From | Philipp Zabel <p.zabel@pengutronix.de> |
|---|---|
| Date | 2017-02-17 15:20 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbRy9-5mq-13@gated-at.bofh.it> |
| In reply to | #1583322 |
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 <steve_longerbeam@mentor.com>
> > ---
> > 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 0000000..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 <linux/clk.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/io.h>
> > +#include <linux/iopoll.h>
> > +#include <linux/irq.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <media/v4l2-device.h>
> > +#include <media/v4l2-of.h>
> > +#include <media/v4l2-subdev.h>
> > +#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;
> > + bool on;
> > + bool stream_on;
> > + bool src_linked;
> > + bool sink_linked[CSI2_NUM_SRC_PADS];
> > +};
> > +
> > +#define DEVICE_NAME "imx6-mipi-csi2"
> > +
> > +/* Register offsets */
> > +#define CSI2_VERSION 0x000
> > +#define CSI2_N_LANES 0x004
> > +#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_RXULPSCLKNOT BIT(9)
> > +#define PHY_STOPSTATECLK BIT(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 + 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);
> > +
> > + /* Clear strobe signal */
> > + writel(0x0, csi2->base + CSI2_PHY_TST_CTRL0);
> > +}
> > +
> > +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)
which is 0x28. Further, the Rockchip D-PHY probably is another version,
as its max_mbps goes up to 1500.
regards
Philipp
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-17 19:30 +0100 |
| Subject | Re: [PATCH v4 23/36] media: imx: Add MIPI CSI-2 Receiver subdev driver |
| Message-ID | <tbVs6-7Mv-7@gated-at.bofh.it> |
| In reply to | #1583441 |
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.
>
>
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 03:30 +0100 |
| Subject | [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt |
| Message-ID | <tbjZv-8cO-19@gated-at.bofh.it> |
| In reply to | #1582252 |
From: Philipp Zabel <p.zabel@pengutronix.de>
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 <p.zabel@pengutronix.de>
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
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, &priv->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, &sensor_mbus_cfg, &if_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, &crop, 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, &crop, 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
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-02-16 12:10 +0100 |
| Subject | Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt |
| Message-ID | <tbs6J-5om-9@gated-at.bofh.it> |
| In reply to | #1582256 |
On Wed, Feb 15, 2017 at 06:19:30PM -0800, Steve Longerbeam wrote: > 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, &priv->crop); > > + ipu_csi_set_downsize(priv->csi, > + priv->crop.width == 2 * outfmt->width, > + priv->crop.height == 2 * outfmt->height); > + This fails to build: ERROR: "ipu_csi_set_downsize" [drivers/staging/media/imx/imx-media-csi.ko] undefined! ipu_csi_set_downsize needs to be exported if we're going to use it in a module: -- 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.
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-02-16 19:20 +0100 |
| Subject | Re: [PATCH v4 28/36] media: imx: csi: fix crop rectangle changes in set_fmt |
| Message-ID | <tbyOT-1GL-37@gated-at.bofh.it> |
| In reply to | #1582468 |
On 02/16/2017 03:05 AM, Russell King - ARM Linux wrote: > On Wed, Feb 15, 2017 at 06:19:30PM -0800, Steve Longerbeam wrote: >> 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, &priv->crop); >> >> + ipu_csi_set_downsize(priv->csi, >> + priv->crop.width == 2 * outfmt->width, >> + priv->crop.height == 2 * outfmt->height); >> + > > This fails to build: > > ERROR: "ipu_csi_set_downsize" [drivers/staging/media/imx/imx-media-csi.ko] undefined! > > ipu_csi_set_downsize needs to be exported if we're going to use it in > a module: > Yes I encountered the missing export too, forgot to mention it. Philipp submitted a patch to dri-devel separately. Steve
[toc] | [prev] | [next] | [standalone]
Page 1 of 5 [1] 2 3 4 5 Next page →
Back to top | Article view | linux.kernel
csiph-web