On Tue, Aug 20, 2019 at 07:43:52AM +0200, Stefan Wahren wrote:
> i applied this patch and it fixes the build issue i reported before. But
> this seems to reveal another build issue in drivers/firmware/qcom_scm.c:
Yes, I rean into this as well until I disabled the qcom platform. But
this is in no
Hi Christoph,
Am 20.08.19 um 03:24 schrieb Christoph Hellwig:
> Hi Stefan,
>
> please try the patch below.
>
> ---
> From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
> From: Christoph Hellwig
> Date: Tue, 20 Aug 2019 10:08:38 +0900
> Subject: arm: select the dma-noncoherent
Tobias, plase try this patch:
--
>From 88c590a2ecafc8279388f25bfbe1ead8ea3507a6 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 20 Aug 2019 11:45:49 +0900
Subject: dma-direct: fix zone selection after an unaddressable CMA allocation
The new dma_alloc_contiguous hides if we allocate C
On Tue, 20 Aug 2019 10:15:01 +0800 Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 06:58:52PM -0700, Nicolin Chen wrote:
> > Right...the condition was in-between. However, not every caller
> > of dma_alloc_contiguous() is supposed to have a coherent check.
> > So we either add a 'bool coherent
On Mon, Aug 19, 2019 at 06:58:52PM -0700, Nicolin Chen wrote:
> Right...the condition was in-between. However, not every caller
> of dma_alloc_contiguous() is supposed to have a coherent check.
> So we either add a 'bool coherent_ok' to the API or revert the
> dma-direct part back to the original.
Hello Hillf,
On Mon, Aug 19, 2019 at 12:38:38AM +0200, Tobias Klausmann wrote:
>
> On 18.08.19 05:13, Hillf Danton wrote:
> > On Sat, 17 Aug 2019 00:42:48 +0200 Tobias Klausmann wrote:
> > > Hi Nicolin,
> > >
> > > On 17.08.19 00:25, Nicolin Chen wrote:
> > > > Hi Tobias
> > > >
> > > > On Fri,
Hi Jens,
> From: Jens Axboe, Sent: Monday, August 19, 2019 11:54 PM
>
> On 8/16/19 1:50 PM, Wolfram Sang wrote:
> > On Fri, Jul 26, 2019 at 05:31:14PM +0900, Yoshihiro Shimoda wrote:
> >> This patch sorts the headers in alphabetic order to ease
> >> the maintenance for this part.
> >>
> >> Signed
Hi Robin,
> From: Robin Murphy, Sent: Monday, August 19, 2019 9:55 PM
>
> On 26/07/2019 09:31, Yoshihiro Shimoda wrote:
> > This patch adds a new dma_map_ops of get_merge_boundary() to
> > expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
> >
> > Signed-off-by: Yoshihiro Shimo
Hi Stefan,
please try the patch below.
---
>From e0570628d96faa50ebfc94ce8e545968336db225 Mon Sep 17 00:00:00 2001
From: Christoph Hellwig
Date: Tue, 20 Aug 2019 10:08:38 +0900
Subject: arm: select the dma-noncoherent symbols for all swiotlb builds
We need to provide the arch hooks for non-cohe
On Mon, Aug 19, 2019 at 03:53:31PM -0700, Kuppuswamy Sathyanarayanan wrote:
> On Mon, Aug 19, 2019 at 09:15:00AM -0500, Bjorn Helgaas wrote:
> > On Thu, Aug 15, 2019 at 03:39:03PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > > On 8/15/19 3:20 PM, Bjorn Helgaas wrote:
> > > > [+cc Joerg, David, iomm
On Mon, Aug 19, 2019 at 09:15:00AM -0500, Bjorn Helgaas wrote:
> On Thu, Aug 15, 2019 at 03:39:03PM -0700, Kuppuswamy Sathyanarayanan wrote:
> > On 8/15/19 3:20 PM, Bjorn Helgaas wrote:
> > > [+cc Joerg, David, iommu list: because IOMMU drivers are the only
> > > callers of pci_enable_pri() and pci
On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
> Now that callers are free to use a given table for TTBR1 if they wish
> (all they need do is shift the provided attributes when constructing
> their final TCR value), the only remaining impediment is the address
> validation on map/unm
Am 19.08.19 um 21:02 schrieb Robin Murphy:
> On 19/08/2019 19:37, Stefan Wahren wrote:
>> Hi,
>>
>> i tried to cross compile arm/multi_v7_defconfig with CONFIG_XEN=y with
>> Linux 5.3-rc5 and i'm getting this:
>>
>> arch/arm/mm/dma-mapping.c: In function ‘arch_setup_dma_ops’:
>> arch/arm/mm/dma-map
On 19/08/2019 19:37, Stefan Wahren wrote:
Hi,
i tried to cross compile arm/multi_v7_defconfig with CONFIG_XEN=y with
Linux 5.3-rc5 and i'm getting this:
arch/arm/mm/dma-mapping.c: In function ‘arch_setup_dma_ops’:
arch/arm/mm/dma-mapping.c:2347:5: error: ‘struct device’ has no member
named ‘dma
Hi,
i tried to cross compile arm/multi_v7_defconfig with CONFIG_XEN=y with
Linux 5.3-rc5 and i'm getting this:
arch/arm/mm/dma-mapping.c: In function ‘arch_setup_dma_ops’:
arch/arm/mm/dma-mapping.c:2347:5: error: ‘struct device’ has no member
named ‘dma_coherent’
dev->dma_coherent = coherent;
On 15/08/2019 12:09, Tom Murphy wrote:
Use the dev->coherent_dma_mask when allocating in the dma-iommu ops api.
Oops... I suppose technically that's my latent bug, but since we've all
missed it so far, I doubt arm64 systems ever see any devices which
actually have different masks.
Reviewed-
On 15/08/2019 12:09, Tom Murphy wrote:
Handle devices which defer their attach to the iommu in the dma-iommu api
Other than nitpicking the name (I'd lean towards something like
iommu_dma_deferred_attach),
Reviewed-by: Robin Murphy
Signed-off-by: Tom Murphy
---
drivers/iommu/dma-iommu.c
On 15/08/2019 12:09, Tom Murphy wrote:
Add a gfp_t parameter to the iommu_ops::map function.
Remove the needless locking in the AMD iommu driver.
The iommu_ops::map function (or the iommu_map function which calls it)
was always supposed to be sleepable (according to Joerg's comment in
this threa
Between VMSAv8-64 and the various 32-bit formats, there is either one
64-bit MAIR or a pair of 32-bit MAIR0/MAIR1 or NMRR/PMRR registers.
As such, keeping two 64-bit values in io_pgtable_cfg has always been
overkill.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu-v3.c| 2 +-
drivers/
Although it's conceptually nice for the io_pgtable_cfg to provide a
standard VMSA TCR value, the reality is that no VMSA-compliant IOMMU
looks exactly like an Arm CPU, and they all have various other TCR
controls which io-pgtable can't be expected to understand. Thus since
there is an expectation t
Hi all,
Although the io-pgtable-arm formats started out with the notion of being
able to provide a complete ready-to-use context for VMSA-compliant users
to consume, the reality is that users inevitably still have to make their
own adjustments to that context anyway. Worse, though, is that some of
TTBR1 values have so far been redundant since no users implement any
support for split address spaces. Crucially, though, one of the main
reasons for wanting to do so is to be able to manage each half entirely
independently, e.g. context-switching one set of mappings without
disturbing the other. T
Now that callers are free to use a given table for TTBR1 if they wish
(all they need do is shift the provided attributes when constructing
their final TCR value), the only remaining impediment is the address
validation on map/unmap. The fact that the LPAE address space split is
symmetric makes this
On 19/08/2019 16:56, Will Deacon wrote:
On Thu, Aug 15, 2019 at 07:37:20PM +0100, Robin Murphy wrote:
v1 for context: https://patchwork.kernel.org/cover/11087347/
Here's a quick v2 attempting to address all the minor comments; I've
tweaked a whole bunch of names, added some verbosity in macros
Hi Joerg,
Please pull this series to enable batched unmap support in the IOMMU
core API. Later patches will enable this for Arm SMMUv3, and I suspect
other IOMMU hardware can also benefit from the changes.
The rough idea is to track the current range being unmapped on the stack
of the caller, so
On Thu, Aug 15, 2019 at 07:37:20PM +0100, Robin Murphy wrote:
> v1 for context: https://patchwork.kernel.org/cover/11087347/
>
> Here's a quick v2 attempting to address all the minor comments; I've
> tweaked a whole bunch of names, added some verbosity in macros and
> comments for clarity, and rej
On 8/16/19 1:50 PM, Wolfram Sang wrote:
> On Fri, Jul 26, 2019 at 05:31:14PM +0900, Yoshihiro Shimoda wrote:
>> This patch sorts the headers in alphabetic order to ease
>> the maintenance for this part.
>>
>> Signed-off-by: Yoshihiro Shimoda
>> Reviewed-by: Wolfram Sang
>> Reviewed-by: Simon Horm
Does my explanation from Thursday make sense or is it completely
off? Does the patch description need some update to be less
confusing to those used to different terminology?
On Thu, Aug 15, 2019 at 12:50:02PM +0200, Christoph Hellwig wrote:
> Except for the different naming scheme vs the code th
On Thu, Aug 15, 2019 at 03:39:03PM -0700, Kuppuswamy Sathyanarayanan wrote:
> On 8/15/19 3:20 PM, Bjorn Helgaas wrote:
> > [+cc Joerg, David, iommu list: because IOMMU drivers are the only
> > callers of pci_enable_pri() and pci_enable_pasid()]
> >
> > On Thu, Aug 01, 2019 at 05:06:01PM -0700,
>
Hi Christoph,
On 8/16/19 2:00 PM, Christoph Hellwig wrote:
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_vali method a well.
NIT: s/pfn_vali/pfn_valid/
Signed-off-by: Christoph Hel
From: Joerg Roedel
Set the default domain-type at runtime, not at compile-time.
This keeps default domain type setting in one place when we
have to change it at runtime.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 23 +++
1 file changed, 15 insertions(+), 8 dele
From: Joerg Roedel
Introduce a subsys_initcall for IOMMU code and use it to
print the default domain type at boot.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 30 +-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iommu.c b/dr
From: Joerg Roedel
Add a couple of functions to allow changing the default
domain type from architecture code and a function for iommu
drivers to request whether the default domain is
passthrough.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 22 ++
include/linux/
From: Joerg Roedel
This variable has no users anymore. Remove it and tell the
IOMMU code via its new functions about requested DMA modes.
Signed-off-by: Joerg Roedel
---
arch/x86/include/asm/iommu.h | 1 -
arch/x86/kernel/pci-dma.c| 20 +++-
2 files changed, 3 insertions(+
From: Joerg Roedel
Using Passthrough mode when SME is active causes certain
devices to use the SWIOTLB bounce buffer. The bounce buffer
code has an upper limit of 256kb for the size of DMA
allocations, which is too small for certain devices and
causes them to fail.
With this patch we enable IOMM
From: Joerg Roedel
Get rid of the iommu_pass_through variable and request
passthrough mode via the new iommu core function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/intel-iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iomm
From: Joerg Roedel
There are functions now to set the default domain type which
take care of updating other necessary state. Don't open-code
it in iommu_set_def_domain_type() and use those functions
instead.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iommu.c | 6 --
1 file changed, 4 in
From: Joerg Roedel
This kernel parameter now takes also effect on X86.
Signed-off-by: Joerg Roedel
---
Documentation/admin-guide/kernel-parameters.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guid
From: Joerg Roedel
This variable has no users anymore so it can be removed.
Signed-off-by: Joerg Roedel
---
arch/ia64/include/asm/iommu.h | 2 --
arch/ia64/kernel/pci-dma.c| 2 --
2 files changed, 4 deletions(-)
diff --git a/arch/ia64/include/asm/iommu.h b/arch/ia64/include/asm/iommu.h
in
From: Joerg Roedel
Introduce an extensible concept to remember when certain
configuration settings for the IOMMU code have been set on
the kernel command line.
This will be used later to prevent overwriting these
settings with other defaults.
Signed-off-by: Joerg Roedel
---
drivers/iommu/iomm
From: Joerg Roedel
Hi,
This patch-set started out small to overwrite the default passthrough
setting (through CONFIG_IOMMU_DEFAULT_PASSTHROUGH=y) when SME is active.
But on the way to that Tom reminded me that the current ways to
configure passthrough/no-passthrough modes for IOMMU on x86 is a
From: Joerg Roedel
Get rid of the iommu_pass_through variable and request
passthrough mode via the new iommu core function.
Signed-off-by: Joerg Roedel
---
drivers/iommu/amd_iommu.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/io
On Fri, Aug 16, 2019 at 05:58:37PM -0500, Suman Anna wrote:
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/m
On 26/07/2019 09:31, Yoshihiro Shimoda wrote:
This patch adds a new dma_map_ops of get_merge_boundary() to
expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
Signed-off-by: Yoshihiro Shimoda
Reviewed-by: Simon Horman
---
drivers/iommu/dma-iommu.c | 11 +++
1 file
On Fri, Jul 26, 2019 at 05:31:13PM +0900, Yoshihiro Shimoda wrote:
> This patch adds a new dma_map_ops of get_merge_boundary() to
> expose the DMA merge boundary if the domain type is IOMMU_DOMAIN_DMA.
>
> Signed-off-by: Yoshihiro Shimoda
> Reviewed-by: Simon Horman
Acked-by: Joerg Roedel
Hi Christoph,
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 dir, unsigned long attrs)
+{
+ unsigned long pa
Hi Christoph,
On 8/16/19 2:00 PM, Christoph Hellwig wrote:
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
Cheers,
--
Julien Grall
Hi Christoph,
On 8/16/19 2:00 PM, Christoph Hellwig wrote:
Use the dma-noncoherent dev_is_dma_coherent helper instead of the home
grown variant.
It took me a bit of time to understand that dev->archdata.dma_coherent
and dev->dma_coherent will always contain the same value.
Would you mind it
On Fri, Aug 16, 2019 at 03:22:20PM +0800, Yong Wu wrote:
> On Thu, 2019-08-15 at 12:50 +0100, Will Deacon wrote:
> > Ok, I think speaking to Robin helped me a bit with this...
> >
> > On Thu, Aug 15, 2019 at 06:18:38PM +0800, Yong Wu wrote:
> > > On Thu, 2019-08-15 at 10:51 +0100, Will Deacon wrot
On Fri, Aug 16, 2019 at 03:00:13PM +0200, Christoph Hellwig wrote:
> 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
> ---
> arch/arm64/include/asm/Kbuild
50 matches
Mail list logo
