Re: [RFC 1/5] RISC-V: Implement arch_sync_dma* functions

2021-09-11 Thread Guo Ren
dn't > have been included. > > > ___ > > iommu mailing list > > iommu@lists.linux-foundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/iommu > > > > -- > Regards, > Atish > ___ > iommu mailing list > iommu@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/iommu -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu

Re: [RFC 0/5] Support non-coherent DMA on RISC-V using a global pool

2021-08-17 Thread Guo Ren
On Tue, Aug 17, 2021 at 11:28 AM Atish Patra wrote: > > On Mon, Aug 16, 2021 at 6:37 PM Guo Ren wrote: > > > > 1 > > > > On Thu, Jul 29, 2021 at 2:19 PM Atish Patra wrote: > > > > > > On Wed, Jul 28, 2021 at 9:30 PM Palmer Dabbelt wrote: > &g

Re: [RFC 1/5] RISC-V: Implement arch_sync_dma* functions

2021-08-17 Thread Guo Ren
On Tue, Aug 17, 2021 at 11:24 AM Atish Patra wrote: > > On Mon, Aug 16, 2021 at 6:48 PM Guo Ren wrote: > > > > On Sat, Jul 24, 2021 at 5:40 AM Atish Patra wrote: > > > > > > To facilitate streaming DMA APIs, this patch introduces a set of generic > >

Re: [RFC 1/5] RISC-V: Implement arch_sync_dma* functions

2021-08-16 Thread Guo Ren
); > + > + memset(flush_addr, 0, size); > + if (dma_cache_sync && dma_cache_sync->cache_flush) > + dma_cache_sync->cache_flush(__pa(flush_addr), size); > +} > + > +void riscv_dma_cache_sync_set(struct riscv_dma_cache_sync *ops) > +{ &

Re: [RFC 0/5] Support non-coherent DMA on RISC-V using a global pool

2021-08-16 Thread Guo Ren
oncoherent.h > > > create mode 100644 arch/riscv/mm/dma-noncoherent.c > > > > Can you guys please make up your minds about how this is going to be > > supported at the ISA level? I get a different answer every day here: > > sometimes it's that these systems are not compliant, sometim

Re: [tech-privileged] [RFC PATCH V1] riscv-privileged: Add broadcast mode to sfence.vma

2019-09-19 Thread Guo Ren
t only takes care of its own request. > > On Thu, Sep 19, 2019 at 5:36 AM Guo Ren wrote: >> >> From: Guo Ren >> >> The patch is for https://github.com/riscv/riscv-isa-manual >> >> The proposal has been talked in LPC-2019 RISC-V MC ref [1]. Here is t

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-19 Thread Guo Ren
t can't support is assigning partitions of a PCI function (VF or PF) to multiple Virtual Machines" are conflict and I don't want to play naming game :) -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-19 Thread Guo Ren
e to do with that? It's an awful lot of > > effort to > > review this sort of stuff and given that Guo Ren is talking about sharing > > page > > tables between the CPU and an accelerator, maybe you're better off > > stabilising Linux for the platforms that you ca

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-19 Thread Guo Ren
Hi, On Mon, Sep 16, 2019 at 8:57 PM Jean-Philippe Brucker wrote: > On 13/09/2019 09:13, Guo Ren wrote: > > Another idea is seperate remote TLB invalidate into two instructions: > > > > - sfence.vma.b.asyc > > - sfence.vma.b.barrier // wait all async TLB invalid

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-14 Thread Guo Ren
Here is the presentation, any comments is welcome. https://docs.google.com/presentation/d/1sc295JznVAfDIPieAqzjcyUkcHnNFQsK8FFqdoCY854/edit?usp=sharing On Fri, Sep 13, 2019 at 3:13 PM Guo Ren wrote: > > Another idea is seperate remote TLB invalidate into two instru

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-13 Thread Guo Ren
?) Actually, I never consider asyc TLB invalidate before, because current our light iommu did not need it. Thx all people attend the session :) Let's continue the talk. Guo Ren 于 2019年9月12日周四 22:59写道: > Thx Will for reply. > > On Thu, Sep 12, 2019 at 3:03 PM Will Deacon wrote: > > >

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-12 Thread Guo Ren
Thx Will for reply. On Thu, Sep 12, 2019 at 3:03 PM Will Deacon wrote: > > On Sun, Sep 08, 2019 at 07:52:55AM +0800, Guo Ren wrote: > > On Mon, Jun 24, 2019 at 6:40 PM Will Deacon wrote: > > > > I'll keep my system use the same ASID for SMP + IOMMU :P > > &g

Re: [PATCH RFC 11/14] arm64: Move the ASID allocator code in a separate file

2019-09-07 Thread Guo Ren
oin our disscusion: "Introduce an implementation of IOMMU in linux-riscv" 9 Sep 2019, 10:45 Jade-room-I (Corinthia Hotel Lisbon) RISC-V MC -- Best Regards Guo Ren ML: https://lore.kernel.org/linux-csky/ ___ iommu mailing list iommu@list

Re: [PATCH 9/9] csky: use the generic remapping dma alloc implementation

2018-11-05 Thread Guo Ren
ma_alloc_nonatomic(dev, size, dma_handle, gfp, > - attrs); > - else > - return csky_dma_alloc_atomic(dev, size, dma_handle); > -} > - > -void arch_dma_free(struct device *dev, size_t size, void

Re: [PATCH 8/9] csky: don't use GFP_DMA in atomic_pool_init

2018-11-05 Thread Guo Ren
> BUG(); > > - page = alloc_pages(GFP_KERNEL | GFP_DMA, get_order(size)); > + page = alloc_pages(GFP_KERNEL, get_order(size)); > if (!page) > BUG(); > > -- > 2.19.1 Acked-by: Guo Ren ___

Re: [PATCH 7/9] csky: don't select DMA_NONCOHERENT_OPS

2018-11-05 Thread Guo Ren
select IRQ_DOMAIN > select HANDLE_DOMAIN_IRQ > -- > 2.19.1 Acked-by: Guo Ren ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu