On Fri, 29 Apr 2016 09:43:45 +1000 Simon Horman <horms@xxxxxxxxxxxx> wrote: > [Cc Mark Zyngier, linux-arm-kernel] > > Hi Dirk, > > On Thu, Apr 28, 2016 at 07:41:57AM +0200, Dirk Behme wrote: > > Hi Simon, > > > > On 28.04.2016 01:30, Simon Horman wrote: > > >Hi Dirk, > > > > > >I understand that there is an issue here but I'm not yet able > > >to convince myself that this is the correct solution. > > > > > >In revision r0p1 of the CoreLink GIC-400 Generic Interrupt Controller > > >Technical Reference Manual[1] I see in Section 3.2. "GIC-400 register map" > > >that the size of both the CPU interfaces and Virtual CPU interfaces are > > >0x2000 bytes. And assuming that the hardware follows the specification it > > >appears that DT is correctly describing the hardware. > > > > > > I think you are missing the details described by ARM in > > > > http://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=21550029f709072aacf3b9 > > > > > > Maybe Julien could help if you have some more doubts? > > I guess I am confused. > > I see that there is now handling of the case where the region size is > 128Kbytes. But I'm still not seeing the bit which describes that the > GIC-400 has a region size of 128Kbytes. Perhaps the later is somehow > implied by the former. Or perhaps I need to check with the hw team. Please have a look at the SBSA document, and in particular the Appendix-F (registration and selling your soul required - only kidding): http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0029/index.html This requires that, in order for the two halves of GICV to be trappable *separately* by a hypervisor using 64kB pages at Stage-2, the two 4kB pages that describe that region are aliased as such: - the first 4kB page is aliased 16 times over a 64kB region - the second 4kB page is aliased 16 times over another contiguous 64kB region This means that your GIC is indeed covering a 128kB region, with the mapping corresponding to the GICv2 memory map located at offset 0xf000 from the base of that 128kB region. Also, this GICV requirement also applies to GICC (most likely because the two regions use the same decoding logic). The OS must of course be aware of this (see gic_check_eoimode in the GIC driver). Of course, almost nobody got that right (I only know of the APM Xgene-1 so far). If you actually did, great! Also, the ACPI spec fails to recognize this by not providing the length of the region, meaning that those who got it right with DT are likely to get it wrong with ACPI, and vice-versa. It's a wonderful world. M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
