Hello Dirk, On Sun, Jul 02, 2017 at 07:48:41AM +0200, Dirk Behme wrote: > > On my machine (Udoo Neo, A9 + M4) the A9 is the primary CPU that is > > started by the bootrom. If I want the M4 being the primary device I'd > > need support in the bootloader to wait long enough (i.e. until the M4 is > > up) before letting the A9 jump into Linux. Managable I'd say. This way > > would even make sense if the M4 runs a rt critical OS that shouldn't be > > forced to wait on the non-rt A9 to enable a clk. > > > Overall, assuming that the issue we are discussing here can be solved quite > easily in hardware (a set of clock registers for each CPU/OS domain, > connected cleverly to effectively control each clock, with access protection > for each set of registers) I tend to think that for a SoC supposed to run > different OS on different cores this is a missing hardware feature (bug?). So you want to enable bits for your CAN clock, one in each cpu's domain. I'd say that is a nice idea that a hardware engineer might be proud to pick up but that results in more headache than fun for the software colleague. There are several problems that come immediately to mind: - You can switch of a clk because you don't need it on, or because you need it off. I guess you want to have the clock on if at least one cpu wants it on. So you take away the freedom from the other cpu to force the clock off. (Yeah, the currently available clk framework doesn't allow that either.) - What if cpu 0 sets the parent of the can clk to pll2 but cpu 1 wants it set to pll1? How does cpu 1 notice the change? - On off might be relatively easy, what about clk dividers? cpu 0 sets 2 which cpu 1 sets 6. That convinces me that the disadvantages of having two views on the clk core have more weight and you really want a single view and share that by software. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ | -- 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
