Re: [PATCH v3 00/24] i.MX Media Driver

Hi Steve, On Tue, 2017-02-14 at 18:27 -0800, Steve Longerbeam wrote: [...] > > > > # Provide an EDID to the HDMI source > > v4l2-ctl -d /dev/v4l-subdev2 --set-edid=file=edid-1080p.hex > > I can probably generate this Intel hex file myself from sysfs > edid outputs, but for convenience do you

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Philipp, I've created a test branch off my imx-media-staging-md-wip called tc358743, which cherry-picks a couple of your commits from your imx-media-staging-md-wip branch: [media] tc358743: set entity function to video interface bridge [media] tc358743: put lanes in STOP state before

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/02/2017 02:29 PM, Russell King - ARM Linux wrote: On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote: Here is the current .queue_setup() op in imx-media-capture.c: static int capture_queue_setup(struct vb2_queue *vq, unsigned int *nbuffers,

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/03/2017 06:41 AM, Laurent Pinchart wrote: Hello, On Wednesday 01 Feb 2017 16:19:27 Steve Longerbeam wrote: On 02/01/2017 01:30 AM, Philipp Zabel wrote: media-ctl propagates the output pad format to all remote subdevices' input pads for all enabled links:

Re: [PATCH v3 00/24] i.MX Media Driver

Hello, On Wednesday 01 Feb 2017 16:19:27 Steve Longerbeam wrote: > On 02/01/2017 01:30 AM, Philipp Zabel wrote: > > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote: > > [...] > > > >>> # Set pad formats > >>> media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]" > >>>

Re: vb2 queue_setup documentation clarification (was "Re: [PATCH v3 00/24] i.MX Media Driver")

On 03/02/17 15:21, Laurent Pinchart wrote: Hi Steve, (stripping the CC list a bit and adding Sakari Ailus) On Thursday 02 Feb 2017 11:12:41 Steve Longerbeam wrote: On 02/02/2017 10:58 AM, Russell King - ARM Linux wrote: [snip] It seems to me that if you don't take account of the existing

vb2 queue_setup documentation clarification (was "Re: [PATCH v3 00/24] i.MX Media Driver")

Hi Steve, (stripping the CC list a bit and adding Sakari Ailus) On Thursday 02 Feb 2017 11:12:41 Steve Longerbeam wrote: > On 02/02/2017 10:58 AM, Russell King - ARM Linux wrote: [snip] > > It seems to me that if you don't take account of the existing queue > > size, your camif_queue_setup()

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 11:12:41AM -0800, Steve Longerbeam wrote: > Here is the current .queue_setup() op in imx-media-capture.c: > > static int capture_queue_setup(struct vb2_queue *vq, >unsigned int *nbuffers, >unsigned int

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/02/2017 10:58 AM, Russell King - ARM Linux wrote: On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote: On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: and for whatever reason we end up falling out through free_ring. This is VERY bad news, because it means that the

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 10:26:55AM -0800, Steve Longerbeam wrote: > On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: > >and for whatever reason we end up falling out through free_ring. This > >is VERY bad news, because it means that the ring which SMFC took a copy > >of is now freed

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/02/2017 09:56 AM, Russell King - ARM Linux wrote: On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote: I thought, maybe, it's the IPU overwriting past the end of the buffer, but I've added checks and that doesn't seem to have fired. I also wondered if it was some

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Feb 02, 2017 at 05:22:46PM +, Russell King - ARM Linux wrote: > I thought, maybe, it's the IPU overwriting past the end of the buffer, > but I've added checks and that doesn't seem to have fired. I also > wondered if it was some kind of use-after-free of the ring, so I made >

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Russell, I don't recommend spending too much time debugging this OOPS. The dma buffer ring has been removed completely in version 4 (which I'm trying to get ready to post hopefully by end of this week). Steve On 02/02/2017 09:22 AM, Russell King - ARM Linux wrote: I seem to be getting

Re: [PATCH v3 00/24] i.MX Media Driver

I seem to be getting some sort of memory corruption with this driver. I've had two instances now of uninitialised spinlocks in imx_media_dma_buf_get_active() which show that the spinlock being taken in this function is all-zeros. That very quickly leads to an oops, where I've seen buf->ring is

Re: [PATCH v3 00/24] i.MX Media Driver

On 02/01/2017 01:30 AM, Philipp Zabel wrote: On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote: [...] # Set pad formats media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]" media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]" media-ctl --set-v4l2

Re: [PATCH v3 00/24] i.MX Media Driver

On Wed, Feb 01, 2017 at 11:42:31AM +0100, Philipp Zabel wrote: > On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote: > Right, it's just that in the latest version there is no v4l2_subdev for > fifos and idmac. There is the capture interface entity that represents > one of the IDMAC

Re: [PATCH v3 00/24] i.MX Media Driver

On Wed, 2017-02-01 at 10:11 +, Russell King - ARM Linux wrote: > On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote: > > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote: > > [...] > > > right, need to fix that. Probably by poking the attached > > > source subdev (csi or

Re: [PATCH v3 00/24] i.MX Media Driver

On Wed, Feb 01, 2017 at 10:30:57AM +0100, Philipp Zabel wrote: > On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote: > [...] > > right, need to fix that. Probably by poking the attached > > source subdev (csi or prpenc/vf) for its supported formats. > > You are right, in bayer/raw mode

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, 2017-01-31 at 17:26 -0800, Steve Longerbeam wrote: [...] > > # Set pad formats > > media-ctl --set-v4l2 "'tc358743 1-000f':0[fmt:UYVY/1920x1080]" > > media-ctl --set-v4l2 "'imx6-mipi-csi2':1[fmt:UYVY2X8/1920x1080]" > > media-ctl --set-v4l2 "'ipu1_csi0_mux':2[fmt:UYVY2X8/1920x1080]" > >

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 05:54:52PM -0800, Steve Longerbeam wrote: > On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote: > First, thank you for the explanation, it clears up a lot. > > But of_parse_subdev() is used to parse the OF graph starting > from the CSI ports, to discover all the nodes

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/31/2017 04:23 PM, Russell King - ARM Linux wrote: On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote: On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote: Just like smiapp, the camera sensor block (which is the very far end of the pipeline) is marked with

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/31/2017 05:54 AM, Philipp Zabel wrote: Hi Steve, I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some observations: # Link pipeline media-ctl -l "'tc358743 1-000f':0->'imx6-mipi-csi2':0[1]"

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 03:43:22PM -0800, Steve Longerbeam wrote: > > > On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote: > >Just like smiapp, the camera sensor block (which is the very far end > >of the pipeline) is marked with MEDIA_ENT_F_CAM_SENSOR. However, in > >front of that is the

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/31/2017 03:00 AM, Russell King - ARM Linux wrote: On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote: I'm also having trouble finding a datasheet for it, but from what I've read, it has a MIPI CSI-2 interface. It should work fine as long as it presents a single source pad,

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 03:25:10PM +0100, Philipp Zabel wrote: > On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote: > > Hi Steve, > > > > I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X > > with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some > >

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, 2017-01-31 at 14:54 +0100, Philipp Zabel wrote: > Hi Steve, > > I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X > with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some > observations: > > # Link pipeline > media-ctl -l "'tc358743

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 02:35:00PM +0100, Philipp Zabel wrote: > On Tue, 2017-01-31 at 13:14 +, Russell King - ARM Linux wrote: > > This isn't limited to the serial side - the parallel bus side between > > the CSI2 interface and CSI2IPU wrapper, and the CSI2IPU wrapper and > > the CS0/1

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Steve, I have just tested the imx-media-staging-md-wip branch on a Nitrogen6X with a tc358743 (BD_HDMI_MIPI HDMI to MIPI CSI-2 receiver board). Some observations: # Link pipeline media-ctl -l "'tc358743 1-000f':0->'imx6-mipi-csi2':0[1]" media-ctl -l "'imx6-mipi-csi2':1->'ipu1_csi0_mux':0[1]"

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, 2017-01-31 at 13:14 +, Russell King - ARM Linux wrote: > On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote: > > On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote: > > > To help illustrate my point, consider the difference between > > >

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 11:09:24AM +0100, Philipp Zabel wrote: > On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote: > > To help illustrate my point, consider the difference between > > MEDIA_BUS_FMT_RGB565_1X16 and MEDIA_BUS_FMT_RGB565_2X8_BE or > > MEDIA_BUS_FMT_RGB565_2X8_LE.

Re: [PATCH v3 00/24] i.MX Media Driver

On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote: > I'm also having trouble finding a datasheet for it, but from what > I've read, it has a MIPI CSI-2 interface. It should work fine as long > as it presents a single source pad, registers asynchronously, and > sets its entity

Re: [PATCH v3 00/24] i.MX Media Driver

On Mon, Jan 30, 2017 at 05:22:01PM -0800, Steve Longerbeam wrote: > Edit: I see a subdev that is missing: the video mux. Did you enable > CONFIG_VIDEO_MULTIPLEXER? Yes, and that's where the problem is - the video-multiplexer is missing the module aliases to allow it to be automatically loaded.

Re: [PATCH v3 00/24] i.MX Media Driver

On Mon, 2017-01-30 at 13:06 +, Russell King - ARM Linux wrote: > > The central issue seems to be that I think media pad links / media bus > > formats should describe physical links, such as parallel or serial > > buses, and the formats of pixels flowing through them, whereas Steve > > would

Re: [PATCH v3 00/24] i.MX Media Driver

On Mon, 2017-01-30 at 17:22 -0800, Steve Longerbeam wrote: > > On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote: > > > > Hi, > > > > Trying this driver with an imx219 camera (which works with Philipp's > > driver) results in not much happening... no /dev/media* node for it, > > no subdevs,

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 05:06 PM, Russell King - ARM Linux wrote: On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing.

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/30/2017 04:45 PM, Russell King - ARM Linux wrote: Hi, Trying this driver with an imx219 camera (which works with Philipp's driver) results in not much happening... no /dev/media* node for it, no subdevs, no nothing. No clues as to what's missing either. Only messages from imx-media

Re: [PATCH v3 00/24] i.MX Media Driver

On Tue, Jan 31, 2017 at 12:45:11AM +, Russell King - ARM Linux wrote: > Trying this driver with an imx219 camera (which works with Philipp's > driver) results in not much happening... no /dev/media* node for it, > no subdevs, no nothing. No clues as to what's missing either. Only > messages

Re: [PATCH v3 00/24] i.MX Media Driver

On Fri, Jan 06, 2017 at 06:11:18PM -0800, Steve Longerbeam wrote: > Philipp Zabel (3): > 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 > > Steve

Re: [PATCH v3 00/24] i.MX Media Driver

> The central issue seems to be that I think media pad links / media bus > formats should describe physical links, such as parallel or serial > buses, and the formats of pixels flowing through them, whereas Steve > would like to extend them to describe software transports and in-memory > formats.

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/24/2017 03:27 AM, Philipp Zabel wrote: Hi Steve, Hans, [added Laurent to Cc: who I believe might have an opinion on the media bus formats, too. Sorry for the wall of text, I have put a marker where the MEDIA_BUS argument starts] The central issue seems to be that I think media pad

Re: [PATCH v3 00/24] i.MX Media Driver

On Mon, 2017-01-23 at 12:08 +0100, Hans Verkuil wrote: > On 01/23/2017 12:00 PM, Philipp Zabel wrote: > > On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote: [...] > As long as it is mentioned in the TODO, and ideally in the Kconfig as well, > then I'm fine with it. > > The big advantage of

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Steve, Hans, [added Laurent to Cc: who I believe might have an opinion on the media bus formats, too. Sorry for the wall of text, I have put a marker where the MEDIA_BUS argument starts] The central issue seems to be that I think media pad links / media bus formats should describe physical

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/23/2017 03:00 AM, Philipp Zabel wrote: On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote: [...] There is a VDIC entity in the i.MX IPU that performs de-interlacing with hardware filters for motion compensation. Some of the motion compensation modes ("low" and "medium" motion)

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/23/2017 12:00 PM, Philipp Zabel wrote: > On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote: > [...] >>> There is a VDIC entity in the i.MX IPU that performs de-interlacing with >>> hardware filters for motion compensation. Some of the motion compensation >>> modes ("low" and "medium"

Re: [PATCH v3 00/24] i.MX Media Driver

On Fri, 2017-01-20 at 21:39 +0100, Hans Verkuil wrote: [...] > > There is a VDIC entity in the i.MX IPU that performs de-interlacing with > > hardware filters for motion compensation. Some of the motion compensation > > modes ("low" and "medium" motion) require that the VDIC receive video > >

Re: [PATCH v3 00/24] i.MX Media Driver

On 01/20/2017 07:40 PM, Steve Longerbeam wrote: > Hi Hans, Philipp, > > > On 01/20/2017 08:31 AM, Philipp Zabel wrote: >> Hi Hans, >> >> On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote: >>> Hi Steve, Philipp, >>> >>> On 01/07/2017 03:11 AM, Steve Longerbeam wrote: In version 3:

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Hans, Philipp, On 01/20/2017 08:31 AM, Philipp Zabel wrote: Hi Hans, On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote: Hi Steve, Philipp, On 01/07/2017 03:11 AM, Steve Longerbeam wrote: In version 3: Changes suggested by Rob Herring : - prepended FIM node

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Hans, On Fri, 2017-01-20 at 14:52 +0100, Hans Verkuil wrote: > Hi Steve, Philipp, > > On 01/07/2017 03:11 AM, Steve Longerbeam wrote: > > In version 3: > > > > Changes suggested by Rob Herring : > > > > - prepended FIM node properties with vendor prefix "fsl,". > > > >

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Steve, Philipp, On 01/07/2017 03:11 AM, Steve Longerbeam wrote: > In version 3: > > Changes suggested by Rob Herring : > > - prepended FIM node properties with vendor prefix "fsl,". > > - make mipi csi-2 receiver compatible string SoC specific: >

Re: [PATCH v3 00/24] i.MX Media Driver

On Thu, Jan 12, 2017 at 2:32 PM, Steve Longerbeam wrote: > Hi Tim, > > > On 01/12/2017 01:13 PM, Tim Harvey wrote: >> >> Now that your driver is hooking into the current media framework, I'm not at all clear on how to link and configure the media entities. >>> >>>

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Tim, On 01/12/2017 01:13 PM, Tim Harvey wrote: Now that your driver is hooking into the current media framework, I'm not at all clear on how to link and configure the media entities. It's all documented at Documentation/media/v4l-drivers/imx.rst. Follow the SabreAuto pipeline setup

Re: [PATCH v3 00/24] i.MX Media Driver

On Wed, Jan 11, 2017 at 7:22 PM, Steve Longerbeam wrote: > Hi Tim, > > > On 01/11/2017 03:14 PM, Tim Harvey wrote: >> >> >> >> >> Hi Steve, >> >> I took a stab at testing this today on a gw51xx which has an adv7180 >> hooked up as follows: >> - i2c3@0x20 >> - 8bit

Re: [PATCH v3 00/24] i.MX Media Driver

Hi Tim, On 01/11/2017 03:14 PM, Tim Harvey wrote: Hi Steve, I took a stab at testing this today on a gw51xx which has an adv7180 hooked up as follows: - i2c3@0x20 - 8bit data bus from DAT12 to DAT19, HSYNC, VSYNC, PIXCLK on CSI0 pads (CSI0_IPU1) - PWRDWN# on

Re: [PATCH v3 00/24] i.MX Media Driver

On Fri, Jan 6, 2017 at 6:11 PM, Steve Longerbeam wrote: > In version 3: > > Changes suggested by Rob Herring : > > - prepended FIM node properties with vendor prefix "fsl,". > > - make mipi csi-2 receiver compatible string SoC specific: >

[PATCH v3 00/24] i.MX Media Driver

In version 3: Changes suggested by Rob Herring : - prepended FIM node properties with vendor prefix "fsl,". - make mipi csi-2 receiver compatible string SoC specific: "fsl,imx6-mipi-csi2" instead of "fsl,imx-mipi-csi2". - redundant "_clk" removed from mipi csi-2