Re: [PATCH v10 7/9] irqchip/gicv3-its: register the MSI global doorbell

Hi Eric, On Tue, Jun 07, 2016 at 04:01:26PM +, Eric Auger wrote: > This patch adds the registration of the MSI global doorbell in > gicv3-its driver. > > This will allow the msi layer to iommu_map this doorbell when > requested. > > Signed-off-by: Eric Auger > --- >

Re: [RFC PATCH v1 10/18] x86/efi: Access EFI related tables in the clear

On Thu, 16 Jun, at 09:38:31AM, Tom Lendacky wrote: > > Ok, I think this was happening before the commit to build our own > EFI page table structures: > > commit 67a9108ed ("x86/efi: Build our own page table structures") > > Before this commit the boot services ended up mapped into the kernel >

[git pull] IOMMU Fixes for Linux v4.7-rc3

Hi Linus, The following changes since commit 5edb56491d4812c42175980759da53388e5d86f5: Linux 4.7-rc3 (2016-06-12 07:20:35 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git tags/iommu-fixes-v4.7-rc3 for you to fetch changes up to

Re: [RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to attach DMA ops

Hi Robin, On Fri, Jun 17, 2016 at 10:27:22AM +0100, Robin Murphy wrote: > Hi Lorenzo, > > I think this patch makes sense even independent of the rest of the > series, one nit inline notwithstanding. Thanks. Yes I added it to this series since it is not strictly necessary (ie it does not fix

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Fri, Jun 17, 2016 at 02:54:56PM +0200, Rafael J. Wysocki wrote: > On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote: > > On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote: > > > From: "Rafael J. Wysocki" > > We also have such a

Re: [PATCH] iommu/io-pgtable-arm: Fix iova_to_phys for block entries

On 16/06/16 18:44, Will Deacon wrote: The implementation of iova_to_phys for the long-descriptor ARM io-pgtable code always masks with the granule size when inserting the low virtual address bits into the physical address determined from the page tables. In cases where the leaf entry is found

[PATCH] iommu/io-pgtable-arm: Fix iova_to_phys for block entries

The implementation of iova_to_phys for the long-descriptor ARM io-pgtable code always masks with the granule size when inserting the low virtual address bits into the physical address determined from the page tables. In cases where the leaf entry is found before the final level of table (i.e. due

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

On Fri, Jun 17, 2016 at 12:36 PM, Lukas Wunner wrote: > Hi Marek, > > On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote: >> From: "Rafael J. Wysocki" >> >> Currently, there is a problem with handling cases where functional >>

Re: [PATCH v2 02/10] driver core: Functional dependencies tracking support

Hi Marek, On Fri, Jun 17, 2016 at 08:26:52AM +0200, Marek Szyprowski wrote: > From: "Rafael J. Wysocki" > > Currently, there is a problem with handling cases where functional > dependencies between devices are involved. > > What I mean by a "functional dependency"

[PATCH] iommu/vt-d: Enable QI on all IOMMUs before setting root entry

From: Joerg Roedel This seems to be required on some X58 chipsets on systems with more than one IOMMU. QI does not work until it is enabled on all IOMMUs in the system. Reported-by: Dheeraj CVR Tested-by: Dheeraj CVR Fixes:

Re: [RFC PATCH v2 03/15] arm64: mm: change IOMMU notifier action to attach DMA ops

Hi Lorenzo, I think this patch makes sense even independent of the rest of the series, one nit inline notwithstanding. Marek; I'm curious as to whether this could make the workaround in 722ec35f7 obsolete as well, or are all the drivers also bound super-early in the setup you had there?

Re: [PATCH v2 7/7] iommu/arm-smmu: Support non-PCI devices with SMMUv3

On 17/06/16 02:54, Leizhen (ThunderTown) wrote: Hi, I only applied these patch series on lastest 4.7-rc3, is there any patches I missed? According to my test, it seems can not work. The problem is: Thanks, that's helpful (if irritating) confirmation. Would you mind trying this patch on top

Re: [BUGREPORT] Intel X58 Boards don't boot after "iommu/vt-d: Make root entry visible for hardware right after allocation"

On Thu, Jun 16, 2016 at 08:11:29PM +0400, Dheeraj CVR wrote: > I have applied your patch to 4.7.0-rc3 mainline kernel and the machine > successfully boots with intel_iommu=on. Thank you so much for your time and > effort. Thanks a lot for testing. I am sending this patch upstream soon. Regards,

[PATCH v2 05/10] PM core: Optimize the use of device links for runtime PM

From: "Rafael J. Wysocki" If the device has no links to suppliers that should be used for runtime PM (links with DEVICE_LINK_PM_RUNTIME set), there is no reason to walk the list of suppliers for that device during runtime suspend and resume. Add a simple mechanism to

[PATCH v2 07/10] driver core: Add support for links to already probed drivers

Set proper link state if link is created between already probed supplier device and to be probed consumer device. Signed-off-by: Marek Szyprowski --- drivers/base/core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/base/core.c

[PATCH v2 03/10] PM core: Make async suspend/resume of devices use device links

From: "Rafael J. Wysocki" Make the device suspend/resume part of the core system suspend/resume code use device links to ensure that supplier and consumer devices will be suspended and resumed in the right order in case of async suspend/resume. The idea, roughly, is

[PATCH v2 02/10] driver core: Functional dependencies tracking support

From: "Rafael J. Wysocki" Currently, there is a problem with handling cases where functional dependencies between devices are involved. What I mean by a "functional dependency" is when the driver of device B needs both device A and its driver to be present and

[PATCH v2 06/10] driver core: Avoid endless recursion if device has more than one link

This patch fixes endless recursion, which happends when device has more than one link. Signed-off-by: Marek Szyprowski --- drivers/base/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index

[PATCH v2 00/10] Exynos IOMMU: proper runtime PM support (use device dependencies)

Hello, This patch series finally implements proper runtime PM support in Exynos IOMMU driver. This has been achieved by using device links, which lets SYSMMU controller's runtime PM to follow master's device runtime PM (the device which actually performs DMA transaction). The main idea behind

[PATCH v2 10/10] iommu/exynos: Add proper runtime pm support

This patch uses recently introduced device links to track the runtime pm state of the master's device. This way each SYSMMU controller is runtime active its master's device is active and can save/restore its state instead of being enabled all the time. This way SYSMMU controllers no longer

[PATCH v2 09/10] iommu/exynos: Remove excessive, useless debug

Remove excessive, useless debug about skipping TLB invalidation, which is a normal situation when more aggressive power management is enabled. Signed-off-by: Marek Szyprowski --- drivers/iommu/exynos-iommu.c | 3 --- 1 file changed, 3 deletions(-) diff --git

[PATCH v2 04/10] PM core: Make runtime PM of devices use device links

From: "Rafael J. Wysocki" Modify the runtime PM framework to use device links to ensure that supplier devices will not be suspended if any of their consumer devices are active. The idea is to reference count suppliers on the consumer's resume and drop references to

[PATCH v2 08/10] PM core: Fix restoring devices with links during system PM transition

When devices are being runtime resumed during the system PM transition to suspend state, the link suppliers might be already resumed and have runtime pm disabled. This is normal case. This patch adds special support for such case. Simple call to pm_runtime_get_syncreturns error when device has

[PATCH v2 01/10] driver core: Add a wrapper around __device_release_driver()

From: "Rafael J. Wysocki" Add an internal wrapper around __device_release_driver() that will acquire device locks and do the necessary checks before calling it. The next patch will make use of it. Signed-off-by: Rafael J. Wysocki

Re: [PATCH 1/3] PM / Runtime: Add notifiers for device runtime PM events

Hi Rafael, On 2016-06-08 19:18, Rafael J. Wysocki wrote: On Wed, Jun 8, 2016 at 12:25 PM, Marek Szyprowski wrote: From: Krzysztof Kozlowski Allow drivers registering for certain runtime PM events of other devices. Some drivers in power