From: Marc Zyngier <maz@kernel.org>
To: Chanho Park <chanho61.park@samsung.com>
Cc: 'Mark Rutland' <mark.rutland@arm.com>,
'Thomas Gleixner' <tglx@linutronix.de>,
'Daniel Lezcano' <daniel.lezcano@linaro.org>,
linux-arm-kernel@lists.infradead.org,
'Chanho Park' <parkch98@gmail.com>
Subject: Re: [PATCH] clocksource/drivers/arm_arch_timer: export arch_timer_get_rate
Date: Wed, 13 Jan 2021 10:06:34 +0000 [thread overview]
Message-ID: <5621b8a1fd75c4aaecd91663bda67fe6@kernel.org> (raw)
In-Reply-To: <00ba01d6e992$611fa850$235ef8f0$@samsung.com>
On 2021-01-13 09:56, Chanho Park wrote:
> Hi Marc,
[...]
>> Well, you can compare the raw counter values, and do the conversion in
>> a
>> single place. Also, if your system is correctly configured, you have
>> access to CNTFRQ_EL0, which contains the same thing as
>> arch_timer_get_rate().
>
> To convert the value in the single place, we may need to use inter-VM
> communication so that it makes quite complex design/implementation for
> me.
> Regarding CNTFRQ_EL0, I already tried to read it by
> arch_timer_get_cntfrq
> but I got '0'. It looks like different according to the system.
That's a bug in your firmware that you should consider fixing.
The architecture and the arm64 boot protocol are pretty explicit
that CNTFRQ_EL0 must contain the frequency of the timer, and be
initialised on all CPUs. You are probably using some DT property
to advertise the frequency, which is very much discouraged.
>>
>> >> So this symbol is probably used by a module *inside* the VMs, and
>> >> Mark's question still stands.
>> >>
>> >
>> > Yes. Actually, we use this timestamp for our internal module which is
>> > not yet upstreamed.
>>
>> If the module code is not upstream, I don't see the point in exporting
>> this symbol. I suggest you post both as a series so that we can decide
>> whether that is a good idea or not.
>
> Well, I'm not sure the module can be upstream because it's definitely
> necessary only to analyze a panic in my hypervisor system. Let me find
> a
> better way to expose this.
If your module doesn't make sense in the upstream kernel, then exporting
the symbol doesn't make much sense either.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2021-01-13 10:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-12 1:31 [PATCH] clocksource/drivers/arm_arch_timer: export arch_timer_get_rate Chanho Park
2021-01-12 10:12 ` Mark Rutland
2021-01-12 13:39 ` Chanho Park
2021-01-12 14:45 ` Marc Zyngier
2021-01-12 15:14 ` Chanho Park
2021-01-12 15:30 ` Marc Zyngier
2021-01-13 9:56 ` Chanho Park
2021-01-13 10:06 ` Marc Zyngier [this message]
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=5621b8a1fd75c4aaecd91663bda67fe6@kernel.org \
--to=maz@kernel.org \
--cc=chanho61.park@samsung.com \
--cc=daniel.lezcano@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=parkch98@gmail.com \
--cc=tglx@linutronix.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.