Skip to contentSkip to conversation

iommu/io-pgtable-arm: Mali LPAE improvements

PATCH Superseded Robin Murphy 5 participants 13 messages Sep 11, 2019 – Sep 23, 2019

Subsystems (2)
IOMMU Arm SMMU drivers

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore

Robin Murphy

author reviewer
#0 lore raw

cover iommu/io-pgtable-arm: Mali LPAE improvements

Hi all,

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

 drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 13 deletions(-)
Signature · 6 lines
2.21.0.dirty

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
author reviewer
#1 lore raw

PATCH 1/3 iommu/io-pgtable-arm: Correct Mali attributes

Whilst Midgard's MEMATTR follows a similar principle to the VMSA MAIR, the actual attribute values differ, so although it currently appears to work to some degree, we probably shouldn't be using our standard stage 1 MAIR for that. Instead, generate a reasonable MEMATTR with attribute values borrowed from the kbase driver; at this point we'll be overriding or ignoring pretty much all of the LPAE config, so just implement these Mali details in a dedicated allocator instead of pretending to subclass the standard VMSA format.

Signed-off-by Robin Murphy <[email protected]>
---
 drivers/iommu/io-pgtable-arm.c | 53 +++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 13 deletions(-)
drivers/iommu/io-pgtable-arm.c +40 -13
index 161a7d56264d..9e35cd991f06 100644
@@ -167,6 +167,9 @@
 #define ARM_MALI_LPAE_TTBR_READ_INNER	BIT(2)
 #define ARM_MALI_LPAE_TTBR_SHARE_OUTER	BIT(4)
 
+#define ARM_MALI_LPAE_MEMATTR_IMP_DEF	0x88ULL
+#define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
+
 /* IOPTE accessors */
 #define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
 

@@ -1013,27 +1016,51 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
 static struct io_pgtable *
 arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 {
-	struct io_pgtable *iop;
+	struct arm_lpae_io_pgtable *data;
+
+	/* No quirks for Mali (hopefully) */
+	if (cfg->quirks)
+		return NULL;
 
 	if (cfg->ias != 48 || cfg->oas > 40)
 		return NULL;
 
 	cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
-	iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
-	if (iop) {
-		u64 mair, ttbr;
 
-		/* Copy values as union fields overlap */
-		mair = cfg->arm_lpae_s1_cfg.mair[0];
-		ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
+	data = arm_lpae_alloc_pgtable(cfg);
+	if (!data)
+		return NULL;
 
-		cfg->arm_mali_lpae_cfg.memattr = mair;
-		cfg->arm_mali_lpae_cfg.transtab = ttbr |
-			ARM_MALI_LPAE_TTBR_READ_INNER |
-			ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
-	}
+	/*
+	 * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
+	 * best we can do is mimic the out-of-tree driver and hope that the
+	 * "implementation-defined caching policy" is good enough. Similarly,
+	 * we'll use it for the sake of a valid attribute for our 'device'
+	 * index, although callers should never request that in practice.
+	 */
+	cfg->arm_mali_lpae_cfg.memattr =
+		(ARM_MALI_LPAE_MEMATTR_IMP_DEF
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_NC)) |
+		(ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_CACHE)) |
+		(ARM_MALI_LPAE_MEMATTR_IMP_DEF
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
 
-	return iop;
+	data->pgd = __arm_lpae_alloc_pages(data->pgd_size, GFP_KERNEL, cfg);
+	if (!data->pgd)
+		goto out_free_data;
+
+	/* Ensure the empty pgd is visible before TRANSTAB can be written */
+	wmb();
+
+	cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
+					  ARM_MALI_LPAE_TTBR_READ_INNER |
+					  ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+	return &data->iop;
+
+out_free_data:
+	kfree(data);
+	return NULL;
 }
 
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
Signature · 6 lines
2.21.0.dirty

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Reviewed-by on v1 1/3
#2 lore raw

Re: [PATCH 1/3] iommu/io-pgtable-arm: Correct Mali attributes

Quoted 10 lines · Robin Murphy

Whilst Midgard's MEMATTR follows a similar principle to the VMSA MAIR, the actual attribute values differ, so although it currently appears to work to some degree, we probably shouldn't be using our standard stage 1 MAIR for that. Instead, generate a reasonable MEMATTR with attribute values borrowed from the kbase driver; at this point we'll be overriding or ignoring pretty much all of the LPAE config, so just implement these Mali details in a dedicated allocator instead of pretending to subclass the standard VMSA format.

Signed-off-by Robin Murphy <[email protected]>

The Midgard MMU "uses concepts" from LPAE but really isn't LPAE, so this seems like a good tidy up.

Reviewed-by Steven Price <[email protected]>

Steve

Quoted 74 lines
---
 drivers/iommu/io-pgtable-arm.c | 53 +++++++++++++++++++++++++---------
 1 file changed, 40 insertions(+), 13 deletions(-)
drivers/iommu/io-pgtable-arm.c +33 -13
index 161a7d56264d..9e35cd991f06 100644
@@ -167,6 +167,9 @@
 #define ARM_MALI_LPAE_TTBR_READ_INNER	BIT(2)
 #define ARM_MALI_LPAE_TTBR_SHARE_OUTER	BIT(4)
 
+#define ARM_MALI_LPAE_MEMATTR_IMP_DEF	0x88ULL
+#define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
+
 /* IOPTE accessors */
 #define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
 

@@ -1013,27 +1016,51 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
 static struct io_pgtable *
 arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 {
-	struct io_pgtable *iop;
+	struct arm_lpae_io_pgtable *data;
+
+	/* No quirks for Mali (hopefully) */
+	if (cfg->quirks)
+		return NULL;
 
 	if (cfg->ias != 48 || cfg->oas > 40)
 		return NULL;
 
 	cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
-	iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
-	if (iop) {
-		u64 mair, ttbr;
 
-		/* Copy values as union fields overlap */
-		mair = cfg->arm_lpae_s1_cfg.mair[0];
-		ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
+	data = arm_lpae_alloc_pgtable(cfg);
+	if (!data)
+		return NULL;
 
-		cfg->arm_mali_lpae_cfg.memattr = mair;
-		cfg->arm_mali_lpae_cfg.transtab = ttbr |
-			ARM_MALI_LPAE_TTBR_READ_INNER |
-			ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
-	}
+	/*
+	 * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
+	 * best we can do is mimic the out-of-tree driver and hope that the
+	 * "implementation-defined caching policy" is good enough. Similarly,
+	 * we'll use it for the sake of a valid attribute for our 'device'
+	 * index, although callers should never request that in practice.
+	 */
+	cfg->arm_mali_lpae_cfg.memattr =
+		(ARM_MALI_LPAE_MEMATTR_IMP_DEF
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_NC)) |
+		(ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_CACHE)) |
+		(ARM_MALI_LPAE_MEMATTR_IMP_DEF
+		 << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
 
-	return iop;
+	data->pgd = __arm_lpae_alloc_pages(data->pgd_size, GFP_KERNEL, cfg);
+	if (!data->pgd)
+		goto out_free_data;
+
+	/* Ensure the empty pgd is visible before TRANSTAB can be written */
+	wmb();
+
+	cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |

drivers/iommu/io-pgtable-arm.c arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie) · line 1066

Quoted 10 lines
drivers/iommu/io-pgtable-arm.c +7 -0
+					  ARM_MALI_LPAE_TTBR_READ_INNER |
+					  ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+	return &data->iop;
+
+out_free_data:
+	kfree(data);
+	return NULL;
 }
 
 struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

author reviewer
#3 lore raw

PATCH 2/3 iommu/io-pgtable-arm: Support more Mali configurations

In reply to Robin Murphy

In principle, Midgard GPUs supporting smaller VA sizes should only require 3-level pagetables, since the address bits resolved at level 0 (47:40) will never change. However, the kbase driver does not appear to have any notion of a variable start level, and empirically T720 and T820 rapidly blow up with translation faults unless given a full 4-level table, despite only supporting a 33-bit VA size.

The 'real' IAS value is still valuable in terms of validating addresses on map/unmap, so tweak the allocator to allow smaller values while still forcing the resultant tables to the full 4 levels.

Signed-off-by Robin Murphy <[email protected]>
---
 drivers/iommu/io-pgtable-arm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/iommu/io-pgtable-arm.c +6 -1
index 9e35cd991f06..77f41c9dd9be 100644
@@ -1022,7 +1022,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	if (cfg->quirks)
 		return NULL;
 
-	if (cfg->ias != 48 || cfg->oas > 40)
+	if (cfg->ias > 48 || cfg->oas > 40)
 		return NULL;
 
 	cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);

@@ -1031,6 +1031,11 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	if (!data)
 		return NULL;
 
+	/* Mali seems to need a full 4-level table regardless of IAS */
+	if (data->levels < ARM_LPAE_MAX_LEVELS) {
+		data->levels = ARM_LPAE_MAX_LEVELS;
+		data->pgd_size = sizeof(arm_lpae_iopte);
+	}
 	/*
 	 * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
 	 * best we can do is mimic the out-of-tree driver and hope that the
Signature · 6 lines
2.21.0.dirty

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Reviewed-by on v1 2/3
#4 lore raw

Re: [PATCH 2/3] iommu/io-pgtable-arm: Support more Mali configurations

Quoted 6 lines · Robin Murphy

In principle, Midgard GPUs supporting smaller VA sizes should only require 3-level pagetables, since the address bits resolved at level 0 (47:40) will never change. However, the kbase driver does not appear to have any notion of a variable start level, and empirically T720 and T820 rapidly blow up with translation faults unless given a full 4-level table, despite only supporting a 33-bit VA size.

Midgard 'LPAE' isn't really LPAE and does indeed always require all levels of page tables. The 33-bit VA size is really only limiting the storage of virtual addresses in the GPU and not affecting the MMU.

Quoted 5 lines

The 'real' IAS value is still valuable in terms of validating addresses on map/unmap, so tweak the allocator to allow smaller values while still forcing the resultant tables to the full 4 levels.

Signed-off-by Robin Murphy <[email protected]>
Reviewed-by Steven Price <[email protected]>

Steve

Quoted 20 lines
---
 drivers/iommu/io-pgtable-arm.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)
drivers/iommu/io-pgtable-arm.c +1 -1
index 9e35cd991f06..77f41c9dd9be 100644
@@ -1022,7 +1022,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	if (cfg->quirks)
 		return NULL;
 
-	if (cfg->ias != 48 || cfg->oas > 40)
+	if (cfg->ias > 48 || cfg->oas > 40)
 		return NULL;
 
 	cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);

@@ -1031,6 +1031,11 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	if (!data)

drivers/iommu/io-pgtable-arm.c arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) · line 1041

Quoted 10 lines
drivers/iommu/io-pgtable-arm.c +5 -0
 		return NULL;
 
+	/* Mali seems to need a full 4-level table regardless of IAS */
+	if (data->levels < ARM_LPAE_MAX_LEVELS) {
+		data->levels = ARM_LPAE_MAX_LEVELS;
+		data->pgd_size = sizeof(arm_lpae_iopte);
+	}
 	/*
 	 * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
 	 * best we can do is mimic the out-of-tree driver and hope that the

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

author reviewer
#5 lore raw

PATCH 3/3 iommu/io-pgtable-arm: Allow coherent walks for Mali

In reply to Robin Murphy

Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and it will only emit snoop signals for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely.

Making data accesses coherent seems to be more of a challenge...

Signed-off-by Robin Murphy <[email protected]>
---
 drivers/iommu/io-pgtable-arm.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/iommu/io-pgtable-arm.c +3 -0
index 77f41c9dd9be..2794d4661339 100644
@@ -1061,6 +1061,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
 					  ARM_MALI_LPAE_TTBR_READ_INNER |
 					  ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+	if (cfg->coherent_walk)
+		cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER;
+
 	return &data->iop;
 
 out_free_data:
Signature · 6 lines
2.21.0.dirty

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Reviewed-by on v1 3/3
#6 lore raw

Re: [PATCH 3/3] iommu/io-pgtable-arm: Allow coherent walks for Mali

Quoted 10 lines · Robin Murphy

Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and it will only emit snoop signals for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely.

Making data accesses coherent seems to be more of a challenge...

Signed-off-by Robin Murphy <[email protected]>
Reviewed-by Steven Price <[email protected]>

Note the terminology in the GPU is *very* confusing here. Midgard refers to the system's inner shareable domain as "outer shareable", and uses "inner shareable" to mean purely within the GPU.

For data access kbase sets up a different default MEMATTR if ACE is available:

	/* Set to implementation defined, outer caching */
	#define AS_MEMATTR_LPAE_OUTER_IMPL_DEF        0x88ull
[...]
	#define AS_MEMATTR_INDEX_DEFAULT_ACE           3
[...]
	/* Outer coherent, inner implementation defined policy */
	#define AS_MEMATTR_INDEX_OUTER_IMPL_DEF        3

Steve

Quoted 10 lines
---
 drivers/iommu/io-pgtable-arm.c | 3 +++
 1 file changed, 3 insertions(+)
drivers/iommu/io-pgtable-arm.c +0 -0
index 77f41c9dd9be..2794d4661339 100644

drivers/iommu/io-pgtable-arm.c arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie) · line 1069

Quoted 9 lines
drivers/iommu/io-pgtable-arm.c +3 -0
@@ -1061,6 +1061,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
 	cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
 					  ARM_MALI_LPAE_TTBR_READ_INNER |
 					  ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
+	if (cfg->coherent_walk)
+		cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER;
+
 	return &data->iop;
 
 out_free_data:

_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

Tested-by on the v1 series
#7 lore raw
In reply to Robin Murphy

Hi,

Quoted 10 lines · Robin Murphy

Hi all,

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Quoted 8 lines

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

 drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 13 deletions(-)
Tested-by Neil Armstrong <[email protected]>

On Khadas VIM2 (Amlogic S912) with T820 Mali GPU

I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !

Thanks for pushing this,
Neil
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

maintainer
#8 lore raw
Quoted 18 lines · Neil Armstrong
Quoted 8 lines · Robin Murphy

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Quoted 8 lines

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

 drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
 1 file changed, 48 insertions(+), 13 deletions(-)
Quoted 5 lines
Tested-by Neil Armstrong <[email protected]>

On Khadas VIM2 (Amlogic S912) with T820 Mali GPU

I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !

Not a chance -- the merge window opens on Monday and -next isn't being rolled out at the moment due to LPC. Let's shoot for 5.5 and get this queued up in a few weeks.

Will
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

author reviewer
#9 lore raw
Quoted 21 lines · Will Deacon
Quoted 20 lines · Neil Armstrong
Quoted 8 lines · Robin Murphy

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Quoted 8 lines

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

  drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
  1 file changed, 48 insertions(+), 13 deletions(-)
Tested-by Neil Armstrong <[email protected]>
Quoted 7 lines
Quoted 3 lines

On Khadas VIM2 (Amlogic S912) with T820 Mali GPU

I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !

Not a chance -- the merge window opens on Monday and -next isn't being rolled out at the moment due to LPC. Let's shoot for 5.5 and get this queued up in a few weeks.

Fair enough, that was certainly more extreme optimism than realistic expectation on my part :)

There is some argument for taking #1 and #2 as 5.4 fixes, though - the upcoming Mesa 19.2 release will enable T820 support on the userspace side - so let's pick that discussion up again in a few weeks.

Robin.

(And at worst, I guess we could carry the "cfg.ias = 48" workaround in the DRM driver for the 5.4 cycle if need be)
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

maintainer
#10 lore raw
Quoted 30 lines · Robin Murphy
Quoted 21 lines · Will Deacon
Quoted 20 lines · Neil Armstrong
Quoted 8 lines · Robin Murphy

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Quoted 8 lines

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

  drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
  1 file changed, 48 insertions(+), 13 deletions(-)
Tested-by Neil Armstrong <[email protected]>
Quoted 7 lines
Quoted 3 lines

On Khadas VIM2 (Amlogic S912) with T820 Mali GPU

I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !

Not a chance -- the merge window opens on Monday and -next isn't being rolled out at the moment due to LPC. Let's shoot for 5.5 and get this queued up in a few weeks.

Quoted 6 lines

Fair enough, that was certainly more extreme optimism than realistic expectation on my part :)

There is some argument for taking #1 and #2 as 5.4 fixes, though - the upcoming Mesa 19.2 release will enable T820 support on the userspace side - so let's pick that discussion up again in a few weeks.

Ok, I'll include those two in my fixes pull to Joerg at -rc1.

Will
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

#11 lore raw
Quoted 32 lines · Will Deacon
Quoted 30 lines · Robin Murphy
Quoted 28 lines · Will Deacon
Quoted 18 lines · Neil Armstrong
Quoted 8 lines · Robin Murphy

Here's the eagerly-awaited fix to unblock T720/T820, plus a couple of other bits that I've collected so far. I'm not considering this as 5.3 fixes material, but it would be nice if there's any chance still to sneak it into 5.4.

Robin.

Quoted 8 lines

Robin Murphy (3):
iommu/io-pgtable-arm: Correct Mali attributes iommu/io-pgtable-arm: Support more Mali configurations iommu/io-pgtable-arm: Allow coherent walks for Mali

  drivers/iommu/io-pgtable-arm.c | 61 ++++++++++++++++++++++++++--------
  1 file changed, 48 insertions(+), 13 deletions(-)
Quoted 5 lines
Tested-by Neil Armstrong <[email protected]>

On Khadas VIM2 (Amlogic S912) with T820 Mali GPU

I hope this will be part of v5.4 so we can run panfrost on vanilla v5.4 !

Not a chance -- the merge window opens on Monday and -next isn't being rolled out at the moment due to LPC. Let's shoot for 5.5 and get this queued up in a few weeks.

Quoted 8 lines
Quoted 6 lines

Fair enough, that was certainly more extreme optimism than realistic expectation on my part :)

There is some argument for taking #1 and #2 as 5.4 fixes, though - the upcoming Mesa 19.2 release will enable T820 support on the userspace side - so let's pick that discussion up again in a few weeks.

Ok, I'll include those two in my fixes pull to Joerg at -rc1.

Hi Will,

Looks like this didn't end up happening?

Thanks,

Tomeu
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu

author reviewer
#12 lore raw

Hi Tomeu,

Quoted 9 lines · Tomeu Vizoso
Quoted 5 lines
Quoted 3 lines

There is some argument for taking #1 and #2 as 5.4 fixes, though - the upcoming Mesa 19.2 release will enable T820 support on the userspace side - so let's pick that discussion up again in a few weeks.

Ok, I'll include those two in my fixes pull to Joerg at -rc1.

Hi Will,

Looks like this didn't end up happening?

Don't panic, there's still another week until rc1 is even out to base a PR on ;)

FWIW I was planning to rebase and resend these with the review tags included early next week, once the dust has settled and queues are opening again.

Robin.
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu