Re: [PATCH v5 00/39] i.MX Media Driver

Le mardi 21 mars 2017 à 11:36 +, Russell King - ARM Linux a écrit : >     warn: v4l2-test-formats.cpp(1187): S_PARM is > supported for buftype 2, but not ENUM_FRAMEINTERVALS >     warn: v4l2-test-formats.cpp(1194): S_PARM is > supported but doesn't report

Re: [PATCH v5 00/39] i.MX Media Driver

On Tue, Mar 21, 2017 at 11:59:02AM +0100, Hans Verkuil wrote: > Ah, good to hear that -s works with MC. I was not sure about that. > Thanks for the feedback! Not soo good on iMX6: $ v4l2-compliance -d /dev/video10 -s --expbuf-device=/dev/video0 ... Input ioctls: test

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/21/17 11:42, Niklas Söderlund wrote: > On 2017-03-20 16:57:54 +0100, Hans Verkuil wrote: >> On 03/20/2017 03:11 PM, Russell King - ARM Linux wrote: >>> On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote: On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: > It's what I

Re: [PATCH v5 00/39] i.MX Media Driver

On 2017-03-20 16:57:54 +0100, Hans Verkuil wrote: > On 03/20/2017 03:11 PM, Russell King - ARM Linux wrote: > > On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote: > >> On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: > >>> It's what I have - remember, not everyone is happy to

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 05:29:07PM +0100, Philipp Zabel wrote: > According to the documentation [1], you are doing the right thing: > > The struct v4l2_subdev_frame_interval pad references a non-existing > pad, or the pad doesn’t support frame intervals. > > But v4l2_subdev_call returns

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, 2017-03-20 at 15:43 +, Russell King - ARM Linux wrote: > On Mon, Mar 20, 2017 at 02:20:16PM +0100, Philipp Zabel wrote: > > To set and read colorimetry information: > > https://patchwork.linuxtv.org/patch/39350/ > > Thanks, I've applied all four of your patches, but there's a side

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/20/2017 03:11 PM, Russell King - ARM Linux wrote: > On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote: >> On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: >>> It's what I have - remember, not everyone is happy to constantly replace >>> their distro packages with random new

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:20:16PM +0100, Philipp Zabel wrote: > To set and read colorimetry information: > https://patchwork.linuxtv.org/patch/39350/ Thanks, I've applied all four of your patches, but there's a side effect from that. Old media-ctl (modified by me): - entity 53: imx219 0-0010

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:57:03PM +0100, Hans Verkuil wrote: > On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: > > It's what I have - remember, not everyone is happy to constantly replace > > their distro packages with random new stuff. > > This is a compliance test, which is

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/20/2017 02:29 PM, Russell King - ARM Linux wrote: > On Mon, Mar 20, 2017 at 02:01:58PM +0100, Hans Verkuil wrote: >> On 03/19/2017 06:54 PM, Steve Longerbeam wrote: >>> >>> >>> On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: What did you do with: ioctl(3,

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 20, 2017 at 02:01:58PM +0100, Hans Verkuil wrote: > On 03/19/2017 06:54 PM, Steve Longerbeam wrote: > > > > > > On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: > >> What did you do with: > >> > >> ioctl(3, VIDIOC_REQBUFS, {count=0, type=0 /* V4L2_BUF_TYPE_??? */, > >>

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, 2017-03-19 at 12:14 +, Russell King - ARM Linux wrote: > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > > On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: > > >0:00:01.955927879 20954 0x15ffe90 INFOv4l2 > >

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, 2017-03-18 at 12:58 -0700, Steve Longerbeam wrote: > > On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: > > Hi Steve, > > > > I've just been trying to get gstreamer to capture and h264 encode > > video from my camera at various frame rates, and what I've discovered > > does not

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 06:54 PM, Steve Longerbeam wrote: > > > On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: >> On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: >>> Right, imx-media-capture.c (the "standard" v4l2 user interface module) >>> is not implementing

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 01:14 PM, Russell King - ARM Linux wrote: > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: >> On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: >>> 0:00:01.955927879 20954 0x15ffe90 INFOv4l2 >>>

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 05:14 AM, Russell King - ARM Linux wrote: On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: 0:00:01.955927879 20954 0x15ffe90 INFOv4l2 gstv4l2object.c:3811:gst_v4l2_object_get_caps:

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 11:37:15AM -0700, Steve Longerbeam wrote: > On 03/19/2017 05:14 AM, Russell King - ARM Linux wrote: > >Right now, CSI doesn't do that - it only looks at the width, height, > >code, and field. > > Correct, there is currently no propagation of the colorimetry > parameters

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 11:51 AM, Russell King - ARM Linux wrote: On Sun, Mar 19, 2017 at 11:37:15AM -0700, Steve Longerbeam wrote: On 03/19/2017 05:14 AM, Russell King - ARM Linux wrote: Right now, CSI doesn't do that - it only looks at the width, height, code, and field. Correct, there is currently

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 10:54:22AM -0700, Steve Longerbeam wrote: > > > On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: > >On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > >>Right, imx-media-capture.c (the "standard" v4l2 user interface module) > >>is not implementing

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 03:38 AM, Russell King - ARM Linux wrote: On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: Right, imx-media-capture.c (the "standard" v4l2 user interface module) is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only return the single frame size

Re: [PATCH v5 00/39] i.MX Media Driver

Le dimanche 19 mars 2017 à 00:54 +, Russell King - ARM Linux a écrit : > > > > In practice, I have the impression there is a fair reason why > > framerate > > enumeration isn't implemented (considering there is only 1 valid > > rate). > > That's actually completely incorrect. > > With the

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 05:00:08PM +0200, Vladimir Zapolskiy wrote: > On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote: > > On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote: > >> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9, > >> analysed it

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/19/2017 04:22 PM, Russell King - ARM Linux wrote: > On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote: >> There's a good reason why I dumped a full debug log using GST_DEBUG=*:9, >> analysed it for the cause of the failure, and tried several different >> pipelines,

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 10:33:25AM -0400, Nicolas Dufresne wrote: > Le dimanche 19 mars 2017 à 00:54 +, Russell King - ARM Linux a > écrit : > > > > > > In practice, I have the impression there is a fair reason why > > > framerate > > > enumeration isn't implemented (considering there is only

Re: [PATCH v5 00/39] i.MX Media Driver

Le dimanche 19 mars 2017 à 14:21 +, Russell King - ARM Linux a écrit : > > Can it be a point of failure? > > There's a good reason why I dumped a full debug log using > GST_DEBUG=*:9, > analysed it for the cause of the failure, and tried several different > pipelines, including the standard

Re: [PATCH v5 00/39] i.MX Media Driver

Le dimanche 19 mars 2017 à 09:55 +, Russell King - ARM Linux a écrit : > 2) would it also make sense to allow gstreamer's v4l2src to try > setting >    a these parameters, and only fail if it's unable to set it?  IOW, > if >    I use: > > gst-launch-1.0 v4l2src device=/dev/video10 ! \ >   

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 02:21:10PM +, Russell King - ARM Linux wrote: > There's a good reason why I dumped a full debug log using GST_DEBUG=*:9, > analysed it for the cause of the failure, and tried several different > pipelines, including the standard bayer2rgb plugin. > > Please don't blame

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 19, 2017 at 03:57:56PM +0200, Vladimir Zapolskiy wrote: > Hi Russell, > > On 03/18/2017 10:43 PM, Russell King - ARM Linux wrote: > > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > >> Can you share your gstreamer pipeline? For now, until > >>

Re: [PATCH v5 00/39] i.MX Media Driver

Hi Russell, On 03/18/2017 10:43 PM, Russell King - ARM Linux wrote: > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: >> Can you share your gstreamer pipeline? For now, until >> VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that >> does not attempt to specify a frame

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: > >0:00:01.955927879 20954 0x15ffe90 INFOv4l2 > >gstv4l2object.c:3811:gst_v4l2_object_get_caps: probed caps: > >video/x-bayer, format=(string)rggb,

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Right, imx-media-capture.c (the "standard" v4l2 user interface module) > is not implementing VIDIOC_ENUM_FRAMESIZES. It should, but it can only > return the single frame size that the pipeline has configured (the mbus > format of

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Along with the norm fallback, GStreamer could could also consider the > currently set framerate as returned by VIDIOC_G_PARM. At the same time, > implementing that enumeration shall be straightforward, and will make a > large

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 08:41:14PM -0400, Nicolas Dufresne wrote: > Le samedi 18 mars 2017 à 20:43 +, Russell King - ARM Linux a > écrit : > > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > > > Can you share your gstreamer pipeline? For now, until > > >

Re: [PATCH v5 00/39] i.MX Media Driver

Le samedi 18 mars 2017 à 20:43 +, Russell King - ARM Linux a écrit : > On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > > Can you share your gstreamer pipeline? For now, until > > VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that > > does not attempt to specify a

Re: [PATCH v5 00/39] i.MX Media Driver

On Sat, Mar 18, 2017 at 12:58:27PM -0700, Steve Longerbeam wrote: > Can you share your gstreamer pipeline? For now, until > VIDIOC_ENUM_FRAMESIZES is implemented, try a pipeline that > does not attempt to specify a frame rate. I use the attached > script for testing, which works for me. It's

Re: [PATCH v5 00/39] i.MX Media Driver

Hi Russell, On 03/14/2017 10:29 AM, Steve Longerbeam wrote: On 03/12/2017 02:09 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 08:40:37PM +, 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

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/18/2017 12:22 PM, Russell King - ARM Linux wrote: Hi Steve, I've just been trying to get gstreamer to capture and h264 encode video from my camera at various frame rates, and what I've discovered does not look good. 1) when setting frame rates, media-ctl _always_ calls

Re: [PATCH v5 00/39] i.MX Media Driver

Hi Steve, I've just been trying to get gstreamer to capture and h264 encode video from my camera at various frame rates, and what I've discovered does not look good. 1) when setting frame rates, media-ctl _always_ calls VIDIOC_SUBDEV_S_FRAME_INTERVAL with pad=0. 2) media-ctl never retrieves

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 02:09 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 08:40:37PM +, 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,

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 03:10 PM, Mauro Carvalho Chehab wrote: Em Sun, 12 Mar 2017 21:13:24 + Russell King - ARM Linux 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

Re: [PATCH v5 00/39] i.MX Media Driver

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 +, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 09:26:41PM -0700, Steve

Re: [PATCH v5 00/39] i.MX Media Driver

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,

Re: [PATCH v5 00/39] i.MX Media Driver

On Mon, Mar 13, 2017 at 08:16:25AM +, 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

Re: [PATCH v5 00/39] i.MX Media Driver

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()

Re: [PATCH v5 00/39] i.MX Media Driver

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

Re: [PATCH v5 00/39] i.MX Media Driver

Em Sun, 12 Mar 2017 21:13:24 + Russell King - ARM Linux 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.

Re: [PATCH v5 00/39] i.MX Media Driver

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

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 08:40:37PM +, 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, > >

Re: [PATCH v5 00/39] i.MX Media Driver

Em Sun, 12 Mar 2017 19:47:00 + Russell King - ARM Linux 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

Re: [PATCH v5 00/39] i.MX Media Driver

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.

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 01:36 PM, Steve Longerbeam wrote: On 03/12/2017 01:16 PM, Steve Longerbeam wrote: On 03/12/2017 12:44 PM, Steve Longerbeam wrote: On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: There's actually

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 01:16 PM, Steve Longerbeam wrote: On 03/12/2017 12:44 PM, Steve Longerbeam wrote: On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: There's actually nothing preventing userland from disabling a link

Re: [PATCH v5 00/39] i.MX Media Driver

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,

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 12:44 PM, Steve Longerbeam wrote: On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: There's actually nothing preventing userland from disabling a link multiple times, and imx_media_link_notify() complies,

Re: [PATCH v5 00/39] i.MX Media Driver

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

Re: [PATCH v5 00/39] i.MX Media Driver

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,

Re: [PATCH v5 00/39] i.MX Media Driver

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

Re: [PATCH v5 00/39] i.MX Media Driver

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

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 12:29 PM, Russell King - ARM Linux wrote: On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: There's actually nothing preventing userland from disabling a link multiple times, and imx_media_link_notify() complies, and so csi_s_power(OFF) gets called multiple

Re: [PATCH v5 00/39] i.MX Media Driver

On Sun, Mar 12, 2017 at 12:21:45PM -0700, Steve Longerbeam wrote: > There's actually nothing preventing userland from disabling a link > multiple times, and imx_media_link_notify() complies, and so > csi_s_power(OFF) gets called multiple times, and so that WARN_ON() > in there is silly, I borrowed

Re: [PATCH v5 00/39] i.MX Media Driver

On 03/12/2017 10:51 AM, Russell King - ARM Linux wrote: I've just looked at my test system's dmesg, and spotted this in the log. It's been a while since these popped out of the kernel, so I don't know what caused them (other than the obvious, a media-ctl command.) My script which sets this up

Re: [PATCH v5 00/39] i.MX Media Driver

I've just looked at my test system's dmesg, and spotted this in the log. It's been a while since these popped out of the kernel, so I don't know what caused them (other than the obvious, a media-ctl command.) My script which sets this up only enables links, and then configures the formats etc,

Re: [PATCH v5 00/39] i.MX Media Driver

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: > >

Re: [PATCH v5 00/39] i.MX Media Driver

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 = 0x0200 ipu1_csi0: pipeline start

Re: [PATCH v5 00/39] i.MX Media Driver

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 = 0x0200 ipu1_csi0: pipeline start

Re: [PATCH v5 00/39] i.MX Media Driver

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 = 0x0200 ipu1_csi0: pipeline start failed with -110 imx6-mipi-csi2: LP-11 timeout, phy_state =

[PATCH v5 00/39] i.MX Media Driver

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