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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).