[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170221161518.GM16975@valkosipuli.retiisi.org.uk>
Date: Tue, 21 Feb 2017 18:15:19 +0200
From: Sakari Ailus <sakari.ailus@....fi>
To: Russell King - ARM Linux <linux@...linux.org.uk>
Cc: Steve Longerbeam <slongerbeam@...il.com>, robh+dt@...nel.org,
mark.rutland@....com, shawnguo@...nel.org, kernel@...gutronix.de,
fabio.estevam@....com, mchehab@...nel.org, hverkuil@...all.nl,
nick@...anahar.org, markus.heiser@...marIT.de,
p.zabel@...gutronix.de, laurent.pinchart+renesas@...asonboard.com,
bparrot@...com, geert@...ux-m68k.org, arnd@...db.de,
sudipm.mukherjee@...il.com, minghsiu.tsai@...iatek.com,
tiffany.lin@...iatek.com, jean-christophe.trotin@...com,
horms+renesas@...ge.net.au, niklas.soderlund+renesas@...natech.se,
robert.jarzmik@...e.fr, songjun.wu@...rochip.com,
andrew-ct.chen@...iatek.com, gregkh@...uxfoundation.org,
shuah@...nel.org, sakari.ailus@...ux.intel.com, pavel@....cz,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org,
devel@...verdev.osuosl.org,
Steve Longerbeam <steve_longerbeam@...tor.com>
Subject: Re: [PATCH v4 29/36] media: imx: mipi-csi2: enable setting and
getting of frame rates
On Tue, Feb 21, 2017 at 04:03:32PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 21, 2017 at 05:38:34PM +0200, Sakari Ailus wrote:
> > Hi Russell,
> >
> > On Tue, Feb 21, 2017 at 01:21:32PM +0000, Russell King - ARM Linux wrote:
> > > On Tue, Feb 21, 2017 at 02:37:57PM +0200, Sakari Ailus wrote:
> > > > Hi Russell,
> > > >
> > > > On Tue, Feb 21, 2017 at 12:13:32AM +0000, Russell King - ARM Linux wrote:
> > > > > On Tue, Feb 21, 2017 at 12:04:10AM +0200, Sakari Ailus wrote:
> > > > > > On Wed, Feb 15, 2017 at 06:19:31PM -0800, Steve Longerbeam wrote:
> > > > > > > From: Russell King <rmk+kernel@...linux.org.uk>
> > > > > > >
> > > > > > > Setting and getting frame rates is part of the negotiation mechanism
> > > > > > > between subdevs. The lack of support means that a frame rate at the
> > > > > > > sensor can't be negotiated through the subdev path.
> > > > > >
> > > > > > Just wondering --- what do you need this for?
> > > > >
> > > > > The v4l2 documentation contradicts the media-ctl implementation.
> > > > >
> > > > > While v4l2 documentation says:
> > > > >
> > > > > These ioctls are used to get and set the frame interval at specific
> > > > > subdev pads in the image pipeline. The frame interval only makes sense
> > > > > for sub-devices that can control the frame period on their own. This
> > > > > includes, for instance, image sensors and TV tuners. Sub-devices that
> > > > > don't support frame intervals must not implement these ioctls.
> > > > >
> > > > > However, when trying to configure the pipeline using media-ctl, eg:
> > > > >
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 pixel 0-0010":0[crop:(0,0)/3264x2464]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 0-0010":1[fmt:SRGGB10/3264x2464@...0]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx219 0-0010":0[fmt:SRGGB8/816x616@...0]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"imx6-mipi-csi2":1[fmt:SRGGB8/816x616@...0]'
> > > > > Unable to setup formats: Inappropriate ioctl for device (25)
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0_mux":2[fmt:SRGGB8/816x616@...0]'
> > > > > media-ctl -d /dev/media1 --set-v4l2 '"ipu1_csi0":2[fmt:SRGGB8/816x616@...0]'
> > > > >
> > > > > The problem there is that the format setting for the csi2 does not get
> > > > > propagated forward:
> > > >
> > > > The CSI-2 receivers typically do not implement frame interval IOCTLs as they
> > > > do not control the frame interval. Some sensors or TV tuners typically do,
> > > > so they implement these IOCTLs.
> > >
> > > No, TV tuners do not. The frame rate for a TV tuner is set by the
> > > broadcaster, not by the tuner. The tuner can't change that frame rate.
> > > The tuner may opt to "skip" fields or frames. That's no different from
> > > what the CSI block in my example below is capable of doing.
> > >
> > > Treating a tuner differently from the CSI block is inconsistent and
> > > completely wrong.
> >
> > I agree tuners in that sense are somewhat similar, and they are not treated
> > differently because they are tuners (and not CSI-2 receivers). Neither can
> > control the frame rate of the incoming video stream.
> >
> > Conceivably a tuner could implement G_FRAME_INTERVAL IOCTL, but based on a
> > quick glance none appears to. Neither do CSI-2 receivers. Only sensor
> > drivers do currently.
>
> Please look again. I am being very careful with "CSI" vs "CSI-2" in my
> emails, you are conflating the two.
>
> In all my emails so far, "CSI" refers to a block of hardware that is
> responsible for receiving an image stream from some kind of source. It
> contains hardware that supports frame skipping.
Ah, I missed the difference. Thanks for pointing it out.
Still, that does not change how the skipping would work nor how I proposed
it would be configured from the user space.
>
> "CSI-2" refers to a different block of hardware that is responsible for
> receiving a serially encoded stream from a MIPI-CSI-2 compliant source
> and providing it to the "CSI" block.
>
> I would have thought my diagram that I drew would have made it clear that
> they were different blocks of hardware, but I guess in this case, the old
> saying "a picture is worth 1000 words" is simply not true.
>
> > Images are transmitted as series of lines, with each line ending in a
> > horizontal blanking period, and each frame ending with a similar period of
>
> I'm sorry, are you seriously teaching me to suck rocks? I am insulted.
>
> I've been involved in TV and video for many years, I don't need you to
> tell me how video is transmitted.
>
> Sorry, you've just lost my interest in further discussion.
There's no need to feel insulted; that certainly was not the intention.
I've proposed you a solution, please comment on that.
--
Regards,
Sakari Ailus
e-mail: sakari.ailus@....fi XMPP: sailus@...iisi.org.uk
Powered by blists - more mailing lists