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