Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp4149038pxb; Mon, 30 Aug 2021 20:47:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyudYh5jLZQBtLpEE6jvRRVPZ5WqP9lQ8tsWH+KOc6OWwDGlyRyapfoZfV4dTwvGU0Zgo7z X-Received: by 2002:a17:907:7668:: with SMTP id kk8mr1875737ejc.248.1630381652433; Mon, 30 Aug 2021 20:47:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630381652; cv=none; d=google.com; s=arc-20160816; b=y5GC+k31AziJZdbiheFZUPF/zcjGRrYNdzX5DP5V6Ud+6OghEq/C4yE2h/9QYFU4un Rsu5mS3eAGkKM+1Dcv9jN8G6mQ7vwWDP1CMX71JsUiIXYLkrR4/StXNN2E6gcfcVeZ23 tKFRQiCnT1flE4cWxDNAeRfyZKvNV1K0UaHtEsPGxzaJ95oLQ8LhUEdqH3ojcWVc+t/Z hyhgxvs1enxnnEdW5VJdDw/Bv/kt5hB3i9npvkCxh3X8VqUvQcGC0FlWsM12XEqJLpTH TNoqXS097jK+3mJV432ol1EXbUGct+szQ38WQed3HYC6H+XK1t5nQ/A+lYmPkE1Tdx6X jYow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=xByzIQcIhhmSgiojq2BqOUhVym64StJSryCTz8ug66c=; b=fmHLi51CzJJmxXAywNZmXh4Bhhy69CRgS4WiaMITdl96iKyfhkwwNTi0ycEpil5Rfq ct7qmzs52wpELTOSLgNr6enyBt6jloKHV4ocxbkFaY+fbJLq1JUCbMTgsssodojF4EGd Arg4G2xHeuw7lm2w4m+bEvz+Bv5yQyfboI+oTrfMQ13vwNmlQ+n+vz5XdNRx/R9LuUG8 l/T5Ztp7nrtXxywCGAzpdup9y19o2nqQcuBF62uUkrgJPBtdPe86Kirr4/nxN6wrLyma BiRN2nofndPqPC4PSHd8YJH5S/vhGXOHTboksykYfqxSUqzEoy5+q3cQ0PJFH+2/5M5b 6Vlw== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x6si16961285eds.591.2021.08.30.20.47.08; Mon, 30 Aug 2021 20:47:32 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239725AbhHaDoc (ORCPT + 99 others); Mon, 30 Aug 2021 23:44:32 -0400 Received: from mailgw02.mediatek.com ([210.61.82.184]:47734 "EHLO mailgw02.mediatek.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S239719AbhHaDoa (ORCPT ); Mon, 30 Aug 2021 23:44:30 -0400 X-UUID: 4a0dc76cfe024ee08efc38d92901c77a-20210831 X-UUID: 4a0dc76cfe024ee08efc38d92901c77a-20210831 Received: from mtkmbs10n1.mediatek.inc [(172.21.101.34)] by mailgw02.mediatek.com (envelope-from ) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1749306869; Tue, 31 Aug 2021 11:43:33 +0800 Received: from mtkcas11.mediatek.inc (172.21.101.40) by mtkmbs06n1.mediatek.inc (172.21.101.129) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 31 Aug 2021 11:43:32 +0800 Received: from mszswglt01.gcn.mediatek.inc (10.16.20.20) by mtkcas11.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.0.1497.2 via Frontend Transport; Tue, 31 Aug 2021 11:43:31 +0800 From: To: CC: , , , , , , , , , , , , , , , Guangming Cao Subject: Re: [PATCH] dma-buf: heaps: remove duplicated cache sync Date: Tue, 31 Aug 2021 11:44:05 +0800 Message-ID: <20210831034405.41916-1-guangming.cao@mediatek.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain X-MTK: N Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Guangming Cao > Am 30.08.21 um 12:01 schrieb guangming.cao@mediatek.com: > > From: Guangming Cao > > > > Current flow, one dmabuf maybe call cache sync many times if > > it has beed mapped more than one time. > > Well I'm not an expert on DMA heaps, but this will most likely not work > correctly. > All attachments of one dmabuf will add into a list, I think it means dmabuf supports map more than one time. Could you tell me more about it? > > Is there any case that attachments of one dmabuf will points to > > different memory? If not, seems do sync only one time is more better. > > I think that this can happen, yes. > > Christian. > Seems it's a very special case on Android, if you don't mind, could you tell me more about it? > > > > > Signed-off-by: Guangming Cao > > --- > > drivers/dma-buf/heaps/system_heap.c | 14 ++++++++------ > > 1 file changed, 8 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/dma-buf/heaps/system_heap.c b/drivers/dma-buf/heaps/system_heap.c > > index 23a7e74ef966..909ef652a8c8 100644 > > --- a/drivers/dma-buf/heaps/system_heap.c > > +++ b/drivers/dma-buf/heaps/system_heap.c > > @@ -162,9 +162,10 @@ static int system_heap_dma_buf_begin_cpu_access(struct dma_buf *dmabuf, > > invalidate_kernel_vmap_range(buffer->vaddr, buffer->len); > > > > list_for_each_entry(a, &buffer->attachments, list) { > > - if (!a->mapped) > > - continue; > > - dma_sync_sgtable_for_cpu(a->dev, a->table, direction); > > + if (a->mapped) { > > + dma_sync_sgtable_for_cpu(a->dev, a->table, direction); > > + break; > > + } > > } > > mutex_unlock(&buffer->lock); > > > > @@ -183,9 +184,10 @@ static int system_heap_dma_buf_end_cpu_access(struct dma_buf *dmabuf, > > flush_kernel_vmap_range(buffer->vaddr, buffer->len); > > > > list_for_each_entry(a, &buffer->attachments, list) { > > - if (!a->mapped) > > - continue; > > - dma_sync_sgtable_for_device(a->dev, a->table, direction); > > + if (!a->mapped) { > > + dma_sync_sgtable_for_device(a->dev, a->table, direction); > > + break; > > + } > > } > > mutex_unlock(&buffer->lock); > >