| 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. |
| |
| v2: |
| - Rebased to v4.12-rc1 |
| |
| Kieran Bingham (2): |
| Revert "[media] v4l: vsp1: Supply frames to the DU continuously" |
| v4l: vsp1: Provide a writeback video device |
