On Mon, Jun 24, 2019 at 09:16:30AM +0200, Geert Uytterhoeven wrote:
> Doing
>
> - select DMA_DIRECT_REMAP if MMU && !COLDFIRE
> + select DMA_DIRECT_REMAP if MMU && !COLDFIRE && !SUN3
>
> in arch/m68k/Kconfig fixes the build.
>
> Alternatively, you could use:
>
> - select DMA_D
On Mon, Jun 17, 2019 at 08:53:55PM +0200, Geert Uytterhoeven wrote:
> Hi Christoph,
>
> On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote:
> > can you take a look at the (untested) patches below? They convert m68k
> > to use the generic remapping DMA allocator, which is also used by
> > a
On Mon, Jun 24, 2019 at 03:23:08PM +0100, Vladimir Murzin wrote:
> On 6/14/19 3:44 PM, Christoph Hellwig wrote:
> > The arm-nommu DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
> > does not provide a cache_sync operation. This means any user of it
> > will never be able to actually tra
On Sun, Jun 16, 2019 at 06:08:40PM +0800, Hillf Danton wrote:
> Literally, any cpu (call it cpuW) other than pcx12 and pcx1 will no longer do
> dma alloc for any device with this patch applied.
Yes. And that is not a chance from the previous code, where only
pcx1 and pcx12 could do coherent alloc
On Fri, Jun 14, 2019 at 09:46:48AM +0200, Christoph Hellwig wrote:
> If I don't hear anything back in the next days I will just merge
> these patches, please comment.
Applied to the dma-mapping for-next tree now.
On Tue, Jun 25, 2019 at 01:29:40PM +0800, Ley Foon Tan wrote:
> On Mon, Jun 3, 2019 at 2:54 PM Christoph Hellwig wrote:
> >
> > Stop providing our own arch alloc/free hooks and just expose the segment
> > offset and use the generic dma-direct allocator.
> >
> > Signed-off-by: Christoph Hellwig
>
Thanks,
applied to dma-mapping for-next.
On Mon, Jun 3, 2019 at 2:54 PM Christoph Hellwig wrote:
>
> Stop providing our own arch alloc/free hooks and just expose the segment
> offset and use the generic dma-direct allocator.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Ley Foon Tan
> ---
> arch/nios2/Kconfig| 1 +
> a
On Tue, 18 Jun 2019 17:42:37 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:19 -0700
> Jacob Pan wrote:
>
> > Use combined macro for_each_svm_dev() to simplify SVM device
> > iteration.
> >
> > Suggested-by: Andy Shevchenko
> > Signed-off-by: Jacob Pan
> > Reviewed-by: Eric Auger
On Tue, 18 Jun 2019 17:03:35 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:17 -0700
> Jacob Pan wrote:
>
> > After each setup for PASID entry, related translation caches must
> > be flushed. We can combine duplicated code into one function which
> > is less error prone.
> >
> > Sign
On Tue, 18 Jun 2019 17:44:49 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:20 -0700
> Jacob Pan wrote:
>
> > When supporting guest SVA with emulated IOMMU, the guest PASID
> > table is shadowed in VMM. Updates to guest vIOMMU PASID table
> > will result in PASID cache flush which wil
On Tue, 18 Jun 2019 15:10:31 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:10 -0700
> Jacob Pan wrote:
>
> > struct page_response_msg needs to be defined outside
> > CONFIG_IOMMU_API.
>
> What was the error?
>
struct page_response_msg can be undefined if under CONFIG_IOMMU_API.
On Tue, 18 Jun 2019 16:36:33 +0100
Jean-Philippe Brucker wrote:
> On 09/06/2019 14:44, Jacob Pan wrote:
> > Guest shared virtual address (SVA) may require host to shadow guest
> > PASID tables. Guest PASID can also be allocated from the host via
> > enlightened interfaces. In this case, guest nee
On Tue, 18 Jun 2019 16:57:09 +0100
Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:15 -0700
> Jacob Pan wrote:
>
> > Make use of generic IOASID code to manage PASID allocation,
> > free, and lookup. Replace Intel specific code.
> >
> > Signed-off-by: Jacob Pan
> Hi Jacob,
>
> One questi
Linux IRQ number virq is not used in IRTE allocation. Remove it.
Signed-off-by: Jacob Pan
---
drivers/iommu/intel_irq_remapping.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel_irq_remapping.c
b/drivers/iommu/intel_irq_remapping.c
index 4160aa9..4786
[+Krishna]
Hi Vivek,
On Mon, Jun 24, 2019 at 03:58:32PM +0530, Vivek Gautam wrote:
> On Tue, Jun 18, 2019 at 11:22 PM Will Deacon wrote:
> > On Fri, Jun 14, 2019 at 02:48:07PM +0530, Vivek Gautam wrote:
> > > On 6/14/2019 9:35 AM, Bjorn Andersson wrote:
> > > > On Wed 12 Jun 00:15 PDT 2019, Vive
On 24/06/2019 16:06, Auger Eric wrote:
> Hi,
>
> On 6/18/19 5:41 PM, Jonathan Cameron wrote:
>> On Sun, 9 Jun 2019 06:44:08 -0700
>> Jacob Pan wrote:
>>
>>> In virtualization use case, when a guest is assigned
>>> a PCI host device, protected by a virtual IOMMU on the guest,
>>> the physical IOMM
Hi,
On 6/18/19 5:41 PM, Jonathan Cameron wrote:
> On Sun, 9 Jun 2019 06:44:08 -0700
> Jacob Pan wrote:
>
>> In virtualization use case, when a guest is assigned
>> a PCI host device, protected by a virtual IOMMU on the guest,
>> the physical IOMMU must be programmed to be consistent with
>> the
On 6/14/19 3:44 PM, Christoph Hellwig wrote:
> The arm-nommu DMA code supports DMA_ATTR_NON_CONSISTENT allocations, but
> does not provide a cache_sync operation. This means any user of it
> will never be able to actually transfer cache ownership and thus cause
> coherency bugs.
By the way, Docum
Hi again, Bjorn,
On Tue, Jun 18, 2019 at 06:39:33PM +0100, Will Deacon wrote:
> On Wed, May 15, 2019 at 04:32:34PM -0700, Bjorn Andersson wrote:
> > Describe the memory related to page table walks as non-cachable for iommu
> > instances that are not DMA coherent.
> >
> > Signed-off-by: Bjorn Ande
Hi Will,
On Tue, Jun 18, 2019 at 11:22 PM Will Deacon wrote:
>
> Hi Vivek,
>
> On Fri, Jun 14, 2019 at 02:48:07PM +0530, Vivek Gautam wrote:
> > On 6/14/2019 9:35 AM, Bjorn Andersson wrote:
> > > On Wed 12 Jun 00:15 PDT 2019, Vivek Gautam wrote:
> > >
> > > > Qcom's implementation of arm,mmu-500
Hi Christoph,
On Fri, Jun 14, 2019 at 12:21 PM Christoph Hellwig wrote:
> can you take a look at the (untested) patches below? They convert m68k
> to use the generic remapping DMA allocator, which is also used by
> arm64 and csky.
When building for Sun-3:
kernel/dma/remap.o: In function `arch_
22 matches
Mail list logo
