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=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,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 5D15CC48BD4 for ; Tue, 25 Jun 2019 11:36:13 +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 2B87920656 for ; Tue, 25 Jun 2019 11:36:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="oQVqeXpZ" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2B87920656 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=29/k8106ME0wbMrQRpk2lWTG+lRUYqK+RqgT1PT5vFA=; b=oQVqeXpZ7dXfpx ybeN1PTMxJk9B4ukTbTXxLFyLYWwz0rvcRXAdfWjFMBAcNLUxjpKtlE4bojJmurcMySz0UE38MuNl 9JZTpJVho8ppYXbFE3YirFEIEWmzUdONKfr9nVUZXQwGeNX03QU6uM6+URsO1RGmdGudEDj44lwzT 2z2Ebx2iUdMlMrggmHCVGlpielMS8mfWuIu9RSy9MgvP5s2GxsoZST/vJfkUIf4QPHHGV+ysOBKLR bgZBubj8L0wq9QJpATOcdQ8YzdW7htqVPkiDDTgQRwsp1VyFAz91mL3HhdyLBlNNhjMAB2SUXFxzD fQN4WOy7prMMMh7ub/Bg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hfjkC-0006Hw-ND; Tue, 25 Jun 2019 11:36:12 +0000 Received: from mailgw01.mediatek.com ([216.200.240.184]) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hfjk7-0006HU-5x; Tue, 25 Jun 2019 11:36:11 +0000 X-UUID: a1bf63b899584b2fb7b299d1bc04eef3-20190625 X-UUID: a1bf63b899584b2fb7b299d1bc04eef3-20190625 Received: from mtkcas68.mediatek.inc [(172.29.94.19)] by mailgw01.mediatek.com (envelope-from ) (musrelay.mediatek.com ESMTP with TLS) with ESMTP id 897121878; Tue, 25 Jun 2019 03:35:54 -0800 Received: from mtkmbs08n2.mediatek.inc (172.21.101.56) by MTKMBS62N1.mediatek.inc (172.29.193.41) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Jun 2019 04:35:52 -0700 Received: from mtkcas08.mediatek.inc (172.21.101.126) by mtkmbs08n2.mediatek.inc (172.21.101.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 25 Jun 2019 19:35:38 +0800 Received: from [172.21.84.99] (172.21.84.99) by mtkcas08.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1395.4 via Frontend Transport; Tue, 25 Jun 2019 19:35:38 +0800 Message-ID: <1561462538.23799.19.camel@mtksdccf07> Subject: Re: [RFC PATCH V1 6/6] platform: mtk-isp: Add Mediatek DIP driver From: Frederic Chen To: Tomasz Figa Date: Tue, 25 Jun 2019 19:35:38 +0800 In-Reply-To: References: <20190417104511.21514-1-frederic.chen@mediatek.com> <20190417104511.21514-7-frederic.chen@mediatek.com> <20190509094846.GA65444@google.com> <1558466055.15388.342.camel@mtksdccf07> <1560242886.23799.13.camel@mtksdccf07> <1560247648.23799.16.camel@mtksdccf07> X-Mailer: Evolution 3.2.3-0ubuntu6 MIME-Version: 1.0 X-TM-SNTS-SMTP: A96D21B4832B5BB347BCC937165A0AD695ED92798361EA550FFEA438A530F48C2000:8 X-MTK: N X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190625_043609_593392_24D5B999 X-CRM114-Status: GOOD ( 28.02 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Shik Chen , devicetree@vger.kernel.org, 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 , Holmes Chiou =?UTF-8?Q?=28=E9=82=B1=E6=8C=BA=29?= , suleiman@chromium.org, Jerry-ch Chen , Jungo Lin =?UTF-8?Q?=28=E6=9E=97=E6=98=8E=E4=BF=8A=29?= , Sj Huang , yuzhao@chromium.org, "moderated list:ARM/Mediatek SoC support" , zwisler@chromium.org, Matthias Brugger , Christie Yu =?UTF-8?Q?=28=E6=B8=B8=E9=9B=85=E6=83=A0=29?= , Mauro Carvalho Chehab , 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 Hi Tomasz, On Tue, 2019-06-11 at 19:13 +0900, Tomasz Figa wrote: > On Tue, Jun 11, 2019 at 7:07 PM Frederic Chen > wrote: > > > > Hi Tomasz, > > > > > > On Tue, 2019-06-11 at 17:59 +0900, Tomasz Figa wrote: > > > On Tue, Jun 11, 2019 at 5:48 PM Frederic Chen > > > wrote: > > > > > > > > Dear Tomasz, > > > > > > > > I'd like to elaborate more about the tuning_data.va. > > > > Would you like to give us some advice about our improvement proposal inline? > > > > > > > > Thank you very much. > > > > > > > > > > > > On Wed, 2019-05-22 at 03:14 +0800, Frederic Chen wrote: > > > > > Dear Tomasz, > > > > > > > > > > I appreciate your comment. It is very helpful for us. > > > > > > > > > > > > > > > > > diff --git a/drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c b/drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c > > > > > > > new file mode 100644 > > > > > > > index 000000000000..54d2b5f5b802 > > > > > > > --- /dev/null > > > > > > > +++ b/drivers/media/platform/mtk-isp/isp_50/dip/mtk_dip-sys.c > > > > > > > @@ -0,0 +1,1384 @@ > > > > > > > > [snip] > > > > > > > > > > > +static void dip_submit_worker(struct work_struct *work) > > > > > > > +{ > > > > > > > + struct mtk_dip_hw_submit_work *dip_submit_work = > > > > > > > + container_of(work, struct mtk_dip_hw_submit_work, frame_work); > > > > > > > + struct mtk_dip_hw *dip_hw = dip_submit_work->dip_hw; > > > > > > > + struct mtk_dip_dev *dip_dev = mtk_dip_hw_to_dev(dip_hw); > > > > > > > + struct mtk_dip_hw_work *dip_work; > > > > > > > + struct mtk_dip_hw_subframe *buf; > > > > > > > + u32 len, num; > > > > > > > + int ret; > > > > > > > + > > > > > > > + num = atomic_read(&dip_hw->num_composing); > > > > > > > + > > > > > > > + mutex_lock(&dip_hw->dip_worklist.queuelock); > > > > > > > + dip_work = list_first_entry(&dip_hw->dip_worklist.queue, > > > > > > > > [snip] > > > > > > > > > > > + > > > > > > > + if (dip_work->frameparams.tuning_data.pa == 0) { > > > > > > > + dev_dbg(&dip_dev->pdev->dev, > > > > > > > + "%s: frame_no(%d) has no tuning_data\n", > > > > > > > + __func__, dip_work->frameparams.frame_no); > > > > > > > + > > > > > > > + memcpy(&dip_work->frameparams.tuning_data, > > > > > > > + &buf->tuning_buf, sizeof(buf->tuning_buf)); > > > > > > > > > > > > Ditto. > > > > > > > > > > > > > > > > I got it. > > > > > > > > > > > > + memset((char *)buf->tuning_buf.va, 0, DIP_TUNING_SZ); > > > > > > > > > > > > Ditto. > > > > > > > > > > I got it. > > > > > > > > > > > > > > > > > > + /* > > > > > > > + * When user enqueued without tuning buffer, > > > > > > > + * it would use driver internal buffer. > > > > > > > + * So, tuning_data.va should be 0 > > > > > > > + */ > > > > > > > + dip_work->frameparams.tuning_data.va = 0; > > > > > > > > > > > > I don't understand this. We just zeroed the buffer via this kernel VA few > > > > > > lines above, so why would it have to be set to 0? > > > > > > > > > > > > > > > > I will remove this unnecessary line. > > > > > > > > > > > > + } > > > > > > > > After confirming the firmware part, I found that we use this field > > > > (tuning_data.va) to notify firmware if there is no tuning data from > > > > user. > > > > > > > > - frameparams.tuning_data.va is 0: use the default tuning data in > > > > SCP, but we still need to pass > > > > frameparams.tuning_data.pa because > > > > the buffer contains some working > > > > buffer required. > > > > - frameparams.tuning_data.va is not 0: the tuning data was passed from > > > > the user > > > > > > > > Since we should not pass cpu addres to SCP, could I rename tuning_data.va > > > > as tuning_data.cookie, and write a constant value to indicate if SCP > > > > should use its internal default setting or not here? > > > > > > > > For example, > > > > /* SCP uses tuning data passed from userspace*/ > > > > dip_work->frameparams.tuning_data.cookie = MTK_DIP_USER_TUNING_DATA; > > > > > > > > /* SCP uses internal tuning data */ > > > > dip_work->frameparams.tuning_data.cookie = MTK_DIP_DEFAULT_TUNING_DATA; > > > > > > Perhaps we could just call it "present" and set to true or false? > > > > > > > Yes. I would like to use "present" here. > > > > Original: > > struct img_addr { > > u64 va; /* Used by Linux OS access */ > > u32 pa; /* Used by CM4 access */ > > u32 iova; /* Used by IOMMU HW access */ > > } __attribute__ ((__packed__)); > > > > struct img_ipi_frameparam { > > u32 index; > > u32 frame_no; > > u64 timestamp; > > u8 type; /* enum mdp_stream_type */ > > u8 state; > > u8 num_inputs; > > u8 num_outputs; > > u64 drv_data; > > struct img_input inputs[IMG_MAX_HW_INPUTS]; > > struct img_output outputs[IMG_MAX_HW_OUTPUTS]; > > struct img_addr tuning_data; > > struct img_addr subfrm_data; > > struct img_sw_addr config_data; > > struct img_sw_addr self_data; > > } __attribute__ ((__packed__)); > > > > > > Modified: > > struct tuning_buf { > > u8 present; > > I'd make this u32 to keep the other fields aligned. > > > u32 pa; /* Used by CM4 access */ > > u32 iova; /* Used by IOMMU HW access */ > > } __attribute__ ((__packed__)); > We will use u32 to keep the fields aligned in next patch. > Best regards, > Tomasz Sincerely, Frederic Chen _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel