Linux-Devicetree Archive on lore.kernel.org
 help / color / Atom feed
From: Xia Jiang <xia.jiang@mediatek.com>
To: Tomasz Figa <tfiga@chromium.org>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	Rick Chang <rick.chang@mediatek.com>,
	<linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	<srv_heupstream@mediatek.com>, <senozhatsky@chromium.org>,
	<mojahsu@chromium.org>, <drinkcat@chromium.org>,
	<maoguang.meng@mediatek.com>, <sj.huang@mediatek.com>
Subject: Re: [PATCH RESEND v9 18/18] media: platform: Add jpeg enc feature
Date: Wed, 1 Jul 2020 16:28:41 +0800
Message-ID: <1593592121.4007.33.camel@mhfsdcap03> (raw)
In-Reply-To: <20200630165301.GA1212092@chromium.org>

On Tue, 2020-06-30 at 16:53 +0000, Tomasz Figa wrote:
> Hi Xia,
> 
> On Tue, Jun 30, 2020 at 10:56:21AM +0800, Xia Jiang wrote:
> > On Thu, 2020-06-11 at 18:46 +0000, Tomasz Figa wrote:
> > > Hi Xia,
> > > 
> > > On Thu, Jun 04, 2020 at 05:05:53PM +0800, Xia Jiang wrote:
> [snip]
> > > > +static void mtk_jpeg_enc_device_run(void *priv)
> > > > +{
> > > > +	struct mtk_jpeg_ctx *ctx = priv;
> > > > +	struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> > > > +	struct vb2_v4l2_buffer *src_buf, *dst_buf;
> > > > +	enum vb2_buffer_state buf_state = VB2_BUF_STATE_ERROR;
> > > > +	unsigned long flags;
> > > > +	struct mtk_jpeg_src_buf *jpeg_src_buf;
> > > > +	struct mtk_jpeg_enc_bs enc_bs;
> > > > +	int ret;
> > > > +
> > > > +	src_buf = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > > > +	dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> > > > +	jpeg_src_buf = mtk_jpeg_vb2_to_srcbuf(&src_buf->vb2_buf);
> > > > +
> > > > +	ret = pm_runtime_get_sync(jpeg->dev);
> > > > +	if (ret < 0)
> > > > +		goto enc_end;
> > > > +
> > > > +	spin_lock_irqsave(&jpeg->hw_lock, flags);
> > > > +
> > > > +	/*
> > > > +	 * Resetting the hardware every frame is to ensure that all the
> > > > +	 * registers are cleared. This is a hardware requirement.
> > > > +	 */
> > > > +	mtk_jpeg_enc_reset(jpeg->reg_base);
> > > > +
> > > > +	mtk_jpeg_set_enc_dst(ctx, jpeg->reg_base, &dst_buf->vb2_buf, &enc_bs);
> > > > +	mtk_jpeg_set_enc_src(ctx, jpeg->reg_base, &src_buf->vb2_buf);
> > > > +	mtk_jpeg_enc_set_config(jpeg->reg_base, ctx->out_q.fmt->hw_format,
> > > > +				ctx->enable_exif, ctx->enc_quality,
> > > > +				ctx->restart_interval);
> > > > +	mtk_jpeg_enc_start(jpeg->reg_base);
> > > 
> > > Could we just move the above 5 functions into one function inside
> > > mtk_jpeg_enc_hw.c that takes mtk_jpeg_dev pointer as its argument, let's
> > > say mtk_jpeg_enc_hw_run() and simply program all the data to the registers
> > > directly, without the extra level of abstractions?
> > I can move the 5 functions into one function(mtk_jpeg_enc_hw_run()), but
> > this function will be very long, because it contains computation code
> > such as setting dst addr, blk_num, quality.
> > In v4, you have adviced the following architecture:
> > How about the following model, as used by many other drivers:
> > 
> > mtk_jpeg_enc_set_src()
> > {
> >         // Set any registers related to source format and buffer
> > }
> > 
> > mtk_jpeg_enc_set_dst()
> > {
> >         // Set any registers related to destination format and buffer
> > }
> > 
> > mtk_jpeg_enc_set_params()
> > {
> >         // Set any registers related to additional encoding parameters
> > }
> > 
> > mtk_jpeg_enc_device_run(enc, ctx)
> > {
> >         mtk_jpeg_enc_set_src(enc, src_buf, src_fmt);
> >         mtk_jpeg_enc_set_dst(enc, dst_buf, dst_fmt);
> >         mtk_jpeg_enc_set_params(enc, ctx);
> >         // Trigger the hardware run
> > }
> > I think that this architecture is more clear(mtk_jpeg_enc_set_config is
> > equivalent to mtk_jpeg_enc_set_params).
> > Should I keep the original architecture or move 5 functions into
> > mtk_jpeg_enc_hw_run?
> 
> Sounds good to me.
> 
> My biggest issue with the code that it ends up introducing one more
> level of abstraction, but with the approach you suggested, the arguments
> just accept standard structs, which avoids that problem.
Dear Tomasz,

Sorry for that I didn't understand your final preference.

As you mentioned, using mtk_jpeg_dev pointer as its argument, but some
arguments come from mtk_jpeg_ctx pointer, such as ctx->enable_exif/
ctx->enc_quality/ctx->restart_interval. Should we use  mtk_jpeg_ctx
pointer as its argument? Should we use src_dma_addr/dst_dma_addr as its
arguments too? Because that src_dma_addr/dst_dma_addr need to be getted
by v4l2 interfaces(
src_buf=v4l2_m2m_next_src_buf();
src_dma_ddr=vb2_dma_contig_plane_dma_addr();). 
Using V4L2 interfaces in mtk_jpeg_enc_hw.c doesn't seem reasonable.

solution 1:
mtk_jpeg_enc_hw_run(ctx, src_dma_addr, dst_dma_addr)
{
	//Set all the registers
without one more level of abstraction
}

solution 2:
mtk_jpeg_enc_reset(jpeg)
{
	//set the reset register
}

mtk_jpeg_set_enc_dst(ctx, dst_dma_addr)
{
	
	//Set any registers related to destination format and buffer
without one more level of abstraction
}
mtk_jpeg_set_enc_src(ctx, src_dma_addr)
{

	//Set any registers related to source format and buffer     without one
more level of abstraction
}
mtk_jpeg_enc_set_config(ctx)
{
	// Set any registers related to additional encoding parameters
without one more level of abstraction
}
mtk_jpeg_enc_start(jpeg)
{
	//set the trigger register
}

Solution 1 or Solution 2?

Best Regards,
Xia Jiang
> 
> [snip]
> > > > +
> > > > +	ctx->fh.ctrl_handler = &ctx->ctrl_hdl;
> > > > +	ctx->colorspace = V4L2_COLORSPACE_JPEG,
> > > > +	ctx->ycbcr_enc = V4L2_YCBCR_ENC_DEFAULT;
> > > > +	ctx->quantization = V4L2_QUANTIZATION_DEFAULT;
> > > > +	ctx->xfer_func = V4L2_XFER_FUNC_DEFAULT;
> > > 
> > > Since we already have a v4l2_pix_format_mplane struct which has fields for
> > > the above 4 values, could we just store them there?
> > > 
> > > Also, I don't see this driver handling the colorspaces in any way, but it
> > > seems to allow changing them from the userspace. This is incorrect, because
> > > the userspace has no way to know that the colorspace is not handled.
> > > Instead, the try_fmt implementation should always override the
> > > userspace-provided colorspace configuration with the ones that the driver
> > > assumes.
> > > 
> > > > +	pix_mp->width = MTK_JPEG_MIN_WIDTH;
> > > > +	pix_mp->height = MTK_JPEG_MIN_HEIGHT;
> > > > +
> > > > +	q->fmt = mtk_jpeg_find_format(V4L2_PIX_FMT_YUYV,
> > > > +				      MTK_JPEG_FMT_FLAG_ENC_OUTPUT);
> > > > +	vidioc_try_fmt(container_of(pix_mp, struct v4l2_format,
> > > > +				    fmt.pix_mp), q->fmt);
> > > > +	q->w = pix_mp->width;
> > > > +	q->h = pix_mp->height;
> > > > +	q->crop_rect.width = pix_mp->width;
> > > > +	q->crop_rect.height = pix_mp->height;
> > > > +	q->sizeimage[0] = pix_mp->plane_fmt[0].sizeimage;
> > > > +	q->bytesperline[0] = pix_mp->plane_fmt[0].bytesperline;
> > > 
> > > Actually, do we need this custom mtk_jpeg_q_data struct? Why couldn't we
> > > just keep the same values inside the standard v4l2_pix_format_mplane
> > > struct?
> > I think that we need mtk_jpeg_q_data struct.If we delete it, how can we
> > know these values(w, h, sizeimage, bytesperline, mtk_jpeg_fmt) belong to
> > output or capture(output and capture's sizeimages are different, width
> > and height are differnt too for jpeg dec )?We have
> > s_fmt_vid_out_mplane/cap_mplane function to set these values.
> > 
> > But we can use standard v4l2_pix_format_mplane struct replacing the w, h
> > bytesperline, sizeimage in mtk_jpeg_q_data struct like this:
> > struct mtk_jpeg_q_data{
> > 	struct mtk_jpeg_fmt *fmt;
> > 	struct v4l2_pix_format_mplane pix_mp;
> > 	struct v4l2_rect enc_crop_rect
> > }
> > Then delete ctx->colorspace ctx->ycbcr_enc ctx->quantization
> > ctx->xfer_func, becuase v4l2_pix_format_mplane in q_data has contained
> > them and assign them for out_q and cap_q separately.
> > 
> > WDYT?
> 
> Sounds good to me. I was considering just making it like
> 
> struct mtk_jpeg_ctx {
> 	struct mtk_jpeg_fmt *src_fmt;
> 	struct v4l2_pix_format_mplane src_pix_mp;
> 	struct v4l2_rect src_crop;
> 
> 	struct mtk_jpeg_fmt *dst_fmt;
> 	struct v4l2_pix_format_mplane dst_pix_mp;
> 	struct v4l2_rect dst_crop;
> };
> 
> but I like your suggestion as well, as long as custom data structures
> are not used to store standard information.
> [snip]
> > > > @@ -1042,8 +1619,12 @@ static int mtk_jpeg_probe(struct platform_device *pdev)
> > > >  		return jpeg_irq;
> > > >  	}
> > > >  
> > > > -	ret = devm_request_irq(&pdev->dev, jpeg_irq, mtk_jpeg_dec_irq, 0,
> > > > -			       pdev->name, jpeg);
> > > > +	if (jpeg->variant->is_encoder)
> > > > +		ret = devm_request_irq(&pdev->dev, jpeg_irq, mtk_jpeg_enc_irq,
> > > > +				       0, pdev->name, jpeg);
> > > > +	else
> > > > +		ret = devm_request_irq(&pdev->dev, jpeg_irq, mtk_jpeg_dec_irq,
> > > > +				       0, pdev->name, jpeg);
> > > 
> > > Rather than having "is_encoder" in the variant struct, would it make more
> > > sense to have "irq_handler" instead? That would avoid the explicit if.
> > Do you mean to delete "is_encoder"? It is used 8 times in the
> > driver.Should I move them all to the match data?
> 
> Yes. It would make the code linear and the varability between the
> decoder and encoder would be self-contained in the variant struct.
> 
> Best regards,
> Tomasz


  reply index

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04  9:05 [PATCH RESEND v9 00/18] Add support for mt2701 JPEG ENC support Xia Jiang
2020-06-04  9:05 ` Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 01/18] media: platform: Improve subscribe event flow for bug fixing Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 02/18] media: platform: Improve queue set up " Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 03/18] media: platform: Improve getting and requesting irq " Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 04/18] media: platform: Change the fixed device node number to unfixed value Xia Jiang
2020-06-11 11:58   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 05/18] media: platform: Improve power on and power off flow Xia Jiang
2020-06-11 12:08   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 06/18] media: platform: Delete the resetting hardware flow in the system PM ops Xia Jiang
2020-06-11 11:59   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 07/18] media: platform: Improve the implementation of " Xia Jiang
2020-06-11 14:17   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 08/18] media: platform: Cancel the last frame handling flow Xia Jiang
2020-06-11 14:25   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 09/18] media: platform: Delete zeroing the reserved fields Xia Jiang
2020-06-11 14:27   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 10/18] media: platform: Stylistic changes for improving code quality Xia Jiang
2020-06-11 14:28   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 11/18] media: platform: Use generic rounding helpers Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 12/18] media: platform: Change MTK_JPEG_COMP_MAX macro definition location Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 13/18] media: platform: Delete redundant code and add annotation for an enum Xia Jiang
2020-06-11 16:50   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 14/18] media: dt-bindings: Add jpeg enc device tree node document Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 15/18] arm: dts: mt2701: Add jpeg enc device tree node Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 16/18] media: platform: Rename jpeg dec file name Xia Jiang
2020-06-04  9:05 ` [PATCH RESEND v9 17/18] media: platform: Rename existing functions/defines/variables Xia Jiang
2020-06-08 10:59   ` Hans Verkuil
2020-06-11 16:48   ` Tomasz Figa
2020-06-04  9:05 ` [PATCH RESEND v9 18/18] media: platform: Add jpeg enc feature Xia Jiang
2020-06-07 23:36   ` Chun-Kuang Hu
2020-06-08 10:54   ` Hans Verkuil
2020-06-11 18:46   ` Tomasz Figa
2020-06-30  2:56     ` Xia Jiang
2020-06-30 16:53       ` Tomasz Figa
2020-07-01  8:28         ` Xia Jiang [this message]
2020-07-01 11:07           ` Tomasz Figa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1593592121.4007.33.camel@mhfsdcap03 \
    --to=xia.jiang@mediatek.com \
    --cc=devicetree@vger.kernel.org \
    --cc=drinkcat@chromium.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maoguang.meng@mediatek.com \
    --cc=matthias.bgg@gmail.com \
    --cc=mchehab+samsung@kernel.org \
    --cc=mojahsu@chromium.org \
    --cc=rick.chang@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=senozhatsky@chromium.org \
    --cc=sj.huang@mediatek.com \
    --cc=srv_heupstream@mediatek.com \
    --cc=tfiga@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-Devicetree Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-devicetree/0 linux-devicetree/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-devicetree linux-devicetree/ https://lore.kernel.org/linux-devicetree \
		devicetree@vger.kernel.org
	public-inbox-index linux-devicetree

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-devicetree


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git