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
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
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
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
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 ++
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
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
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
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
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
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
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
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
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
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
+++
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
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
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.
>
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
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
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
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:
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
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
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
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
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
>>
27 matches
Mail list logo