From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chen-Yu Tsai Subject: Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name Date: Fri, 8 Mar 2019 00:09:47 +0800 Message-ID: References: <43eeca13733faefe62f9facc25b8e88f7e593f61.1549897336.git-series.maxime.ripard@bootlin.com> <553c987c-da9a-1f85-fb16-4b9fe17dd14b@linaro.org> <20190305155337.glfvgyddvnkv774m@flea> <0e72fbf7-b100-ddc5-3c19-32f71c37f76f@arm.com> <477995b0-9ac3-b6ca-f5f2-856e4af926f1@linaro.org> <20190307154755.5kgc7oh4b5bhg2fj@flea> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190307154755.5kgc7oh4b5bhg2fj@flea> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Maxime Ripard Cc: Mark Rutland , devicetree , Thomas Petazzoni , Arnd Bergmann , Robin Murphy , dri-devel , Dave Martin , Paul Kocialkowski , Chen-Yu Tsai , Rob Herring , Yong Deng , Frank Rowand , Georgi Djakov , linux-arm-kernel List-Id: devicetree@vger.kernel.org On Thu, Mar 7, 2019 at 11:48 PM Maxime Ripard wrote: > > On Thu, Mar 07, 2019 at 05:15:20PM +0200, Georgi Djakov wrote: > > Hi, > > > > On 3/5/19 18:14, Robin Murphy wrote: > > > On 05/03/2019 15:53, Maxime Ripard wrote: > > >> Hi, > > >> > > >> On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote: > > >>> On 2/11/19 17:02, Maxime Ripard wrote: > > >>>> The current DT bindings assume that the DMA will be performed by the > > >>>> devices through their parent DT node, and rely on that assumption > > >>>> for the > > >>>> address translation using dma-ranges. > > >>>> > > >>>> However, some SoCs have devices that will perform DMA through > > >>>> another bus, > > >>>> with separate address translation rules. We therefore need to > > >>>> express that > > >>>> relationship, through the special interconnect name "dma". > > >>>> > > >>>> Signed-off-by: Maxime Ripard > > >>>> --- > > >>>> Documentation/devicetree/bindings/interconnect/interconnect.txt | > > >>>> 3 +++ > > >>>> 1 file changed, 3 insertions(+) > > >>>> > > >>>> diff --git > > >>>> a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> index 5a3c575b387a..e69fc2d992c3 100644 > > >>>> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> @@ -51,6 +51,9 @@ interconnect-names : List of interconnect path > > >>>> name strings sorted in the same > > >>>> interconnect-names to match interconnect paths with > > >>>> interconnect > > >>>> specifier pairs. > > >>>> + Reserved interconnect names: > > >>>> + * dma: Path from the device to the main > > >>>> memory of the system > > >>> > > >>> Bikeshed: As it's from the device to the main memory, maybe here we can > > >>> also denote this my calling the path dma-mem or dma-memory. For other > > >>> paths, we are trying to mention both the source and the destination and > > >>> maybe it would be good to be consistent although this is special one. > > >> > > >> I'm not sure I understand what you mean. You'd like two interconnect > > >> names, one called dma-memory, and one memory-dma? > > > > > > Hmm, yes, it's not like "dma" describes an actual source or destination > > > either :/ > > > > IIUC, it's a path (bus) that a dma device use to access some memory > > (read or/and write). So i have used source-destination above more in the > > sense of initiator-target or master-slave. My suggestion was just to > > change the reserved interconnect name from "dma" to "dma-mem" or > > "dma-memory". > > If dma is an issue in itself, maybe we can call it "device-memory" ? Might I ask what happens if the device can both DMA to and from memory? IIRC the display frontends, backends, and mixers all have writeback capability, using the same interconnect port. ChenYu 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,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS autolearn=ham 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 2838DC43381 for ; Thu, 7 Mar 2019 16:10:22 +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 E56AF2064A for ; Thu, 7 Mar 2019 16:10:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="JxpPL7g3"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="Oo6aJkRR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E56AF2064A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=V2BD0bYiNeOcFlQT0SjsOklQ9fKh+Td3y4d2WF+TKEU=; b=JxpPL7g3uZ3Pjo LSj1DwDJX9E0v9nShrJ/29liixrCSlt8LIUptSejAihn1iMAAK101lewFgrblrgZDyqLVTomRpS5Q uVKAb1xcdJbMMywa0iEZ+rDLEkOzbjqidXbD+ILWcfG+4m5GQCIWqQle16goW8+0p6d3QSoJaZvu1 I5d29AyXY8Ow6Rs0RG4K3FdXK6bU0zgp4HKyzqjEKqfQZGby9qR1/5vLudorJjjeMa3Hxw/EzIqmL Vl2/tsQy1SW37ZVM/E8fKTDyax7bbM/R6NyTa7QI9p54AzzltDvMpvW411A+AwJDEjR/cV8dtwhBw gPygn4COD1ikhtXjtILg==; 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 1h1vb4-0004Fo-Iz; Thu, 07 Mar 2019 16:10:14 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h1vaq-00030D-Me for linux-arm-kernel@lists.infradead.org; Thu, 07 Mar 2019 16:10:13 +0000 Received: from mail-wm1-f45.google.com (mail-wm1-f45.google.com [209.85.128.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id EBE54214AE for ; Thu, 7 Mar 2019 16:09:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1551975000; bh=F1dBDvT/R/UeA/oRI1+AnGNazzwx38WI+QOlBlA1QiY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Oo6aJkRRlxg2vwS19N+UCDcOHLaa106gXVsS5GZI3Bqbdg2QYcqo8ZorNeZmSdU/s JlmPQBoMbQaCAXAHXLMQQOpzjEPLctWnyBYLc4we+T0jJ6ZQpvLeuJvVP7pRHLoHsm YdkDRtgKpYEeBRgLA0c9CEyUGwWosV2EYuOPllUg= Received: by mail-wm1-f45.google.com with SMTP id x10so9735113wmg.2 for ; Thu, 07 Mar 2019 08:09:59 -0800 (PST) X-Gm-Message-State: APjAAAXrdVAMRqzML+0z2Zdkg68D5iQtRA867G5Osof+CnNTA5fbJi2M cx3GDxgvogd3thypa6AC8HK8fc4iOLAuMMNm1UU= X-Google-Smtp-Source: APXvYqyoqgxANbdTuYmIOKhi8xr8oUTlqIaUBLTrdn2zfDw1+YZ7rv+oAyeVHe8dpko4mxoej/ShVXlSG2uLjtEXfVE= X-Received: by 2002:a1c:f502:: with SMTP id t2mr6102490wmh.124.1551974998300; Thu, 07 Mar 2019 08:09:58 -0800 (PST) MIME-Version: 1.0 References: <43eeca13733faefe62f9facc25b8e88f7e593f61.1549897336.git-series.maxime.ripard@bootlin.com> <553c987c-da9a-1f85-fb16-4b9fe17dd14b@linaro.org> <20190305155337.glfvgyddvnkv774m@flea> <0e72fbf7-b100-ddc5-3c19-32f71c37f76f@arm.com> <477995b0-9ac3-b6ca-f5f2-856e4af926f1@linaro.org> <20190307154755.5kgc7oh4b5bhg2fj@flea> In-Reply-To: <20190307154755.5kgc7oh4b5bhg2fj@flea> From: Chen-Yu Tsai Date: Fri, 8 Mar 2019 00:09:47 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name To: Maxime Ripard X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190307_081000_896073_F96442A2 X-CRM114-Status: GOOD ( 27.19 ) 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: Mark Rutland , devicetree , Thomas Petazzoni , Arnd Bergmann , Robin Murphy , dri-devel , Dave Martin , Paul Kocialkowski , Chen-Yu Tsai , Rob Herring , Yong Deng , Frank Rowand , Georgi Djakov , linux-arm-kernel 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, Mar 7, 2019 at 11:48 PM Maxime Ripard wrote: > > On Thu, Mar 07, 2019 at 05:15:20PM +0200, Georgi Djakov wrote: > > Hi, > > > > On 3/5/19 18:14, Robin Murphy wrote: > > > On 05/03/2019 15:53, Maxime Ripard wrote: > > >> Hi, > > >> > > >> On Fri, Mar 01, 2019 at 07:48:15PM +0200, Georgi Djakov wrote: > > >>> On 2/11/19 17:02, Maxime Ripard wrote: > > >>>> The current DT bindings assume that the DMA will be performed by the > > >>>> devices through their parent DT node, and rely on that assumption > > >>>> for the > > >>>> address translation using dma-ranges. > > >>>> > > >>>> However, some SoCs have devices that will perform DMA through > > >>>> another bus, > > >>>> with separate address translation rules. We therefore need to > > >>>> express that > > >>>> relationship, through the special interconnect name "dma". > > >>>> > > >>>> Signed-off-by: Maxime Ripard > > >>>> --- > > >>>> Documentation/devicetree/bindings/interconnect/interconnect.txt | > > >>>> 3 +++ > > >>>> 1 file changed, 3 insertions(+) > > >>>> > > >>>> diff --git > > >>>> a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> index 5a3c575b387a..e69fc2d992c3 100644 > > >>>> --- a/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> +++ b/Documentation/devicetree/bindings/interconnect/interconnect.txt > > >>>> @@ -51,6 +51,9 @@ interconnect-names : List of interconnect path > > >>>> name strings sorted in the same > > >>>> interconnect-names to match interconnect paths with > > >>>> interconnect > > >>>> specifier pairs. > > >>>> + Reserved interconnect names: > > >>>> + * dma: Path from the device to the main > > >>>> memory of the system > > >>> > > >>> Bikeshed: As it's from the device to the main memory, maybe here we can > > >>> also denote this my calling the path dma-mem or dma-memory. For other > > >>> paths, we are trying to mention both the source and the destination and > > >>> maybe it would be good to be consistent although this is special one. > > >> > > >> I'm not sure I understand what you mean. You'd like two interconnect > > >> names, one called dma-memory, and one memory-dma? > > > > > > Hmm, yes, it's not like "dma" describes an actual source or destination > > > either :/ > > > > IIUC, it's a path (bus) that a dma device use to access some memory > > (read or/and write). So i have used source-destination above more in the > > sense of initiator-target or master-slave. My suggestion was just to > > change the reserved interconnect name from "dma" to "dma-mem" or > > "dma-memory". > > If dma is an issue in itself, maybe we can call it "device-memory" ? Might I ask what happens if the device can both DMA to and from memory? IIRC the display frontends, backends, and mixers all have writeback capability, using the same interconnect port. ChenYu _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel