properly set test pattern to a sub-device

properly set test pattern to a sub-device

[Petko Manolov]

	Hi guys,

I've got a long pipeline of four entities and need to make the imx492 sensor 
stream out a test pattern.  When i do:

	v4l2-ctl -d /dev/v4l-subdev2 --set-ctrl=test_pattern=2

I can see the driver acknowledging the switch to test pattern 2.  However, when 
start streaming with:

	v4l2-ctl -d /dev/video0 --stream-mmap --stream-to=frame.raw --stream-count=1

the driver reports setting the test pattern to the default 0.  How should this 
be done properly?


thanks,
Petko

Re: properly set test pattern to a sub-device

[Kieran Bingham]

Quoting Petko Manolov (2022-07-14 16:22:09)
>         Hi guys,
> 
> I've got a long pipeline of four entities and need to make the imx492 sensor 
> stream out a test pattern.  When i do:
> 
>         v4l2-ctl -d /dev/v4l-subdev2 --set-ctrl=test_pattern=2
> 
> I can see the driver acknowledging the switch to test pattern 2.  However, when 
> start streaming with:
> 
>         v4l2-ctl -d /dev/video0 --stream-mmap --stream-to=frame.raw --stream-count=1
> 
> the driver reports setting the test pattern to the default 0.  How should this 
> be done properly?

'Which' driver is reporting setting the test pattern? Can you check
where that's happening and identify 'why'?

As I understand it - it shouldn't be happening, so I suspect it's
something in your CSI2 receiver driver initialising some defaults
perhaps.
--
Kieran

> 
> 
> thanks,
> Petko

Re: properly set test pattern to a sub-device

[Petko Manolov]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

On 22-07-15 00:21:29, Kieran Bingham wrote:
> 
> As I understand it - it shouldn't be happening, so I suspect it's something in 
> your CSI2 receiver driver initialising some defaults perhaps.

I've attached 'media-ctl -p' output for clarity.  This is imx8m-mini based board 
on 5.19.0-rc6.

When selecting a test pattern with:

	v4l2-ctl -d /dev/v4l-subdev2 --set-ctrl=test_pattern=2

I get this from v4l2-ctl:

	VIDIOC_S_EXT_CTRLS: failed: Invalid argument
	test_pattern: Invalid argument

but the fun part is that my .s_ctrl() routine receives V4L2_CID_TEST_PATTERN and 
ctrl->val is indeed 2, hence i'm setting sensor registers according to this 
data.

I (falsely) assumed this would be a 'sticky' attribute so when i ask the 
receiver driver (/dev/video0) to start streaming, it wouldn't change the test 
pattern value under my feet.  Instead the imx492 driver once again receive 
V4L2_CID_TEST_PATTERN, this time with ctrl->val == 0, which kind of ruins all 
the fun.

Following you advice, i tried to find which CSI2 driver might be the culprit. 
None of the relevant drivers in drivers/staging/media/imx have v4l2_ctrl_ops 
callback registered.  If that's what i am supposed to look for, which now seems 
unlikely.

Do you have other recommendations about what (and where) should i look next?


		Petko

[-- Attachment #2: mctl --]
[-- Type: text/plain, Size: 1506 bytes --]

Media controller API version 5.19.0

Media device information
------------------------
driver          imx7-csi
model           imx-media
serial          
bus info        platform:32e20000.csi
hw revision     0x0
driver version  5.19.0

Device topology
- entity 1: csi (2 pads, 2 links)
            type V4L2 subdev subtype Unknown flags 0
            device node name /dev/v4l-subdev0
	pad0: Sink
		[fmt:SGBRG12_1X12/8192x4320 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range]
		<- "csis-32e30000.mipi-csi":1 [ENABLED,IMMUTABLE]
	pad1: Source
		[fmt:SGBRG12_1X12/8192x4320 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range]
		-> "csi capture":0 [ENABLED,IMMUTABLE]

- entity 4: csi capture (1 pad, 1 link)
            type Node subtype V4L flags 0
            device node name /dev/video0
	pad0: Sink
		<- "csi":1 [ENABLED,IMMUTABLE]

- entity 10: csis-32e30000.mipi-csi (2 pads, 2 links)
             type V4L2 subdev subtype Unknown flags 0
             device node name /dev/v4l-subdev1
	pad0: Sink
		[fmt:SGBRG12_1X12/8192x4320 field:none colorspace:raw]
		<- "imx492 1-0010":0 [ENABLED]
	pad1: Source
		[fmt:SGBRG12_1X12/8192x4320 field:none colorspace:raw]
		-> "csi":0 [ENABLED,IMMUTABLE]

- entity 15: imx492 1-0010 (1 pad, 1 link)
             type V4L2 subdev subtype Sensor flags 0
             device node name /dev/v4l-subdev2
	pad0: Source
		[fmt:SGBRG12_1X12/8192x4320 field:none colorspace:raw xfer:none]
		-> "csis-32e30000.mipi-csi":0 [ENABLED]

Re: properly set test pattern to a sub-device

[Petko Manolov]

On 22-07-15 00:21:29, Kieran Bingham wrote:
> Quoting Petko Manolov (2022-07-14 16:22:09)
> >         Hi guys,
> > 
> > I've got a long pipeline of four entities and need to make the imx492 sensor 
> > stream out a test pattern.  When i do:
> > 
> >         v4l2-ctl -d /dev/v4l-subdev2 --set-ctrl=test_pattern=2
> > 
> > I can see the driver acknowledging the switch to test pattern 2.  However, 
> > when start streaming with:
> > 
> >         v4l2-ctl -d /dev/video0 --stream-mmap --stream-to=frame.raw 
> >         --stream-count=1
> > 
> > the driver reports setting the test pattern to the default 0.  How should 
> > this be done properly?
> 
> 'Which' driver is reporting setting the test pattern? Can you check where 
> that's happening and identify 'why'?
> 
> As I understand it - it shouldn't be happening, so I suspect it's something in 
> your CSI2 receiver driver initialising some defaults perhaps.

Well, found it - my s_ctrl() was accidentally returning -EINVAL for 
V4L2_CID_TEST_PATTERN.  I _assume_ this is why V4L2 was correcting it to '0' at 
stream time.  Not being well versed in V4L2 i leave this one to you guys. :)

Now, this brings out an interesting question.  The way s_ctrl() is written 'int 
ret' is declared in the prologue of the function.  The only place 'ret' was not 
assigned some value was at 'case V4L2_CID_TEST_PATTERN:'.  s_ctrl() was happily 
returning whatever happened to be in the stack at that time.

With all GCC warnings enabled these days for the kernel build, i'm rather 
surprised to see absolutely nothing on the command line when compiling the 
driver.  Odd...


		Petko