mbox series

[0/2] Improve V4L2 M2M job scheduler

Message ID 20230704040044.681850-1-randy.li@synaptics.com (mailing list archive)
Headers
Series Improve V4L2 M2M job scheduler |

Message

Hsia-Jun Li July 4, 2023, 4 a.m. UTC 
  From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>

The first patch is an old patch, I resend it again.
I want to make the work thats parses the bitstream
to extract the sequence information or video resolution
as a part of V4L2 schedule. Such a work would also
consume the device's resources likes remote CPU
time.

Although reuse a flag which no current driver may
not be a good idea. I could add a new flag for that
if people like that.

The second is a patch offering a generic solution
for tracking buffers which have been pushed to
hardware(or firmware). It didn't record which buffer
that hardware(firmware) still holds for future
decoding(likes the reference buffer), while it
has been sent to the user(dequeue). We may need
a flag for this work.

Hsia-Jun(Randy) Li (1):
  media: v4l2-mem2mem: add a list for buf used by hw

Randy Li (1):
  media: v4l2-mem2mem: allow device run without buf

 drivers/media/v4l2-core/v4l2-mem2mem.c | 30 +++++++++++++++++---------
 include/media/v4l2-mem2mem.h           | 10 ++++++++-
 2 files changed, 29 insertions(+), 11 deletions(-)

Comments

Hans Verkuil Aug. 18, 2023, 2:45 p.m. UTC | #1 
On 04/07/2023 06:00, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>
> 
> The first patch is an old patch, I resend it again.
> I want to make the work thats parses the bitstream
> to extract the sequence information or video resolution
> as a part of V4L2 schedule. Such a work would also
> consume the device's resources likes remote CPU
> time.
> 
> Although reuse a flag which no current driver may
> not be a good idea. I could add a new flag for that
> if people like that.
> 
> The second is a patch offering a generic solution
> for tracking buffers which have been pushed to
> hardware(or firmware). It didn't record which buffer
> that hardware(firmware) still holds for future
> decoding(likes the reference buffer), while it
> has been sent to the user(dequeue). We may need
> a flag for this work.

I am dropping this series from patchwork: clearly this generated
a lot of discussion, and I think that needs to come to a conclusion.

BTW, I believe that at minimum the codec-specific parts in
v4l2-mem2mem.c should be split off in their own source (v4l2-m2m-codec.c?).

I agree with Tomasz that mem2mem.c was originally for simple m2m devices,
and adding all sorts of codec specific code to that source doesn't make
it easier to follow.

Regards,

	Hans

> 
> Hsia-Jun(Randy) Li (1):
>   media: v4l2-mem2mem: add a list for buf used by hw
> 
> Randy Li (1):
>   media: v4l2-mem2mem: allow device run without buf
> 
>  drivers/media/v4l2-core/v4l2-mem2mem.c | 30 +++++++++++++++++---------
>  include/media/v4l2-mem2mem.h           | 10 ++++++++-
>  2 files changed, 29 insertions(+), 11 deletions(-)
>
Tomasz Figa Aug. 22, 2023, 7:59 a.m. UTC | #2 
On Fri, Aug 18, 2023 at 11:45 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 04/07/2023 06:00, Hsia-Jun Li wrote:
> > From: "Hsia-Jun(Randy) Li" <randy.li@synaptics.com>
> >
> > The first patch is an old patch, I resend it again.
> > I want to make the work thats parses the bitstream
> > to extract the sequence information or video resolution
> > as a part of V4L2 schedule. Such a work would also
> > consume the device's resources likes remote CPU
> > time.
> >
> > Although reuse a flag which no current driver may
> > not be a good idea. I could add a new flag for that
> > if people like that.
> >
> > The second is a patch offering a generic solution
> > for tracking buffers which have been pushed to
> > hardware(or firmware). It didn't record which buffer
> > that hardware(firmware) still holds for future
> > decoding(likes the reference buffer), while it
> > has been sent to the user(dequeue). We may need
> > a flag for this work.
>
> I am dropping this series from patchwork: clearly this generated
> a lot of discussion, and I think that needs to come to a conclusion.
>
> BTW, I believe that at minimum the codec-specific parts in
> v4l2-mem2mem.c should be split off in their own source (v4l2-m2m-codec.c?).

I like the idea. This way we could possibly evolve the framework more
towards the codec helpers, reusing as much code as possible, but also
keeping the basic implementation simple.

>
> I agree with Tomasz that mem2mem.c was originally for simple m2m devices,
> and adding all sorts of codec specific code to that source doesn't make
> it easier to follow.
>
> Regards,
>
>         Hans
>
> >
> > Hsia-Jun(Randy) Li (1):
> >   media: v4l2-mem2mem: add a list for buf used by hw
> >
> > Randy Li (1):
> >   media: v4l2-mem2mem: allow device run without buf
> >
> >  drivers/media/v4l2-core/v4l2-mem2mem.c | 30 +++++++++++++++++---------
> >  include/media/v4l2-mem2mem.h           | 10 ++++++++-
> >  2 files changed, 29 insertions(+), 11 deletions(-)
> >
>