All of lore.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	iommu@lists.linux-foundation.org
Cc: Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: [PATCH 10/10] ARM: shmobile: r8a7791: Add IPMMU DT nodes
Date: Tue, 16 Dec 2014 13:47:53 +0200	[thread overview]
Message-ID: <11086003.zET0ejo4os@avalon> (raw)
In-Reply-To: <CAMuHMdWnOgN+rmDTo7S+o3AS2hyjgzKEza0vuUYnWz7CbksfSA@mail.gmail.com>

Hi Geert,

On Tuesday 16 December 2014 11:02:03 Geert Uytterhoeven wrote:
> On Mon, Dec 15, 2014 at 7:44 PM, Laurent Pinchart wrote:
> > On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
> >> On Mon, Dec 15, 2014 at 1:13 AM, Laurent Pinchart wrote:
> >> > Add the seven IPMMU instances found in the r8a7791 to DT with a
> >> > disabled status.
> >> > 
> >> > Signed-off-by: Laurent Pinchart
> >> > <laurent.pinchart+renesas@ideasonboard.com>
> >> 
> >> The addresses and interrupt numbers look OK to me.
> >> However, my comment about the "0x800" offset is still valid.
> >> Shouldn't we have two register blocks, and let the driver use only the
> >> second one?
> >> 
> >> If you ignore, feel free to add my
> >> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > 
> > I don't want to ignore your comment, but I don't know what to do here :-/
> > The datasheet lacks detailed information about secure vs. non-secure mode
> > and how the two register sets are supposed to interoperate and be handled
> > by the operating system.
> 
> When in doubt, the safest thing to do is "describe the hardware in DT".
> 
> The datasheet says there are two register sets of size 0x800, so IMHO we
> should have both in DT. Whether the driver only uses the second bank due to
> our limited understanding of the hardware is something different. We can
> still fix the driver later, if needed. Fixing the DT is, ... well...
> complicated ;-)

According to the datasheet there are two register sets sharing the same base 
address, banked through secure mode. There's additionally an alias at a 
different base address for non-secure registers access when running in secure 
mode. The hardware description thus depends on whether we're running in secure 
or non-secure mode, which doesn't play nicely with DT.

Additionally, I've tried to disable secure mode at boot time to test non-
secure mode at the base address, but it didn't seem to make any difference. I 
might have done something wrong though.

For these reasons I don't really like the idea of having two resources for 
secure and non-secure mode. Extending the single resource to cover the base 
address and the aliases should be fine though, I'll give it a go.

> Following the rule "describe the hardware in DT", I would also add the
> second interrupt (marked "SEC") for the DS0, MX, SY0, and GP IPMMU
> instances.

Agreed, I'll do that.

-- 
Regards,

Laurent Pinchart


WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>,
	iommu@lists.linux-foundation.org
Cc: Linux-sh list <linux-sh@vger.kernel.org>
Subject: Re: [PATCH 10/10] ARM: shmobile: r8a7791: Add IPMMU DT nodes
Date: Tue, 16 Dec 2014 11:47:53 +0000	[thread overview]
Message-ID: <11086003.zET0ejo4os@avalon> (raw)
In-Reply-To: <CAMuHMdWnOgN+rmDTo7S+o3AS2hyjgzKEza0vuUYnWz7CbksfSA@mail.gmail.com>

Hi Geert,

On Tuesday 16 December 2014 11:02:03 Geert Uytterhoeven wrote:
> On Mon, Dec 15, 2014 at 7:44 PM, Laurent Pinchart wrote:
> > On Monday 15 December 2014 14:07:52 Geert Uytterhoeven wrote:
> >> On Mon, Dec 15, 2014 at 1:13 AM, Laurent Pinchart wrote:
> >> > Add the seven IPMMU instances found in the r8a7791 to DT with a
> >> > disabled status.
> >> > 
> >> > Signed-off-by: Laurent Pinchart
> >> > <laurent.pinchart+renesas@ideasonboard.com>
> >> 
> >> The addresses and interrupt numbers look OK to me.
> >> However, my comment about the "0x800" offset is still valid.
> >> Shouldn't we have two register blocks, and let the driver use only the
> >> second one?
> >> 
> >> If you ignore, feel free to add my
> >> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > 
> > I don't want to ignore your comment, but I don't know what to do here :-/
> > The datasheet lacks detailed information about secure vs. non-secure mode
> > and how the two register sets are supposed to interoperate and be handled
> > by the operating system.
> 
> When in doubt, the safest thing to do is "describe the hardware in DT".
> 
> The datasheet says there are two register sets of size 0x800, so IMHO we
> should have both in DT. Whether the driver only uses the second bank due to
> our limited understanding of the hardware is something different. We can
> still fix the driver later, if needed. Fixing the DT is, ... well...
> complicated ;-)

According to the datasheet there are two register sets sharing the same base 
address, banked through secure mode. There's additionally an alias at a 
different base address for non-secure registers access when running in secure 
mode. The hardware description thus depends on whether we're running in secure 
or non-secure mode, which doesn't play nicely with DT.

Additionally, I've tried to disable secure mode at boot time to test non-
secure mode at the base address, but it didn't seem to make any difference. I 
might have done something wrong though.

For these reasons I don't really like the idea of having two resources for 
secure and non-secure mode. Extending the single resource to cover the base 
address and the aliases should be fine though, I'll give it a go.

> Following the rule "describe the hardware in DT", I would also add the
> second interrupt (marked "SEC") for the DS0, MX, SY0, and GP IPMMU
> instances.

Agreed, I'll do that.

-- 
Regards,

Laurent Pinchart


  reply	other threads:[~2014-12-16 11:47 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15  0:13 [PATCH 00/10] Renesas IPMMU-VMSA fixes and DT support Laurent Pinchart
2014-12-15  0:13 ` Laurent Pinchart
     [not found] ` <1418602429-11276-1-git-send-email-laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
2014-12-15  0:13   ` [PATCH 01/10] iommu/ipmmu-vmsa: Cleanup failures of ARM mapping creation or attachment Laurent Pinchart
2014-12-15  0:13     ` Laurent Pinchart
2014-12-15  0:13   ` [PATCH 04/10] iommu/ipmmu-vmsa: Return proper error if devm_request_irq fails Laurent Pinchart
2014-12-15  0:13     ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 02/10] iommu/ipmmu-vmsa: Flush P[UM]D entry before freeing the child page table Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 03/10] iommu/ipmmu-vmsa: Invalidate TLB after unmapping Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 05/10] iommu/ipmmu-vmsa: Add device tree bindings documentation Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 06/10] iommu/ipmmu-vmsa: Add device tree support Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 07/10] iommu/ipmmu-vmsa: Support multiple micro TLBs per device Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 08/10] iommu/ipmmu-vmsa: Remove platform data support Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 09/10] ARM: shmobile: r8a7790: Add IPMMU DT nodes Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15  0:13 ` [PATCH 10/10] ARM: shmobile: r8a7791: " Laurent Pinchart
2014-12-15  0:13   ` Laurent Pinchart
2014-12-15 13:07   ` Geert Uytterhoeven
2014-12-15 13:07     ` Geert Uytterhoeven
     [not found]     ` <CAMuHMdWtkk=Q=Mfcyz03LBzXMuBOr8BZGNyCsQb9bwDty-4OiQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-12-15 18:44       ` Laurent Pinchart
2014-12-15 18:44         ` Laurent Pinchart
2014-12-15 22:44         ` Magnus Damm
2014-12-15 22:44           ` Magnus Damm
2014-12-15 23:16           ` Laurent Pinchart
2014-12-15 23:16             ` Laurent Pinchart
2014-12-16 11:54             ` Magnus Damm
2014-12-16 11:54               ` Magnus Damm
2014-12-16 10:02         ` Geert Uytterhoeven
2014-12-16 10:02           ` Geert Uytterhoeven
2014-12-16 11:47           ` Laurent Pinchart [this message]
2014-12-16 11:47             ` Laurent Pinchart

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11086003.zET0ejo4os@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=geert@linux-m68k.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.