Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/2] ARM: EXYNOS: Allow to use architected timer
Date: Tue, 06 Oct 2015 11:12:53 +0200	[thread overview]
Message-ID: <5008072.V9UdTVvpUS@wuerfel> (raw)
In-Reply-To: <00d801d10014$e6d994a0$b48cbde0$@samsung.com>

On Tuesday 06 October 2015 11:56:33 Pavel Fedin wrote:
>  Hello!
> 
> > IIRC the use of the CP15 timer is not reliable on this platform.
> > I don't have a link ready, but this has come up a few times.
> 
>  I know that Samsung SoC guys are not very keen on this, therefore i actually made this optional. If
> you want, you could omit the second patch, and by default Exynos platform will use MCT. But if
> someone wants to use KVM, it would be enough only to modify device tree in order to enable CP15.
> Would this be a good compromise?
> 
> > Regarding KVM usage, would it be possible to emulate the architected
> > timer from qemu instead?
> 
>  Unfortunately no. Accesses to virtual timer registers cannot be trapped. It is possible to trap
> physical timer accesses, and trick the kernel into using it, but it's slow, and it is a different
> story, which you can read here: http://www.spinics.net/lists/kvm/msg121714.html.
>  So, i think that having an option to use CP15 would be a good solution.

My feeling is that is shouldn't be keyed off the presence of the device in DT
though. Maybe we can find a way that allows you to put the device into DT
but not have it used by default unless the user explicitly enables it, e.g. though
a kernel command line option like "force_broken_archtimer"?

Or maybe we could find a way to keep using MCT in the host but use the
arch timer in the guest only? At least that would not potentially break
anything that works today.

> It is known to work, and i use this configuration here on SMDK5410 without any problems.

For all I can tell, nobody every /saw/ the problem, we just know that it
hasn't passed verification (or something like that) and you shouldn't
use it in production.

	Arnd

  reply	other threads:[~2015-10-06  9:12 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-06  8:23 [PATCH 0/2] ARM: EXYNOS: Allow to use architected timer Pavel Fedin
2015-10-06  8:23 ` [PATCH 1/2] exynos_mct: Allow to use architected timer mode Pavel Fedin
2015-10-06  8:24 ` [PATCH 2/2] ARM: dts: Use architected timer on Exynos 5410 Pavel Fedin
2015-10-06  8:33   ` Chanwoo Choi
2015-10-06  8:49     ` Pavel Fedin
2015-10-06  8:37 ` [PATCH 0/2] ARM: EXYNOS: Allow to use architected timer Arnd Bergmann
2015-10-06  8:51   ` Alexey Klimov
2015-10-06  8:56   ` Pavel Fedin
2015-10-06  9:12     ` Arnd Bergmann [this message]
2015-10-06  9:44       ` Pavel Fedin
2015-10-06 10:03         ` Arnd Bergmann
2015-10-06 10:09     ` Kukjin Kim
2015-10-06 10:16       ` Pavel Fedin
2015-10-06 10:25       ` Kukjin Kim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5008072.V9UdTVvpUS@wuerfel \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox