[0/4] media: mc: add manual request completion support

Message

Hans Verkuil Aug. 28, 2024, 12:37 p.m. UTC

Normally a request contains one or more request objects, and once all
objects are marked as 'completed' the request itself is completed and
userspace gets a signal that the request is complete.

Calling vb2_buffer_done will complete a buffer object, and
v4l2_ctrl_request_complete will complete a control handler object.

In some cases (e.g. VP9 codecs) there is only a buffer object, so
as soon as the buffer is marked done, the request is marked as
completed. But in the case of mediatek, while the buffer is done
(i.e. the data is consumed by the hardware), the request isn't
completed yet as the data is still being processed. Once the
data is fully processed, the driver wants to call
v4l2_ctrl_request_complete() which will either update an existing
control handler object, or add a new control handler object to the
request containing the latest control values. But since the
request is already completed, calling v4l2_ctrl_request_complete()
will fail.

One option is to simply postpone calling vb2_buffer_done() and do
it after the call to v4l2_ctrl_request_complete(). However, in some
use-cases (e.g. secure memory) the number of available buffers is
very limited and you really want to return a buffer as soon as
possible.

In that case you want to postpone request completion until you
know the request is really ready.

Originally I thought the best way would be to make a dummy request
object, but that turned out to be overly complicated. So instead
I just add a bool manual_completion, which you set to true in
req_queue, and you call media_request_manual_complete() when you
know the request is complete. That was a lot less complicated.

The first patch adds this new manual completion code, the second
patch adds this to vicodec and the last patch is an updated old
patch of mine that adds debugfs code to check if all requests and
request objects are properly freed. Without it it is really hard to
verify that there are no dangling requests or objects.

Regards,

	Hans

Hans Verkuil (4):
  media: mc: add manual request completion
  media: vicodec: add support for manual completion
  media: mc: add media_debugfs_root()
  media: mc: add debugfs node to keep track of requests

 drivers/media/mc/mc-device.c                  | 28 ++++++++++++
 drivers/media/mc/mc-devnode.c                 | 16 +++++++
 drivers/media/mc/mc-request.c                 | 43 ++++++++++++++++++-
 .../media/test-drivers/vicodec/vicodec-core.c | 21 +++++++--
 include/media/media-device.h                  |  9 ++++
 include/media/media-devnode.h                 | 15 +++++++
 include/media/media-request.h                 | 38 +++++++++++++++-
 7 files changed, 163 insertions(+), 7 deletions(-)

Comments

Hans Verkuil Aug. 28, 2024, 12:59 p.m. UTC | #1

Please ignore, I'll post a v2 soon.

Regards,

	Hans

On 28/08/2024 14:37, Hans Verkuil wrote:
> Normally a request contains one or more request objects, and once all
> objects are marked as 'completed' the request itself is completed and
> userspace gets a signal that the request is complete.
> 
> Calling vb2_buffer_done will complete a buffer object, and
> v4l2_ctrl_request_complete will complete a control handler object.
> 
> In some cases (e.g. VP9 codecs) there is only a buffer object, so
> as soon as the buffer is marked done, the request is marked as
> completed. But in the case of mediatek, while the buffer is done
> (i.e. the data is consumed by the hardware), the request isn't
> completed yet as the data is still being processed. Once the
> data is fully processed, the driver wants to call
> v4l2_ctrl_request_complete() which will either update an existing
> control handler object, or add a new control handler object to the
> request containing the latest control values. But since the
> request is already completed, calling v4l2_ctrl_request_complete()
> will fail.
> 
> One option is to simply postpone calling vb2_buffer_done() and do
> it after the call to v4l2_ctrl_request_complete(). However, in some
> use-cases (e.g. secure memory) the number of available buffers is
> very limited and you really want to return a buffer as soon as
> possible.
> 
> In that case you want to postpone request completion until you
> know the request is really ready.
> 
> Originally I thought the best way would be to make a dummy request
> object, but that turned out to be overly complicated. So instead
> I just add a bool manual_completion, which you set to true in
> req_queue, and you call media_request_manual_complete() when you
> know the request is complete. That was a lot less complicated.
> 
> The first patch adds this new manual completion code, the second
> patch adds this to vicodec and the last patch is an updated old
> patch of mine that adds debugfs code to check if all requests and
> request objects are properly freed. Without it it is really hard to
> verify that there are no dangling requests or objects.
> 
> Regards,
> 
> 	Hans
> 
> Hans Verkuil (4):
>   media: mc: add manual request completion
>   media: vicodec: add support for manual completion
>   media: mc: add media_debugfs_root()
>   media: mc: add debugfs node to keep track of requests
> 
>  drivers/media/mc/mc-device.c                  | 28 ++++++++++++
>  drivers/media/mc/mc-devnode.c                 | 16 +++++++
>  drivers/media/mc/mc-request.c                 | 43 ++++++++++++++++++-
>  .../media/test-drivers/vicodec/vicodec-core.c | 21 +++++++--
>  include/media/media-device.h                  |  9 ++++
>  include/media/media-devnode.h                 | 15 +++++++
>  include/media/media-request.h                 | 38 +++++++++++++++-
>  7 files changed, 163 insertions(+), 7 deletions(-)
>