From mboxrd@z Thu Jan 1 00:00:00 1970 From: Georgi Djakov Subject: Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name Date: Wed, 13 Mar 2019 13:48:48 +0200 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> <20190311101130.7t7rctxlqly3uqmt@flea> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20190311101130.7t7rctxlqly3uqmt@flea> Content-Language: en-US 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 , Chen-Yu Tsai Cc: Mark Rutland , devicetree , Thomas Petazzoni , Arnd Bergmann , Robin Murphy , dri-devel , Paul Kocialkowski , Chen-Yu Tsai , Rob Herring , Yong Deng , Frank Rowand , Dave Martin , linux-arm-kernel List-Id: devicetree@vger.kernel.org Hi, On 3/11/19 12:11, Maxime Ripard wrote: > On Fri, Mar 08, 2019 at 12:09:47AM +0800, Chen-Yu Tsai wrote: >> 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? > > We can create another one called memory-device if that's needed? I don't think this is needed if in both cases the DMA device is the initiator of the transfer. In both cases the DMA device is the initiator (master), so memory-device or memory-dma does not make much sense. Sorry for the confusion. > >> IIRC the display frontends, backends, and mixers all have writeback >> capability, using the same interconnect port. > > I think in both cases it's the same path. The camera driver also need > to have that offset, even though it's a producer and not a consumer, > and the VPU does too. Again, the camera driver and probably the VPU too would be the initiators, so regarding naming it should be the same (despite that the data flow is bi-directional). Thanks, Georgi 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,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_PASS,URIBL_BLOCKED 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 97F46C43381 for ; Wed, 13 Mar 2019 11:49:02 +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 648BC214AE for ; Wed, 13 Mar 2019 11:49:02 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="eYga/Vu2"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="CafVtJOL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 648BC214AE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.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:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=XnWiX+ods4+SmZLQoHkT0xYsh1cK5zYZL2v47a1EXNw=; b=eYga/Vu2VPDMTi 8b12ZUEX4RfFRbthIWRm3psgq6GvtQ2cBhyS5o0+P01bLmLEnv8zpED/yA7skk/iY9OiOSVnfplDF SChwXVIXp1UWt8z6/DHI3B5WpP4uDI1vOnAFw3MZpttP0DaLzGnpms2PiM496qz5b8aPi+zYZoX+r gpfFje49601kZdZkgXrmWz744YxQ7rn2FrtdOfM7u2xChS5ZqnDLF3WJV9fRajz505X/seUUrW40h ek58anVxDt6oSXeBnDgqt1t/IzVpyat0MmsLu1lIV59CtgvhhFJE2uTr2vNnqo1pPsgWGTk4nvUUw Z9h4WrkUzwLSokXj9IWw==; 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 1h42NV-0003g9-58; Wed, 13 Mar 2019 11:48:57 +0000 Received: from mail-lj1-x243.google.com ([2a00:1450:4864:20::243]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1h42NS-0003fp-8v for linux-arm-kernel@lists.infradead.org; Wed, 13 Mar 2019 11:48:55 +0000 Received: by mail-lj1-x243.google.com with SMTP id z25so1254081ljk.8 for ; Wed, 13 Mar 2019 04:48:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:openpgp:autocrypt:message-id:date :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=w/ivox8X6QjBHHDdPrT4p1Rkyxd8TsyHQFgIV6GLb3U=; b=CafVtJOLwoyOjnk1/4lG8IGW6fb52GD+pPulZxZvMmgNNholuAaLME07Iy++dBziRq Q+8wTcURMCyrHIEeUAL37LV3xGW77m7geKMIQzmWQp5zlEMDqh9+J3E8Q/HJY9XVmZD7 vWl95JvMzK/bQzWYC4e23FWrbgZeAE2BHSys94rjOu/D6QCtO/UGrcFyNiL3sfnOfeVV xM5tDoC+gMa00E6PwX+/WjHwwpB1DvCq/3Ka6dGDd3ymDDJMXSErd7IQcKB3Fc/eFQKm 85POZybGsU+ySdQre0TWBUlgawarviCh/oYm/+P1ZN9Nezj+8F8+9p1FPhD4/j22ptN8 n4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp:autocrypt :message-id:date:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=w/ivox8X6QjBHHDdPrT4p1Rkyxd8TsyHQFgIV6GLb3U=; b=Z8AqjGu2JsNmNT5AzPItKKYolfed0RqZ/3r1j0CB42IraKT19JImo6u8UaTJoYy2j/ ucmm7NW0qeV2QIyLqveH2E6hdMxHGiSZfPL+cvff3Mtr2KLnL0LY0cSC6uZ81mWxrbCK UmR3bVczr20H5aAX+PtW8P5kJaRsZonHJj/KLi9f36i1UMMPuPAK0jTahlPSBW4RUsEn m4sYWy5RfjnqDQQE5h0F0bS0TNkgabPodFQYiUbOx0yhxYTz2rk7ySw4rRC7tbBsB00T LnJORXD0Vhk6hxfQrMfVElFABNSa8F9eMadCDtnE32qKpWEOHtvfmoMz3fBe/ujV1JUO WfcQ== X-Gm-Message-State: APjAAAXYmwTcLQfXz4h1WyLawlYfBS52w7ouHUgQJtCTwUbEzMw5naqd Fp3lv68HCrdxNyAXKRMxqpBwyg== X-Google-Smtp-Source: APXvYqyr8HTdnE8hdFATo+xkH2qm/X0QyE+FSvlOnwgKwf59vYya6sJWfY5E4+w8QtYmawQorMYv2w== X-Received: by 2002:a2e:811:: with SMTP id 17mr24242611lji.42.1552477731810; Wed, 13 Mar 2019 04:48:51 -0700 (PDT) Received: from [10.44.66.8] ([212.45.67.2]) by smtp.googlemail.com with ESMTPSA id h5sm2030547lfc.6.2019.03.13.04.48.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 04:48:51 -0700 (PDT) Subject: Re: [PATCH v3 1/7] dt-bindings: interconnect: Add a dma interconnect name To: Maxime Ripard , Chen-Yu Tsai 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> <20190311101130.7t7rctxlqly3uqmt@flea> From: Georgi Djakov Openpgp: preference=signencrypt Autocrypt: addr=georgi.djakov@linaro.org; prefer-encrypt=mutual; keydata= mQINBFjTuRcBEACyAOVzghvyN19Sa/Nit4LPBWkICi5W20p6bwiZvdjhtuh50H5q4ktyxJtp 1+s8dMSa/j58hAWhrc2SNL3fttOCo+MM1bQWwe8uMBQJP4swgXf5ZUYkSssQlXxGKqBSbWLB uFHOOBTzaQBaNgsdXo+mQ1h8UCgM0zQOmbs2ort8aHnH2i65oLs5/Xgv/Qivde/FcFtvEFaL 0TZ7odM67u+M32VetH5nBVPESmnEDjRBPw/DOPhFBPXtal53ZFiiRr6Bm1qKVu3dOEYXHHDt nF13gB+vBZ6x5pjl02NUEucSHQiuCc2Aaavo6xnuBc3lnd4z/xk6GLBqFP3P/eJ56eJv4d0B 0LLgQ7c1T3fU4/5NDRRCnyk6HJ5+HSxD4KVuluj0jnXW4CKzFkKaTxOp7jE6ZD/9Sh74DM8v etN8uwDjtYsM07I3Szlh/I+iThxe/4zVtUQsvgXjwuoOOBWWc4m4KKg+W4zm8bSCqrd1DUgL f67WiEZgvN7tPXEzi84zT1PiUOM98dOnmREIamSpKOKFereIrKX2IcnZn8jyycE12zMkk+Sc ASMfXhfywB0tXRNmzsywdxQFcJ6jblPNxscnGMh2VlY2rezmqJdcK4G4Lprkc0jOHotV/6oJ mj9h95Ouvbq5TDHx+ERn8uytPygDBR67kNHs18LkvrEex/Z1cQARAQABtChHZW9yZ2kgRGph a292IDxnZW9yZ2kuZGpha292QGxpbmFyby5vcmc+iQI+BBMBAgAoBQJY07kXAhsDBQkHhM4A BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRCyi/eZcnWWUuvsD/4miikUeAO6fU2Xy3fT l7RUCeb2Uuh1/nxYoE1vtXcow6SyAvIVTD32kHXucJJfYy2zFzptWpvD6Sa0Sc58qe4iLY4j M54ugOYK7XeRKkQHFqqR2T3g/toVG1BOLS2atooXEU+8OFbpLkBXbIdItqJ1M1SEw8YgKmmr JlLAaKMq3hMb5bDQx9erq7PqEKOB/Va0nNu17IL58q+Q5Om7S1x54Oj6LiG/9kNOxQTklOQZ t61oW1Ewjbl325fW0/Lk0QzmfLCrmGXXiedFEMRLCJbVImXVKdIt/Ubk6SAAUrA5dFVNBzm2 L8r+HxJcfDeEpdOZJzuwRyFnH96u1Xz+7X2V26zMU6Wl2+lhvr2Tj7spxjppR+nuFiybQq7k MIwyEF0mb75RLhW33sdGStCZ/nBsXIGAUS7OBj+a5fm47vQKv6ekg60oRTHWysFSJm1mlRyq exhI6GwUo5GM/vE36rIPSJFRRgkt6nynoba/1c4VXxfhok2rkP0x3CApJ5RimbvITTnINY0o CU6f1ng1I0A1UTi2YcLjFq/gmCdOHExT4huywfu1DDf0p1xDyPA1FJaii/gJ32bBP3zK53hM dj5S7miqN7F6ZpvGSGXgahQzkGyYpBR5pda0m0k8drV2IQn+0W8Qwh4XZ6/YdfI81+xyFlXc CJjljqsMCJW6PdgEH7kCDQRY07kXARAAvupGd4Jdd8zRRiF+jMpv6ZGz8L55Di1fl1YRth6m lIxYTLwGf0/p0oDLIRldKswena3fbWh5bbTMkJmRiOQ/hffhPSNSyyh+WQeLY2kzl6geiHxD zbw37e2hd3rWAEfVFEXOLnmenaUeJFyhA3Wd8OLdRMuoV+RaLhNfeHctiEn1YGy2gLCq4VNb 4Wj5hEzABGO7+LZ14hdw3hJIEGKtQC65Jh/vTayGD+qdwedhINnIqslk9tCQ33a+jPrCjXLW X29rcgqigzsLHH7iVHWA9R5Aq7pCy5hSFsl4NBn1uV6UHlyOBUuiHBDVwTIAUnZ4S8EQiwgv WQxEkXEWLM850V+G6R593yZndTr3yydPgYv0xEDACd6GcNLR/x8mawmHKzNmnRJoOh6Rkfw2 fSiVGesGo83+iYq0NZASrXHAjWgtZXO1YwjW9gCQ2jYu9RGuQM8zIPY1VDpQ6wJtjO/KaOLm NehSR2R6tgBJK7XD9it79LdbPKDKoFSqxaAvXwWgXBj0Oz+Y0BqfClnAbxx3kYlSwfPHDFYc R/ppSgnbR5j0Rjz/N6Lua3S42MDhQGoTlVkgAi1btbdV3qpFE6jglJsJUDlqnEnwf03EgjdJ 6KEh0z57lyVcy5F/EUKfTAMZweBnkPo+BF2LBYn3Qd+CS6haZAWaG7vzVJu4W/mPQzsAEQEA AYkCJQQYAQIADwUCWNO5FwIbDAUJB4TOAAAKCRCyi/eZcnWWUhlHD/0VE/2x6lKh2FGP+QHH UTKmiiwtMurYKJsSJlQx0T+j/1f+zYkY3MDX+gXa0d0xb4eFv8WNlEjkcpSPFr+pQ7CiAI33 99kAVMQEip/MwoTYvM9NXSMTpyRJ/asnLeqa0WU6l6Z9mQ41lLzPFBAJ21/ddT4xeBDv0dxM GqaH2C6bSnJkhSfSja9OxBe+F6LIAZgCFzlogbmSWmUdLBg+sh3K6aiBDAdZPUMvGHzHK3fj gHK4GqGCFK76bFrHQYgiBOrcR4GDklj4Gk9osIfdXIAkBvRGw8zg1zzUYwMYk+A6v40gBn00 OOB13qJe9zyKpReWMAhg7BYPBKIm/qSr82aIQc4+FlDX2Ot6T/4tGUDr9MAHaBKFtVyIqXBO xOf0vQEokkUGRKWBE0uA3zFVRfLiT6NUjDQ0vdphTnsdA7h01MliZLQ2lLL2Mt5lsqU+6sup Tfql1omgEpjnFsPsyFebzcKGbdEr6vySGa3Cof+miX06hQXKe99a5+eHNhtZJcMAIO89wZmj 7ayYJIXFqjl/X0KBcCbiAl4vbdBw1bqFnO4zd1lMXKVoa29UHqby4MPbQhjWNVv9kqp8A39+ E9xw890l1xdERkjVKX6IEJu2hf7X3MMl9tOjBK6MvdOUxvh1bNNmXh7OlBL1MpJYY/ydIm3B KEmKjLDvB0pePJkdTw== Message-ID: Date: Wed, 13 Mar 2019 13:48:48 +0200 MIME-Version: 1.0 In-Reply-To: <20190311101130.7t7rctxlqly3uqmt@flea> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190313_044854_333979_8267ACA3 X-CRM114-Status: GOOD ( 22.71 ) 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 , Paul Kocialkowski , Chen-Yu Tsai , Rob Herring , Yong Deng , Frank Rowand , Dave Martin , 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 Hi, On 3/11/19 12:11, Maxime Ripard wrote: > On Fri, Mar 08, 2019 at 12:09:47AM +0800, Chen-Yu Tsai wrote: >> 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? > > We can create another one called memory-device if that's needed? I don't think this is needed if in both cases the DMA device is the initiator of the transfer. In both cases the DMA device is the initiator (master), so memory-device or memory-dma does not make much sense. Sorry for the confusion. > >> IIRC the display frontends, backends, and mixers all have writeback >> capability, using the same interconnect port. > > I think in both cases it's the same path. The camera driver also need > to have that offset, even though it's a producer and not a consumer, > and the VPU does too. Again, the camera driver and probably the VPU too would be the initiators, so regarding naming it should be the same (despite that the data flow is bi-directional). Thanks, Georgi _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel