Re: [PATCH v3 7/7] iommu/vt-d: Differentiate relaxable and non relaxable RMRRs

Hi Lu, On 5/17/19 6:46 AM, Lu Baolu wrote: > Hi Eric, > > On 5/16/19 6:08 PM, Eric Auger wrote: >> Now we have a new IOMMU_RESV_DIRECT_RELAXABLE reserved memory >> region type, let's report USB and GFX RMRRs as relaxable ones. >> >> This allows to have a finer reporting at IOMMU API level of >>

Re: [PATCH 2/4] vfio: vfio_iommu_type1: Define VFIO_IOMMU_INFO_CAPABILITIES

On 16/05/2019 20:31, Alex Williamson wrote: On Fri, 10 May 2019 10:22:33 +0200 Pierre Morel wrote: To use the VFIO_IOMMU_GET_INFO to retrieve IOMMU specific information, we define a new flag VFIO_IOMMU_INFO_CAPABILITIES in the vfio_iommu_type1_info structure and the associated capability

Re: [PATCH v3 6/7] iommu: Introduce IOMMU_RESV_DIRECT_RELAXABLE reserved memory regions

Hi Robin, On 5/16/19 7:53 PM, Robin Murphy wrote: > On 16/05/2019 14:23, Auger Eric wrote: >> Hi Robin, >> On 5/16/19 2:46 PM, Robin Murphy wrote: >>> On 16/05/2019 11:08, Eric Auger wrote: Introduce a new type for reserved region. This corresponds to directly mapped regions which are

Re: [PATCH 4/4] vfio: vfio_iommu_type1: implement VFIO_IOMMU_INFO_CAPABILITIES

On 16/05/2019 20:40, Alex Williamson wrote: On Fri, 10 May 2019 10:22:35 +0200 Pierre Morel wrote: We implement a capability intercafe for VFIO_IOMMU_GET_INFO and add the first capability: VFIO_IOMMU_INFO_CAPABILITIES. When calling the ioctl, the user must specify

[PATCH v2 4/4] vfio: vfio_iommu_type1: implement VFIO_IOMMU_INFO_CAPABILITIES

We implement the capability interface for VFIO_IOMMU_GET_INFO. When calling the ioctl, the user must specify VFIO_IOMMU_INFO_CAPABILITIES to retrieve the capabilities and must check in the answer if capabilities are supported. The iommu get_attr callback will be used to retrieve the specific

[PATCH v2 2/4] vfio: vfio_iommu_type1: Define VFIO_IOMMU_INFO_CAPABILITIES

We add a capabilities functionality to VFIO_IOMMU_GET_INFO. This will allow the VFIO_IOMMU_GET_INFO ioctl to retrieve IOMMU specific information. we define a new flag VFIO_IOMMU_INFO_CAPABILITIES in the vfio_iommu_type1_info structure and two Z-PCI specific capabilities: VFIO_IOMMU_INFO_CAP_QFN:

[PATCH v2 3/4] s390: iommu: Adding get attributes for s390_iommu

We add the "get attributes" callback to the S390 iommu operations to retrieve the S390 specific attributes through the call of zPCI dedicated CLP functions. The caller can use the following attributes and retrieve: DOMAIN_ATTR_ZPCI_FN_SIZE: the size of the Z-PCI function attributes

[PATCH v2 0/4] Retrieving zPCI specific info with VFIO

Using the PCI VFIO interface allows userland, a.k.a. QEMU, to retrieve ZPCI specific information without knowing Z specific identifiers like the function ID or the function handle of the zPCI function hidden behind the PCI interface. By using the VFIO_IOMMU_GET_INFO ioctl we enter the

[PATCH v2 1/4] s390: pci: Exporting access to CLP PCI function and PCI group

For the generic implementation of VFIO PCI we need to retrieve the hardware configuration for the PCI functions and the PCI function groups. We modify the internal function using CLP Query PCI function and CLP query PCI function group so that they can be called from outside the S390 architecture

[RFC/PATCH 0/4] Initial support for modular IOMMU drivers

This series adds initial support for being able to use the ARM SMMU driver as a loadable kernel module. The series also adds to the IOMMU framework, so that it can defer probing for devices that depend on an IOMMU driver that may be a loadable module. The primary reason behind these changes is

Re: [PATCH v2 4/4] vfio: vfio_iommu_type1: implement VFIO_IOMMU_INFO_CAPABILITIES

On 17/05/2019 18:41, Alex Williamson wrote: On Fri, 17 May 2019 18:16:50 +0200 Pierre Morel wrote: We implement the capability interface for VFIO_IOMMU_GET_INFO. When calling the ioctl, the user must specify VFIO_IOMMU_INFO_CAPABILITIES to retrieve the capabilities and must check in the

[PATCH v5 1/6] drm: panfrost: add optional bus_clock

Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock. Add an optional bus_clock at the init of the panfrost driver. Signed-off-by: Clément Péron --- drivers/gpu/drm/panfrost/panfrost_device.c | 25 +- drivers/gpu/drm/panfrost/panfrost_device.h | 1 + 2 files

[PATCH v5 3/6] dt-bindings: gpu: add bus clock for Mali Midgard GPUs

From: Icenowy Zheng Some SoCs adds a bus clock gate to the Mali Midgard GPU. Add the binding for the bus clock. Signed-off-by: Icenowy Zheng Signed-off-by: Clément Péron Reviewed-by: Rob Herring --- Documentation/devicetree/bindings/gpu/arm,mali-midgard.txt | 6 ++ 1 file changed, 6

[PATCH v5 0/6] Allwinner H6 Mali GPU support

Hi, The Allwinner H6 has a Mali-T720 MP2 which should be supported by the new panfrost driver. This series fix two issues and introduce the dt-bindings but a simple benchmark show that it's still NOT WORKING. I'm pushing it in case someone want to continue the work. This has been tested with

[PATCH v5 2/6] iommu: io-pgtable: fix sanity check for non 48-bit mali iommu

Allwinner H6 SoC has a Mali T720MP2 with a 33-bit iommu which trig the sanity check during the alloc of the pgtable. Change the sanity check to allow non 48-bit configuration. Suggested-by: Robin Murphy Signed-off-by: Clément Péron --- drivers/iommu/io-pgtable-arm.c | 2 +- 1 file changed, 1

[PATCH v5 4/6] dt-bindings: gpu: mali-midgard: Add H6 mali gpu compatible

This add the H6 mali compatible in the dt-bindings to later support specific implementation. Signed-off-by: Clément Péron Reviewed-by: Rob Herring --- .../devicetree/bindings/gpu/arm,mali-midgard.txt | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git

[PATCH v5 5/6] arm64: dts: allwinner: Add ARM Mali GPU node for H6

Add the mali gpu node to the H6 device-tree. Signed-off-by: Clément Péron --- arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 14 ++ 1 file changed, 14 insertions(+) diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi index

Re: [PATCH v2 4/4] vfio: vfio_iommu_type1: implement VFIO_IOMMU_INFO_CAPABILITIES

On Fri, 17 May 2019 18:16:50 +0200 Pierre Morel wrote: > We implement the capability interface for VFIO_IOMMU_GET_INFO. > > When calling the ioctl, the user must specify > VFIO_IOMMU_INFO_CAPABILITIES to retrieve the capabilities and > must check in the answer if capabilities are supported. >

[RFC/PATCH 4/4] iommu: Add probe deferral support for IOMMU kernel modules

Currently, the IOMMU core assumes that all IOMMU drivers will be built into the kernel. This makes it so that all the IOMMU core will stop deferring probes when all of the builtin kernel drivers have finished probing (i.e. when initcalls are finished). This is problematic if an IOMMU driver is

[RFC/PATCH 2/4] PCI: Export PCI ACS and DMA searching functions to modules

IOMMU drivers that can be compiled as modules may want to use pci_for_each_dma_alias() and pci_request_acs(), so export those functions. Signed-off-by: Isaac J. Manjarres --- drivers/pci/pci.c| 1 + drivers/pci/search.c | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/pci/pci.c

[RFC/PATCH 3/4] iommu: Export core IOMMU functions to kernel modules

IOMMU drivers that can be compiled as modules need to use some of the IOMMU core functions, so expose them. Signed-off-by: Isaac J. Manjarres --- drivers/iommu/iommu-sysfs.c | 3 +++ drivers/iommu/iommu.c | 6 ++ 2 files changed, 9 insertions(+) diff --git

[RFC/PATCH 1/4] of: Export of_phandle_iterator_args() to modules

Kernel modules may want to use of_phandle_iterator_args(), so export it. Signed-off-by: Isaac J. Manjarres --- drivers/of/base.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/of/base.c b/drivers/of/base.c index 20e0e7e..8b9c597 100644 --- a/drivers/of/base.c +++

[PATCH v5 6/6] arm64: dts: allwinner: Add mali GPU supply for H6 boards

Enable and add supply to the Mali GPU node on all the H6 boards. Regarding the datasheet the maximum time for supply to reach its voltage is 32ms. Signed-off-by: Clément Péron --- arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts | 6 ++

Re: [PATCH v5 1/6] drm: panfrost: add optional bus_clock

Hi Rob, On Fri, 17 May 2019 at 22:07, Rob Herring wrote: > > On Fri, May 17, 2019 at 1:47 PM Clément Péron wrote: > > > > Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock. > > > > Add an optional bus_clock at the init of the panfrost driver. > > > > Signed-off-by: Clément Péron

Re: [PATCH v5 1/6] drm: panfrost: add optional bus_clock

On Fri, May 17, 2019 at 1:47 PM Clément Péron wrote: > > Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock. > > Add an optional bus_clock at the init of the panfrost driver. > > Signed-off-by: Clément Péron > --- > drivers/gpu/drm/panfrost/panfrost_device.c | 25

Re: [RFC/PATCH 1/4] of: Export of_phandle_iterator_args() to modules

On Fri, May 17, 2019 at 1:48 PM Isaac J. Manjarres wrote: > > Kernel modules may want to use of_phandle_iterator_args(), > so export it. > > Signed-off-by: Isaac J. Manjarres > --- > drivers/of/base.c | 1 + > 1 file changed, 1 insertion(+) Acked-by: Rob Herring

Re: [PATCH v5 1/6] drm: panfrost: add optional bus_clock

On Fri, May 17, 2019 at 5:08 PM Clément Péron wrote: > > Hi Rob, > > On Fri, 17 May 2019 at 22:07, Rob Herring wrote: > > > > On Fri, May 17, 2019 at 1:47 PM Clément Péron wrote: > > > > > > Allwinner H6 has an ARM Mali-T720 MP2 which required a bus_clock. > > > > > > Add an optional bus_clock