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 -- 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
