Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1596626 > unrolled thread
| Started by | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| First post | 2017-03-10 06:00 +0100 |
| Last post | 2017-03-20 14:20 +0100 |
| Articles | 20 on this page of 168 — 16 participants |
Back to article view | Back to linux.kernel
[PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 26/39] media: imx: Add VDIC subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 16:30 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 20:20 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 13:20 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 13:40 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 15:30 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 18:20 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 18:30 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 22:00 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-21 05:20 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-21 12:30 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-22 01:00 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-22 00:40 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 18:50 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 19:20 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 15:30 +0100
Re: [PATCH v5 38/39] media: imx: csi: fix crop rectangle reset in sink set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-20 21:10 +0100
[PATCH v5 30/39] media: imx: add support for bayer formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 35/39] media: imx: csi/fim: add support for frame intervals Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 20/39] platform: add video-multiplexer subdevice driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 29/39] ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 09/39] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 10/39] ARM: dts: imx6-sabreauto: create i2cmux for i2c3 Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 08/39] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 01/39] [media] dt-bindings: Add bindings for video-multiplexer device Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 01/39] [media] dt-bindings: Add bindings for video-multiplexer device Rob Herring <robh@kernel.org> - 2017-03-16 22:30 +0100
[PATCH v5 24/39] media: imx: Add Capture Device Interface Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 32/39] media: imx: csi: fix crop rectangle changes in set_fmt Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 33/39] media: imx: mipi-csi2: enable setting and getting of frame rates Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 25/39] media: imx: Add CSI subdev driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 05/39] ARM: dts: imx6qdl: Add mipi_ipu1/2 multiplexers, mipi_csi, and their connections Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 11/39] ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 21/39] UAPI: Add media UAPI Kbuild file Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 21/39] UAPI: Add media UAPI Kbuild file Sakari Ailus <sakari.ailus@iki.fi> - 2017-03-11 14:50 +0100
Re: [PATCH v5 21/39] UAPI: Add media UAPI Kbuild file Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 19:30 +0100
Re: [PATCH v5 21/39] UAPI: Add media UAPI Kbuild file Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-13 11:00 +0100
[PATCH v5 37/39] media: imx: csi: add frame skipping support Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 22/39] media: Add userspace header file for i.MX Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 22/39] media: Add userspace header file for i.MX Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-10 12:50 +0100
Re: [PATCH v5 22/39] media: Add userspace header file for i.MX Pavel Machek <pavel@ucw.cz> - 2017-03-11 00:40 +0100
[PATCH v5 36/39] media: imx: redo pixel format enumeration and negotiation Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-10 13:10 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 19:40 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Pavel Machek <pavel@ucw.cz> - 2017-03-11 00:40 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 00:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-11 12:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 19:20 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-11 20:00 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 20:00 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 20:10 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-13 11:10 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-13 11:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-13 12:00 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-13 18:10 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-13 18:20 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-13 22:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-14 17:30 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-14 17:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Sakari Ailus <sakari.ailus@iki.fi> - 2017-03-16 23:30 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-14 17:50 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-14 18:00 +0100
Re: [PATCH v5 15/39] [media] v4l2: add a frame interval error event Pavel Machek <pavel@ucw.cz> - 2017-03-14 19:30 +0100
[PATCH v5 31/39] media: imx: csi: add support for bayer formats Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
[PATCH v5 03/39] [media] dt/bindings: Add bindings for OV5640 Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:00 +0100
Re: [PATCH v5 03/39] [media] dt/bindings: Add bindings for OV5640 Rob Herring <robh@kernel.org> - 2017-03-20 16:10 +0100
[PATCH v5 14/39] add mux and video interface bridge entity functions Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
[PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Troy Kisky <troy.kisky@boundarydevices.com> - 2017-03-10 20:00 +0100
Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Fabio Estevam <festevam@gmail.com> - 2017-03-10 20:20 +0100
Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Pavel Machek <pavel@ucw.cz> - 2017-03-10 23:00 +0100
Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Fabio Estevam <festevam@gmail.com> - 2017-03-10 23:10 +0100
Re: [PATCH v5 07/39] ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-15 19:50 +0100
[PATCH v5 17/39] [media] v4l2-mc: add a function to inherit controls from a pipeline Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
Re: [PATCH v5 17/39] [media] v4l2-mc: add a function to inherit controls from a pipeline Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-10 12:50 +0100
[PATCH v5 12/39] ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
[PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval Sakari Ailus <sakari.ailus@iki.fi> - 2017-03-11 14:50 +0100
Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 21:40 +0100
Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval Sakari Ailus <sakari.ailus@iki.fi> - 2017-03-16 23:30 +0100
[PATCH v5 04/39] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
[PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
Re: [PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-10 13:10 +0100
[PATCH v5 06/39] ARM: dts: imx6qdl: add capture-subsystem device Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
[PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-10 06:10 +0100
Re: [PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver Rob Herring <robh@kernel.org> - 2017-03-20 16:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-10 21:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-11 00:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 18:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 01:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 21:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 21:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 21:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-13 05:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-13 09:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-13 10:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-14 00:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <steve_longerbeam@mentor.com> - 2017-03-14 00:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 19:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 20:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 20:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 20:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 21:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 21:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 21:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 21:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 22:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-14 18:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-18 21:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 20:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-12 21:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-03-12 22:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-12 22:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Mauro Carvalho Chehab <mchehab@s-opensource.com> - 2017-03-12 23:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <steve_longerbeam@mentor.com> - 2017-03-14 18:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-18 20:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <steve_longerbeam@mentor.com> - 2017-03-18 21:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-18 21:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-19 01:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 02:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 16:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-19 16:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 11:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-19 15:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> - 2017-03-19 15:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 15:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com> - 2017-03-19 16:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 16:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 15:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-19 15:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 11:50 +0100
[PATCH 2/4] media: imx: allow bayer pixel formats to be looked up Russell King <rmk+kernel@armlinux.org.uk> - 2017-03-19 11:50 +0100
Re: [PATCH 2/4] media: imx: allow bayer pixel formats to be looked up Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 23:20 +0100
[PATCH 1/4] media: imx-media-csi: fix v4l2-compliance check Russell King <rmk+kernel@armlinux.org.uk> - 2017-03-19 11:50 +0100
Re: [PATCH 1/4] media: imx-media-csi: fix v4l2-compliance check Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 23:20 +0100
[PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Russell King <rmk+kernel@armlinux.org.uk> - 2017-03-19 12:00 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 23:30 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 23:50 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Philippe De Muyter <phdm@macq.eu> - 2017-03-20 10:00 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 10:10 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Philippe De Muyter <phdm@macq.eu> - 2017-03-20 10:30 +0100
Re: [PATCH 4/4] media: imx-media-capture: add frame sizes/interval enumeration Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 11:50 +0100
[PATCH 3/4] media: imx-csi: add frame size/interval enumeration Russell King <rmk+kernel@armlinux.org.uk> - 2017-03-19 12:10 +0100
Re: [PATCH 3/4] media: imx-csi: add frame size/interval enumeration Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 23:30 +0100
Re: [PATCH 3/4] media: imx-csi: add frame size/interval enumeration Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-22 00:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 19:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 19:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-20 14:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 14:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-20 15:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 15:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-20 17:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver "Niklas Söderlund" <niklas.soderlund@ragnatech.se> - 2017-03-21 11:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-21 12:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-21 12:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Nicolas Dufresne <nicolas@ndufresne.ca> - 2017-03-22 19:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 13:20 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-19 20:10 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 21:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Steve Longerbeam <slongerbeam@gmail.com> - 2017-03-19 21:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Hans Verkuil <hverkuil@xs4all.nl> - 2017-03-20 14:00 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 14:30 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 16:50 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Russell King - ARM Linux <linux@armlinux.org.uk> - 2017-03-20 17:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 17:40 +0100
Re: [PATCH v5 00/39] i.MX Media Driver Philipp Zabel <p.zabel@pengutronix.de> - 2017-03-20 14:20 +0100
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-03-11 21:40 +0100 |
| Subject | Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval |
| Message-ID | <tjVXX-7Yc-1@gated-at.bofh.it> |
| In reply to | #1598321 |
On 03/11/2017 05:41 AM, Sakari Ailus wrote: > Hi Steve, > > On Thu, Mar 09, 2017 at 08:52:58PM -0800, Steve Longerbeam wrote: >> If the pads on both sides of a link specify a frame interval, then >> those frame intervals should match. Create the exported function >> v4l2_subdev_link_validate_frame_interval() to verify this. This >> function can be called in a subdevice's media_entity_operations >> or v4l2_subdev_pad_ops link_validate callbacks. >> >> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> > > If your only goal is to configure frame dropping on a sub-device, I suggest > to implement s_frame_interval() on the pads of that sub-device only. The > frames are then dropped according to the configured frame rates between the > sink and source pads. Say, configuring sink for 1/30 s and source 1/15 would > drop half of the incoming frames. > > Considering that supporting specific frame interval on most sub-devices adds > no value or is not the interface through which it the frame rate configured, > I think it is overkill to change the link validation to expect otherwise. Well, while I think this function might still have validity in the future, I do agree with you that a subdev that has no control over frame rate has no business implementing the get|set ops. In the imx-media subdevs, the only one that can affect frame rate (via frame skipping) is the CSI. So I'll go ahead and remove the [gs]_frame_interval ops from the others. I can remove this patch as a result. Steve
[toc] | [prev] | [next] | [standalone]
| From | Sakari Ailus <sakari.ailus@iki.fi> |
|---|---|
| Date | 2017-03-16 23:30 +0100 |
| Subject | Re: [PATCH v5 18/39] [media] v4l: subdev: Add function to validate frame interval |
| Message-ID | <tlM49-4UO-5@gated-at.bofh.it> |
| In reply to | #1598457 |
On Sat, Mar 11, 2017 at 12:31:24PM -0800, Steve Longerbeam wrote: > > > On 03/11/2017 05:41 AM, Sakari Ailus wrote: > >Hi Steve, > > > >On Thu, Mar 09, 2017 at 08:52:58PM -0800, Steve Longerbeam wrote: > >>If the pads on both sides of a link specify a frame interval, then > >>those frame intervals should match. Create the exported function > >>v4l2_subdev_link_validate_frame_interval() to verify this. This > >>function can be called in a subdevice's media_entity_operations > >>or v4l2_subdev_pad_ops link_validate callbacks. > >> > >>Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com> > > > >If your only goal is to configure frame dropping on a sub-device, I suggest > >to implement s_frame_interval() on the pads of that sub-device only. The > >frames are then dropped according to the configured frame rates between the > >sink and source pads. Say, configuring sink for 1/30 s and source 1/15 would > >drop half of the incoming frames. > > > >Considering that supporting specific frame interval on most sub-devices adds > >no value or is not the interface through which it the frame rate configured, > >I think it is overkill to change the link validation to expect otherwise. > > > Well, while I think this function might still have validity in the future, I > do agree with you that a subdev that has no control over > frame rate has no business implementing the get|set ops. > > In the imx-media subdevs, the only one that can affect frame rate (via > frame skipping) is the CSI. So I'll go ahead and remove the > [gs]_frame_interval ops from the others. I can remove this patch as > a result. Agreed. -- Sakari Ailus e-mail: sakari.ailus@iki.fi XMPP: sailus@retiisi.org.uk
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-03-10 06:10 +0100 |
| Subject | [PATCH v5 04/39] ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node |
| Message-ID | <tjkYp-7iw-17@gated-at.bofh.it> |
| In reply to | #1596626 |
Add to the MIPI CSI2 receiver node: compatible strings,
interrupt sources, and clocks.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 6d7bf64..d28a413 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1134,7 +1134,14 @@
};
mipi_csi: mipi@021dc000 {
+ compatible = "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
reg = <0x021dc000 0x4000>;
+ interrupts = <0 100 0x04>, <0 101 0x04>;
+ clocks = <&clks IMX6QDL_CLK_HSI_TX>,
+ <&clks IMX6QDL_CLK_VIDEO_27M>,
+ <&clks IMX6QDL_CLK_EIM_PODF>;
+ clock-names = "dphy", "ref", "pix";
+ status = "disabled";
};
mipi_dsi: mipi@021e0000 {
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-03-10 06:10 +0100 |
| Subject | [PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event |
| Message-ID | <tjkYq-7iw-25@gated-at.bofh.it> |
| In reply to | #1596626 |
Add a NEW_FRAME_BEFORE_EOF event to signal that a video capture or
output device has signaled a new frame is ready before a previous
frame has completed reception or transmission. This usually indicates
a DMA read/write channel is having trouble gaining bus access.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++++++
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
index dc77363..54bc7ae 100644
--- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
+++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
@@ -203,6 +203,12 @@ call.
has measured an interval between the reception or transmit
completion of two consecutive frames of video that is outside
the nominal frame interval by some tolerance value.
+ * - ``V4L2_EVENT_NEW_FRAME_BEFORE_EOF``
+ - 8
+ - This event is triggered when the video capture or output device
+ has signaled a new frame is ready before a previous frame has
+ completed reception or transmission. This usually indicates a
+ DMA read/write channel is having trouble gaining bus access.
* - ``V4L2_EVENT_PRIVATE_START``
- 0x08000000
- Base event number for driver-private events.
diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
index c7d8fad..be6f332 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -460,6 +460,7 @@ replace define V4L2_EVENT_FRAME_SYNC event-type
replace define V4L2_EVENT_SOURCE_CHANGE event-type
replace define V4L2_EVENT_MOTION_DET event-type
replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
+replace define V4L2_EVENT_NEW_FRAME_BEFORE_EOF event-type
replace define V4L2_EVENT_PRIVATE_START event-type
replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index cf5a0d0..f54a82a 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
#define V4L2_EVENT_SOURCE_CHANGE 5
#define V4L2_EVENT_MOTION_DET 6
#define V4L2_EVENT_FRAME_INTERVAL_ERROR 7
+#define V4L2_EVENT_NEW_FRAME_BEFORE_EOF 8
#define V4L2_EVENT_PRIVATE_START 0x08000000
/* Payload for V4L2_EVENT_VSYNC */
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Hans Verkuil <hverkuil@xs4all.nl> |
|---|---|
| Date | 2017-03-10 13:10 +0100 |
| Subject | Re: [PATCH v5 16/39] [media] v4l2: add a new-frame before end-of-frame event |
| Message-ID | <tjrwT-3LF-57@gated-at.bofh.it> |
| In reply to | #1596658 |
On 10/03/17 05:52, Steve Longerbeam wrote:
> Add a NEW_FRAME_BEFORE_EOF event to signal that a video capture or
> output device has signaled a new frame is ready before a previous
> frame has completed reception or transmission. This usually indicates
> a DMA read/write channel is having trouble gaining bus access.
This too is a weird event. Based on what you describe this basically means
that the previous frame is incomplete, in which case you would typically
return the buffer with the V4L2_BUF_FLAG_ERROR bit set.
Using an event for this is not a good idea.
Regards,
Hans
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 6 ++++++
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 8 insertions(+)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> index dc77363..54bc7ae 100644
> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
> @@ -203,6 +203,12 @@ call.
> has measured an interval between the reception or transmit
> completion of two consecutive frames of video that is outside
> the nominal frame interval by some tolerance value.
> + * - ``V4L2_EVENT_NEW_FRAME_BEFORE_EOF``
> + - 8
> + - This event is triggered when the video capture or output device
> + has signaled a new frame is ready before a previous frame has
> + completed reception or transmission. This usually indicates a
> + DMA read/write channel is having trouble gaining bus access.
> * - ``V4L2_EVENT_PRIVATE_START``
> - 0x08000000
> - Base event number for driver-private events.
> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> index c7d8fad..be6f332 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -460,6 +460,7 @@ replace define V4L2_EVENT_FRAME_SYNC event-type
> replace define V4L2_EVENT_SOURCE_CHANGE event-type
> replace define V4L2_EVENT_MOTION_DET event-type
> replace define V4L2_EVENT_FRAME_INTERVAL_ERROR event-type
> +replace define V4L2_EVENT_NEW_FRAME_BEFORE_EOF event-type
> replace define V4L2_EVENT_PRIVATE_START event-type
>
> replace define V4L2_EVENT_CTRL_CH_VALUE ctrl-changes-flags
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index cf5a0d0..f54a82a 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -2132,6 +2132,7 @@ struct v4l2_streamparm {
> #define V4L2_EVENT_SOURCE_CHANGE 5
> #define V4L2_EVENT_MOTION_DET 6
> #define V4L2_EVENT_FRAME_INTERVAL_ERROR 7
> +#define V4L2_EVENT_NEW_FRAME_BEFORE_EOF 8
> #define V4L2_EVENT_PRIVATE_START 0x08000000
>
> /* Payload for V4L2_EVENT_VSYNC */
>
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-03-10 06:10 +0100 |
| Subject | [PATCH v5 06/39] ARM: dts: imx6qdl: add capture-subsystem device |
| Message-ID | <tjkYq-7iw-23@gated-at.bofh.it> |
| In reply to | #1596626 |
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
arch/arm/boot/dts/imx6dl.dtsi | 5 +++++
arch/arm/boot/dts/imx6q.dtsi | 5 +++++
2 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx6dl.dtsi b/arch/arm/boot/dts/imx6dl.dtsi
index 8958c4a..a959c76 100644
--- a/arch/arm/boot/dts/imx6dl.dtsi
+++ b/arch/arm/boot/dts/imx6dl.dtsi
@@ -100,6 +100,11 @@
};
};
+ capture-subsystem {
+ compatible = "fsl,imx-capture-subsystem";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+ };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>;
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index b833b0d..4cc6579 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -206,6 +206,11 @@
};
};
+ capture-subsystem {
+ compatible = "fsl,imx-capture-subsystem";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>, <&ipu2_csi0>, <&ipu2_csi1>;
+ };
+
display-subsystem {
compatible = "fsl,imx-display-subsystem";
ports = <&ipu1_di0>, <&ipu1_di1>, <&ipu2_di0>, <&ipu2_di1>;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <slongerbeam@gmail.com> |
|---|---|
| Date | 2017-03-10 06:10 +0100 |
| Subject | [PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver |
| Message-ID | <tjkYq-7iw-31@gated-at.bofh.it> |
| In reply to | #1596626 |
Add bindings documentation for the i.MX media driver.
Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
---
Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
1 file changed, 74 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/imx.txt
diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 0000000..3059c06
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,74 @@
+Freescale i.MX Media Video Device
+=================================
+
+Video Media Controller node
+---------------------------
+
+This is the media controller node for video capture support. It is a
+virtual device that lists the camera serial interface nodes that the
+media device will control.
+
+Required properties:
+- compatible : "fsl,imx-capture-subsystem";
+- ports : Should contain a list of phandles pointing to camera
+ sensor interface ports of IPU devices
+
+example:
+
+capture-subsystem {
+ compatible = "fsl,imx-capture-subsystem";
+ ports = <&ipu1_csi0>, <&ipu1_csi1>;
+};
+
+fim child node
+--------------
+
+This is an optional child node of the ipu_csi port nodes. If present and
+available, it enables the Frame Interval Monitor. Its properties can be
+used to modify the method in which the FIM measures frame intervals.
+Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
+Frame Interval Monitor.
+
+Optional properties:
+- fsl,input-capture-channel: an input capture channel and channel flags,
+ specified as <chan flags>. The channel number
+ must be 0 or 1. The flags can be
+ IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
+ IRQ_TYPE_EDGE_BOTH, and specify which input
+ capture signal edge will trigger the input
+ capture event. If an input capture channel is
+ specified, the FIM will use this method to
+ measure frame intervals instead of via the EOF
+ interrupt. The input capture method is much
+ preferred over EOF as it is not subject to
+ interrupt latency errors. However it requires
+ routing the VSYNC or FIELD output signals of
+ the camera sensor to one of the i.MX input
+ capture pads (SD1_DAT0, SD1_DAT1), which also
+ gives up support for SD1.
+
+
+mipi_csi2 node
+--------------
+
+This is the device node for the MIPI CSI-2 Receiver, required for MIPI
+CSI-2 sensors.
+
+Required properties:
+- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
+- reg : physical base address and length of the register set;
+- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+ (the D-PHY clock), video_27m (D-PHY PLL reference
+ clock), and eim_podf;
+- clock-names : must contain "dphy", "ref", "pix";
+- port@* : five port nodes must exist, containing endpoints
+ connecting to the source and sink devices according to
+ of_graph bindings. The first port is an input port,
+ connecting with a MIPI CSI-2 source, and ports 1
+ through 4 are output ports connecting with parallel
+ bus sink endpoint nodes and correspond to the four
+ MIPI CSI-2 virtual channel outputs.
+
+Optional properties:
+- interrupts : must contain two level-triggered interrupts,
+ in order: 100 and 101;
--
2.7.4
[toc] | [prev] | [next] | [standalone]
| From | Rob Herring <robh@kernel.org> |
|---|---|
| Date | 2017-03-20 16:20 +0100 |
| Subject | Re: [PATCH v5 02/39] [media] dt-bindings: Add bindings for i.MX media driver |
| Message-ID | <tn7ge-6yN-27@gated-at.bofh.it> |
| In reply to | #1596660 |
+Ramiro
On Thu, Mar 09, 2017 at 08:52:42PM -0800, Steve Longerbeam wrote:
> Add bindings documentation for the i.MX media driver.
>
> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
> ---
> Documentation/devicetree/bindings/media/imx.txt | 74 +++++++++++++++++++++++++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/imx.txt
>
> diff --git a/Documentation/devicetree/bindings/media/imx.txt b/Documentation/devicetree/bindings/media/imx.txt
> new file mode 100644
> index 0000000..3059c06
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/imx.txt
> @@ -0,0 +1,74 @@
> +Freescale i.MX Media Video Device
> +=================================
> +
> +Video Media Controller node
> +---------------------------
> +
> +This is the media controller node for video capture support. It is a
> +virtual device that lists the camera serial interface nodes that the
> +media device will control.
> +
> +Required properties:
> +- compatible : "fsl,imx-capture-subsystem";
> +- ports : Should contain a list of phandles pointing to camera
> + sensor interface ports of IPU devices
> +
> +example:
> +
> +capture-subsystem {
> + compatible = "fsl,imx-capture-subsystem";
> + ports = <&ipu1_csi0>, <&ipu1_csi1>;
> +};
> +
> +fim child node
> +--------------
> +
> +This is an optional child node of the ipu_csi port nodes. If present and
> +available, it enables the Frame Interval Monitor. Its properties can be
> +used to modify the method in which the FIM measures frame intervals.
> +Refer to Documentation/media/v4l-drivers/imx.rst for more info on the
> +Frame Interval Monitor.
> +
> +Optional properties:
> +- fsl,input-capture-channel: an input capture channel and channel flags,
> + specified as <chan flags>. The channel number
> + must be 0 or 1. The flags can be
> + IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, or
> + IRQ_TYPE_EDGE_BOTH, and specify which input
> + capture signal edge will trigger the input
> + capture event. If an input capture channel is
> + specified, the FIM will use this method to
> + measure frame intervals instead of via the EOF
> + interrupt. The input capture method is much
> + preferred over EOF as it is not subject to
> + interrupt latency errors. However it requires
> + routing the VSYNC or FIELD output signals of
> + the camera sensor to one of the i.MX input
> + capture pads (SD1_DAT0, SD1_DAT1), which also
> + gives up support for SD1.
> +
> +
> +mipi_csi2 node
> +--------------
> +
> +This is the device node for the MIPI CSI-2 Receiver, required for MIPI
> +CSI-2 sensors.
> +
> +Required properties:
> +- compatible : "fsl,imx6-mipi-csi2", "snps,dw-mipi-csi2";
Ramiro is also working on a binding for DW MIPI CSI2 block[1]. We need 1
binding for that.
> +- reg : physical base address and length of the register set;
> +- clocks : the MIPI CSI-2 receiver requires three clocks: hsi_tx
> + (the D-PHY clock), video_27m (D-PHY PLL reference
> + clock), and eim_podf;
> +- clock-names : must contain "dphy", "ref", "pix";
> +- port@* : five port nodes must exist, containing endpoints
> + connecting to the source and sink devices according to
> + of_graph bindings. The first port is an input port,
> + connecting with a MIPI CSI-2 source, and ports 1
> + through 4 are output ports connecting with parallel
> + bus sink endpoint nodes and correspond to the four
> + MIPI CSI-2 virtual channel outputs.
> +
> +Optional properties:
> +- interrupts : must contain two level-triggered interrupts,
> + in order: 100 and 101;
> --
> 2.7.4
>
[1] https://lkml.org/lkml/2017/3/7/395
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-10 21:20 +0100 |
| Message-ID | <tjzb4-yL-17@gated-at.bofh.it> |
| In reply to | #1596626 |
Version 5 gives me no v4l2 controls exposed through the video device interface. Just like with version 4, version 5 is completely useless with IMX219: imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 ipu1_csi0: pipeline start failed with -110 imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 ipu1_csi0: pipeline start failed with -110 imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 ipu1_csi0: pipeline start failed with -110 So, like v4, I can't do any further testing. On Thu, Mar 09, 2017 at 08:52:40PM -0800, Steve Longerbeam wrote: > In version 5: > > - ov5640: renamed "pwdn-gpios" to "powerdown-gpios" > > - ov5640: add mutex lock around the subdev op entry points. > > - ov5640: don't attempt to program the new mode in ov5640_set_fmt(). > Instead set a new flag, pending_mode_change, and program the new > mode at s_stream() if flag is set. > > - ov5640: implement [gs]_frame_interval. As part of that, create > ov5640_try_frame_interval(), which is used by both [gs]_frame_interval > and [gs]_parm. > > - ov5640: don't attempt to set controls in ov5640_s_ctrl(), or at > mode change, do it instead after first power-up. > > - video-multiplexer: include link_validate in media_entity_operations. > > - video-multiplexer: enforce that output pad frame interval must match > input pad frame interval in vidsw_s_frame_interval(). > > - video-multiplexer: initialize frame interval to a default 30 fps. > > - mipi csi-2: renamed "cfg" clock name property to "ref". This is the > 27 MHz mipi csi-2 PLL reference clock. > > - mipi csi-2: create a hsfreq_map[] table based on > https://community.nxp.com/docs/DOC-94312. Use it to select > a hsfreqrange_sel value when programming the D-PHY, based on > a max Mbps per lane. This is computed from the source subdev > via V4L2_CID_LINK_FREQ control, and if the subdev doesn't implement > that control, use a default hard-coded max Mbps per lane. > > - added required ports property description to imx-media binding doc. > > - removed event V4L2_EVENT_FRAME_TIMEOUT. On a frame timeout, which > is always unrecoverable, call vb2_queue_error() instead. > > - export the remaining custom events to V4L2_EVENT_FRAME_INTERVAL_ERROR > and V4L2_EVENT_NEW_FRAME_BEFORE_EOF. > > - vdic: use V4L2_CID_DEINTERLACING_MODE for motion compensation control > instead of a custom control. > > - add v4l2_subdev_link_validate_frame_interval(). Call this in the > link_validate imx-media subdev callbacks and video-multiplexer. > > - fix subdev event registration: implementation of subscribe_event() > and unsubscribe_event() subdev ops were missing. > > - all calls from the pipeline to the sensor subdev have been removed. > Only the CSI subdev still refers to a sensor, and only to retrieve > its media bus config, which is necessary to setup the CSI interface. > > - add mutex locks around the imx-media subdev op entry points. > > - completed the propagation of all pad format parameters from sink > pads to source pads within every imx-media subdev. > > - implement [gs]_frame_interval in all the imx-media subdevs. > > - imx-ic-prpencvf: there isn't necessarily a CSI subdev in the pipeline > in the future, so make sure this is optional when calling the CSI's > FIM. > > - the source pads that attach to capture device nodes now require the > IPU internal pixel codes. The capture device translates these to > v4l2 fourcc memory formats. > > - fix control inheritance to the capture device. When the pipeline > was modified, the inherited controls were not being refreshed. > v4l2_pipeline_inherit_controls() is now called only in imx-media > link_notify() callback when a pipelink link is disabled or modified. > imx_media_find_pipeline_video_device() is created to locate the > capture device in the pipeline. > > - fix a possible race when propagating formats to the capture device. > The subdevs and capture device use different mutex locks when setting > formats. imx_media_capture_device_set_format() is created which acquires > the capture device mutex when updating the capture device format. > > - verify all subdevs were bound in the async completion callback. > > > Philipp Zabel (7): > [media] dt-bindings: Add bindings for video-multiplexer device > 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 (4): > 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 > media: imx: csi/fim: add support for frame intervals > > Steve Longerbeam (28): > [media] dt-bindings: Add bindings for i.MX media driver > [media] dt/bindings: Add bindings for OV5640 > ARM: dts: imx6qdl: Add compatible, clocks, irqs to MIPI CSI-2 node > ARM: dts: imx6qdl: add capture-subsystem device > ARM: dts: imx6qdl-sabrelite: remove erratum ERR006687 workaround > ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors > ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors > ARM: dts: imx6-sabreauto: create i2cmux for i2c3 > ARM: dts: imx6-sabreauto: add reset-gpios property for max7310_b > ARM: dts: imx6-sabreauto: add pinctrl for gpt input capture > ARM: dts: imx6-sabreauto: add the ADV7180 video decoder > [media] v4l2: add a frame interval error event > [media] v4l2: add a new-frame before end-of-frame event > [media] v4l2-mc: add a function to inherit controls from a pipeline > [media] v4l: subdev: Add function to validate frame interval > [media] add Omnivision OV5640 sensor driver > 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 > ARM: imx_v6_v7_defconfig: Enable staging video4linux drivers > media: imx: csi: add __csi_get_fmt > media: imx: redo pixel format enumeration and negotiation > media: imx: propagate sink pad formats to source pads > > .../devicetree/bindings/media/i2c/ov5640.txt | 45 + > Documentation/devicetree/bindings/media/imx.txt | 74 + > .../bindings/media/video-multiplexer.txt | 59 + > Documentation/media/uapi/mediactl/media-types.rst | 22 + > Documentation/media/uapi/v4l/vidioc-dqevent.rst | 12 + > Documentation/media/v4l-drivers/imx.rst | 560 +++++ > Documentation/media/videodev2.h.rst.exceptions | 2 + > 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 | 11 + > drivers/media/i2c/Kconfig | 7 + > drivers/media/i2c/Makefile | 1 + > drivers/media/i2c/ov5640.c | 2231 ++++++++++++++++++++ > drivers/media/platform/Kconfig | 8 + > drivers/media/platform/Makefile | 2 + > drivers/media/platform/video-multiplexer.c | 498 +++++ > drivers/media/v4l2-core/v4l2-mc.c | 48 + > drivers/media/v4l2-core/v4l2-subdev.c | 50 + > 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 | 17 + > drivers/staging/media/imx/imx-ic-common.c | 113 + > drivers/staging/media/imx/imx-ic-prp.c | 497 +++++ > drivers/staging/media/imx/imx-ic-prpencvf.c | 1236 +++++++++++ > drivers/staging/media/imx/imx-ic.h | 38 + > drivers/staging/media/imx/imx-media-capture.c | 694 ++++++ > drivers/staging/media/imx/imx-media-csi.c | 1595 ++++++++++++++ > drivers/staging/media/imx/imx-media-dev.c | 522 +++++ > 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 | 1009 +++++++++ > drivers/staging/media/imx/imx-media-vdic.c | 949 +++++++++ > drivers/staging/media/imx/imx-media.h | 311 +++ > drivers/staging/media/imx/imx6-mipi-csi2.c | 725 +++++++ > include/media/imx.h | 15 + > include/media/v4l2-mc.h | 25 + > include/media/v4l2-subdev.h | 10 + > include/uapi/Kbuild | 1 + > include/uapi/linux/media.h | 6 + > include/uapi/linux/v4l2-controls.h | 4 + > include/uapi/linux/videodev2.h | 2 + > include/uapi/media/Kbuild | 2 + > include/uapi/media/imx.h | 21 + > 54 files changed, 13262 insertions(+), 27 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 > -- 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-03-11 00:30 +0100 |
| Message-ID | <tjC8V-2w2-13@gated-at.bofh.it> |
| In reply to | #1598070 |
On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote: > Version 5 gives me no v4l2 controls exposed through the video device > interface. > > Just like with version 4, version 5 is completely useless with IMX219: > > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > > So, like v4, I can't do any further testing. > Is the imx219 placing the csi-2 bus in LP-11 state on exit from s_power(ON)? I realize that probably means bringing the chip up to a completely operational state and then setting it to stream OFF in the s_power() op. The same had to be done for the OV5640. Steve
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-12 18:50 +0100 |
| Message-ID | <tkfMZ-4Kl-1@gated-at.bofh.it> |
| In reply to | #1598172 |
On Fri, Mar 10, 2017 at 03:20:34PM -0800, Steve Longerbeam wrote: > > > On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote: > >Version 5 gives me no v4l2 controls exposed through the video device > >interface. > > > >Just like with version 4, version 5 is completely useless with IMX219: > > > >imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > >ipu1_csi0: pipeline start failed with -110 > >imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > >ipu1_csi0: pipeline start failed with -110 > >imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > >ipu1_csi0: pipeline start failed with -110 > > > >So, like v4, I can't do any further testing. > > > > Is the imx219 placing the csi-2 bus in LP-11 state on exit > from s_power(ON)? > > I realize that probably means bringing the chip up to a > completely operational state and then setting it to stream > OFF in the s_power() op. > > The same had to be done for the OV5640. What do you suggest - setting it to the highest CSI2 bus speed that it supports? That's likely to be over the maximum data rate specified for iMX6Q if it's wired up using four lanes. Also, as I've already said, I think that powering on the sensor just because it's got an enabled media-controller link is a silly idea. Right now, the only way of using the imx6 capture stuff is to manually configure it with media-ctl, which means that happens either at boot due to a custom boot script, or when you first use it (by manually running a script.) This results in the sensor staying powered from that point onwards, wasting power unnecessarily. -- 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-03-12 01:40 +0100 |
| Message-ID | <tjZId-27o-1@gated-at.bofh.it> |
| In reply to | #1598070 |
[Multipart message — attachments visible in raw view] — view raw
On 03/10/2017 12:13 PM, Russell King - ARM Linux wrote: > Version 5 gives me no v4l2 controls exposed through the video device > interface. > > Just like with version 4, version 5 is completely useless with IMX219: > > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > ipu1_csi0: pipeline start failed with -110 > If it's too difficult to get the imx219 csi-2 transmitter into the LP-11 state on power on, perhaps the csi-2 receiver can be a little more lenient on the transmitter and make the LP-11 timeout a warning instead of error-out. Can you try the attached change on top of the version 5 patchset? If that doesn't work then you're just going to have to fix the bug in imx219. Steve
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-12 21:00 +0100 |
| Message-ID | <tkhOO-65d-9@gated-at.bofh.it> |
| In reply to | #1598516 |
On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote: > If it's too difficult to get the imx219 csi-2 transmitter into the > LP-11 state on power on, perhaps the csi-2 receiver can be a little > more lenient on the transmitter and make the LP-11 timeout a warning > instead of error-out. > > Can you try the attached change on top of the version 5 patchset? > > If that doesn't work then you're just going to have to fix the bug > in imx219. That patch gets me past that hurdle, only to reveal that there's another issue: imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 imx219 0-0010: VT: pixclk 139200000Hz line 80742Hz frame 30.0Hz imx219 0-0010: VT: line period 12385ns imx219 0-0010: OP: pixclk 38500000Hz, 2 lanes, 308Mbps peak each imx219 0-0010: OP: 3288 bits/line/lane act=10675ns lp/idle=1710ns ipu1_csi0: csi_idmac_setup failed: -22 ipu1_csi0: pipeline start failed with -22 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1860 at /home/rmk/git/linux-rmk/drivers/media/v4l2-core/videobuf2-core.c:1340 vb2_start_streaming+0x124/0x1b4 [videobuf2_core] -- 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-03-12 21:10 +0100 |
| Message-ID | <tkhYu-6pU-19@gated-at.bofh.it> |
| In reply to | #1598728 |
On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote: > On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote: >> If it's too difficult to get the imx219 csi-2 transmitter into the >> LP-11 state on power on, perhaps the csi-2 receiver can be a little >> more lenient on the transmitter and make the LP-11 timeout a warning >> instead of error-out. >> >> Can you try the attached change on top of the version 5 patchset? >> >> If that doesn't work then you're just going to have to fix the bug >> in imx219. > > That patch gets me past that hurdle, only to reveal that there's another > issue: Yeah, ipu_cpmem_set_image() failed because it doesn't recognize the bayer formats. Wait, didn't we fix this already? I've lost track. Ah, right, we were going to move this support into the IPUv3 driver, but in the meantime I think you had some patches to get around this. Steve > > imx6-mipi-csi2: LP-11 timeout, phy_state = 0x00000200 > imx219 0-0010: VT: pixclk 139200000Hz line 80742Hz frame 30.0Hz > imx219 0-0010: VT: line period 12385ns > imx219 0-0010: OP: pixclk 38500000Hz, 2 lanes, 308Mbps peak each > imx219 0-0010: OP: 3288 bits/line/lane act=10675ns lp/idle=1710ns > ipu1_csi0: csi_idmac_setup failed: -22 > ipu1_csi0: pipeline start failed with -22 > ------------[ cut here ]------------ > WARNING: CPU: 0 PID: 1860 at /home/rmk/git/linux-rmk/drivers/media/v4l2-core/videobuf2-core.c:1340 vb2_start_streaming+0x124/0x1b4 [videobuf2_core] >
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-12 21:30 +0100 |
| Message-ID | <tkihP-6wS-1@gated-at.bofh.it> |
| In reply to | #1598735 |
On Sun, Mar 12, 2017 at 01:05:06PM -0700, Steve Longerbeam wrote:
>
>
> On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote:
> >On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
> >>If it's too difficult to get the imx219 csi-2 transmitter into the
> >>LP-11 state on power on, perhaps the csi-2 receiver can be a little
> >>more lenient on the transmitter and make the LP-11 timeout a warning
> >>instead of error-out.
> >>
> >>Can you try the attached change on top of the version 5 patchset?
> >>
> >>If that doesn't work then you're just going to have to fix the bug
> >>in imx219.
> >
> >That patch gets me past that hurdle, only to reveal that there's another
> >issue:
>
> Yeah, ipu_cpmem_set_image() failed because it doesn't recognize the
> bayer formats. Wait, didn't we fix this already? I've lost track.
> Ah, right, we were going to move this support into the IPUv3 driver,
> but in the meantime I think you had some patches to get around this.
What I had was this patch for your v3. I never got to testing your
v4 because of the LP-11 problem.
In v5, you've changed to propagate the ipu_cpmem_set_image() error
code to avoid the resulting corruption, but that leaves the other bits
of this patch unaddressed, along my "media: imx: smfc: add support
for bayer formats" patch.
Your driver basically has no support for bayer formats.
diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
index 313732201a52..4351c0365cf4 100644
--- a/drivers/staging/media/imx/imx-smfc.c
+++ b/drivers/staging/media/imx/imx-smfc.c
@@ -234,11 +234,6 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
buf1 = imx_media_dma_buf_get_next_queued(priv->out_ring);
priv->next = buf1;
- image.phys0 = buf0->phys;
- image.phys1 = buf1->phys;
- ipu_cpmem_set_image(priv->smfc_ch, &image);
-
-
switch (image.pix.pixelformat) {
case V4L2_PIX_FMT_SBGGR8:
case V4L2_PIX_FMT_SGBRG8:
@@ -247,6 +242,10 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
burst_size = 8;
passthrough = true;
passthrough_bits = 8;
+ ipu_cpmem_set_resolution(priv->smfc_ch, image.rect.width, image.rect.height);
+ ipu_cpmem_set_stride(priv->smfc_ch, image.pix.bytesperline);
+ ipu_cpmem_set_buffer(priv->smfc_ch, 0, buf0->phys);
+ ipu_cpmem_set_buffer(priv->smfc_ch, 1, buf1->phys);
break;
case V4L2_PIX_FMT_SBGGR16:
@@ -256,9 +255,17 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
burst_size = 4;
passthrough = true;
passthrough_bits = 16;
+ ipu_cpmem_set_resolution(priv->smfc_ch, image.rect.width, image.rect.height);
+ ipu_cpmem_set_stride(priv->smfc_ch, image.pix.bytesperline);
+ ipu_cpmem_set_buffer(priv->smfc_ch, 0, buf0->phys);
+ ipu_cpmem_set_buffer(priv->smfc_ch, 1, buf1->phys);
break;
default:
+ image.phys0 = buf0->phys;
+ image.phys1 = buf1->phys;
+ ipu_cpmem_set_image(priv->smfc_ch, &image);
+
burst_size = (outfmt->width & 0xf) ? 8 : 16;
/*
--
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-03-13 05:40 +0100 |
| Message-ID | <tkpW1-3nD-3@gated-at.bofh.it> |
| In reply to | #1598741 |
On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote:
> On Sun, Mar 12, 2017 at 01:05:06PM -0700, Steve Longerbeam wrote:
>>
>>
>> On 03/12/2017 12:57 PM, Russell King - ARM Linux wrote:
>>> On Sat, Mar 11, 2017 at 04:30:53PM -0800, Steve Longerbeam wrote:
>>>> If it's too difficult to get the imx219 csi-2 transmitter into the
>>>> LP-11 state on power on, perhaps the csi-2 receiver can be a little
>>>> more lenient on the transmitter and make the LP-11 timeout a warning
>>>> instead of error-out.
>>>>
>>>> Can you try the attached change on top of the version 5 patchset?
>>>>
>>>> If that doesn't work then you're just going to have to fix the bug
>>>> in imx219.
>>>
>>> That patch gets me past that hurdle, only to reveal that there's another
>>> issue:
>>
>> Yeah, ipu_cpmem_set_image() failed because it doesn't recognize the
>> bayer formats. Wait, didn't we fix this already? I've lost track.
>> Ah, right, we were going to move this support into the IPUv3 driver,
>> but in the meantime I think you had some patches to get around this.
>
> What I had was this patch for your v3. I never got to testing your
> v4 because of the LP-11 problem.
>
> In v5, you've changed to propagate the ipu_cpmem_set_image() error
> code to avoid the resulting corruption, but that leaves the other bits
> of this patch unaddressed, along my "media: imx: smfc: add support
> for bayer formats" patch.
>
> Your driver basically has no support for bayer formats.
You added the patches to this driver that adds the bayer support,
I don't think there is anything more required of the driver at this
point to support bayer, the remaining work needs to happen in the IPUv3
driver.
I'll see if I have time to write that patch to IPUv3, but it's simple,
in fact what you wrote below can be translate directly into
ipu_cpmem_set_image(). There's a few other places bayer needs to be
treated in IPUv3, but it should be obvious by grepping for the
reference to pixel formats.
Steve
>
> diff --git a/drivers/staging/media/imx/imx-smfc.c b/drivers/staging/media/imx/imx-smfc.c
> index 313732201a52..4351c0365cf4 100644
> --- a/drivers/staging/media/imx/imx-smfc.c
> +++ b/drivers/staging/media/imx/imx-smfc.c
> @@ -234,11 +234,6 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
> buf1 = imx_media_dma_buf_get_next_queued(priv->out_ring);
> priv->next = buf1;
>
> - image.phys0 = buf0->phys;
> - image.phys1 = buf1->phys;
> - ipu_cpmem_set_image(priv->smfc_ch, &image);
> -
> -
> switch (image.pix.pixelformat) {
> case V4L2_PIX_FMT_SBGGR8:
> case V4L2_PIX_FMT_SGBRG8:
> @@ -247,6 +242,10 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
> burst_size = 8;
> passthrough = true;
> passthrough_bits = 8;
> + ipu_cpmem_set_resolution(priv->smfc_ch, image.rect.width, image.rect.height);
> + ipu_cpmem_set_stride(priv->smfc_ch, image.pix.bytesperline);
> + ipu_cpmem_set_buffer(priv->smfc_ch, 0, buf0->phys);
> + ipu_cpmem_set_buffer(priv->smfc_ch, 1, buf1->phys);
> break;
>
> case V4L2_PIX_FMT_SBGGR16:
> @@ -256,9 +255,17 @@ static void imx_smfc_setup_channel(struct imx_smfc_priv *priv)
> burst_size = 4;
> passthrough = true;
> passthrough_bits = 16;
> + ipu_cpmem_set_resolution(priv->smfc_ch, image.rect.width, image.rect.height);
> + ipu_cpmem_set_stride(priv->smfc_ch, image.pix.bytesperline);
> + ipu_cpmem_set_buffer(priv->smfc_ch, 0, buf0->phys);
> + ipu_cpmem_set_buffer(priv->smfc_ch, 1, buf1->phys);
> break;
>
> default:
> + image.phys0 = buf0->phys;
> + image.phys1 = buf1->phys;
> + ipu_cpmem_set_image(priv->smfc_ch, &image);
> +
> burst_size = (outfmt->width & 0xf) ? 8 : 16;
>
> /*
>
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-13 09:20 +0100 |
| Message-ID | <tktmW-66Q-3@gated-at.bofh.it> |
| In reply to | #1598844 |
On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote:
> On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote:
> >What I had was this patch for your v3. I never got to testing your
> >v4 because of the LP-11 problem.
> >
> >In v5, you've changed to propagate the ipu_cpmem_set_image() error
> >code to avoid the resulting corruption, but that leaves the other bits
> >of this patch unaddressed, along my "media: imx: smfc: add support
> >for bayer formats" patch.
> >
> >Your driver basically has no support for bayer formats.
>
> You added the patches to this driver that adds the bayer support,
> I don't think there is anything more required of the driver at this
> point to support bayer, the remaining work needs to happen in the IPUv3
> driver.
There is more work, because the way you've merged my changes to
imx_smfc_setup_channel() into csi_idmac_setup_channel() is wrong with
respect to the burst size.
You always set it to 8 or 16 depending on the width:
burst_size = (image.pix.width & 0xf) ? 8 : 16;
ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
and then you have my switch() statement which assigns burst_size.
My _tested_ code removed the above, added the switch, which had
a default case which reflected the above setting:
default:
burst_size = (outfmt->width & 0xf) ? 8 : 16;
and then went on to set the burst size _after_ the switch statement:
ipu_cpmem_set_burstsize(priv->smfc_ch, burst_size);
The effect is unchanged for non-bayer formats. For bayer formats, the
burst size is determined by the bayer data size.
So, even if it's appropriate to fix ipu_cpmem_set_image(), fixing the
above is still required.
I'm not convinced that fixing ipu_cpmem_set_image() is even the best
solution - it's not as trivial as it looks on the surface:
ipu_cpmem_set_resolution(ch, image->rect.width, image->rect.height);
ipu_cpmem_set_stride(ch, pix->bytesperline);
this is fine, it doesn't depend on the format. However, the next line:
ipu_cpmem_set_fmt(ch, v4l2_pix_fmt_to_drm_fourcc(pix->pixelformat));
does - v4l2_pix_fmt_to_drm_fourcc() is a locally defined function (it
isn't v4l2 code) that converts a v4l2 pixel format to a DRM fourcc.
DRM knows nothing about bayer formats, there aren't fourcc codes in
DRM for it. The result is that v4l2_pix_fmt_to_drm_fourcc() returns
-EINVAL cast to a u32, which gets passed unchecked into ipu_cpmem_set_fmt().
ipu_cpmem_set_fmt() won't recognise that, and also returns -EINVAL - and
it's a bug that this is not checked and propagated. If it is checked and
propagated, then we need this to support bayer formats, and I don't see
DRM people wanting bayer format fourcc codes added without there being
a real DRM driver wanting to use them.
Then there's the business of calculating the top-left offset of the image,
which for bayer always needs to be an even number of pixels - as this
function takes the top-left offset, it ought to respect it, but if it
doesn't meet this criteria, what should it do? csi_idmac_setup_channel()
always sets them to zero, but that's not really something that
ipu_cpmem_set_image() should assume.
--
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 | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-13 10:40 +0100 |
| Message-ID | <tkuCm-6Ws-25@gated-at.bofh.it> |
| In reply to | #1598929 |
On Mon, Mar 13, 2017 at 08:16:25AM +0000, Russell King - ARM Linux wrote:
> On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote:
> > On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote:
> > >What I had was this patch for your v3. I never got to testing your
> > >v4 because of the LP-11 problem.
> > >
> > >In v5, you've changed to propagate the ipu_cpmem_set_image() error
> > >code to avoid the resulting corruption, but that leaves the other bits
> > >of this patch unaddressed, along my "media: imx: smfc: add support
> > >for bayer formats" patch.
> > >
> > >Your driver basically has no support for bayer formats.
> >
> > You added the patches to this driver that adds the bayer support,
> > I don't think there is anything more required of the driver at this
> > point to support bayer, the remaining work needs to happen in the IPUv3
> > driver.
>
> There is more work, because the way you've merged my changes to
> imx_smfc_setup_channel() into csi_idmac_setup_channel() is wrong with
> respect to the burst size.
>
> You always set it to 8 or 16 depending on the width:
>
> burst_size = (image.pix.width & 0xf) ? 8 : 16;
>
> ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
>
> and then you have my switch() statement which assigns burst_size.
> My _tested_ code removed the above, added the switch, which had
> a default case which reflected the above setting:
>
> default:
> burst_size = (outfmt->width & 0xf) ? 8 : 16;
>
> and then went on to set the burst size _after_ the switch statement:
>
> ipu_cpmem_set_burstsize(priv->smfc_ch, burst_size);
>
> The effect is unchanged for non-bayer formats. For bayer formats, the
> burst size is determined by the bayer data size.
>
> So, even if it's appropriate to fix ipu_cpmem_set_image(), fixing the
> above is still required.
>
> I'm not convinced that fixing ipu_cpmem_set_image() is even the best
> solution - it's not as trivial as it looks on the surface:
>
> ipu_cpmem_set_resolution(ch, image->rect.width, image->rect.height);
> ipu_cpmem_set_stride(ch, pix->bytesperline);
>
> this is fine, it doesn't depend on the format. However, the next line:
>
> ipu_cpmem_set_fmt(ch, v4l2_pix_fmt_to_drm_fourcc(pix->pixelformat));
>
> does - v4l2_pix_fmt_to_drm_fourcc() is a locally defined function (it
> isn't v4l2 code) that converts a v4l2 pixel format to a DRM fourcc.
> DRM knows nothing about bayer formats, there aren't fourcc codes in
> DRM for it. The result is that v4l2_pix_fmt_to_drm_fourcc() returns
> -EINVAL cast to a u32, which gets passed unchecked into ipu_cpmem_set_fmt().
>
> ipu_cpmem_set_fmt() won't recognise that, and also returns -EINVAL - and
> it's a bug that this is not checked and propagated. If it is checked and
> propagated, then we need this to support bayer formats, and I don't see
> DRM people wanting bayer format fourcc codes added without there being
> a real DRM driver wanting to use them.
>
> Then there's the business of calculating the top-left offset of the image,
> which for bayer always needs to be an even number of pixels - as this
> function takes the top-left offset, it ought to respect it, but if it
> doesn't meet this criteria, what should it do? csi_idmac_setup_channel()
> always sets them to zero, but that's not really something that
> ipu_cpmem_set_image() should assume.
For the time being, I've restored the functionality along the same lines
as I originally had. This seems to get me working capture, but might
break non-bayer passthrough mode:
diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
index fc0036aa84d0..df336971a009 100644
--- a/drivers/staging/media/imx/imx-media-csi.c
+++ b/drivers/staging/media/imx/imx-media-csi.c
@@ -314,14 +314,6 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
image.phys0 = phys[0];
image.phys1 = phys[1];
- ret = ipu_cpmem_set_image(priv->idmac_ch, &image);
- if (ret)
- return ret;
-
- burst_size = (image.pix.width & 0xf) ? 8 : 16;
-
- ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
-
/*
* Check for conditions that require the IPU to handle the
* data internally as generic data, aka passthrough mode:
@@ -346,15 +338,29 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
passthrough_bits = 16;
break;
default:
+ burst_size = (image.pix.width & 0xf) ? 8 : 16;
passthrough = (sensor_ep->bus_type != V4L2_MBUS_CSI2 &&
sensor_ep->bus.parallel.bus_width >= 16);
passthrough_bits = 16;
break;
}
- if (passthrough)
+ if (passthrough) {
+ ipu_cpmem_set_resolution(priv->idmac_ch, image.rect.width,
+ image.rect.height);
+ ipu_cpmem_set_stride(priv->idmac_ch, image.pix.bytesperline);
+ ipu_cpmem_set_buffer(priv->idmac_ch, 0, image.phys0);
+ ipu_cpmem_set_buffer(priv->idmac_ch, 1, image.phys1);
+ ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
ipu_cpmem_set_format_passthrough(priv->idmac_ch,
passthrough_bits);
+ } else {
+ ret = ipu_cpmem_set_image(priv->idmac_ch, &image);
+ if (ret)
+ return ret;
+
+ ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
+ }
/*
* Set the channel for the direct CSI-->memory via SMFC
--
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-03-14 00:40 +0100 |
| Message-ID | <tkHJf-8hM-13@gated-at.bofh.it> |
| In reply to | #1599146 |
er, I meant I will integrate this patch. And verify/fix
possible breakage for non-bayer passthrough.
Steve
On 03/13/2017 02:30 AM, Russell King - ARM Linux wrote:
> On Mon, Mar 13, 2017 at 08:16:25AM +0000, Russell King - ARM Linux wrote:
>> On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote:
>>> On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote:
>>>> What I had was this patch for your v3. I never got to testing your
>>>> v4 because of the LP-11 problem.
>>>>
>>>> In v5, you've changed to propagate the ipu_cpmem_set_image() error
>>>> code to avoid the resulting corruption, but that leaves the other bits
>>>> of this patch unaddressed, along my "media: imx: smfc: add support
>>>> for bayer formats" patch.
>>>>
>>>> Your driver basically has no support for bayer formats.
>>> You added the patches to this driver that adds the bayer support,
>>> I don't think there is anything more required of the driver at this
>>> point to support bayer, the remaining work needs to happen in the IPUv3
>>> driver.
>> There is more work, because the way you've merged my changes to
>> imx_smfc_setup_channel() into csi_idmac_setup_channel() is wrong with
>> respect to the burst size.
>>
>> You always set it to 8 or 16 depending on the width:
>>
>> burst_size = (image.pix.width & 0xf) ? 8 : 16;
>>
>> ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
>>
>> and then you have my switch() statement which assigns burst_size.
>> My _tested_ code removed the above, added the switch, which had
>> a default case which reflected the above setting:
>>
>> default:
>> burst_size = (outfmt->width & 0xf) ? 8 : 16;
>>
>> and then went on to set the burst size _after_ the switch statement:
>>
>> ipu_cpmem_set_burstsize(priv->smfc_ch, burst_size);
>>
>> The effect is unchanged for non-bayer formats. For bayer formats, the
>> burst size is determined by the bayer data size.
>>
>> So, even if it's appropriate to fix ipu_cpmem_set_image(), fixing the
>> above is still required.
>>
>> I'm not convinced that fixing ipu_cpmem_set_image() is even the best
>> solution - it's not as trivial as it looks on the surface:
>>
>> ipu_cpmem_set_resolution(ch, image->rect.width, image->rect.height);
>> ipu_cpmem_set_stride(ch, pix->bytesperline);
>>
>> this is fine, it doesn't depend on the format. However, the next line:
>>
>> ipu_cpmem_set_fmt(ch, v4l2_pix_fmt_to_drm_fourcc(pix->pixelformat));
>>
>> does - v4l2_pix_fmt_to_drm_fourcc() is a locally defined function (it
>> isn't v4l2 code) that converts a v4l2 pixel format to a DRM fourcc.
>> DRM knows nothing about bayer formats, there aren't fourcc codes in
>> DRM for it. The result is that v4l2_pix_fmt_to_drm_fourcc() returns
>> -EINVAL cast to a u32, which gets passed unchecked into ipu_cpmem_set_fmt().
>>
>> ipu_cpmem_set_fmt() won't recognise that, and also returns -EINVAL - and
>> it's a bug that this is not checked and propagated. If it is checked and
>> propagated, then we need this to support bayer formats, and I don't see
>> DRM people wanting bayer format fourcc codes added without there being
>> a real DRM driver wanting to use them.
>>
>> Then there's the business of calculating the top-left offset of the image,
>> which for bayer always needs to be an even number of pixels - as this
>> function takes the top-left offset, it ought to respect it, but if it
>> doesn't meet this criteria, what should it do? csi_idmac_setup_channel()
>> always sets them to zero, but that's not really something that
>> ipu_cpmem_set_image() should assume.
> For the time being, I've restored the functionality along the same lines
> as I originally had. This seems to get me working capture, but might
> break non-bayer passthrough mode:
>
> diff --git a/drivers/staging/media/imx/imx-media-csi.c b/drivers/staging/media/imx/imx-media-csi.c
> index fc0036aa84d0..df336971a009 100644
> --- a/drivers/staging/media/imx/imx-media-csi.c
> +++ b/drivers/staging/media/imx/imx-media-csi.c
> @@ -314,14 +314,6 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
> image.phys0 = phys[0];
> image.phys1 = phys[1];
>
> - ret = ipu_cpmem_set_image(priv->idmac_ch, &image);
> - if (ret)
> - return ret;
> -
> - burst_size = (image.pix.width & 0xf) ? 8 : 16;
> -
> - ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
> -
> /*
> * Check for conditions that require the IPU to handle the
> * data internally as generic data, aka passthrough mode:
> @@ -346,15 +338,29 @@ static int csi_idmac_setup_channel(struct csi_priv *priv)
> passthrough_bits = 16;
> break;
> default:
> + burst_size = (image.pix.width & 0xf) ? 8 : 16;
> passthrough = (sensor_ep->bus_type != V4L2_MBUS_CSI2 &&
> sensor_ep->bus.parallel.bus_width >= 16);
> passthrough_bits = 16;
> break;
> }
>
> - if (passthrough)
> + if (passthrough) {
> + ipu_cpmem_set_resolution(priv->idmac_ch, image.rect.width,
> + image.rect.height);
> + ipu_cpmem_set_stride(priv->idmac_ch, image.pix.bytesperline);
> + ipu_cpmem_set_buffer(priv->idmac_ch, 0, image.phys0);
> + ipu_cpmem_set_buffer(priv->idmac_ch, 1, image.phys1);
> + ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
> ipu_cpmem_set_format_passthrough(priv->idmac_ch,
> passthrough_bits);
> + } else {
> + ret = ipu_cpmem_set_image(priv->idmac_ch, &image);
> + if (ret)
> + return ret;
> +
> + ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size);
> + }
>
> /*
> * Set the channel for the direct CSI-->memory via SMFC
>
>
[toc] | [prev] | [next] | [standalone]
| From | Steve Longerbeam <steve_longerbeam@mentor.com> |
|---|---|
| Date | 2017-03-14 00:40 +0100 |
| Message-ID | <tkHJf-8hM-3@gated-at.bofh.it> |
| In reply to | #1598929 |
On 03/13/2017 01:16 AM, Russell King - ARM Linux wrote: > On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve Longerbeam wrote: >> On 03/12/2017 01:22 PM, Russell King - ARM Linux wrote: >>> What I had was this patch for your v3. I never got to testing your >>> v4 because of the LP-11 problem. >>> >>> In v5, you've changed to propagate the ipu_cpmem_set_image() error >>> code to avoid the resulting corruption, but that leaves the other bits >>> of this patch unaddressed, along my "media: imx: smfc: add support >>> for bayer formats" patch. >>> >>> Your driver basically has no support for bayer formats. >> You added the patches to this driver that adds the bayer support, >> I don't think there is anything more required of the driver at this >> point to support bayer, the remaining work needs to happen in the IPUv3 >> driver. > There is more work, because the way you've merged my changes to > imx_smfc_setup_channel() into csi_idmac_setup_channel() is wrong with > respect to the burst size. > > You always set it to 8 or 16 depending on the width: > > burst_size = (image.pix.width & 0xf) ? 8 : 16; > > ipu_cpmem_set_burstsize(priv->idmac_ch, burst_size); > > and then you have my switch() statement which assigns burst_size. > My _tested_ code removed the above, added the switch, which had > a default case which reflected the above setting: > > default: > burst_size = (outfmt->width & 0xf) ? 8 : 16; > > and then went on to set the burst size _after_ the switch statement: > > ipu_cpmem_set_burstsize(priv->smfc_ch, burst_size); > > The effect is unchanged for non-bayer formats. For bayer formats, the > burst size is determined by the bayer data size. > > So, even if it's appropriate to fix ipu_cpmem_set_image(), fixing the > above is still required. Oops, sorry missed that. I'll fix. > > I'm not convinced that fixing ipu_cpmem_set_image() is even the best > solution - it's not as trivial as it looks on the surface: > > ipu_cpmem_set_resolution(ch, image->rect.width, image->rect.height); > ipu_cpmem_set_stride(ch, pix->bytesperline); > > this is fine, it doesn't depend on the format. However, the next line: > > ipu_cpmem_set_fmt(ch, v4l2_pix_fmt_to_drm_fourcc(pix->pixelformat)); > > does - v4l2_pix_fmt_to_drm_fourcc() is a locally defined function (it > isn't v4l2 code) that converts a v4l2 pixel format to a DRM fourcc. > DRM knows nothing about bayer formats, there aren't fourcc codes in > DRM for it. right, yeah that's a problem. > The result is that v4l2_pix_fmt_to_drm_fourcc() returns > -EINVAL cast to a u32, which gets passed unchecked into ipu_cpmem_set_fmt(). Ugh. > > ipu_cpmem_set_fmt() won't recognise that, and also returns -EINVAL - and > it's a bug that this is not checked and propagated. If it is checked and > propagated, then we need this to support bayer formats, and I don't see > DRM people wanting bayer format fourcc codes added without there being > a real DRM driver wanting to use them. true. > > Then there's the business of calculating the top-left offset of the image, > which for bayer always needs to be an even number of pixels - as this > function takes the top-left offset, it ought to respect it, but if it > doesn't meet this criteria, what should it do? csi_idmac_setup_channel() > always sets them to zero, but that's not really something that > ipu_cpmem_set_image() should assume. Well, I will integrate your patch above. Thanks for doing this work for me. We do need to address the issues you brought up in ipu_cpmem at some point. Steve
[toc] | [prev] | [next] | [standalone]
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
Back to top | Article view | linux.kernel
csiph-web