[PATCH v10 0/5] iommu/arm-smmu: Add runtime pm/sleep support

This series provides the support for turning on the arm-smmu's clocks/power domains using runtime pm. This is done using the recently introduced device links patches, which lets the smmu's runtime to follow the master's runtime pm, so the smmu remains powered only when the masters use it. As not

[PATCH v10 2/5] iommu/arm-smmu: Add pm_runtime/sleep ops

From: Sricharan R The smmu needs to be functional only when the respective master's using it are active. The device_link feature helps to track such functional dependencies, so that the iommu gets powered when the master device enables itself using pm_runtime. So by

[PATCH v10 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the master is added to the smmu.

[PATCH v10 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those places separately. Signed-off-by: Sricharan R

[PATCH v10 5/5] iommu/arm-smmu: Add support for qcom,smmu-v2 variant

qcom,smmu-v2 is an arm,smmu-v2 implementation with specific clock and power requirements. This smmu core is used with multiple masters on msm8996, viz. mdss, video, etc. Add bindings for the same. Signed-off-by: Vivek Gautam Reviewed-by: Rob Herring

[PATCH v10 1/5] driver core: Delete the link between two given devices

Given the consumer and supplier devices, add an API to delete the link between them. Suggested-by: Tomasz Figa Signed-off-by: Vivek Gautam Cc: Rafael J. Wysocki Cc: Greg Kroah-Hartman --- - This

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: > On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam > wrote: > > Hi Tomasz, > > > > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa wrote: > >> Hi Vivek, > >> > >> Thanks for the patch. > >> >

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

Hi Rafael, On 14/03/18 11:57, Rafael J. Wysocki wrote: On Wednesday, March 14, 2018 12:50:54 PM CET Tomasz Figa wrote: On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki wrote: On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: On Tue, Mar 13, 2018 at 7:34 PM,

Re: [PATCH 1/3] dt-bindings: iommu: ipmmu-vmsa: Add device tree support for r8a774[35]

On Wed, Mar 07, 2018 at 09:09:21AM +0100, Simon Horman wrote: > [CC Alex Williamson] > > It looks like the last patch to this file was taken by Alex. > Perhaps he would be willing to take this one too if it it was > reposted with him CCed. Alex was taking care of IOMMU patches while I was off at

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Wed, Mar 14, 2018 at 12:12:05PM +0100, Rafael J. Wysocki wrote: > On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: > > On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam > > wrote: > > > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz Figa

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki wrote: > On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: >> On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam >> wrote: >> > Hi Tomasz, >> > >> > On Tue, Mar 13, 2018 at 3:45 PM, Tomasz

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

>> +.dev_groups = amba_dev_groups, >> +.match = amba_match, >> +.uevent = amba_uevent, >> +.pm = _pm, >> +.dma_configure = amba_dma_configure, >> +.dma_deconfigure= amba_dma_deconfigure, >> +

Re: [PATCH] dma-mapping: move dma configuration to bus infrastructure

> Agree. There is no good point in duplicating the code. > So this new API will be part of 'drivers/base/dma-mapping.c' file? Yes. > > As mention in my previous reply I think we don't even need a deconfigure > > callback at this point - just remove the ACPI and OF wrappers and > > clear the dma

Re: [PATCH v9 1/5] driver core: Find an existing link between two devices

On Wed, Mar 14, 2018 at 12:14:15PM +, Robin Murphy wrote: > >>On Wed, Mar 14, 2018 at 8:12 PM, Rafael J. Wysocki > >>wrote: > >>>On Tuesday, March 13, 2018 12:23:34 PM CET Tomasz Figa wrote: > On Tue, Mar 13, 2018 at 7:34 PM, Vivek Gautam >

[PATCH v3 1/5] iommu/amd - Add debugfs support

Expose the IOMMU MMIO registers and device table Signed-off-by: Gary R Hook --- drivers/iommu/Kconfig |7 ++ drivers/iommu/Makefile|1 drivers/iommu/amd_iommu_debugfs.c | 122 +

[PATCH v3 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

Initially (at boot) the device table values dumped are all of the active devices. Add a devid debugfs file to allow the user to select a single device table entry to dump (active or not). Let any devid value greater than the maximum allowable PCI ID (0x) restore the behavior to that effective

[PATCH v3 3/5] iommu/amd - Add a README variable for the IOMMU debugfs

Provide help text via a filesystem entry Signed-off-by: Gary R Hook --- drivers/iommu/amd_iommu_debugfs.c | 31 +++ 1 file changed, 31 insertions(+) diff --git a/drivers/iommu/amd_iommu_debugfs.c b/drivers/iommu/amd_iommu_debugfs.c index

[PATCH v3 0/5] Add debugfs info for the AMD IOMMU

The following series creates a debugfs directory for AMD IOMMUs, constructs a framework for additional entries, an online README, and a method for dumping device table entries. Data is reported in a default concise mode, but a verbose mode is enabled via a filesystem entry. This is the first of

[PATCH v3 2/5] iommu/amd - Add a 'verbose' switch for IOMMU debugfs

Enable more descriptive debugfs output via a 'verbose' variable. Signed-off-by: Gary R Hook --- drivers/iommu/amd_iommu_debugfs.c | 14 +- 1 file changed, 13 insertions(+), 1 deletion(-) diff --git a/drivers/iommu/amd_iommu_debugfs.c

[PATCH 3/3] iommu/vt-d: Use global PASID for SVM usage

This patch switches PASID management for SVM from SVM specific idr to the global idr. Cc: Ashok Raj Cc: Jacob Pan Cc: Kevin Tian Cc: Liu Yi L Signed-off-by: Lu Baolu

[PATCH 0/3] iommu/vt-d: Global PASID name space

Hi, This patch series is trying to change the scope of PASID management used in Intel IOMMU driver from per IOMMU to driver global. This is required for some cases where current per-IOMMU PASID name space doesn't work. For an example, one application (associated with one PASID) might talk to two

[PATCH 2/3] iommu/vt-d: Decouple idr bond pointer from svm

As we move the PASID idr out of SVM code and make it serving as a global PASID name space, the consumer can specify a ptr to bind it with a PASID. We shouldn't assume that each PASID will be bond with a ptr of struct intel_svm anymore. This patch cleans up a idr_for_each_entry() usage in the SVM

[PATCH 1/3] iommu/vt-d: Global PASID name space

This adds the algorithm to maintain a system wide PASID name space for the PASID allocation. Previously we maintained a per IOMMU unit PASID name space which is not suitable for some use cases. For an example, one application (associated with one PASID) might talk to two physical devices

[PATCH 01/14] x86: remove X86_PPRO_FENCE

There were only a few Pentium Pro multiprocessors systems where this errata applied. They are more than 20 years old now, and we've slowly dropped places where put the workarounds in and discouraged anyone from enabling the workaround. Get rid of it for good. Signed-off-by: Christoph Hellwig

[PATCH 05/14] x86/amd_gart: look at coherent_dma_mask instead of GFP_DMA

We want to phase out looking at the magic GFP_DMA flag in the dma mapping routines, so switch the gart driver to use the coherent_dma_mask instead, which is used to select the GFP_DMA flag in the caller. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/amd_gart_64.c | 2 +- 1

[PATCH 03/14] x86: use dma-direct

The generic dma-direct implementation is now functionally equivalent to the x86 nommu dma_map implementation, so switch over to using it. Note that the various iommu drivers are switched from x86_dma_supported to dma_direct_supported to provide identical functionality, although the checks looks

use generic dma-direct and swiotlb code for x86 V2

Hi all, this series switches the x86 code the the dma-direct implementation for direct (non-iommu) dma and the generic swiotlb ops. This includes getting rid of the special ops for the AMD memory encryption case and the STA2x11 SOC. The generic implementations are based on the x86 code, so they

[PATCH 04/14] x86: use generic swiotlb_ops

The generic swiotlb dma ops were based on the x86 ones and provide equivalent functionality, so use them. Also fix the sta2x11 case. For that SOC the dma map ops need an additional physical to dma address translations. For swiotlb buffers that is done throught the phys_to_dma helper, but the

[PATCH 09/14] x86: remove dma_alloc_coherent_gfp_flags

All dma_ops implementations used on x86 now take care of setting their own required GFP_ masks for the allocation. And given that the common code now clears harmful flags itself that means we can stop the flags in all the iommu implementations as well. Signed-off-by: Christoph Hellwig

[PATCH 08/14] iommu/intel-iommu: cleanup intel_{alloc,free}_coherent

Use the dma_direct_* helpers and cleanup the code flow. Signed-off-by: Christoph Hellwig --- drivers/iommu/Kconfig | 1 + drivers/iommu/intel-iommu.c | 62 - 2 files changed, 17 insertions(+), 46 deletions(-) diff --git

Re: [RFC 2/5] dt-bindings: brcm: Add reserved-dma-region for iPROC

On 12/03/18 07:03, Jitendra Bhivare wrote: On Tue, Mar 6, 2018 at 5:12 PM, Robin Murphy wrote: On 06/03/18 04:59, Jitendra Bhivare wrote: With SoC wide DMA mask of 40-bit, the mappings for entire IOVA space can't be specified in the PAXBv2 PCIe RC of SoC. The holes in

Re: WARN_ON(irqs_disabled()) in dma_free_attrs?

On 13/03/18 13:17, Christoph Hellwig wrote: On Tue, Mar 13, 2018 at 12:11:49PM +, Robin Murphy wrote: Taking a step back, though, provided the original rationale about dma_declare_coherent_memory() is still valid, I wonder if we should simply permit the USB code to call

Re: [PATCH v9 4/5] iommu/arm-smmu: Add the device_link between masters and smmu

On 13/03/18 08:55, Vivek Gautam wrote: From: Sricharan R Finally add the device link between the master device and smmu, so that the smmu gets runtime enabled/disabled only when the master needs it. This is done from add_device callback which gets called once when the

Re: [PATCH v9 3/5] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device

On 13/03/18 08:55, Vivek Gautam wrote: From: Sricharan R The smmu device probe/remove and add/remove master device callbacks gets called when the smmu is not linked to its master, that is without the context of the master device. So calling runtime apis in those

use generic dma-direct and swiotlb code for x86 V2

Hi all, this series switches the x86 code the the dma-direct implementation for direct (non-iommu) dma and the generic swiotlb ops. This includes getting rid of the special ops for the AMD memory encryption case and the STA2x11 SOC. The generic implementations are based on the x86 code, so they

[PATCH 14/14] swiotlb: remove swiotlb_{alloc,free}_coherent

Unused now that everyone uses swiotlb_{alloc,free}. Signed-off-by: Christoph Hellwig --- include/linux/swiotlb.h | 8 lib/swiotlb.c | 38 -- 2 files changed, 46 deletions(-) diff --git a/include/linux/swiotlb.h

[PATCH 12/14] dma-direct: handle the memory encryption bit in common code

Give the basic phys_to_dma and dma_to_phys helpers a __-prefix and add the memory encryption mask to the non-prefixed versions. Use the __-prefixed versions directly instead of clearing the mask again in various places. Signed-off-by: Christoph Hellwig ---

[PATCH 06/14] x86/amd_gart: use dma_direct_{alloc,free}

This gains support for CMA allocations for the force_iommu case, and cleans up the code a bit. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/amd_gart_64.c | 36 ++-- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git

[PATCH 10/14] set_memory.h: provide set_memory_{en,de}crypted stubs

Signed-off-by: Christoph Hellwig --- include/linux/set_memory.h | 12 1 file changed, 12 insertions(+) diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h index e5140648f638..da5178216da5 100644 --- a/include/linux/set_memory.h +++

[PATCH 11/14] swiotlb: remove swiotlb_set_mem_attributes

Now that set_memory_decrypted is always available we can just call it directly. Signed-off-by: Christoph Hellwig --- arch/x86/include/asm/mem_encrypt.h | 2 -- arch/x86/mm/mem_encrypt.c | 9 - lib/swiotlb.c | 12 ++-- 3 files changed,

Re: [PATCH 07/37] iommu: Add a page fault handler

Hi Jonathan, Thanks for reviewing On 08/03/18 15:40, Jonathan Cameron wrote: >> +/** >> + * iommu_fault_queue_unregister() - Unregister an IOMMU driver from the >> fault >> + * queue. >> + * @flush_notifier: same parameter as iommu_fault_queue_register >> + */ >> +void

Re: [PATCH v2 5/5] iommu/amd - Add a debugfs entry to specify a IOMMU device table entry

On 03/13/2018 03:56 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: On 03/13/2018 12:20 PM, Andy Shevchenko wrote: + } else if (obuf[0] == '0' && obuf[1] == 'x') { + n = sscanf(obuf, "%x", _iommu_devid); + } else {

Re: [PATCH v2 1/5] iommu/amd - Add debugfs support

On 03/13/2018 03:23 PM, Andy Shevchenko wrote: On Tue, Mar 13, 2018 at 8:54 PM, Gary R Hook wrote: On 03/13/2018 12:16 PM, Andy Shevchenko wrote: On Fri, Mar 9, 2018 at 2:50 AM, Gary R Hook wrote: +#include +#include +#include Keep in order?

Re: [PATCH v2 1/5] iommu/amd - Add debugfs support

On Wed, Mar 14, 2018 at 5:24 PM, Gary R Hook wrote: > On 03/13/2018 03:23 PM, Andy Shevchenko wrote: > +#include > +#include > +#include Keep in order? >>> What order would that be? These few needed files are listed in the same >>> order as which they

Re: [PATCH 11/13] dma-direct: handle the memory encryption bit in common code

On 03/13/2018 08:10 AM, Christoph Hellwig wrote: > On Mon, Mar 12, 2018 at 02:48:51PM -0500, Tom Lendacky wrote: >> Ok, I found one issue that allows this to work when the IOMMU isn't >> enabled (see below). > > Thanks, folded! > >> But the bigger issue is when the IOMMU is enabled. The IOMMU

Re: [PATCH 31/37] iommu/arm-smmu-v3: Add support for PCI ATS

On 08/03/18 16:17, Jonathan Cameron wrote: >> +arm_smmu_enable_ats(master); > It's a bit nasty not to handle the errors that this could output (other than > the ENOSYS for when it's not available). Seems that it would be nice to at > least add a note to the log if people are expecting it to

Re: [PATCH 35/37] iommu/arm-smmu-v3: Add support for PRI

On 08/03/18 16:24, Jonathan Cameron wrote: > On Mon, 12 Feb 2018 18:33:50 + > Jean-Philippe Brucker wrote: > >> For PCI devices that support it, enable the PRI capability and handle >> PRI Page Requests with the generic fault handler. >> >> Signed-off-by:

Re: [PATCH 28/37] iommu/arm-smmu-v3: Maintain a SID->device structure

On 08/03/18 17:34, Jonathan Cameron wrote: >> static int arm_smmu_add_device(struct device *dev) >> @@ -2198,6 +2298,7 @@ static int arm_smmu_add_device(struct device *dev) >> >> group = iommu_group_get_for_dev(dev); >> if (!IS_ERR(group)) { >> +

Re: [PATCH 27/37] iommu/arm-smmu-v3: Register fault workqueue

On 08/03/18 17:44, Jonathan Cameron wrote: >> @@ -3168,6 +3260,13 @@ static int arm_smmu_device_probe(struct >> platform_device *pdev) >> if (ret) >> return ret; >> >> +if (smmu->features & (ARM_SMMU_FEAT_STALLS | ARM_SMMU_FEAT_PRI)) { >> +

Re: [PATCH 17/37] iommu/arm-smmu-v3: Move context descriptor code

On 09/03/18 11:44, Jonathan Cameron wrote: > On Mon, 12 Feb 2018 18:33:32 + > Jean-Philippe Brucker wrote: > >> In order to add support for substream ID, move the context descriptor code >> into a separate library. At the moment it only manages context