From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_PASS,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BCC25C43381 for ; Fri, 22 Mar 2019 00:13:53 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 8983421900 for ; Fri, 22 Mar 2019 00:13:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VpxD03VA" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8983421900 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=mediatek.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Date:To:From:Subject:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=olLIbYWzDSV2HjIAsLwO4+i+AIiXmwOOhRAAogWSE/A=; b=VpxD03VAuhsGOi RcDdFGjwgqJR5WcbPNGHq0RtPgKRlUHl8Q4khpy2Zbb+Ck0Eji9MGdzj+3dOQm4OUo3Uf88iTd560 cJqI02W1ZOQoaTI0phNh8xR+rpAl1Vu6rRi0KNDj7NPax3GwSeVYMpGasViksvanIDXsBn8J5ye6f 79JuU9Xzsio9U79RVog1bxDW/5vMWkBMITi/QsisEUpkElmxFgiJtrZZxo6XWslSnmeo2oOKBRiW5 FL8XYHDfkPj5AZ4NVm9IEUG2fbMHXIXVV1uYLcVxD9CJjFQFFTNZen1FXt6Xp1eYmP1Mfb7J/YNlO 9JVwR4BS16KP837ljHKA==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1h77of-0001XH-M7; Fri, 22 Mar 2019 00:13:45 +0000 Received: from mailgw02.mediatek.com ([216.200.240.185]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h77ob-0001WR-HO; Fri, 22 Mar 2019 00:13:43 +0000 X-UUID: 9b5b6516718f4719a0936d6a37aedd6a-20190321 X-UUID: 9b5b6516718f4719a0936d6a37aedd6a-20190321 Received: from mtkcas67.mediatek.inc [(172.29.193.45)] by mailgw02.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 318252966; Thu, 21 Mar 2019 16:13:40 -0800 Received: from MTKMBS01DR.mediatek.inc (172.21.101.111) by MTKMBS62N2.mediatek.inc (172.29.193.42) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 21 Mar 2019 17:13:38 -0700 Received: from mtkcas09.mediatek.inc (172.21.101.178) by mtkmbs01dr.mediatek.inc (172.21.101.111) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 22 Mar 2019 08:13:36 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas09.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Fri, 22 Mar 2019 08:13:30 +0800 Message-ID: <1553213610.7066.14.camel@mtksdccf07> Subject: Re: [RFC PATCH V0 7/7] [media] platform: mtk-isp: Add Mediatek ISP Pass 1 driver From: Jungo Lin To: Tomasz Figa Date: Fri, 22 Mar 2019 08:13:30 +0800 In-Reply-To: References: <1549348966-14451-1-git-send-email-frederic.chen@mediatek.com> <1549348966-14451-8-git-send-email-frederic.chen@mediatek.com> <1552378607.13953.71.camel@mtksdccf07> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190321_171341_586955_8B1F39F3 X-CRM114-Status: GOOD ( 32.88 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Sean Cheng =?UTF-8?Q?=28=E9=84=AD=E6=98=87=E5=BC=98=29?= , Laurent Pinchart , Rynn Wu =?UTF-8?Q?=28=E5=90=B3=E8=82=B2=E6=81=A9=29?= , srv_heupstream@mediatek.com, Mauro Carvalho Chehab , Holmes Chiou =?UTF-8?Q?=28=E9=82=B1=E6=8C=BA=29?= , Jerry-ch Chen , Sj Huang , yuzhao@chromium.org, Christie Yu =?UTF-8?Q?=28=E6=B8=B8=E9=9B=85=E6=83=A0=29?= , zwisler@chromium.org, Matthias Brugger , linux-mediatek@lists.infradead.org, Frederic Chen , Hans Verkuil , "list@263.net:IOMMU DRIVERS , Joerg Roedel , " , Linux Media Mailing List Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 2019-03-21 at 12:45 +0900, Tomasz Figa wrote: > On Tue, Mar 12, 2019 at 5:16 PM Jungo Lin wrote: > > > > On Thu, 2019-03-07 at 19:04 +0900, Tomasz Figa wrote: > [snip] > > > > diff --git a/drivers/media/platform/mtk-isp/isp_50/cam/mtk_cam-smem-drv.c b/drivers/media/platform/mtk-isp/isp_50/cam/mtk_cam-smem-drv.c > > > > new file mode 100644 > > > > index 0000000..020c38c > > > > --- /dev/null > > > > +++ b/drivers/media/platform/mtk-isp/isp_50/cam/mtk_cam-smem-drv.c > > > > > > I don't think we need any of the code that is in this file. We should > > > just use the DMA API. We should be able to create appropriate reserved > > > memory pools in DT and properly assign them to the right allocating > > > devices. > > > > > > Skipping review of this file for the time being. > > > > > > > For this file, we may need your help. > > Its purpose is same as DIP SMEM driver. > > It is used for creating the ISP P1 specific vb2 buffer allocation > > context with reserved memory. Unfortunately, the implementation of > > mtk_cam-smem-drive.c is our best solution now. > > > > Could you give us more hints how to implement? > > Or do you think we could leverage the implementation from "Samsung S5P > > Multi Format Codec driver"? > > drivers/media/platform/s5p-mfc/s5p_mfc.c > > - s5p_mfc_configure_dma_memory function > > - s5p_mfc_configure_2port_memory > > - s5p_mfc_alloc_memdev > > I think we can indeed take some ideas from there. I need some time to > check this and give you more details. > > [snip] Thanks for your support. If you have any input, please kindly let us know. We will list this revision in the to-do list of V1 version. At the same time, we will also continue to investigate how to implement based on current information. > > > > + } > > > > + > > > > + dev_dbg(&isp_dev->pdev->dev, "streamed on sensor(%s)\n", > > > > + cio->sensor->entity.name); > > > > + > > > > + ret = mtk_cam_ctx_streamon(&isp_dev->ctx); > > > > + if (ret) { > > > > + dev_err(&isp_dev->pdev->dev, > > > > + "Pass 1 stream on failed (%d)\n", ret); > > > > + return -EPERM; > > > > + } > > > > + > > > > + isp_dev->mem2mem2.streaming = enable; > > > > + > > > > + ret = mtk_cam_dev_queue_buffers(isp_dev, true); > > > > + if (ret) > > > > + dev_err(&isp_dev->pdev->dev, > > > > + "failed to queue initial buffers (%d)", ret); > > > > + > > > > + dev_dbg(&isp_dev->pdev->dev, "streamed on Pass 1\n"); > > > > + } else { > > > > + if (cio->sensor) { > > > > > > Is it possible to have cio->sensor NULL here? This function would have > > > failed if it wasn't found when enabling. > > > > > > > In the original design, it is protected to avoid abnormal double stream > > off (s_stream) call from upper layer. For stability reason, it is better > > to check. > > If so, having some state (e.g. field in a struct) for tracking the > streaming state would make the code much easier to understand. > Also, the error message on the else case is totally misleading, > because it complains about a missing sensor, rather than double > s_stream. > > [snip] Yes, your suggestion is helpful. We will correct our implementation to make it more clear in next version. > > Thanks for your valued comments on part 2. > > It is helpful for us to make our driver implementation better. > > > > We'd like to know your opinion about the schedule for RFC V1. > > Do you suggest us to send RFC V1 patch set after revising all comments > > on part 1 & 2 or wait for part 3 review? > > I'm going to be a bit busy for the next few days, so it may be a good > idea to address the comments for parts 1, 2 and 3 and send RFC V1. > Also, for the more general comments, please check if they don't apply > to the other drivers too (DIP, FD, Seninf, MDP). Thanks in advance! > > Best regards, > Tomasz > Ok, we plan to send our RFC V1 for ISP P1 driver next week after revising current comments. For DIP & FD drivers, they also have common implementations with P1 driver. We will sync current comments to them. For Seninf & MDP drivers. we will share our coding style & coding defect issues to them. Moreover, we will provide our V4L2_Compliance testing report from RFC V1. Best regards, Jungo > _______________________________________________ > Linux-mediatek mailing list > Linux-mediatek@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-mediatek _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel