Re: [PATCH 4/5] ARM: shmobile: r8a7791: Add IPMMU DT nodes

[Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>]

Hi Ben,

On Monday 31 March 2014 15:30:00 Ben Dooks wrote:
> On 31/03/14 15:01, Laurent Pinchart wrote:
> > On Monday 31 March 2014 10:52:28 Geert Uytterhoeven wrote:
> >> On Sat, Mar 29, 2014 at 12:36 AM, Laurent Pinchart wrote:
> >>> +       ipmmu_sy0: mmu@e6280800 {
> >>> +               compatible = "renesas,ipmmu-vmsa";
> >>> +               reg = <0 0xe6280800 0 0x800>;
> >> 
> >> Shouldn't this be "reg = <0 0xe6280000 0 0x1000>", i.e. expose both
> >> banks?
> >> 
> >> Is there any specific reason you're using the second bank of registers?
> >> These may read as zero, depending on the SoC mode.
> > 
> > That's a very good question, and I have no clear answer. According to the
> > datasheet the second bank of registers is an alias for the non-secure
> > IPMMU registers. It looks like we're running in secure mode (that's what I
> > assume the "CPU: All CPU(s) started in SVC mode." kernel log message
> > means), and the secure IPMMU didn't seem to be functional when I've tested
> > it.
> > 
> > This requires more investigation, but I'm not familiar with secure mode,
> > and the IPMMU documentation is really sparse in that area.
> 
> The default for the R8A7790 is to start in secure-svc mode.

I've tried to boot in non-secure mode by modifying MD5 (DIP switch SW10), but 
it doesn't seem to have any influence.

> I would test it in non-secure SVC but the security framework we are using
> blocks access to the IPMMU blocks :/

I assume that the reason why I have to program the IPMMU non-secure page table 
is that the memory requests coming from the DU are considered as non-secure. 
That's just a guess though. Without a detailed description of how the hardware 
is supposed to work I can't improve the code and DT bindings.

-- 
Regards,

Laurent Pinchart