Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <c79a2a0d-9510-b514-3b94-bc1d68e3d53b@xs4all.nl>
Date:   Fri, 18 Aug 2023 16:45:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.12.0
Subject: Re: [PATCH 0/2] Improve V4L2 M2M job scheduler
Content-Language: en-US, nl
To:     Hsia-Jun Li <randy.li@synaptics.com>, linux-media@vger.kernel.org
Cc:     ayaka@soulik.info, hans.verkuil@cisco.com, tfiga@chromium.org,
        mchehab@kernel.org, laurent.pinchart@ideasonboard.com,
        hiroh@chromium.org, linux-kernel@vger.kernel.org,
        nicolas@ndufresne.ca
References: <20230704040044.681850-1-randy.li@synaptics.com>
From:   Hans Verkuil <hverkuil@xs4all.nl>
In-Reply-To: <20230704040044.681850-1-randy.li@synaptics.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

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(-)
>