[REPOST PATCH] ARM: gic: allow GIC to support non-banked setups
Marc Zyngier
marc.zyngier at arm.com
Fri Nov 11 11:28:52 EST 2011
On 11/11/11 15:51, Rob Herring wrote:
> On 11/04/2011 10:40 AM, Marc Zyngier wrote:
>> The GIC support code is heavily using the fact that hardware
>> implementations are exposing banked registers. Unfortunately, it
>> looks like at least one GIC implementation (EXYNOS4) offers both
>> the distributor and the CPU interfaces at different addresses,
>> depending on the CPU.
>>
>> This problem is solved by turning the distributor and CPU interface
>> addresses into per-cpu variables. The EXYNOS4 code is updated not
>> to mess with the GIC internals while handling interrupts, and
>> struct gic_chip_data is back to being private.
>>
>> Cc: Kukjin Kim <kgene.kim at samsung.com>
>> Cc: Will Deacon <will.deacon at arm.com>
>> Signed-off-by: Marc Zyngier <marc.zyngier at arm.com>
>> ---
>> I'm reposting this in order to generate some comments on the
>> approach. An alternative has been suggested by Will Deacon,
>> by adding platform specific callbacks returning the base addresses.
>> Both solutions have a runtime impact on "normal" platforms.
>>
> This doesn't really work well for DT as you are adding a place where the
> platform needs to know the register addresses. Perhaps extending the gic
> reg field to an array of cpu and dist addresses. This could all be setup
> by gic_of_init on cpu 0.
Agreed, this isn't very nice. Another possibility would be to encode the
per-cpu offset and provide the GIC with one single massive range, but
this looks very Samsung specific, again.
> It would be nice if everyone else wasn't punished with percpu data
> lookups for the base addresses for 1 weird platform...
That's exactly my problem at the moment. One broken platform is
impacting *all* the others, and I wonder if we wouldn't be better off
with a separate driver altogether...
Thanks for having a look.
M.
--
Jazz is not dead. It just smells funny...
More information about the linux-arm-kernel
mailing list