Message-ID: <590a078c46847d605e3e35ff404d774c4d36205c.camel@mediatek.com>
Date: Wed, 30 Oct 2024 03:20:55 +0000
From: CK Hu (胡俊光) <ck.hu@...iatek.com>
To: "sumit.semwal@...aro.org" <sumit.semwal@...aro.org>,
	"christian.koenig@....com" <christian.koenig@....com>, "mchehab@...nel.org"
	<mchehab@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>,
	"robh@...nel.org" <robh@...nel.org>, "matthias.bgg@...il.com"
	<matthias.bgg@...il.com>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Shu-hsiang Yang (楊舒翔)
	<Shu-hsiang.Yang@...iatek.com>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-mediatek@...ts.infradead.org" <linux-mediatek@...ts.infradead.org>,
	"yunkec@...omium.org" <yunkec@...omium.org>, "linaro-mm-sig@...ts.linaro.org"
	<linaro-mm-sig@...ts.linaro.org>, "linux-media@...r.kernel.org"
	<linux-media@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>, Yaya Chang (張雅清)
	<Yaya.Chang@...iatek.com>, Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@...iatek.com>,
	"dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
	Teddy Chen (陳乾元) <Teddy.Chen@...iatek.com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "hidenorik@...omium.org"
	<hidenorik@...omium.org>, Shun-Yi Wang (王順億)
	<Shun-Yi.Wang@...iatek.com>
Subject: Re: [PATCH v1 05/10] media: platform: mediatek: add isp_7x camsys
 unit

Hi, Shu-hsiang:

On Tue, 2024-10-29 at 15:03 +0800, CK Hu wrote:
> Hi, Shu-hsiang:
> 
> On Wed, 2024-10-09 at 19:15 +0800, Shu-hsiang Yang wrote:
> > Introduces the top media device driver for the MediaTek ISP7X CAMSYS.
> > The driver maintains the camera system, including sub-device management,
> > DMA operations, and integration with the V4L2 framework. It handles
> > request stream data, buffer management, and MediaTek-specific features,
> > and pipeline management, streaming control, error handling mechanism.
> > Additionally, it aggregates sub-drivers for the camera interface, raw
> > and yuv pipelines.
> > 
> > Signed-off-by: Shu-hsiang Yang <Shu-hsiang.Yang@...iatek.com>
> > ---
> 
> [snip]
> 
> > +struct mtk_cam_device {
> > +	struct device *dev;
> > +
> > +	struct v4l2_device v4l2_dev;
> > +	struct v4l2_async_notifier notifier;
> > +	struct media_device media_dev;
> > +	void __iomem *base;
> > +
> > +	struct mtk_scp *scp;
> > +	struct device *smem_dev;
> > +	phandle rproc_phandle;
> > +	struct rproc *rproc_handle;
> > +
> > +	unsigned int composer_cnt;
> > +
> > +	unsigned int num_seninf_devices;
> > +	unsigned int num_raw_devices;
> > +	unsigned int num_larb_devices;
> > +
> > +	/* raw_pipe controller subdev */
> > +	struct mtk_raw raw;
> > +	struct mutex queue_lock; /* protect queue request */
> > +
> > +	unsigned int max_stream_num;
> > +	unsigned int streaming_ctx;
> > +	unsigned int streaming_pipe;
> > +	struct mtk_cam_ctx *ctxs;
> > +
> > +	/* request related */
> > +	struct list_head pending_job_list;
> > +	spinlock_t pending_job_lock; /* protect pending_job_list */
> > +	struct list_head running_job_list;
> > +	unsigned int running_job_count;
> > +	spinlock_t running_job_lock; /* protect running_job_list */
> > +
> > +	/* standard v4l2 buffer control */
> > +	struct list_head dma_pending;
> > +	spinlock_t dma_pending_lock; /* protect dma_pending_list */
> > +	struct list_head dma_processing;
> > +	spinlock_t dma_processing_lock; /* protect dma_processing_list and dma_processing_count */
> > +	unsigned int dma_processing_count;
> 
> I would like scp-related variable has the scp prefix.
> 
> struct list_head scp_dma_processing;
> spinlock_t scp_dma_processing_lock;
> unsigned int scp_dma_processing_count;
> 
> So it's easy to understand that scp_dma_processing_count's max value is 2.
> One buffer is currently doing dma, and another one is waiting for dma. Both buffer are queued in scp.

Forget previous comment. After review the buffer control, I think the buffer list should be simplified.
dma_pending, dma_processing, using_buffer_list, composed_buffer_list, processing_buffer_list could be merge into one buf_list.
The buffer in buf_list has different status.
In init, the buffer is queued into driver and status is waiting.

buf_list-> buf0(waiting)-> buf1(waiting)-> buf2(waiting)-> buf3(waiting)-> buf4(waiting)

In mtk_cam_buf_try_queue(), use scp to generate cq buffer content of buf0 and buf1, so the status is scp_generate_cq.

buf_list-> buf0(scp_generate_cq)-> buf1(scp_generate_cq)-> buf2(waiting)-> buf3(waiting)-> buf4(waiting)

So the buf_entry is bound to buf0 and buf1, it's not necessary have using_buffer_list, composed_buffer_list, processing_buffer_list to manage buf_entry.

In isp_composer_handler_ack(), scp has finish generating cq buffer content, so the status is cq_ready.
In the meantime, use scp to generate cq buffer content of buf2.

buf_list-> buf0(cq_ready)-> buf1(scp_generate_cq)-> buf2(scp_generate_cq)-> buf3(waiting)-> buf4(waiting)

In mtk_camsys_raw_frame_start(), apply cq buffer to hardware, so the status is cq_apply

buf_list-> buf0(cq_apply)-> buf1(scp_generate_cq)-> buf2(scp_generate_cq)-> buf3(waiting)-> buf4(waiting)

In mtk_camsys_frame_done(), hardware has finished writing video into buffer, so the status is done

buf_list-> buf0(done)-> buf1(scp_generate_cq)-> buf2(scp_generate_cq)-> buf3(waiting)-> buf4(waiting)

In this design, just need one buf_list with status.
The code would be more simple.
Simple code would has less bug.
Maybe you could drop so many debug utility.

Regards,
CK


> 
> Regards,
> CK
> 
> > +
> > +	struct mtk_cam_debug_fs *debug_fs;
> > +	struct workqueue_struct *debug_wq;
> > +	struct workqueue_struct *debug_exception_wq;
> > +	wait_queue_head_t debug_exception_waitq;
> > +};
> > +
> 
> 

Powered by blists - more mailing lists