On Tue, 21 May 2019 17:09:40 +0100
Jean-Philippe Brucker wrote:
> On 20/05/2019 20:22, Jacob Pan wrote:
> > On Thu, 16 May 2019 09:14:29 -0700
> > Jacob Pan wrote:
> >
> >> On Thu, 16 May 2019 15:14:40 +0100
> >> Jean-Philippe Brucker wrote:
> >>
> >>> Hi Jacob,
> >>>
> >>> On 03/05/2019
On Tue, May 21, 2019 at 06:43:34PM +0100, Robin Murphy wrote:
> On 21/05/2019 17:13, Jordan Crouse wrote:
> >Allow IOMMU enabled devices specified on an opt-in list to create a
> >default identity domain for a new IOMMU group and bypass the DMA
> >domain created by the IOMMU core. This allows the
On 21/05/2019 17:13, Jordan Crouse wrote:
Add support for a split pagetable (TTBR0/TTBR1) scheme for arm-smmu-v2.
If split pagetables are enabled, create a pagetable for TTBR1 and set
up the sign extension bit so that all IOVAs with that bit set are mapped
and translated from the TTBR1
On 21/05/2019 17:13, Jordan Crouse wrote:
Allow IOMMU enabled devices specified on an opt-in list to create a
default identity domain for a new IOMMU group and bypass the DMA
domain created by the IOMMU core. This allows the group to be properly
set up but otherwise skips touching the hardware
On 21/05/2019 18:14, Horia Geanta wrote:
Hi,
Is it mandatory for a device to write data in an area DMA mapped
DMA_FROM_DEVICE?
Can't the device just "ignore" that mapping - i.e. not write anything - and
driver should expect original data to be found in that location (since it was
not touched /
Hi,
Is it mandatory for a device to write data in an area DMA mapped
DMA_FROM_DEVICE?
Can't the device just "ignore" that mapping - i.e. not write anything - and
driver should expect original data to be found in that location (since it was
not touched / written to by the device)?
[Let's leave
On Tue, 21 May 2019 11:41:52 +0200
Auger Eric wrote:
> Hi,
>
> On 5/4/19 12:32 AM, Jacob Pan wrote:
> > From: Jean-Philippe Brucker
> >
> > Some devices might support multiple DMA address spaces, in
> > particular those that have the PCI PASID feature. PASID (Process
> > Address Space ID)
On Tue, 21 May 2019 10:21:55 +0200
Auger Eric wrote:
> Hi,
>
> On 5/4/19 12:32 AM, Jacob Pan wrote:
> > From: Jean-Philippe Brucker
> >
> > Some devices might support multiple DMA address spaces, in
> > particular those that have the PCI PASID feature. PASID (Process
> > Address Space ID)
Allow IOMMU enabled devices specified on an opt-in list to create a
default identity domain for a new IOMMU group and bypass the DMA
domain created by the IOMMU core. This allows the group to be properly
set up but otherwise skips touching the hardware until the client
device attaches a unmanaged
Support auxiliary domains for arm-smmu-v2 to initialize and support
multiple pagetables for a single SMMU context bank. Since the smmu-v2
hardware doesn't have any built in support for switching the pagetable
it is left as an exercise to the caller to actually use the pagetable;
aux domains in the
Add an attribute to return the base address of the pagetable. This is used
by auxiliary domains from arm-smmu to return the address of the pagetable
to the leaf driver so that it can set the appropriate pagetable through
it's own means.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h |
Add a new domain attribute to enable split pagetable support for devices
devices that support it.
Signed-off-by: Jordan Crouse
---
include/linux/iommu.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index 4ef8bd5..204acd8 100644
---
Add support for a split pagetable (TTBR0/TTBR1) scheme for arm-smmu-v2.
If split pagetables are enabled, create a pagetable for TTBR1 and set
up the sign extension bit so that all IOVAs with that bit set are mapped
and translated from the TTBR1 pagetable.
Signed-off-by: Jordan Crouse
---
This is a refresh of the per-instance pagetable support for arm-smmu-v2 and the
MSM GPU driver. I think this is pretty mature at this point, so I've dropped the
RFC designation and ask for consideration for 5.3.
Per-instance pagetables allow the target GPU driver to create and manage
an
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
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
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 ++
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
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
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 | 22 ++
drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
2 files
On 20/05/2019 20:22, Jacob Pan wrote:
> On Thu, 16 May 2019 09:14:29 -0700
> Jacob Pan wrote:
>
>> On Thu, 16 May 2019 15:14:40 +0100
>> Jean-Philippe Brucker wrote:
>>
>>> Hi Jacob,
>>>
>>> On 03/05/2019 23:32, Jacob Pan wrote:
+/**
+ * struct gpasid_bind_data - Information about
On 17/05/2019 19:47, Isaac J. Manjarres wrote:
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
Hi Isaac,
On 17/05/2019 19:47, Isaac J. Manjarres wrote:
> 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
On 21/05/2019 16:59, Alex Williamson wrote:
On Tue, 21 May 2019 11:14:38 +0200
Pierre Morel wrote:
On 20/05/2019 20:23, Alex Williamson wrote:
On Mon, 20 May 2019 18:31:08 +0200
Pierre Morel wrote:
On 20/05/2019 16:27, Cornelia Huck wrote:
On Mon, 20 May 2019 13:19:23 +0200
Pierre
On Tue, 21 May 2019 11:14:38 +0200
Pierre Morel wrote:
> On 20/05/2019 20:23, Alex Williamson wrote:
> > On Mon, 20 May 2019 18:31:08 +0200
> > Pierre Morel wrote:
> >
> >> On 20/05/2019 16:27, Cornelia Huck wrote:
> >>> On Mon, 20 May 2019 13:19:23 +0200
> >>> Pierre Morel wrote:
> >>>
On Tue, May 21, 2019 at 02:04:37PM +0100, Russell King - ARM Linux admin wrote:
> So how does the driver negotiation for >32bit addresses work if we don't
> fail for large masks?
>
> I'm thinking about all those PCI drivers that need DAC cycles for >32bit
> addresses, such as e1000, which
On Tue, May 21, 2019 at 02:47:29PM +0200, Christoph Hellwig wrote:
> Since Linux 5.1 we allow drivers to just set the largest DMA mask they
> support instead of falling back to smaller ones.
This doesn't make sense. "they" is confusing - why would a driver set
a DMA mask larger than the driver
On Tue, May 21, 2019 at 02:47:28PM +0200, Christoph Hellwig wrote:
> The dma masks in struct device are always 64-bits wide. But for builds
> using a 32-bit dma_addr_t we need to ensure we don't store an
> unsupportable value. Before Linux 5.0 this was handled at least by
> the ARM dma mapping
On Tue, May 21, 2019 at 02:00:47PM +0100, Russell King - ARM Linux admin wrote:
> On Tue, May 21, 2019 at 02:47:29PM +0200, Christoph Hellwig wrote:
> > Since Linux 5.1 we allow drivers to just set the largest DMA mask they
> > support instead of falling back to smaller ones.
>
> This doesn't
On 20/05/2019 14:59, Zhen Lei wrote:
First, add build option IOMMU_DEFAULT_{LAZY|STRICT}, so that we have the
opportunity to set {lazy|strict} mode as default at build time. Then put
the three config options in an choice, make people can only choose one of
the three at a time.
The default IOMMU
The dma masks in struct device are always 64-bits wide. But for builds
using a 32-bit dma_addr_t we need to ensure we don't store an
unsupportable value. Before Linux 5.0 this was handled at least by
the ARM dma mapping code by never allowing to set a larger dma_mask,
but these days we allow the
Hi all,
in 5.1 I fixed up the DMA mapping API to always accept larger than
required DMA mask. Except that I forgot about a check in the arm
code that is not required any more, and about the case where a
architecture only supports a 32-bit dma mask, but could potentially
generate large addresses
Since Linux 5.1 we allow drivers to just set the largest DMA mask they
support instead of falling back to smaller ones.
When fixing up all the dma ops instances to allow for this behavior
the arm direct mapping code was missed. Fix it up by removing the
sanity check, as all the actual mapping
On 21/05/2019 13:11, Cornelia Huck wrote:
On Tue, 21 May 2019 11:14:38 +0200
Pierre Morel wrote:
1) A short description, of zPCI functions and groups
IN Z, PCI cards, leave behind an adapter between subchannels and PCI.
We access PCI cards through 2 ways:
- dedicated PCI instructions
On Tue, 21 May 2019 11:14:38 +0200
Pierre Morel wrote:
> 1) A short description, of zPCI functions and groups
>
> IN Z, PCI cards, leave behind an adapter between subchannels and PCI.
> We access PCI cards through 2 ways:
> - dedicated PCI instructions (pci_load/pci_store/pci/store_block)
> -
Hi Jacob,
On 5/4/19 12:32 AM, Jacob Pan wrote:
> Sometimes, IOASID allocation must be handled by platform specific
> code. The use cases are guest vIOMMU and pvIOMMU where IOASIDs need
> to be allocated by the host via enlightened or paravirt interfaces.
>
> This patch adds an extension to the
Hi,
On 5/4/19 12:32 AM, Jacob Pan wrote:
> From: Jean-Philippe Brucker
>
> Some devices might support multiple DMA address spaces, in particular
> those that have the PCI PASID feature. PASID (Process Address Space ID)
> allows to share process address spaces with devices (SVA), partition a
>
On 20/05/2019 20:23, Alex Williamson wrote:
On Mon, 20 May 2019 18:31:08 +0200
Pierre Morel wrote:
On 20/05/2019 16:27, Cornelia Huck wrote:
On Mon, 20 May 2019 13:19:23 +0200
Pierre Morel wrote:
On 17/05/2019 20:04, Pierre Morel wrote:
On 17/05/2019 18:41, Alex Williamson wrote:
On
From: Dave Jiang
Lockdep debug reported lock inversion related with the iommu code
caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
the device_domain_lock out of order versus the code path in
iommu_flush_dev_iotlb(). Expanding the scope of the iommu->lock and
reversing the order
The iommu_group_get_for_dev() will allocate a group for a
device if it isn't in any group. This isn't the use case
in iommu_request_dm_for_dev(). Let's use iommu_group_get()
instead.
Fixes: d290f1e70d85a ("iommu: Introduce iommu_request_dm_for_dev()")
Signed-off-by: Lu Baolu
---
41 matches
Mail list logo
