raspberrypi
media: pisp-be: Split jobs creation and scheduling
Before submitting the same change to mainline, I would like to know what you think about this. This change will make it easier to support multi-context handling without duplicating the media graph instances.
Currently the 'pispbe_schedule()' function does two things:
- Tries to assemble a job by inspecting all the video node queues to make sure all the required buffers are available
- Submit the job to the hardware
The pispbe_schedule() function is called at:
- video device start_streaming() time
- video device qbuf() time
- irq handler
As assembling a job requires inspecting all queues, it is a rather time consuming operation which is better not run in IRQ context.
To avoid the executing the time consuming job creation in interrupt context split the job creation and job scheduling in two distinct operations. When a well-formed job is created, append it to the newly introduced 'pispbe->job_queue' where it will be dequeued from by the scheduling routine.
At start_streaming() and qbuf() time immediately try to schedule a job if one has been created as the irq handler routing is only called when a job has completed, and we can't solely rely on it for scheduling new jobs.
It's a moderately involved change so difficult to review, but LGTM. The principle certainly seems to be a good one.
It's a moderately involved change so difficult to review, but LGTM. The principle certainly seems to be a good one.
I was mostly wondering if you have more sophisticated test tools to validate if this change impact in any way on performances. I've run two a concurrent instances of qcam with an ov5647 and and imx219 and things looked ok apart from the fact the ov5647 runs at 7fps compared to the 15 fps at max res the datasheet claims. I'll soon test with your 6.6.y tree to see if it behaves the same.
I can confirm I get the same framerates with rpi-6.6.y
pi@raspberrypi:~$ cam -c1 -C10
[0:04:28.399287332] [1092] INFO RPI pisp.cpp:1450 Sensor: /base/axi/pcie@120000/rp1/i2c@88000/imx219@10 - Selected sensor format: 1640x1232-SBGGR10_1X10 -B
268.839072 (0.00 fps) cam0-stream0 seq: 000007 bytesused: 1920000
268.905656 (15.02 fps) cam0-stream0 seq: 000008 bytesused: 1920000
268.972379 (14.99 fps) cam0-stream0 seq: 000009 bytesused: 1920000
269.038872 (15.04 fps) cam0-stream0 seq: 000010 bytesused: 1920000
269.105476 (15.01 fps) cam0-stream0 seq: 000011 bytesused: 1920000
269.172096 (15.01 fps) cam0-stream0 seq: 000012 bytesused: 1920000
269.238724 (15.01 fps) cam0-stream0 seq: 000013 bytesused: 1920000
269.305332 (15.01 fps) cam0-stream0 seq: 000014 bytesused: 1920000
269.371979 (15.00 fps) cam0-stream0 seq: 000015 bytesused: 1920000
269.438618 (15.01 fps) cam0-stream0 seq: 000016 bytesused: 1920000
pi@raspberrypi:~$ cam -c2 -C10
[0:04:31.826608053] [1101] INFO RPI pisp.cpp:1450 Sensor: /base/axi/pcie@120000/rp1/i2c@80000/ov5647@36 - Selected sensor format: 1296x972-SGBRG10_1X10 - g
cam0: Capture 10 frames
272.787750 (0.00 fps) cam0-stream0 seq: 000008 bytesused: 1920000
272.921503 (7.48 fps) cam0-stream0 seq: 000009 bytesused: 1920000
273.055178 (7.48 fps) cam0-stream0 seq: 000010 bytesused: 1920000
273.194079 (7.20 fps) cam0-stream0 seq: 000011 bytesused: 1920000
273.332947 (7.20 fps) cam0-stream0 seq: 000012 bytesused: 1920000
273.473272 (7.13 fps) cam0-stream0 seq: 000013 bytesused: 1920000
273.612185 (7.20 fps) cam0-stream0 seq: 000014 bytesused: 1920000
273.751054 (7.20 fps) cam0-stream0 seq: 000015 bytesused: 1920000
273.890057 (7.19 fps) cam0-stream0 seq: 000016 bytesused: 1920000
274.028928 (7.20 fps) cam0-stream0 seq: 000017 bytesused: 1920000