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-12 23:20 +0100 |
| Articles | 7 on this page of 87 — 9 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
[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
[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
[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
[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
[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
[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 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 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
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-12 21:50 +0100 |
| Message-ID | <tkiBb-6FF-13@gated-at.bofh.it> |
| In reply to | #1598743 |
On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote: > But hold on, if my logic is correct, then why did the CSI power-off > get reached in your case, multiple times? Yes I think there is a bug, > link_notify() is not checking if the link has already been disabled. > I will fix this. But I'm surprised media core's link_notify handling > doesn't do this. Well, I think there's something incredibly fishy going on here. I turned that dev_dbg() at the top of the function into a dev_info(), and I get: root@hbi2ex:~# dmesg |grep -A2 imx-ipuv3-csi [ 53.370949] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF [ 53.371015] ------------[ cut here ]------------ [ 53.371075] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi] -- [ 53.372624] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF [ 53.372637] ------------[ cut here ]------------ [ 53.372663] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi] There isn't a power on event being generated before these two power off events. I don't see a power on event even when I attempt to start streaming either (which fails due to the lack of bayer support.) -- 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-12 22:20 +0100 |
| Message-ID | <tkj4d-77v-17@gated-at.bofh.it> |
| In reply to | #1598746 |
On Sun, Mar 12, 2017 at 08:40:37PM +0000, Russell King - ARM Linux wrote: > On Sun, Mar 12, 2017 at 01:36:32PM -0700, Steve Longerbeam wrote: > > But hold on, if my logic is correct, then why did the CSI power-off > > get reached in your case, multiple times? Yes I think there is a bug, > > link_notify() is not checking if the link has already been disabled. > > I will fix this. But I'm surprised media core's link_notify handling > > doesn't do this. > > Well, I think there's something incredibly fishy going on here. I > turned that dev_dbg() at the top of the function into a dev_info(), > and I get: > > root@hbi2ex:~# dmesg |grep -A2 imx-ipuv3-csi > [ 53.370949] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF > [ 53.371015] ------------[ cut here ]------------ > [ 53.371075] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi] > -- > [ 53.372624] imx-ipuv3-csi imx-ipuv3-csi.0: power OFF > [ 53.372637] ------------[ cut here ]------------ > [ 53.372663] WARNING: CPU: 0 PID: 1515 at drivers/staging/media/imx/imx-media-csi.c:806 csi_s_power+0xb8/0xd0 [imx_media_csi] > > There isn't a power on event being generated before these two power > off events. I don't see a power on event even when I attempt to > start streaming either (which fails due to the lack of bayer > support.) Found it - my imx219 driver returns '1' from its s_power function when powering up, which triggers a bug in your code - when imx_media_set_power() fails to power up, you call imx_media_set_power() telling it to power everything off - including devices that are already powered off. This is really bad news - s_power() may be called via other paths, such as when the subdev is opened. -- 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-12 20:50 +0100 |
| Message-ID | <tkhF8-61I-9@gated-at.bofh.it> |
| In reply to | #1596626 |
Another issue.
The "reboot and the /dev/video* devices come up in a completely
different order" problem seems to exist with this version.
The dot graph I supplied previously had "ipu1_csi0 capture" on
/dev/video4. I've just rebooted, and now I find it's on
/dev/video2 instead.
Here's the extract from the .dot file of the old listing:
n00000018 [label="ipu1_ic_prpenc capture\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
n00000021 [label="ipu1_ic_prpvf capture\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
n0000002e [label="ipu2_ic_prpenc capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
n00000037 [label="ipu2_ic_prpvf capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
n00000048 [label="ipu1_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
n00000052 [label="ipu1_csi1 capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
n00000062 [label="ipu2_csi0 capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
n0000006c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
and here's the same after reboot:
n00000014 [label="ipu1_csi0 capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
n0000001e [label="ipu1_csi1 capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
n00000028 [label="ipu2_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
n00000035 [label="ipu1_ic_prpenc capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
n0000003e [label="ipu1_ic_prpvf capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
n0000004c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
n00000059 [label="ipu2_ic_prpenc capture\n/dev/video8", shape=box, style=filled, fillcolor=yellow]
n00000062 [label="ipu2_ic_prpvf capture\n/dev/video9", shape=box, style=filled, fillcolor=yellow]
(/dev/video0 and /dev/video1 are taken up by CODA, since I updated the
names of the firmware files, and now CODA initialises... seems the
back-compat filenames don't work, but that's not a problem with imx6
capture.)
--
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-11@gated-at.bofh.it> |
| In reply to | #1598727 |
On 03/12/2017 12:47 PM, Russell King - ARM Linux wrote: > Another issue. > > The "reboot and the /dev/video* devices come up in a completely > different order" problem seems to exist with this version. > > The dot graph I supplied previously had "ipu1_csi0 capture" on > /dev/video4. I've just rebooted, and now I find it's on > /dev/video2 instead. Yes, that's still an issue I haven't had the chance to get to yet. It could be as simple as passing a fixed device node # to video_register_device(), but something tells me it won't be that easy. But I'll get to this in next version. Steve > > Here's the extract from the .dot file of the old listing: > > n00000018 [label="ipu1_ic_prpenc capture\n/dev/video0", shape=box, style=filled, fillcolor=yellow] > n00000021 [label="ipu1_ic_prpvf capture\n/dev/video1", shape=box, style=filled, fillcolor=yellow] > n0000002e [label="ipu2_ic_prpenc capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow] > n00000037 [label="ipu2_ic_prpvf capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow] > n00000048 [label="ipu1_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow] > n00000052 [label="ipu1_csi1 capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow] > n00000062 [label="ipu2_csi0 capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow] > n0000006c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow] > > and here's the same after reboot: > > n00000014 [label="ipu1_csi0 capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow] > n0000001e [label="ipu1_csi1 capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow] > n00000028 [label="ipu2_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow] > n00000035 [label="ipu1_ic_prpenc capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow] > n0000003e [label="ipu1_ic_prpvf capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow] > n0000004c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow] > n00000059 [label="ipu2_ic_prpenc capture\n/dev/video8", shape=box, style=filled, fillcolor=yellow] > n00000062 [label="ipu2_ic_prpvf capture\n/dev/video9", shape=box, style=filled, fillcolor=yellow] > > (/dev/video0 and /dev/video1 are taken up by CODA, since I updated the > names of the firmware files, and now CODA initialises... seems the > back-compat filenames don't work, but that's not a problem with imx6 > capture.) >
[toc] | [prev] | [next] | [standalone]
| From | Mauro Carvalho Chehab <mchehab@s-opensource.com> |
|---|---|
| Date | 2017-03-12 22:00 +0100 |
| Message-ID | <tkiKR-6Jc-1@gated-at.bofh.it> |
| In reply to | #1598727 |
Em Sun, 12 Mar 2017 19:47:00 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> escreveu:
> Another issue.
>
> The "reboot and the /dev/video* devices come up in a completely
> different order" problem seems to exist with this version.
>
> The dot graph I supplied previously had "ipu1_csi0 capture" on
> /dev/video4. I've just rebooted, and now I find it's on
> /dev/video2 instead.
>
> Here's the extract from the .dot file of the old listing:
>
> n00000018 [label="ipu1_ic_prpenc capture\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
> n00000021 [label="ipu1_ic_prpvf capture\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
> n0000002e [label="ipu2_ic_prpenc capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
> n00000037 [label="ipu2_ic_prpvf capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
> n00000048 [label="ipu1_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
> n00000052 [label="ipu1_csi1 capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
> n00000062 [label="ipu2_csi0 capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
> n0000006c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
>
> and here's the same after reboot:
>
> n00000014 [label="ipu1_csi0 capture\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
> n0000001e [label="ipu1_csi1 capture\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
> n00000028 [label="ipu2_csi0 capture\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
> n00000035 [label="ipu1_ic_prpenc capture\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
> n0000003e [label="ipu1_ic_prpvf capture\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
> n0000004c [label="ipu2_csi1 capture\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
> n00000059 [label="ipu2_ic_prpenc capture\n/dev/video8", shape=box, style=filled, fillcolor=yellow]
> n00000062 [label="ipu2_ic_prpvf capture\n/dev/video9", shape=box, style=filled, fillcolor=yellow]
>
> (/dev/video0 and /dev/video1 are taken up by CODA, since I updated the
> names of the firmware files, and now CODA initialises... seems the
> back-compat filenames don't work, but that's not a problem with imx6
> capture.)
>
Didn't have time yet to read/comment the other e-mails in this thread.
Yet, as this is a simple issue, let me answer it first.
With regards to /dev/video?, the device number depends on the probing
order, with can be random on SoC drivers, due to the way OF works.
Yet, udev/systemd has some rules that provide an unique name for V4L
devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
runs a small application (v4l_id) with creates a persistent symling
using rules like this:
KERNEL=="video*", ENV{ID_SERIAL}=="?*", SYMLINK+="v4l/by-id/$env{ID_BUS}-$env{ID_SERIAL}-video-index$attr{index}"
Those names are stored at /dev/v4l/by-path.
For example, on Exynos, we have:
$ ls -lctra /dev/v4l/by-path/
total 0
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-13e10000.video-scaler-video-index0 -> ../../video7
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-13e00000.video-scaler-video-index0 -> ../../video6
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11f60000.jpeg-video-index0 -> ../../video4
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11f50000.jpeg-video-index1 -> ../../video3
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11f50000.jpeg-video-index0 -> ../../video2
drwxr-xr-x 3 root root 60 Mar 11 07:19 ..
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11f60000.jpeg-video-index1 -> ../../video5
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11000000.codec-video-index1 -> ../../video1
lrwxrwxrwx 1 root root 12 Mar 11 07:19 platform-11000000.codec-video-index0 -> ../../video0
No matter what driver gets probed first, the above names should not
change.
So, if you want to write a script, the best is to use the /dev/v4l/by-path.
Unfortunately, gstreamer has some issues with that, as some of their plugins
don't seem to allow passing the name of the devnode, but just the number of
/dev/video?.
So, you need some script to convert from /dev/v4l/by-path/foo to
/dev/video?.
What I'm using on Exynos scripts is this logic:
NEEDED1=platform-13e00000.video-scaler-video-index0
DEV1=$(ls -l /dev/v4l/by-path/$NEEDED1|perl -ne ' print $1 if (m,/video(\d+),)')
Then, if I need to talk with this mem2mem driver using the v4l2video
convert plugin, I can launch gst with something like:
gst-launch-1.0 videotestsrc ! v4l2video${DEV1}convert ! fakesink
Thanks,
Mauro
Thanks,
Mauro
[toc] | [prev] | [next] | [standalone]
| From | Russell King - ARM Linux <linux@armlinux.org.uk> |
|---|---|
| Date | 2017-03-12 22:20 +0100 |
| Message-ID | <tkj4d-77v-1@gated-at.bofh.it> |
| In reply to | #1598751 |
On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:
> Yet, udev/systemd has some rules that provide an unique name for V4L
> devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
> runs a small application (v4l_id) with creates a persistent symling
> using rules like this:
>
> KERNEL=="video*", ENV{ID_SERIAL}=="?*", SYMLINK+="v4l/by-id/$env{ID_BUS}-$env{ID_SERIAL}-video-index$attr{index}"
>
> Those names are stored at /dev/v4l/by-path.
This doesn't help:
$ ls -Al /dev/v4l/by-id/
total 0
lrwxrwxrwx 1 root root 13 Mar 12 19:54 usb-Sonix_Technology_Co.__Ltd._USB_2.0_Camera-video-index0 -> ../../video10
$ ls -Al /dev/v4l/by-path/
total 0
lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index0 -> ../../video0
lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index1 -> ../../video1
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index0 -> ../../video2
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index1 -> ../../video3
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index2 -> ../../video4
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index3 -> ../../video5
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index4 -> ../../video6
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index5 -> ../../video7
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index6 -> ../../video8
lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index7 -> ../../video9
lrwxrwxrwx 1 root root 13 Mar 12 19:54 platform-ci_hdrc.0-usb-0:1:1.0-video-index0 -> ../../video10
The problem is the "platform-capture-subsystem-video-index" entries.
These themselves change order. For instance, I now have:
- entity 72: ipu1_csi0 capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video6
which means it's platform-capture-subsystem-video-index4. Before, it
was platform-capture-subsystem-video-index2.
--
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 | Mauro Carvalho Chehab <mchehab@s-opensource.com> |
|---|---|
| Date | 2017-03-12 23:20 +0100 |
| Message-ID | <tkk0h-7Lv-1@gated-at.bofh.it> |
| In reply to | #1598761 |
Em Sun, 12 Mar 2017 21:13:24 +0000
Russell King - ARM Linux <linux@armlinux.org.uk> escreveu:
> On Sun, Mar 12, 2017 at 05:59:28PM -0300, Mauro Carvalho Chehab wrote:
> > Yet, udev/systemd has some rules that provide an unique name for V4L
> > devices at /lib/udev/rules.d/60-persistent-v4l.rules. Basically, it
> > runs a small application (v4l_id) with creates a persistent symling
> > using rules like this:
> >
> > KERNEL=="video*", ENV{ID_SERIAL}=="?*", SYMLINK+="v4l/by-id/$env{ID_BUS}-$env{ID_SERIAL}-video-index$attr{index}"
> >
> > Those names are stored at /dev/v4l/by-path.
>
> This doesn't help:
>
> $ ls -Al /dev/v4l/by-id/
> total 0
> lrwxrwxrwx 1 root root 13 Mar 12 19:54 usb-Sonix_Technology_Co.__Ltd._USB_2.0_Camera-video-index0 -> ../../video10
> $ ls -Al /dev/v4l/by-path/
> total 0
> lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index0 -> ../../video0
> lrwxrwxrwx 1 root root 12 Mar 12 19:54 platform-2040000.vpu-video-index1 -> ../../video1
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index0 -> ../../video2
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index1 -> ../../video3
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index2 -> ../../video4
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index3 -> ../../video5
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index4 -> ../../video6
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index5 -> ../../video7
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index6 -> ../../video8
> lrwxrwxrwx 1 root root 12 Mar 12 20:53 platform-capture-subsystem-video-index7 -> ../../video9
> lrwxrwxrwx 1 root root 13 Mar 12 19:54 platform-ci_hdrc.0-usb-0:1:1.0-video-index0 -> ../../video10
>
> The problem is the "platform-capture-subsystem-video-index" entries.
> These themselves change order. For instance, I now have:
>
> - entity 72: ipu1_csi0 capture (1 pad, 1 link)
> type Node subtype V4L flags 0
> device node name /dev/video6
>
> which means it's platform-capture-subsystem-video-index4. Before, it
> was platform-capture-subsystem-video-index2.
That's a driver problem. v4l_id gets information to build the persistent
name from the result of VIDIOC_QUERYCAP.
In the case of Exynos gsc driver, for example, the information is here:
static int gsc_m2m_querycap(struct file *file, void *fh,
struct v4l2_capability *cap)
{
struct gsc_ctx *ctx = fh_to_ctx(fh);
struct gsc_dev *gsc = ctx->gsc_dev;
strlcpy(cap->driver, GSC_MODULE_NAME, sizeof(cap->driver));
strlcpy(cap->card, GSC_MODULE_NAME " gscaler", sizeof(cap->card));
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s",
dev_name(&gsc->pdev->dev));
cap->device_caps = V4L2_CAP_STREAMING | V4L2_CAP_VIDEO_M2M_MPLANE |
V4L2_CAP_VIDEO_CAPTURE_MPLANE | V4L2_CAP_VIDEO_OUTPUT_MPLANE;
cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
return 0;
}
See that the bus_info there is filled with:
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:%s", dev_name(&gsc->pdev->dev));
From the output you printed, it seems that the i.MX6 is just doing:
snprintf(cap->bus_info, sizeof(cap->bus_info), "platform:");
for some devices.
If you change the i.MX6 driver to do the same, you'll likely be able to
have unique names there too.
Regards,
Mauro
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | linux.kernel
csiph-web