Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

On 13 June 2016 at 20:45, Will Deacon wrote: > On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will

Re: [PATCH v2] iommu/amd: Set AMD iommu callbacks for platform bus driver

2016-05-10 21:21 GMT+08:00 Wan Zongshun : > From: Wan Zongshun > > AMD has more drivers will use ACPI to platform bus driver later, > all those devices need iommu support, for example: eMMC driver. > > For latest AMD eMMC controller, it will utilize

Re: [E1000-devel] AMD-Vi: Event logged IO_PAGE_FAULT - ixgbe Detected Tx Unit Hang - Reset adapter - master disable timed out

2016-06-14 1:40 GMT+08:00 Lutz Vieweg : > On 06/13/2016 04:46 AM, Wan ZongShun wrote: >>> >>> With "iommu=pt": [4.832580] iommu: Adding device :04:00.0 to group 13 [4.832838] iommu: Using direct mapping for device :04:00.0 >>> >>> >> >> That is

Re: [E1000-devel] AMD-Vi: Event logged IO_PAGE_FAULT - ixgbe Detected Tx Unit Hang - Reset adapter - master disable timed out

On 06/13/2016 11:08 AM, Joerg Roedel wrote: On Thu, Jun 09, 2016 at 09:03:40AM -0700, Alexander Duyck wrote: Jun 9 14:40:09 computer kernel: AMD-Vi: Event logged [IO_PAGE_FAULT device=04:00.0 domain=0x000e address=0x000178c0 flags=0x0050] Jun 9 14:40:09 computer kernel: AMD-Vi: Event

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

On Thu, 09 Jun, at 01:33:30PM, Tom Lendacky wrote: > > I was trying to play it safe here, but as you say, the firmware should > be using our page tables so we can get rid of this call. The problem > will actually be if we transition to a 32-bit efi. The encryption bit > will be lost in cr3 and so

Re: BUG: using smp_processor_id() in preemptible [00000000] code]

Hello, Am Donnerstag, den 09. Juni schrieb Nadav Amit: > Alan Stern wrote: > > > On Thu, 9 Jun 2016, M G Berberich wrote: > > > >> With 4.7-rc2, after detecting a USB Mass Storage device > >> > >> [ 11.589843] usb-storage 4-2:1.0: USB Mass Storage device detected

Re: BUG: using smp_processor_id() in preemptible [00000000] code]

Hi, On Mon, Jun 13, 2016 at 4:06 PM, M G Berberich wrote: > Hello, > >> >> With 4.7-rc2, after detecting a USB Mass Storage device >> >> >> >> [ 11.589843] usb-storage 4-2:1.0: USB Mass Storage device detected >> >> >> >> a constant flow of kernel-BUGS is reported

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

On Mon, Jun 13, 2016 at 05:20:17PM +0800, Wei Chen wrote: > The PCIe ACS capability will affect the layout of iommu groups. > Generally speaking, if the path from root port to the PCIe device > is ACS enabled, the iommu will create a single iommu group for this > PCIe device. If all PCIe devices

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

Wei, Le 13/06/2016 à 13:18, Robin Murphy a écrit : > On 13/06/16 10:20, Wei Chen wrote: >> The PCIe ACS capability will affect the layout of iommu groups. >> Generally speaking, if the path from root port to the PCIe device >> is ACS enabled, the iommu will create a single iommu group for this >>

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

On Mon, 13 Jun, at 01:03:22PM, Matt Fleming wrote: > > Would we need a new function? Couldn't we just have a new > FIXMAP_PAGE_* constant? e.g. would something like this work? > > --- > > enum memremap_owner { > KERNEL_DATA = 0, > BOOT_DATA, > }; > > void __init * >

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

On Thu, 09 Jun, at 11:16:40AM, Tom Lendacky wrote: > > So maybe something along the lines of an enum that would have entries > (initially) like KERNEL_DATA (equal to zero) and EFI_DATA. Others could > be added later as needed. Sure, that works for me, though maybe BOOT_DATA would be more

[PATCH V6 5/6] iommu/msm: use generic ARMV7S short descriptor pagetable ops

This iommu uses the armv7 short descriptor format. So use the generic ARMV7S pagetable ops instead of rewriting the same stuff in the driver. Signed-off-by: Sricharan R Tested-by: Archit Taneja Tested-by: Srinivas Kandagatla

[PATCH V6 4/6] iommu/msm: Add support for generic master bindings

This adds the xlate callback which gets invoked during device registration from DT. The master devices gets added through this. Signed-off-by: Sricharan R Tested-by: Archit Taneja Tested-by: Srinivas Kandagatla

[PATCH V6 3/6] iommu/msm: Move the contents from msm_iommu_dev.c to msm_iommu.c

There are only two functions left in msm_iommu_dev.c. Move it to msm_iommu.c and delete the file. Signed-off-by: Sricharan R Tested-by: Archit Taneja Tested-by: Srinivas Kandagatla --- drivers/iommu/Makefile

[PATCH V6 6/6] iommu/msm: Remove driver BROKEN

Now that the driver is DT adapted, bus_set_iommu gets called only when on compatible matching. So the driver should not break multiplatform builds now. So remove the BROKEN config. Signed-off-by: Sricharan R Tested-by: Archit Taneja Tested-by:

[PATCH V6 1/6] iommu/msm: Add DT adaptation

The driver currently works based on platform data. Remove this and add support for DT. A single master can have multiple ports connected to more than one iommu. master | | |

[PATCH V6 0/6] iommu/msm: Add DT adaptation and generic bindings support

The msm_iommu.c driver currently works based on platform data. A single master device can be connected to more than one iommu and multiple contexts in each of the iommu. This association between master and iommus was represented from platform data using parent/child devices. The master drivers

[PATCH V6 2/6] documentation: iommu: Add bindings for msm, iommu-v0 ip

The MSM IOMMU is an implementation compatible with the ARM VMSA short descriptor page tables. It provides address translation for bus masters outside of the CPU, each connected to the IOMMU through a port called micro-TLB. Adding the DT bindings for the same. Signed-off-by: Sricharan R

Re: [PATCH] iommu/arm-smmu: request pcie devices to enable ACS

On 13/06/16 10:20, Wei Chen wrote: The PCIe ACS capability will affect the layout of iommu groups. Generally speaking, if the path from root port to the PCIe device is ACS enabled, the iommu will create a single iommu group for this PCIe device. If all PCIe devices on the path are ACS enabled

Re: [PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

On 13/06/16 10:56, Shunqian Zheng wrote: Hi On 2016年06月10日 17:10, Tomasz Figa wrote: Hi, On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng wrote: Use DMA API instead of architecture internal functions like __cpuc_flush_dcache_area() etc. To support the virtual device

Re: [PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

HI, On 2016年06月13日 18:21, Tomasz Figa wrote: On Mon, Jun 13, 2016 at 6:56 PM, Shunqian Zheng wrote: Hi On 2016年06月10日 17:10, Tomasz Figa wrote: Hi, On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng wrote: Use DMA API instead of architecture

Re: [PATCH v2 6/7] iommu/rockchip: use DMA API to map, to flush cache

Hi On 2016年06月10日 17:10, Tomasz Figa wrote: Hi, On Wed, Jun 8, 2016 at 10:26 PM, Shunqian Zheng wrote: Use DMA API instead of architecture internal functions like __cpuc_flush_dcache_area() etc. To support the virtual device like DRM the virtual slave iommu added in

[PATCH] iommu/arm-smmu: request pcie devices to enable ACS

The PCIe ACS capability will affect the layout of iommu groups. Generally speaking, if the path from root port to the PCIe device is ACS enabled, the iommu will create a single iommu group for this PCIe device. If all PCIe devices on the path are ACS enabled then Linux can determine this path is

Re: [E1000-devel] AMD-Vi: Event logged IO_PAGE_FAULT - ixgbe Detected Tx Unit Hang - Reset adapter - master disable timed out

On Thu, Jun 09, 2016 at 09:03:40AM -0700, Alexander Duyck wrote: > >> Jun 9 14:40:09 computer kernel: AMD-Vi: Event logged [IO_PAGE_FAULT > >> device=04:00.0 domain=0x000e address=0x000178c0 flags=0x0050] > >> Jun 9 14:40:09 computer kernel: AMD-Vi: Event logged [IO_PAGE_FAULT > >>

Re: [PATCH] iommu/arm-smmu: wire up map_sg for arm-smmu-v3

On Fri, Jun 03, 2016 at 11:50:30AM +0100, Will Deacon wrote: > From: Jean-Philippe Brucker > > The map_sg callback is missing from arm_smmu_ops, but is required by > iommu.h. Similarly to most other IOMMU drivers, connect it to > default_iommu_map_sg. > > Cc: