Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp4558886pxv; Tue, 6 Jul 2021 04:02:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyu8WT+6H1NXmGG9xGYUs7L3ZNOe2kH81r0dUmE56BwkYbAI7z9ozDytClkcpVGsLR6YcAL X-Received: by 2002:a17:907:7294:: with SMTP id dt20mr12274732ejc.369.1625569347611; Tue, 06 Jul 2021 04:02:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1625569347; cv=none; d=google.com; s=arc-20160816; b=D6l5GNuOiBhe0plxBANBLztn4xmC0G9TMHlEG2eHSbX4BVZQnGswd9rgnUmjEJnV5m ZKyqz7iwzfw7K0wC33TbhXzHezhjeFKIIHeHRH/nE/x+TnmnvjyblRa3xg1jGO3UV5Z1 v9Ddg3jt/gz2zlkyTutEkHWx9HqCsn00BM0AJATYXSMqVVnS3QGkzKnFEg/PCPwmU3TJ IIp5TCS5aGl5LawYqfBohaaL4kBEi/2hkNhj6NpTzAffnTtf2ZoBZvwDvOW5r0QRfBNl o+WJYoF67ByI6y7jXZk2kC0DoRKouZNTIMIP21qRgPhF3m7MPr8h6BwJ0RLxRM2b/S8c bVeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Mf1V7YBSH0+8w/rbv+rSEQ/3yayHw9nqaQvqX58hsvw=; b=WGSL8+/bdTJ11mPs5mzMxzrmzsPwOIKBOR8hrKKIWMeymvUTfYOhNWOxeKgECDBwkx UmPS2UaN8rmbGFix17bnexPv7Af2H2+A4BiNQj/MHAlHbH3LM/vjUM+XQ7MIrfdQeBqu iX6zeppjVlacJ87GcTAWoNhMta8DG7v5OCop8O0Y2Sjw1KbkRsfohJQ3rqfu+XIOMd80 hGwvVQ7wNwVCoYM7DRcuWg/AHzNLV3WrVwuxNyitMsFWa0ZM7lXTt0CY84ThWf5qCx1t 5qAMqMeePSeTW5DsWazNJm8lZPvjPsEr+qBx99X+ywOKPF32rgCVK6BitmSr0I7nqrkG r3zQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Mwluy9OS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e12si14654513ejy.258.2021.07.06.04.02.04; Tue, 06 Jul 2021 04:02:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Mwluy9OS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231774AbhGFLDf (ORCPT + 99 others); Tue, 6 Jul 2021 07:03:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39920 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231585AbhGFLDe (ORCPT ); Tue, 6 Jul 2021 07:03:34 -0400 Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6BF0FC061574 for ; Tue, 6 Jul 2021 04:00:55 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id i13so20149941ilu.4 for ; Tue, 06 Jul 2021 04:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Mf1V7YBSH0+8w/rbv+rSEQ/3yayHw9nqaQvqX58hsvw=; b=Mwluy9OSv9pZApWbLchbl6PRMI+pLr/JEGuuPBMJqtHNX5qBYpBYXSu8ehRp0I13Ko VBnBg1714BD4gYCQu9Vx1kN5uzs5CnOyjy3RbuiIl7ftNTZpht73dIei2KlktRQ8fRUQ P6W2vGPS8rqim7p2BtKEGPz/Vl1VWXhB52nbS6h8/Ymqc8apj+hS6CR+W4OpjBn6bY2G sn08YhYH9WlmPKXavGRxBJRgUGDKBNO/Wiumdto8z6t8ox6nHOBEWOGIouWsDk1ph4ve 5ECczqd+yWPUkNb+S+K5N5Gc0Ac54nw2A0ObdV/8vYZTWOItI1nZLgWchj2epOu2tVjO P3Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Mf1V7YBSH0+8w/rbv+rSEQ/3yayHw9nqaQvqX58hsvw=; b=cEZNcKLkn+aUJTiH90zwmK1mu4nGE8NhQP8hr/w2z152Of8f0med5t90Mu86+2O3bw +eT7cenQmpuDR3AOHgi5X2318BgycXIQbD1oZid7f7W4f3vHUsHDIZLuOpaEaYl63eXn QjXPyVmOUGJmjVoOwWXuL47hNrEHtVuDeRDP0qfyzBSXBO9sHEHHbbBmkphX51oV66m3 5/q5MVuIINhyYCgFCR7YfPR0n8GklRW+dg/pPFM1pf6CgBfQ1fofwqJ54Ie7dSqs6429 +bCkhV+AHu+RNoyHulzJuebK/0AMl1rWRBbkhzZA56J5JMHAVt0R9UjWAaqT7BxqDy+D YP/w== X-Gm-Message-State: AOAM533Jhidr7fouSnK7c4AdwxYHeQRSsnd45p/XQniv4Ga5IiNmyvUB mtSciaklsY2oAPED1QlfjEdlV20gTfhY6POt7XqIJg== X-Received: by 2002:a05:6e02:1a2a:: with SMTP id g10mr12177660ile.204.1625569254711; Tue, 06 Jul 2021 04:00:54 -0700 (PDT) MIME-Version: 1.0 References: <1625038079-25815-1-git-send-email-kyrie.wu@mediatek.com> <1625038079-25815-6-git-send-email-kyrie.wu@mediatek.com> In-Reply-To: <1625038079-25815-6-git-send-email-kyrie.wu@mediatek.com> From: Tzung-Bi Shih Date: Tue, 6 Jul 2021 19:00:43 +0800 Message-ID: Subject: Re: [PATCH v2, 5/9] media: mtk-jpegenc: Generalize jpeg encode irq interfaces To: "kyrie.wu" Cc: Hans Verkuil , Mauro Carvalho Chehab , Rob Herring , Bin Liu , Matthias Brugger , Tzung-Bi Shih , Project_Global_Chrome_Upstream_Group@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, Tomasz Figa , xia.jiang@mediatek.com, maoguang.meng@mediatek.com, srv_heupstream@mediatek.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 30, 2021 at 3:28 PM kyrie.wu 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]?