On Fri, 16 Aug 2019, Christoph Hellwig wrote:
> Hi Xen maintainers and friends,
>
> please take a look at this series that cleans up the parts of swiotlb-xen
> that deal with non-coherent caches.
Hi Christoph,
I just wanted to let you know that your series is on my radar, but I
have been
Hi Tony,
The following 2 patches need to go along with the recent "iommu/omap: misc
fixes" series [1] that is currently staged [2] for a 5.4 merge and available
in linux-next. That series added runtime pm callbacks in preparation for
the ti-sysc migration, but without adding the necessary
The OMAP IOMMU driver requires the device_enable/idle platform
data ops on all the IOMMU devices to be able to enable and disable
the clocks after commit db8918f61d51 ("iommu/omap: streamline
enable/disable through runtime pm callbacks"). Plug in these
pdata ops for all the existing IOMMUs through
The OMAP3 ISP IOMMU does not have any reset lines, so it didn't
need any pdata previously. The OMAP IOMMU driver now requires the
platform data ops for device_enable/idle on all the IOMMU devices
after commit db8918f61d51 ("iommu/omap: streamline enable/disable
through runtime pm callbacks") to
On Tue, Aug 13, 2019 at 08:45:37AM -0700, Ram Pai wrote:
> On Wed, Aug 14, 2019 at 12:24:39AM +1000, David Gibson wrote:
> > On Tue, Aug 13, 2019 at 03:26:17PM +0200, Christoph Hellwig wrote:
> > > On Mon, Aug 12, 2019 at 07:51:56PM +1000, David Gibson wrote:
> > > > AFAICT we already kind of
Hi Joerg and all,
Just wondering if you have more comments for this version. Since
the complete vSVA patchset is quite large, my hope is that we can make
incremental progress with smaller sets.
My plans are:
1. vSVA IOMMU APIs and VT-d support of PCI devices (this patchset)
2. Page request
Global pages support is removed from VT-d spec 3.0. Since global pages G
flag only affects first-level paging structures and because DMA request
with PASID are only supported by VT-d spec. 3.0 and onward, we can
safely remove global pages support.
For kernel shared virtual address IOTLB
26.08.2019 18:18, Dmitry Osipenko пишет:
> Hello Yue,
>
> 26.08.2019 16:31, YueHaibing пишет:
>> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
>> to m will set IOMMU_IOVA to m, this fails the building of
>> TEGRA_HOST1X and DRM_TEGRA which is y like this:
>>
>>
Hello Yue,
26.08.2019 16:31, YueHaibing пишет:
> If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
> to m will set IOMMU_IOVA to m, this fails the building of
> TEGRA_HOST1X and DRM_TEGRA which is y like this:
>
> drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
>
With a little tweak to the intel-iommu code we should be able to work
around the VMD mess for the requester IDs without having to create giant
amounts of boilerplate DMA ops wrapping code. The other advantage of
this scheme is that we can respect the real DMA masks for the actual
devices, and I
On Mon, Jun 10, 2019 at 04:58:02PM +0900, Tomasz Figa wrote:
> On Mon, Jun 10, 2019 at 4:51 PM CK Hu wrote:
> >
> > Hi, Tomasz:
> >
> > On Mon, 2019-06-10 at 12:32 +0900, Tomasz Figa wrote:
> > > Hi CK, Stu,
> > >
> > > On Mon, Jun 10, 2019 at 11:34 AM CK Hu wrote:
> > > >
> > > > Hi, Stu:
> > >
On Mon, 2019-08-26 at 09:09 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> > Some architectures have platform specific DMA addressing limitations.
> > This will allow for hardware description code to provide the constraints
> > in a
If COMPILE_TEST is y and IOMMU_SUPPORT is n, selecting TEGRA_VDE
to m will set IOMMU_IOVA to m, this fails the building of
TEGRA_HOST1X and DRM_TEGRA which is y like this:
drivers/gpu/host1x/cdma.o: In function `host1x_cdma_init':
cdma.c:(.text+0x66c): undefined reference to `alloc_iova'
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/pgtable-nommu.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/pgtable-nommu.h
b/arch/arm/include/asm/pgtable-nommu.h
index 0b1f6799a32e..d0de24f06724 100644
--- a/arch/arm/include/asm/pgtable-nommu.h
+++
Based on an email from Paul Burton, quoting section 4.8 "Cacheability and
Coherency Attributes and Access Types" of "MIPS Architecture Volume 1:
Introduction to the MIPS32 Architecture" (MD00080, revision 6.01).
Signed-off-by: Christoph Hellwig
---
arch/mips/Kconfig | 7 +++
1 file changed,
arch_dma_mmap_pgprot is used for two things:
1) to override the "normal" uncached page attributes for mapping
memory coherent to devices that can't snoop the CPU caches
2) to provide the special DMA_ATTR_WRITE_COMBINE semantics on older
arm systems and some mips platforms
Replace one
Signed-off-by: Christoph Hellwig
---
arch/unicore32/include/asm/pgtable.h | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/unicore32/include/asm/pgtable.h
b/arch/unicore32/include/asm/pgtable.h
index 9492aa304f03..126e961a8cb0 100644
--- a/arch/unicore32/include/asm/pgtable.h
+++
Based on an email from Will Deacon.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
Acked-by: Mark Rutland
---
arch/arm64/include/asm/pgtable.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index
The memory allocated for the atomic pool needs to have the same
mapping attributes that we use for remapping, so use
pgprot_dmacoherent instead of open coding it. Also deduct a
suitable zone to allocate the memory from based on the presence
of the DMA zones.
Signed-off-by: Christoph Hellwig
---
Hi all,
this series replaces the arch_dma_mmap_pgprot hooks with the
simpler pgprot_dmacoherent as used by the arm code already and
cleans up various bits around that area.
Changes since v1:
- improve the new arm64 comment
- keep the special DMA_ATTR_WRITE_COMBINE handling for mips and
On Fri, 23 Aug 2019 10:23:07 +0200
Joerg Roedel wrote:
> Hi Jacob,
>
> On Tue, Aug 20, 2019 at 02:21:08PM -0700, Jacob Pan wrote:
> > Global pages support is removed from VT-d spec 3.0. Since global
> > pages G flag only affects first-level paging structures and because
> > DMA request with
Now that the Xen special cases are gone nothing worth mentioning is
left in the arm64 file, so switch to use the
asm-generic version instead.
Signed-off-by: Christoph Hellwig
Acked-by: Will Deacon
---
arch/arm64/include/asm/Kbuild| 1 +
arch/arm64/include/asm/dma-mapping.h | 22
Now that we know we always have the dma-noncoherent.h helpers available
if we are on an architecture with support for non-coherent devices,
we can just call them directly, and remove the calls to the dma-direct
routines, including the fact that we call the dma_direct_map_page
routines but ignore
xen_dma_map_page uses a different and more complicated check for foreign
pages than the other three cache maintainance helpers. Switch it to the
simpler pfn_valid method a well, and document the scheme with a single
improved comment in xen_dma_map_page.
Signed-off-by: Christoph Hellwig
---
The only thing left of page-coherent.h is two functions implemented by
the architecture for non-coherent DMA support that are never called for
fully coherent architectures. Just move the prototypes for those to
swiotlb-xen.h instead.
Signed-off-by: Christoph Hellwig
---
Hi Xen maintainers and friends,
please take a look at this series that cleans up the parts of swiotlb-xen
that deal with non-coherent caches.
Changes since v1:
- rewrite dma_cache_maint to be much simpler
- improve various comments and commit logs
- remove page-coherent.h entirely
No need for a no-op wrapper.
Signed-off-by: Christoph Hellwig
---
drivers/xen/swiotlb-xen.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/xen/swiotlb-xen.c b/drivers/xen/swiotlb-xen.c
index 95911ff9c11c..384304a77020 100644
---
Calculate the required operation in the caller, and pass it directly
instead of recalculating it for each page, and use simple arithmetics
to get from the physical address to Xen page size aligned chunks.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 62
These routines are only used by swiotlb-xen, which cannot be modular.
Signed-off-by: Christoph Hellwig
---
arch/arm/xen/mm.c | 2 --
arch/x86/xen/mmu_pv.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/arm/xen/mm.c b/arch/arm/xen/mm.c
index 9b3a6c0ca681..b7d53415532b 100644
---
x86 currently calls alloc_pages, but using dma-direct works as well
there, with the added benefit of using the CMA pool if available.
The biggest advantage is of course to remove a pointless bit of
architecture specific code.
Signed-off-by: Christoph Hellwig
---
arm and arm64 can just use xen_swiotlb_dma_ops directly like x86, no
need for a pointer indirection.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
---
arch/arm/mm/dma-mapping.c| 3 ++-
arch/arm/xen/mm.c| 4
arch/arm64/mm/dma-mapping.c | 3 ++-
Reuse the arm64 code that uses the dma-direct/swiotlb helpers for DMA
non-coherent devices.
Signed-off-by: Christoph Hellwig
---
arch/arm/include/asm/device.h | 3 -
arch/arm/include/asm/xen/page-coherent.h | 93 --
arch/arm/mm/dma-mapping.c
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant. Note that both are always initialized to the same
value in arch_setup_dma_ops.
Signed-off-by: Christoph Hellwig
Reviewed-by: Julien Grall
---
arch/arm/include/asm/dma-mapping.h | 6 --
Nicolas Saenz Julienne writes:
> diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
> index 0d52f57fca04..73668a21ae78 100644
> --- a/arch/powerpc/include/asm/page.h
> +++ b/arch/powerpc/include/asm/page.h
> @@ -319,13 +319,4 @@ struct vm_area_struct;
> #endif /*
On Mon, 2019-08-26 at 09:06 +0200, Christoph Hellwig wrote:
> On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:
> > - if (IS_ENABLED(CONFIG_ZONE_DMA))
> > + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> > arm64_dma_phys_limit = max_zone_dma_phys();
> > +
On Mon, Aug 19, 2019 at 12:45:17PM +0100, Julien Grall wrote:
> On 8/16/19 2:00 PM, Christoph Hellwig wrote:
>> +static inline void xen_dma_map_page(struct device *hwdev, struct page *page,
>> + dma_addr_t dev_addr, unsigned long offset, size_t size,
>> + enum dma_data_direction
This reverts commit 557529494d79f3f1fadd486dd18d2de0b19be4da.
Commit 557529494d79f ("iommu/vt-d: Avoid duplicated pci dma alias
consideration") aimed to address a NULL pointer deference issue
happened when a thunderbolt device driver returned unexpectedly.
Unfortunately, this change breaks a
Hi Janusz,
On 8/26/19 4:15 PM, Janusz Krzysztofik wrote:
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
Hi,
On 8/22/19 10:29 PM, Janusz Krzysztofik wrote:
When a perfectly working i915 device is hot unplugged (via sysfs) and
hot re-plugged again, its dev->archdata.iommu
Hi Lu,
On Friday, August 23, 2019 3:51:11 AM CEST Lu Baolu wrote:
> Hi,
>
> On 8/22/19 10:29 PM, Janusz Krzysztofik wrote:
> > When a perfectly working i915 device is hot unplugged (via sysfs) and
> > hot re-plugged again, its dev->archdata.iommu field is not populated
> > again with an IOMMU
On Mon, Aug 26, 2019 at 11:05:00AM +0900, Masahiro Yamada wrote:
> This is included in v5.3-rc6
> so I tested it.
So there is no allocation failure, but you get I/O errors later?
Does the device use a device-private CMA area? Does it work with Linux
5.2 if CONFIG_DMA_CMA is disabled?
Hi,
On 26. 08. 19 9:02, Christoph Hellwig wrote:
> On Wed, Aug 14, 2019 at 04:03:46PM +0200, Christoph Hellwig wrote:
>> Hi Michal,
>>
>> can you take a look at this patch that moves microblaze over to the
>> generic DMA remap allocator? I've been trying to slowly get all
>> architectures over
On Tue, Aug 20, 2019 at 04:58:09PM +0200, Nicolas Saenz Julienne wrote:
> Some architectures have platform specific DMA addressing limitations.
> This will allow for hardware description code to provide the constraints
> in a generic manner, so as for arch code to properly setup it's memory
>
Looks good:
Reviewed-by: Christoph Hellwig
On Tue, Aug 20, 2019 at 04:58:18PM +0200, Nicolas Saenz Julienne wrote:
> - if (IS_ENABLED(CONFIG_ZONE_DMA))
> + if (IS_ENABLED(CONFIG_ZONE_DMA)) {
> arm64_dma_phys_limit = max_zone_dma_phys();
> + zone_dma_bits = ilog2((arm64_dma_phys_limit - 1) &
>
Looks good,
Reviewed-by: Christoph Hellwig
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Aug 14, 2019 at 04:03:46PM +0200, Christoph Hellwig wrote:
> Hi Michal,
>
> can you take a look at this patch that moves microblaze over to the
> generic DMA remap allocator? I've been trying to slowly get all
> architectures over to the generic code, and microblaze is one that
> seems
On Wed, Aug 21, 2019 at 8:05 PM Sakari Ailus
wrote:
>
> Hi Tomasz,
>
> On Wed, Aug 21, 2019 at 07:30:38PM +0900, Tomasz Figa wrote:
[snip]
> > Is it really correct to enable the clock before the regulators?
> >
> > According to the datasheet, it should be:
> > - PD pin HIGH,
> > - nRST pin LOW,
Looks good,
Reviewed-by: Christoph Hellwig
48 matches
Mail list logo
