On Mon, Jan 30, 2017 at 03:52:09PM +0000, Mark Rutland wrote: > Hi Daniel, > > On Tue, Jan 24, 2017 at 05:35:51PM +0100, Daniel Lezcano wrote: > > That wasn't my point. The way the errata are handled in this patchset is > > elegant and I have nothing against it. I'm worried about the accumulation of > > fixes, hacks, workarounds in this driver. So my naive question is about not > > using an identified bogus clocksource and use another one available on the > > board, which is I believe often the case, instead of trying to deal with bogus > > hardware. Apparently, that is not possible because 1) of KVM, 2) of duplication > > and 3) of integration with the ARM64 code. > > > > Does it mean it is not possible to use another clocksource/clockevent than the > > armv8-timer ? > > > > Can you elaborate these three points ? > > Practically speaking, these platforms have no other clocksource or > clockevent device that I am aware of, which can be enumerated in a > standard manner using ACPI. > > For point 1, KVM is intimately familiar with the architected timer > (which is managed during VM context switch in hyp code, for example). > KVM knows nothing of other clocksource or clockevent devices, and it is > far from trivial to plumb these in either way. Since the architected > timer is a mandatory part of ARMv8, guests may attempt to use it > regardless. > > For point 3, arm64 currently requires the architected timer as this is > mandatory per the ARMv8 architecture. It is non-trivial to add support > for other devices to the vDSO, the delay loop, etc. Ok, thanks for these clarifications. > Localising these quirks to the architected timer driver is by far the > least worst option available. Marc and I are perfectly happy to manage > that. It is up to me to ensure the clockevent/clocksource drivers in general are following the right direction. And this driver looks more and more opaque. I will spend some times to do a review of the driver as soon as I have time. So we finish the reviews of this series, you take the patches when I ack them up, but from this point, any submission for this driver will have to stick to the standard submission rules, that is to say: Thomas Gleixner and I have to be recipients of the patches and go through our tree. Dependency issues with other patchset must be solved before applying them in another tree. Thanks. -- Daniel -- <http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook | <http://twitter.com/#!/linaroorg> Twitter | <http://www.linaro.org/linaro-blog/> Blog -- 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
