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:

quoted

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