diff mbox

[v2,2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48

Message ID 148517162908.13306.2467186615655446796.sendpatchset@little-apple (mailing list archive)
State Superseded
Delegated to: Geert Uytterhoeven
Headers show

Commit Message

Magnus Damm Jan. 23, 2017, 11:40 a.m. UTC 
From: Magnus Damm <damm+renesas@opensource.se>

Bump up the maximum numbers of micro-TLBS to 48.

Each IPMMU device instance get micro-TLB assignment via
the "iommus" property in DT. Older SoCs tend to use a
maximum number of 32 micro-TLBs per IPMMU instance however
newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.

At this point no SoC specific handling is done to validate
the maximum number of micro-TLBs, and because of that the
DT information is assumed to be within correct range for
each particular SoC.

If needed in the future SoC specific feature flags can be
added to handle the maximum number of micro-TLBs without
requiring DT changes, however at this point this does not
seem necessary.

Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
---

 Changes since V1:
 - Added support for the second I/O range at 0x600.

 drivers/iommu/ipmmu-vmsa.c |   10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

Comments

Geert Uytterhoeven Jan. 23, 2017, 12:42 p.m. UTC | #1 
Hi Magnus,

On Mon, Jan 23, 2017 at 12:40 PM, Magnus Damm <magnus.damm@gmail.com> wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Bump up the maximum numbers of micro-TLBS to 48.
>
> Each IPMMU device instance get micro-TLB assignment via
> the "iommus" property in DT. Older SoCs tend to use a
> maximum number of 32 micro-TLBs per IPMMU instance however
> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
>
> At this point no SoC specific handling is done to validate
> the maximum number of micro-TLBs, and because of that the
> DT information is assumed to be within correct range for
> each particular SoC.
>
> If needed in the future SoC specific feature flags can be
> added to handle the maximum number of micro-TLBs without
> requiring DT changes, however at this point this does not
> seem necessary.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>

Thanks for your patch!

Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>

> @@ -1141,7 +1145,7 @@ static int ipmmu_probe(struct platform_d
>         }
>
>         mmu->dev = &pdev->dev;
> -       mmu->num_utlbs = 32;
> +       mmu->num_utlbs = 48;

This value is only used to validate the utlb channel numbers received from DT,
in ipmmu_init_platform_device(), right?

>         spin_lock_init(&mmu->lock);
>         bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
>         mmu->features = match->data;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds
Joerg Roedel Jan. 27, 2017, 11:47 a.m. UTC | #2 
On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
> 
> Bump up the maximum numbers of micro-TLBS to 48.
> 
> Each IPMMU device instance get micro-TLB assignment via
> the "iommus" property in DT. Older SoCs tend to use a
> maximum number of 32 micro-TLBs per IPMMU instance however
> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
> 
> At this point no SoC specific handling is done to validate
> the maximum number of micro-TLBs, and because of that the
> DT information is assumed to be within correct range for
> each particular SoC.
> 
> If needed in the future SoC specific feature flags can be
> added to handle the maximum number of micro-TLBs without
> requiring DT changes, however at this point this does not
> seem necessary.
> 
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>

I get a conflict when applying this to v4.10-rc5. What is this based on,
any patches I missed?


	Joerg
Magnus Damm Jan. 30, 2017, 10:16 p.m. UTC | #3 
Hi Joerg,

On Fri, Jan 27, 2017 at 8:47 PM, Joerg Roedel <joro@8bytes.org> wrote:
> On Mon, Jan 23, 2017 at 08:40:29PM +0900, Magnus Damm wrote:
>> From: Magnus Damm <damm+renesas@opensource.se>
>>
>> Bump up the maximum numbers of micro-TLBS to 48.
>>
>> Each IPMMU device instance get micro-TLB assignment via
>> the "iommus" property in DT. Older SoCs tend to use a
>> maximum number of 32 micro-TLBs per IPMMU instance however
>> newer SoCs such as r8a7796 make use of up to 48 micro-TLBs.
>>
>> At this point no SoC specific handling is done to validate
>> the maximum number of micro-TLBs, and because of that the
>> DT information is assumed to be within correct range for
>> each particular SoC.
>>
>> If needed in the future SoC specific feature flags can be
>> added to handle the maximum number of micro-TLBs without
>> requiring DT changes, however at this point this does not
>> seem necessary.
>>
>> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
>
> I get a conflict when applying this to v4.10-rc5. What is this based on,
> any patches I missed?

Thanks for giving it a go. The second patch in this series should apply as-is:
[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding

However for driver code there are two series in between:
 [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6
 [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2

For more detailed dependency information please see the cover letter!

Regarding the driver code please wait for "IPMMU multi-arch update V7"
that takes comments from Laurent into consideration. Hopefully I
should be able to send it out some time this week.

As for "[PATCH v2 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding",
would it be possible to fast track mainline merge of that particular
DT binding patch? Can you take it in your tree?

To give some background, we already have the IPMMU DT binding for
older devices and the sister device r8a7795 in mainline, so the
r8a7796 DT binding is just a small incremental step. To make sure we
don't go too wild with DT changes we tend to require that the DT
binding change should be queued up before starting to merge changes to
DTS files. So currently some DT changes are blocking on that r8a7796
DT binding and it would be nice to unblock those if possible..

Thanks!

/ magnus
diff mbox

Patch

--- 0008/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c	2017-01-23 19:22:54.150607110 +0900
@@ -214,7 +214,9 @@  static void set_archdata(struct device *
 #define IMPMBA(n)			(0x0280 + ((n) * 4))
 #define IMPMBD(n)			(0x02c0 + ((n) * 4))
 
-#define IMUCTR(n)			(0x0300 + ((n) * 16))
+#define IMUCTR(n)			(n) < 32 ? IMUCTR0(n) : IMUCTR32(n)
+#define IMUCTR0(n)			(0x0300 + ((n) * 16))
+#define IMUCTR32(n)			(0x0600 + (((n) - 32) * 16))
 #define IMUCTR_FIXADDEN			(1 << 31)
 #define IMUCTR_FIXADD_MASK		(0xff << 16)
 #define IMUCTR_FIXADD_SHIFT		16
@@ -224,7 +226,9 @@  static void set_archdata(struct device *
 #define IMUCTR_FLUSH			(1 << 1)
 #define IMUCTR_MMUEN			(1 << 0)
 
-#define IMUASID(n)			(0x0308 + ((n) * 16))
+#define IMUASID(n)			(n) < 32 ? IMUASID0(n) : IMUASID32(n)
+#define IMUASID0(n)			(0x0308 + ((n) * 16))
+#define IMUASID32(n)			(0x0608 + (((n) - 32) * 16))
 #define IMUASID_ASID8_MASK		(0xff << 8)
 #define IMUASID_ASID8_SHIFT		8
 #define IMUASID_ASID0_MASK		(0xff << 0)
@@ -1141,7 +1145,7 @@  static int ipmmu_probe(struct platform_d
 	}
 
 	mmu->dev = &pdev->dev;
-	mmu->num_utlbs = 32;
+	mmu->num_utlbs = 48;
 	spin_lock_init(&mmu->lock);
 	bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
 	mmu->features = match->data;