[PATCH v2, 5/9] media: mtk-jpegenc: Generalize jpeg encode irq interfaces

Tzung-Bi Shih tzungbi at google.com
Tue Jul 6 04:00:43 PDT 2021


On Wed, Jun 30, 2021 at 3:28 PM kyrie.wu <kyrie.wu at mediatek.com> wrote:
> Generalizes jpeg encode irq interfaces to support different hardware.
There are some missing pieces for using the code.  I guess the patch
needs to be submitted with other patches or needs to further be
divided.

> + * mtk_jpeg_enc_param:  General jpeg encoding parameters
> + * @enc_w:             image width
> + * @enc_h:             image height
> + * @enable_exif:       EXIF enable for jpeg encode mode
> + * @enc_quality:       destination image quality in encode mode
> + * @enc_format:                input image format
> + * @restart_interval:  JPEG restart interval for JPEG encoding
> + * @img_stride:                jpeg encoder image stride
> + * @mem_stride:                jpeg encoder memory stride
> + * @total_encdu:       total 8x8 block number
They are not well-aligned.

> +struct mtk_jpeg_enc_param {
> +       u32 enc_w;
> +       u32 enc_h;
> +       u32 enable_exif;
> +       u32 enc_quality;
> +       u32 enc_format;
> +       u32 restart_interval;
> +       u32 img_stride;
> +       u32 mem_stride;
> +       u32 total_encdu;
> +};
They are not used.

> +       u32 bs_size;
> +       int flags;
They are not used.

> +       struct mtk_jpeg_enc_param enc_param;
> +       struct mtk_jpeg_ctx *curr_ctx;
They are not used.

> +void mtk_jpeg_put_buf(struct mtk_jpeg_dev *jpeg)
> +{
> +       struct mtk_jpeg_ctx *ctx;
> +       struct vb2_v4l2_buffer *dst_buffer;
> +       struct list_head *temp_entry;
> +       struct list_head *pos;
> +       struct mtk_jpeg_src_buf *dst_done_buf, *tmp_dst_done_buf;
> +       unsigned long flags;
> +
> +       ctx = jpeg->hw_param.curr_ctx;
> +       if (!ctx) {
> +               dev_err(jpeg->dev, "comp_jpeg ctx fail !!!\n");
> +               return;
> +       }
> +
> +       dst_buffer = jpeg->hw_param.dst_buffer;
> +       if (!dst_buffer) {
> +               dev_err(jpeg->dev, "comp_jpeg dst_buffer fail !!!\n");
> +               return;
> +       }
The caller "mtk_jpegenc_hw_irq_handler()" doesn't even check ctx and
dst_buffer.  Does mtk_jpeg_put_buf() need to validate them?

> +       spin_lock_irqsave(&ctx->done_queue_lock, flags);
> +       list_add_tail(&dst_done_buf->list, &ctx->dst_done_queue);
> +       while (!list_empty(&ctx->dst_done_queue) &&
> +              (pos != &ctx->dst_done_queue)) {
Why does it need to compare `pos != &ctx->dst_done_queue`?  On a
related note, at the first time, pos will be some garbage data from
stack.

> +irqreturn_t mtk_jpegenc_hw_irq_handler(int irq, void *priv)
No code is using mtk_jpegenc_hw_irq_handler.  Have no enough context
to review the code.

> +       src_buf = jpeg->hw_param.src_buffer;
> +       dst_buf = jpeg->hw_param.dst_buffer;
> +       ctx = jpeg->hw_param.curr_ctx;
> +       master_jpeg = ctx->jpeg;
Could they be inlined to above where the variables are declared?

> +enum mtk_jpeg_hw_state {
> +       MTK_JPEG_HW_IDLE = 0,
> +       MTK_JPEG_HW_BUSY = 1,
MTK_JPEG_HW_BUSY is not used.

> @@ -124,13 +135,18 @@ struct mtk_jpeg_dev {
>         struct v4l2_m2m_dev     *m2m_dev;
>         void                    *alloc_ctx;
>         struct video_device     *vdev;
> -       void __iomem            *reg_base;
>         struct device           *larb;
>         struct delayed_work job_timeout_work;
>         const struct mtk_jpeg_variant *variant;
>
> +       void __iomem *reg_base[MTK_JPEGENC_HW_MAX];
> +       int jpegenc_irq;
jpegenc_irq is not used.

> @@ -189,6 +205,12 @@ struct mtk_jpeg_ctx {
>         u8 enc_quality;
>         u8 restart_interval;
>         struct v4l2_ctrl_handler ctrl_hdl;
> +
> +       struct list_head dst_done_queue;
> +       spinlock_t done_queue_lock;     /* spinlock protecting done queue */
> +       u32 total_frame_num;
total_frame_num is not used.


Need to double confirm: why sometimes the code uses
jpeg->reg_base[MTK_JPEGENC_HW0] but sometimes jpeg->reg_base[0]?



More information about the linux-arm-kernel mailing list