On Tue, 2015-09-29 at 17:21 +0100, Julien Grall wrote:
> We are currently using a per-platform quirk to know if the 2 4KB region
> of
> the GIC CPU interface are each aligned to 64KB. Although, it may be
> possible to have different layout on a same platform (depending on the
> firmware version).
> 
> Rather than having a quirk it's possible to detect by reading the GIC
> memory. This patch is based from the Linux commit "irqchip/GIC: Add
> workaround
> for aliased GIC400" [1].
> 
> Take the opportunity to clean up the GICv2 of code which was only
> required because of the quirk.
> 
> Note that none of the platform using the gic-hip04 were actually using
> the quirk, so the code has been dropped. I will let the maintainers
> decide whether it's relevant or not to add proper detection for aliased
> GIC for this hardware.
> 
> [1] commit 12e14066f4835f5ee1ca795f0309415b54c067a9
>     Author: Marc Zyngier <marc.zyng...@arm.com>
>     Date:   Sun Sep 13 12:14:31 2015 +0100
> 
>     irqchip/GIC: Add workaround for aliased GIC400
> 
>     The GICv2 architecture mandates that the two 4kB GIC regions are
>     contiguous, and on two separate physical pages (so that access to
>     the second page can be trapped by a hypervisor). This doesn't work
>     very well when PAGE_SIZE is 64kB.
> 
>     A relatively common hack^Wway to work around this is to alias each
>     4kB region over its own 64kB page. Of course in this case, the base
>     address you want to use is not really the begining of the region,
>     but base + 60kB (so that you get a contiguous 8kB region over two
>     distinct pages).
> 
>     Normally, this would be described in DT with a new property, but
>     some HW is already out there, and the firmware makes sure that
>     it will override whatever you put in the GIC node. Duh. And of
> course,
>     said firmware source code is not available, despite being based
>     on u-boot.
> 
>     The workaround is to detect the case where the CPU interface size
>     is set to 128kB, and verify the aliasing by checking that the ID
>     register for GIC400 (which is the only GIC wired this way so far)
>     is the same at base and base + 0xF000. In this case, we update
>     the GIC base address and let it roll.
> 
>     And if you feel slightly sick by looking at this, rest assured that
>     I do too...
> 
>     Reported-by: Julien Grall <julien.gr...@citrix.com>
>     Signed-off-by: Marc Zyngier <marc.zyng...@arm.com>
>     Cc: linux-arm-ker...@lists.infradead.org
>     Cc: Stuart Yoder <stuart.yo...@freescale.com>
>     Cc: Pavel Fedin <p.fe...@samsung.com>
>     Cc: Jason Cooper <ja...@lakedaemon.net>
>     Link: http://lkml.kernel.org/r/1442142873-20213-2-git-send-email-marc
> .zyng...@arm.com
>     Signed-off-by: Thomas Gleixner <t...@linutronix.de>
> 
> Signed-off-by: Julien Grall <julien.gr...@citrix.com>

Acked-by: Ian Campbell <ian.campb...@citrix.com>


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Reply via email to