RFC Consolidation: move SMP local timers to driver/clocksource
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest0 of 16 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 16 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC PATCH 00/16] Consolidation: move SMP local timers to driver/clocksource
Quoted 15 lines · Marc Zyngier
Quoted 14 lines · Rob Herring
Marc,
Quoted 10 lines · Marc Zyngier
Quoted 2 lines · Rob Herring
Also, device tree support for early platform devices would be useful for this.
What about the attached patch? I've used it to boot a VExpress board with the following DT snippet (and the corresponding support in the
amp_smp_twddriver):localtimer at 2c000600 { device_type = "localtimer";
Quoted 8 lines
Quoted 4 lines
My understanding is
device_typeis only supposed to be used for devices with real OpenFirmware. You could just add localtimer or timer as a 2nd compatible string. I think localtimer is a bit of a Linux name, so just timer may be better.Using "compatible" would not work. You'd have to add the same compatible string to all drivers, and get drivers probing the wrong device. Any other property we could use instead?
No, I'm saying you have a compatible property like this:
compatible = "arm,smp-twd", "timer";
You create the early platform device(s) based on matches with "timer", but match the driver based on "arm,smp-twd".
Quoted 8 lines
As for the "localtimer" string, this is to differentiate the per-cpu timers versus the global timers, and they may need to be probed in a specific order (global first, and then local).
The reason for this is that TWD needs to be calibrated, hence the need for a global timer running. Colin's patch could help getting rid of this restriction though.
Yes, my original patch adding clock api allowed just that.
Rob
Quoted 2 lines
M.