From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-2882122-1516851961-2-10715597662502094767 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, FREEMAIL_FROM 0.001, RCVD_IN_DNSWL_NONE -0.0001, RCVD_IN_MSPIKE_H3 -0.01, RCVD_IN_MSPIKE_WL -0.01, SPF_PASS -0.001, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.85.213.68', Host='mail-vk0-f68.google.com', Country='US', FromHeader='com', MailFrom='com' X-Spam-charsets: plain='UTF-8' X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: green.hu@gmail.com ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=arctest; t=1516851960; b=wMOy/1sdJbW5C/nZJFI25CDvxAykIwij3cWQVgvcyR8cm0b wNcAsloc6FlAtgwnnh0OFLQgX9SVruoMJ+ZULitnOzF1rv4qOc0JOMqTYTzCU3kc lGz9tJbqpmz6dyO+Fzx8qyOEniWh0MrWeZXjcWe6WSGuOR3Rr4VDdqag79+D7itk VH2/g9EoLe07V9b6dCrXwZ2RQllpkqAO2gyXRa2ryBxXgnUHBZ69XVj6Ot4W+Wrm xqb5MTHrDh3CXnCnwLZfFBNYwqWVibsXdNfw/VdDK6e8Fv9GjolDimf740714JQl cMLlvzfwfTc6gKHFxInAy0yxL2mOqqvODOmC3Hg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=mime-version:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; s=arctest; t= 1516851960; bh=j49dvjrtvOqIsWCZv6Ih5/4qVS6vRhrTJiyoXxSJqq8=; b=S CEEeaT4f9q4UPx4Aw5UL8a/S39E00Ow61FFhD8ZhHY8GTWmnsV72kWmkNYcCf5aO OmbOm9ZfOIMT8p4bpjLxQN7wNj+0nRQK333ZLF7z2X3gCL0IlGf+cL1TaQ0ZblB9 fkizLd/lu3KWHlEpbPMTMVtJfg2Ll24PU1Dk7i+rcwIPRCQwEO8MpT8sCHJd48zy RB4VTQasUIjmKP7EIErPbY34MsZU415j+k8idU08D9eIvfXFVYBvnK6df+i8ljEV Hfat9CyBPawpGLdbEHyfV6R4u+WWdFCM28QsnsrJZbeyPGcgn769V/cJMZGuGoKR /vPYS/11S4qxuh9gOwDOw== ARC-Authentication-Results: i=1; mx4.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=pJRSNa+0 x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.213.68 (mail-vk0-f68.google.com); spf=pass smtp.mailfrom=green.hu@gmail.com smtp.helo=mail-vk0-f68.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=dmlYR+Hf; x-ptr=pass x-ptr-helo=mail-vk0-f68.google.com x-ptr-lookup=mail-vk0-f68.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 Authentication-Results: mx4.messagingengine.com; arc=none (no signatures found); dkim=pass (2048-bit rsa key sha256) header.d=gmail.com header.i=@gmail.com header.b=pJRSNa+0 x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=20161025; dmarc=pass (p=none,d=none) header.from=gmail.com; iprev=pass policy.iprev=209.85.213.68 (mail-vk0-f68.google.com); spf=pass smtp.mailfrom=green.hu@gmail.com smtp.helo=mail-vk0-f68.google.com; x-aligned-from=pass; x-google-dkim=pass (2048-bit rsa key) header.d=1e100.net header.i=@1e100.net header.b=dmlYR+Hf; x-ptr=pass x-ptr-helo=mail-vk0-f68.google.com x-ptr-lookup=mail-vk0-f68.google.com; x-return-mx=pass smtp.domain=gmail.com smtp.result=pass smtp_is_org_domain=yes header.domain=gmail.com header.result=pass header_is_org_domain=yes; x-tls=pass version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128 X-Google-Smtp-Source: AH8x225xgMbJnvUxMZ9Dnck10yZ/5uJJ2EVO2YMGvkvj8cTuPeq5Px2H524ibzJhgM3tr1wa64xNvrtQaRqNx8g3vks= MIME-Version: 1.0 In-Reply-To: References: From: Greentime Hu Date: Thu, 25 Jan 2018 11:45:18 +0800 Message-ID: Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API To: Arnd Bergmann Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren , Randy Dunlap , David Miller , Jonas Bonn , Stefan Kristiansson , Stafford Horne , Vincent Chen Content-Type: text/plain; charset="UTF-8" X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: Hi, Arnd: 2018-01-24 19:36 GMT+08:00 Arnd Bergmann : > On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-23 16:23 GMT+08:00 Greentime Hu : >>> Hi, Arnd: >>> >>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann : >>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>>>> From: Greentime Hu >>>>> >>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for >>>>> flexibility. >>>>> >>>>> Signed-off-by: Vincent Chen >>>>> Signed-off-by: Greentime Hu >>>> >>>> I'm still unhappy about the way the cache flushes are done here as discussed >>>> before. It's not a show-stopped, but no Ack from me. >>> >>> How about this implementation? > >> I am not sure if I understand it correctly. >> I list all the combinations. >> >> RAM to DEVICE >> before DMA => writeback cache >> after DMA => nop >> >> DEVICE to RAM >> before DMA => nop >> after DMA => invalidate cache >> >> static void consistent_sync(void *vaddr, size_t size, int direction, int master) >> { >> unsigned long start = (unsigned long)vaddr; >> unsigned long end = start + size; >> >> if (master == FOR_CPU) { >> switch (direction) { >> case DMA_TO_DEVICE: >> break; >> case DMA_FROM_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_inval_range(start, end); >> break; >> default: >> BUG(); >> } >> } else { >> /* FOR_DEVICE */ >> switch (direction) { >> case DMA_FROM_DEVICE: >> break; >> case DMA_TO_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_wb_range(start, end); >> break; >> default: >> BUG(); >> } >> } >> } > > That looks reasonable enough, but it does depend on a number of factors, > and the dma-mapping.h implementation is not just about cache flushes. > > As I don't know the microarchitecture, can you answer these questions: > > - are caches always write-back, or could they be write-through? Yes, we can config it to write-back or write-through. > - can the cache be shared with another CPU or a device? No, we don't support it. > - if the cache is shared, is it always coherent, never coherent, or > either of them? We don't support SMP and the device will access memory through bus. I think the cache is not shared. > - could the same memory be visible at different physical addresses > and have conflicting caches? We currently don't have such kind of SoC memory map. > - is the CPU physical address always the same as the address visible to the > device? Yes, it is always the same unless the CPU uses local memory. The physical address of local memory will overlap the original bus address. I think the local memory case can be ignored because we don't use it for now. > - are there devices that can only see a subset of the physical memory? All devices are able to see the whole physical memory in our current SoC, but I think other SoC may support such kind of HW behavior. > - can there be an IOMMU? No. > - are there write-buffers in the CPU that might need to get flushed before > flushing the cache? Yes, there are write-buffers in front of CPU caches but it should be transparent to SW. We don't need to flush it. > - could cache lines be loaded speculatively or with read-ahead while > a buffer is owned by a device? No. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greentime Hu Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API Date: Thu, 25 Jan 2018 11:45:18 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.org List-Id: netdev.vger.kernel.org Hi, Arnd: 2018-01-24 19:36 GMT+08:00 Arnd Bergmann : > On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-23 16:23 GMT+08:00 Greentime Hu : >>> Hi, Arnd: >>> >>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann : >>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>>>> From: Greentime Hu >>>>> >>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for >>>>> flexibility. >>>>> >>>>> Signed-off-by: Vincent Chen >>>>> Signed-off-by: Greentime Hu >>>> >>>> I'm still unhappy about the way the cache flushes are done here as discussed >>>> before. It's not a show-stopped, but no Ack from me. >>> >>> How about this implementation? > >> I am not sure if I understand it correctly. >> I list all the combinations. >> >> RAM to DEVICE >> before DMA => writeback cache >> after DMA => nop >> >> DEVICE to RAM >> before DMA => nop >> after DMA => invalidate cache >> >> static void consistent_sync(void *vaddr, size_t size, int direction, int master) >> { >> unsigned long start = (unsigned long)vaddr; >> unsigned long end = start + size; >> >> if (master == FOR_CPU) { >> switch (direction) { >> case DMA_TO_DEVICE: >> break; >> case DMA_FROM_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_inval_range(start, end); >> break; >> default: >> BUG(); >> } >> } else { >> /* FOR_DEVICE */ >> switch (direction) { >> case DMA_FROM_DEVICE: >> break; >> case DMA_TO_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_wb_range(start, end); >> break; >> default: >> BUG(); >> } >> } >> } > > That looks reasonable enough, but it does depend on a number of factors, > and the dma-mapping.h implementation is not just about cache flushes. > > As I don't know the microarchitecture, can you answer these questions: > > - are caches always write-back, or could they be write-through? Yes, we can config it to write-back or write-through. > - can the cache be shared with another CPU or a device? No, we don't support it. > - if the cache is shared, is it always coherent, never coherent, or > either of them? We don't support SMP and the device will access memory through bus. I think the cache is not shared. > - could the same memory be visible at different physical addresses > and have conflicting caches? We currently don't have such kind of SoC memory map. > - is the CPU physical address always the same as the address visible to the > device? Yes, it is always the same unless the CPU uses local memory. The physical address of local memory will overlap the original bus address. I think the local memory case can be ignored because we don't use it for now. > - are there devices that can only see a subset of the physical memory? All devices are able to see the whole physical memory in our current SoC, but I think other SoC may support such kind of HW behavior. > - can there be an IOMMU? No. > - are there write-buffers in the CPU that might need to get flushed before > flushing the cache? Yes, there are write-buffers in front of CPU caches but it should be transparent to SW. We don't need to flush it. > - could cache lines be loaded speculatively or with read-ahead while > a buffer is owned by a device? No. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greentime Hu Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API Date: Thu, 25 Jan 2018 11:45:18 +0800 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-arch-owner@vger.kernel.org To: Arnd Bergmann Cc: Greentime , Linux Kernel Mailing List , linux-arch , Thomas Gleixner , Jason Cooper , Marc Zyngier , Rob Herring , Networking , Vincent Chen , DTML , Al Viro , David Howells , Will Deacon , Daniel Lezcano , linux-serial@vger.kernel.org, Geert Uytterhoeven , Linus Walleij , Mark Rutland , Greg KH , Guo Ren List-Id: devicetree@vger.kernel.org Hi, Arnd: 2018-01-24 19:36 GMT+08:00 Arnd Bergmann : > On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu wrote: >> Hi, Arnd: >> >> 2018-01-23 16:23 GMT+08:00 Greentime Hu : >>> Hi, Arnd: >>> >>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann : >>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu wrote: >>>>> From: Greentime Hu >>>>> >>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for >>>>> flexibility. >>>>> >>>>> Signed-off-by: Vincent Chen >>>>> Signed-off-by: Greentime Hu >>>> >>>> I'm still unhappy about the way the cache flushes are done here as discussed >>>> before. It's not a show-stopped, but no Ack from me. >>> >>> How about this implementation? > >> I am not sure if I understand it correctly. >> I list all the combinations. >> >> RAM to DEVICE >> before DMA => writeback cache >> after DMA => nop >> >> DEVICE to RAM >> before DMA => nop >> after DMA => invalidate cache >> >> static void consistent_sync(void *vaddr, size_t size, int direction, int master) >> { >> unsigned long start = (unsigned long)vaddr; >> unsigned long end = start + size; >> >> if (master == FOR_CPU) { >> switch (direction) { >> case DMA_TO_DEVICE: >> break; >> case DMA_FROM_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_inval_range(start, end); >> break; >> default: >> BUG(); >> } >> } else { >> /* FOR_DEVICE */ >> switch (direction) { >> case DMA_FROM_DEVICE: >> break; >> case DMA_TO_DEVICE: >> case DMA_BIDIRECTIONAL: >> cpu_dma_wb_range(start, end); >> break; >> default: >> BUG(); >> } >> } >> } > > That looks reasonable enough, but it does depend on a number of factors, > and the dma-mapping.h implementation is not just about cache flushes. > > As I don't know the microarchitecture, can you answer these questions: > > - are caches always write-back, or could they be write-through? Yes, we can config it to write-back or write-through. > - can the cache be shared with another CPU or a device? No, we don't support it. > - if the cache is shared, is it always coherent, never coherent, or > either of them? We don't support SMP and the device will access memory through bus. I think the cache is not shared. > - could the same memory be visible at different physical addresses > and have conflicting caches? We currently don't have such kind of SoC memory map. > - is the CPU physical address always the same as the address visible to the > device? Yes, it is always the same unless the CPU uses local memory. The physical address of local memory will overlap the original bus address. I think the local memory case can be ignored because we don't use it for now. > - are there devices that can only see a subset of the physical memory? All devices are able to see the whole physical memory in our current SoC, but I think other SoC may support such kind of HW behavior. > - can there be an IOMMU? No. > - are there write-buffers in the CPU that might need to get flushed before > flushing the cache? Yes, there are write-buffers in front of CPU caches but it should be transparent to SW. We don't need to flush it. > - could cache lines be loaded speculatively or with read-ahead while > a buffer is owned by a device? No.