All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greentime Hu <green.hu@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greentime <greentime@andestech.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Vincent Chen <deanbo422@gmail.com>,
	DTML <devicetree@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	Will Deacon <will.deacon@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-serial@vger.kernel.org,
	Geert Uytterhoeven <geert.uytterhoeven@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>, Greg KH <greg@kroah.com>,
	Guo Ren <ren_guo@c-sky.com>, Randy Dunlap <rdunlap@infradead.org>,
	David Miller <davem@davemloft.net>,
	Jonas Bonn <jonas@southpole.se>,
	Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>,
	Stafford Horne <shorne@gmail.com>,
	Vincent Chen <vincentc@andestech.com>
Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API
Date: Thu, 25 Jan 2018 11:45:18 +0800	[thread overview]
Message-ID: <CAEbi=3fwCnFXmYKPEiDiqoGFujqRD0bPrPAgqtiTkO_vuX25dQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a30W1ph-6Owuf9yZF-bKg_bx6dJKCtiF_aRAYu9NVO3DQ@mail.gmail.com>

Hi, Arnd:

2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> Hi, Arnd:
>>
>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@gmail.com>:
>>> Hi, Arnd:
>>>
>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> From: Greentime Hu <greentime@andestech.com>
>>>>>
>>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for
>>>>> flexibility.
>>>>>
>>>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>>>
>>>> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Greentime Hu <green.hu@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greentime <greentime@andestech.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Vincent Chen <deanbo422@gmail.com>,
	DTML <devicetree@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	Will Deacon <will.deacon@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-serial@vger.kernel.org,
	Geert Uytterhoeven <geert.uytterhoeven@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>, Greg KH <greg@kroah.com>,
	Guo Ren <ren_guo@c-sky.co
Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API
Date: Thu, 25 Jan 2018 11:45:18 +0800	[thread overview]
Message-ID: <CAEbi=3fwCnFXmYKPEiDiqoGFujqRD0bPrPAgqtiTkO_vuX25dQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a30W1ph-6Owuf9yZF-bKg_bx6dJKCtiF_aRAYu9NVO3DQ@mail.gmail.com>

Hi, Arnd:

2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> Hi, Arnd:
>>
>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@gmail.com>:
>>> Hi, Arnd:
>>>
>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> From: Greentime Hu <greentime@andestech.com>
>>>>>
>>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for
>>>>> flexibility.
>>>>>
>>>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>>>
>>>> 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.

WARNING: multiple messages have this Message-ID (diff)
From: Greentime Hu <green.hu@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Greentime <greentime@andestech.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-arch <linux-arch@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Rob Herring <robh+dt@kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Vincent Chen <deanbo422@gmail.com>,
	DTML <devicetree@vger.kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	David Howells <dhowells@redhat.com>,
	Will Deacon <will.deacon@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	linux-serial@vger.kernel.org,
	Geert Uytterhoeven <geert.uytterhoeven@gmail.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Mark Rutland <mark.rutland@arm.com>, Greg KH <greg@kroah.com>,
	Guo Ren <ren_guo@c-sky.co>
Subject: Re: [PATCH v6 16/36] nds32: DMA mapping API
Date: Thu, 25 Jan 2018 11:45:18 +0800	[thread overview]
Message-ID: <CAEbi=3fwCnFXmYKPEiDiqoGFujqRD0bPrPAgqtiTkO_vuX25dQ@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a30W1ph-6Owuf9yZF-bKg_bx6dJKCtiF_aRAYu9NVO3DQ@mail.gmail.com>

Hi, Arnd:

2018-01-24 19:36 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
> On Tue, Jan 23, 2018 at 12:52 PM, Greentime Hu <green.hu@gmail.com> wrote:
>> Hi, Arnd:
>>
>> 2018-01-23 16:23 GMT+08:00 Greentime Hu <green.hu@gmail.com>:
>>> Hi, Arnd:
>>>
>>> 2018-01-18 18:26 GMT+08:00 Arnd Bergmann <arnd@arndb.de>:
>>>> On Mon, Jan 15, 2018 at 6:53 AM, Greentime Hu <green.hu@gmail.com> wrote:
>>>>> From: Greentime Hu <greentime@andestech.com>
>>>>>
>>>>> This patch adds support for the DMA mapping API. It uses dma_map_ops for
>>>>> flexibility.
>>>>>
>>>>> Signed-off-by: Vincent Chen <vincentc@andestech.com>
>>>>> Signed-off-by: Greentime Hu <greentime@andestech.com>
>>>>
>>>> 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.

  reply	other threads:[~2018-01-25  3:45 UTC|newest]

Thread overview: 261+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-15  5:53 [PATCH v6 00/36] Andes(nds32) Linux Kernel Port Greentime Hu
2018-01-15  5:53 ` [PATCH v6 01/36] asm-generic/io.h: move ioremap_nocache/ioremap_uc/ioremap_wc/ioremap_wt out of ifndef CONFIG_MMU Greentime Hu
2018-01-15  5:53 ` [PATCH v6 02/36] openrisc: add ioremap_nocache declaration before include asm-generic/io.h and sync ioremap prototype with it Greentime Hu
2018-01-15 13:07   ` Stafford Horne
2018-01-15 13:28     ` Greentime Hu
2018-01-15 13:28       ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 03/36] sparc: io: To use the define of ioremap_[nocache|wc|wb] in asm-generic/io.h Greentime Hu
2018-01-18  9:56   ` Arnd Bergmann
2018-01-18  9:56     ` Arnd Bergmann
2018-01-18  9:56     ` Arnd Bergmann
2018-01-19 12:50     ` Greentime Hu
2018-01-19 12:50       ` Greentime Hu
2018-01-19 12:50       ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 04/36] earlycon: add reg-offset to physical address before mapping Greentime Hu
2018-01-18 10:00   ` Arnd Bergmann
2018-01-18 10:00     ` Arnd Bergmann
2018-01-18 10:00     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 05/36] nds32: Assembly macros and definitions Greentime Hu
2018-01-18 10:01   ` Arnd Bergmann
2018-01-18 10:01     ` Arnd Bergmann
2018-01-18 10:01     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 06/36] nds32: Kernel booting and initialization Greentime Hu
2018-01-18 10:11   ` Arnd Bergmann
2018-01-18 10:11     ` Arnd Bergmann
2018-01-18 10:11     ` Arnd Bergmann
2018-01-19 16:34     ` Greentime Hu
2018-01-19 16:34       ` Greentime Hu
2018-01-19 16:34       ` Greentime Hu
2018-01-19 16:41       ` Arnd Bergmann
2018-01-19 16:41         ` Arnd Bergmann
2018-01-19 16:41         ` Arnd Bergmann
2018-01-22  9:49         ` Greentime Hu
2018-01-22  9:49           ` Greentime Hu
2018-01-22  9:49           ` Greentime Hu
2018-01-22  9:53           ` Arnd Bergmann
2018-01-22  9:53             ` Arnd Bergmann
2018-01-22  9:53             ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 07/36] nds32: Exception handling Greentime Hu
2018-01-18 10:14   ` Arnd Bergmann
2018-01-18 10:14     ` Arnd Bergmann
2018-01-18 10:14     ` Arnd Bergmann
2018-01-24 10:53     ` Vincent Chen
2018-01-24 10:53       ` Vincent Chen
2018-01-24 10:53       ` Vincent Chen
2018-01-24 11:09       ` Arnd Bergmann
2018-01-24 11:09         ` Arnd Bergmann
2018-01-24 11:09         ` Arnd Bergmann
2018-01-24 11:10         ` Arnd Bergmann
2018-01-24 11:10           ` Arnd Bergmann
2018-01-24 11:10           ` Arnd Bergmann
2018-01-30 10:01           ` Vincent Chen
2018-01-30 10:01             ` Vincent Chen
2018-01-30 10:01             ` Vincent Chen
2018-01-30 13:33             ` Arnd Bergmann
2018-01-30 13:33               ` Arnd Bergmann
2018-01-30 13:33               ` Arnd Bergmann
2018-01-30 14:49               ` Greentime Hu
2018-01-30 14:49                 ` Greentime Hu
2018-01-30 14:49                 ` Greentime Hu
2018-01-30 15:27                 ` Arnd Bergmann
2018-01-30 15:27                   ` Arnd Bergmann
2018-01-30 15:27                   ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 08/36] nds32: MMU definitions Greentime Hu
2018-01-15  5:53   ` Greentime Hu
2018-01-18 10:14   ` Arnd Bergmann
2018-01-18 10:14     ` Arnd Bergmann
2018-01-18 10:14     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 09/36] nds32: MMU initialization Greentime Hu
2018-01-18 10:16   ` Arnd Bergmann
2018-01-18 10:16     ` Arnd Bergmann
2018-01-18 10:16     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 10/36] nds32: MMU fault handling and page table management Greentime Hu
2018-01-18 10:16   ` Arnd Bergmann
2018-01-18 10:16     ` Arnd Bergmann
2018-01-18 10:16     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 11/36] nds32: Cache and TLB routines Greentime Hu
2018-01-18 10:17   ` Arnd Bergmann
2018-01-18 10:17     ` Arnd Bergmann
2018-01-18 10:17     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 12/36] nds32: Process management Greentime Hu
2018-01-15  5:53   ` Greentime Hu
2018-01-18 10:22   ` Arnd Bergmann
2018-01-18 10:22     ` Arnd Bergmann
2018-01-18 10:22     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 13/36] nds32: IRQ handling Greentime Hu
2018-01-15  5:53   ` Greentime Hu
2018-01-18 10:22   ` Arnd Bergmann
2018-01-18 10:22     ` Arnd Bergmann
2018-01-18 10:22     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 14/36] nds32: Atomic operations Greentime Hu
2018-01-18 10:23   ` Arnd Bergmann
2018-01-18 10:23     ` Arnd Bergmann
2018-01-18 10:23     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 15/36] nds32: Device specific operations Greentime Hu
2018-01-18 10:25   ` Arnd Bergmann
2018-01-18 10:25     ` Arnd Bergmann
2018-01-18 10:25     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 16/36] nds32: DMA mapping API Greentime Hu
2018-01-18 10:26   ` Arnd Bergmann
2018-01-18 10:26     ` Arnd Bergmann
2018-01-18 10:26     ` Arnd Bergmann
2018-01-23  8:23     ` Greentime Hu
2018-01-23  8:23       ` Greentime Hu
2018-01-23  8:23       ` Greentime Hu
2018-01-23 11:52       ` Greentime Hu
2018-01-23 11:52         ` Greentime Hu
2018-01-23 11:52         ` Greentime Hu
2018-01-24 11:36         ` Arnd Bergmann
2018-01-24 11:36           ` Arnd Bergmann
2018-01-24 11:36           ` Arnd Bergmann
2018-01-25  3:45           ` Greentime Hu [this message]
2018-01-25  3:45             ` Greentime Hu
2018-01-25  3:45             ` Greentime Hu
2018-01-25 10:42             ` Arnd Bergmann
2018-01-25 10:42               ` Arnd Bergmann
2018-01-25 10:42               ` Arnd Bergmann
2018-01-25 13:48               ` Greentime Hu
2018-01-25 13:48                 ` Greentime Hu
2018-01-25 13:48                 ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 17/36] nds32: ELF definitions Greentime Hu
2018-01-18 10:27   ` Arnd Bergmann
2018-01-18 10:27     ` Arnd Bergmann
2018-01-18 10:27     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 18/36] nds32: System calls handling Greentime Hu
2018-01-15  5:53   ` Greentime Hu
2018-01-18 10:27   ` Arnd Bergmann
2018-01-18 10:27     ` Arnd Bergmann
2018-01-18 10:27     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 19/36] nds32: VDSO support Greentime Hu
2018-01-18 10:28   ` Arnd Bergmann
2018-01-18 10:28     ` Arnd Bergmann
2018-01-18 10:28     ` Arnd Bergmann
2018-02-06  7:41     ` Vincent Chen
2018-02-06  7:41       ` Vincent Chen
2018-02-06  7:41       ` Vincent Chen
2018-02-06  8:48       ` Arnd Bergmann
2018-02-06  8:48         ` Arnd Bergmann
2018-02-06  8:48         ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 20/36] nds32: Signal handling support Greentime Hu
2018-01-18 10:30   ` Arnd Bergmann
2018-01-18 10:30     ` Arnd Bergmann
2018-01-18 10:30     ` Arnd Bergmann
2018-01-24  0:56     ` Vincent Chen
2018-01-24  0:56       ` Vincent Chen
2018-01-24  0:56       ` Vincent Chen
2018-01-24 11:13       ` Arnd Bergmann
2018-01-24 11:13         ` Arnd Bergmann
2018-01-24 11:13         ` Arnd Bergmann
2018-02-06  6:39         ` Vincent Chen
2018-02-06  6:39           ` Vincent Chen
2018-02-06  6:39           ` Vincent Chen
2018-01-15  5:53 ` [PATCH v6 21/36] nds32: Library functions Greentime Hu
2018-01-18 10:31   ` Arnd Bergmann
2018-01-18 10:31     ` Arnd Bergmann
2018-01-18 10:31     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 22/36] nds32: Debugging support Greentime Hu
2018-01-18 10:37   ` Arnd Bergmann
2018-01-18 10:37     ` Arnd Bergmann
2018-01-18 10:37     ` Arnd Bergmann
2018-01-23  7:28     ` Vincent Chen
2018-01-23  7:28       ` Vincent Chen
2018-01-23  7:28       ` Vincent Chen
2018-01-23  8:21       ` Arnd Bergmann
2018-01-23  8:21         ` Arnd Bergmann
2018-01-23  8:21         ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 23/36] nds32: L2 cache support Greentime Hu
2018-01-18 10:37   ` Arnd Bergmann
2018-01-18 10:37     ` Arnd Bergmann
2018-01-18 10:37     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 24/36] nds32: Loadable modules Greentime Hu
2018-01-18 10:41   ` Arnd Bergmann
2018-01-18 10:41     ` Arnd Bergmann
2018-01-18 10:41     ` Arnd Bergmann
2018-01-19 14:26     ` Greentime Hu
2018-01-19 14:26       ` Greentime Hu
2018-01-19 14:26       ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 25/36] nds32: Generic timers support Greentime Hu
2018-01-18 10:41   ` Arnd Bergmann
2018-01-18 10:41     ` Arnd Bergmann
2018-01-18 10:41     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 26/36] nds32: Device tree support Greentime Hu
2018-01-18 10:43   ` Arnd Bergmann
2018-01-18 10:43     ` Arnd Bergmann
2018-01-18 10:43     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 27/36] nds32: Miscellaneous header files Greentime Hu
2018-01-18 10:46   ` Arnd Bergmann
2018-01-18 10:46     ` Arnd Bergmann
2018-01-18 10:46     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 28/36] nds32: defconfig Greentime Hu
2018-01-18 10:44   ` Arnd Bergmann
2018-01-18 10:44     ` Arnd Bergmann
2018-01-18 10:44     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 29/36] nds32: Build infrastructure Greentime Hu
2018-01-18 11:00   ` Arnd Bergmann
2018-01-18 11:00     ` Arnd Bergmann
2018-01-18 11:00     ` Arnd Bergmann
2018-01-22 15:20     ` Greentime Hu
2018-01-22 15:20       ` Greentime Hu
2018-01-22 15:20       ` Greentime Hu
2018-01-22 15:38       ` Arnd Bergmann
2018-01-22 15:38         ` Arnd Bergmann
2018-01-22 15:38         ` Arnd Bergmann
2018-01-22 16:00         ` Greentime Hu
2018-01-22 16:00           ` Greentime Hu
2018-01-22 16:00           ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 30/36] MAINTAINERS: Add nds32 Greentime Hu
2018-01-18 10:45   ` Arnd Bergmann
2018-01-18 10:45     ` Arnd Bergmann
2018-01-18 10:45     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 31/36] dt-bindings: nds32 CPU Bindings Greentime Hu
2018-01-18 11:02   ` Arnd Bergmann
2018-01-18 11:02     ` Arnd Bergmann
2018-01-18 11:02     ` Arnd Bergmann
2018-01-19 14:32     ` Greentime Hu
2018-01-19 14:32       ` Greentime Hu
2018-01-19 14:32       ` Greentime Hu
2018-01-19 14:52       ` Arnd Bergmann
2018-01-19 14:52         ` Arnd Bergmann
2018-01-19 14:52         ` Arnd Bergmann
2018-01-19 15:18         ` Greentime Hu
2018-01-19 15:18           ` Greentime Hu
2018-01-19 15:18           ` Greentime Hu
2018-01-19 15:29           ` Geert Uytterhoeven
2018-01-19 15:29             ` Geert Uytterhoeven
2018-01-19 15:29             ` Geert Uytterhoeven
2018-01-19 15:35             ` Greentime Hu
2018-01-19 15:35               ` Greentime Hu
2018-01-19 15:35               ` Greentime Hu
2018-01-19 15:37               ` Geert Uytterhoeven
2018-01-19 15:37                 ` Geert Uytterhoeven
2018-01-19 15:37                 ` Geert Uytterhoeven
2018-01-22  9:53                 ` Greentime Hu
2018-01-22  9:53                   ` Greentime Hu
2018-01-22  9:53                   ` Greentime Hu
2018-01-22 11:15                   ` Arnd Bergmann
2018-01-22 11:15                     ` Arnd Bergmann
2018-01-22 11:15                     ` Arnd Bergmann
2018-01-22 13:55                     ` Greentime Hu
2018-01-22 13:55                       ` Greentime Hu
2018-01-22 13:55                       ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 32/36] dt-bindings: nds32 L2 cache controller Bindings Greentime Hu
2018-01-18 10:45   ` Arnd Bergmann
2018-01-18 10:45     ` Arnd Bergmann
2018-01-18 10:45     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 33/36] dt-bindings: nds32 SoC Bindings Greentime Hu
2018-01-18 11:03   ` Arnd Bergmann
2018-01-18 11:03     ` Arnd Bergmann
2018-01-18 11:03     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 34/36] dt-bindings: interrupt-controller: Andestech Internal Vector Interrupt Controller Greentime Hu
2018-01-18 10:46   ` Arnd Bergmann
2018-01-18 10:46     ` Arnd Bergmann
2018-01-18 10:46     ` Arnd Bergmann
2018-01-15  5:53 ` [PATCH v6 35/36] irqchip: Andestech Internal Vector Interrupt Controller driver Greentime Hu
2018-01-15  5:53   ` Greentime Hu
2018-01-15  5:53 ` [PATCH v6 36/36] net: faraday add nds32 support Greentime Hu
2018-01-18 11:02   ` Arnd Bergmann
2018-01-18 11:02     ` Arnd Bergmann
2018-01-18 11:02     ` Arnd Bergmann
2018-01-18  9:49 ` [PATCH v6 00/36] Andes(nds32) Linux Kernel Port Arnd Bergmann
2018-01-18  9:49   ` Arnd Bergmann
2018-01-18  9:49   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAEbi=3fwCnFXmYKPEiDiqoGFujqRD0bPrPAgqtiTkO_vuX25dQ@mail.gmail.com' \
    --to=green.hu@gmail.com \
    --cc=arnd@arndb.de \
    --cc=daniel.lezcano@linaro.org \
    --cc=davem@davemloft.net \
    --cc=deanbo422@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=dhowells@redhat.com \
    --cc=geert.uytterhoeven@gmail.com \
    --cc=greentime@andestech.com \
    --cc=greg@kroah.com \
    --cc=jason@lakedaemon.net \
    --cc=jonas@southpole.se \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=netdev@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=ren_guo@c-sky.com \
    --cc=robh+dt@kernel.org \
    --cc=shorne@gmail.com \
    --cc=stefan.kristiansson@saunalahti.fi \
    --cc=tglx@linutronix.de \
    --cc=vincentc@andestech.com \
    --cc=viro@zeniv.linux.org.uk \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.