| Message ID | 20230704040044.681850-1-randy.li@synaptics.com |
|---|---|
| Headers | show |
| Series | Improve V4L2 M2M job scheduler | expand |
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(-) >
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(-) > > >
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(-)