linux-kernel - Re: [PATCH 0/2] Improve V4L2 M2M job scheduler

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 18 Aug 2023 16:45:09 +0200
From:   Hans Verkuil <hverkuil@...all.nl>
To:     Hsia-Jun Li <randy.li@...aptics.com>, linux-media@...r.kernel.org
Cc:     ayaka@...lik.info, hans.verkuil@...co.com, tfiga@...omium.org,
        mchehab@...nel.org, laurent.pinchart@...asonboard.com,
        hiroh@...omium.org, linux-kernel@...r.kernel.org,
        nicolas@...fresne.ca
Subject: Re: [PATCH 0/2] Improve V4L2 M2M job scheduler

On 04/07/2023 06:00, Hsia-Jun Li wrote:
> From: "Hsia-Jun(Randy) Li" <randy.li@...aptics.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(-)
>