Re: [PATCH 03/12] irqchip: gic: define register_routable_domain_ops conditional

[Stefan Agner <stefan@agner.ch>]

On 2014-12-04 14:42, Marc Zyngier wrote:
> On 04/12/14 13:35, Stefan Agner wrote:
>> On 2014-12-03 20:04, Marc Zyngier wrote:
>> <snip>
>>>> What do you mean by the shared state in the drawing above? Currently, I
>>>> check whether a interrupt is already used by the other core by reading
>>>> the register (do this configuration register reflect the "shared state"
>>>> in your drawing?).
>>>
>>> I think that is basically it. It should only be the register that
>>> decides on the actual routing. BTW, how do you arbitrate between
>>> concurrent accesses to this register? Or is only the A5 allowed to
>>> change it?
>>
>> No arbitration so far... The whole Vybrid on M4 stuff is quite a hack
>> right now. For instance also the concurrent access to the clock
>> registers is not handled. Currently, I start the M4 from a booted A5
>> Linux. To avoid half of the clocks get turned of by the M4 clock driver,
>> I need to specify clk_ignore_unused. Beside that, peripherals have to be
>> enabled/disabled in a non conflicting manor in the device trees...
>>
>> For the interrupt router in MSCM, it would be nice if the access could
>> be done an atomic way, which would avoid the use of a lock mechanism.
>> But I guess this is not possible, since peripherals only support
>> standard ldr/str...?
>>
>> There is the SEMA4 module which provides hardware semaphores. I'm aware
>> of the hardware spinlock drivers (drivers/hwspinlock/), I started to
>> implement such a driver for Vybrid. But so far a grep through the kernel
>> does not show one usage of that framework... I guess we could add dt
>> support for that, so we can assign the locks to individual drivers.
>>
>> I also plan to have a deeper look into remoteproc/rpmsg, not sure if
>> locking of shared peripherals is part (or planned to be part) of that
>> framework.
>>
>> For the clock stuff, the problem is more complex: I guess the would need
>> some kind of master/slave definition, where we disallow the change of
>> the shared clocks for the slave.
>>
>> If you are aware of patches/solutions, I'm happy to hear it...
> 
> I don't have a real solution for this, but I'd be tempted to generate
> the M4 DT based on the HW the A5 is not using, and only describe that.
> 
> Clearly not ideal, but it gives you the control you need (don't describe
> the HW you don't want to see touched)...
> 

Yeah, that avoids the need for any synchronization for those
peripherals.

However, for some hardware (e.g. clocks and that interrupt controller)
both sides need access... I guess to do it properly, I need to take care
of it...

--
Stefan