| vsp1 writeback prototype |
| |
| This short series extends the VSP1 on the RCar platforms to allow creating a |
| V4L2 video node on display pipelines where the hardware allows writing to |
| memory simultaneously. |
| |
| In this instance, the hardware restricts the output to match the display size |
| (no rescaling) but does allow pixel format conversion. |
| |
| A current limitation (that the DRI devs might have ideas about) is that the vb2 |
| buffers are swapped on the atomic_flush() calls rather than on vsync events. |
| |
| Ideally swapping buffers would occur on every vsync such that the output rate |
| of the video node would match the display rate, however the timing here proves |
| more difficult to synchronise the updates from a vsync and flush without adding |
| latency to the flush. |
| |
| Is there anything I can do to synchronise the v4l2 buffers with the DRM/KMS |
| interfaces currently? Or does anyone have any suggestions for extending as |
| such? |
| |
| And of course ideas on anything that could be done generically to support other |
| targets as well would be worth considering - though currently this |
| implementation is very RCar/VSP1 specific. |
| |
| v3: |
| - Rebased to v4.12-rc1 |
| |
| v2: |
| - Fix checkpatch.pl warnings |
| - Adapt to use a single source pad for the Writeback and LIF |
| - Use WPF properties to determine when to create links instead of VSP |
| - Remove incorrect vsp1_video_verify_format() changes |
| - Spelling and grammar fixes |
| |
| Kieran Bingham (2): |
| Revert "[media] v4l: vsp1: Supply frames to the DU continuously" |
| v4l: vsp1: Provide a writeback video device |
