From: Timur Tabi <timur-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
To: Will Deacon <will.deacon-5wv7dgnIgG8@public.gmane.org>,
Fu Wei <fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "Rafael J. Wysocki" <rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org>,
Len Brown <lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
Daniel Lezcano
<daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
Marc Zyngier <marc.zyngier-5wv7dgnIgG8@public.gmane.org>,
Lorenzo Pieralisi
<lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org>,
Sudeep Holla <sudeep.holla-5wv7dgnIgG8@public.gmane.org>,
Hanjun Guo <hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Linaro ACPI Mailman List
<linaro-acpi-cunTk1MwBs8s++Sfvej+rw@public.gmane.org>,
Linux Kernel Mailing List
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
ACPI Devel Maling List
<linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
rruigrok-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
harba-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org,
Christopher Covington
<cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
G Gregory
<graeme.gregory-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Al Stone <al.stone-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Jon Masters <jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
wei-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
Wim Van Sebroeck <wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.org>,
Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>,
Suravee Suthikulpanit <Suravee.Suthikulpanit@a>
Subject: Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT
Date: Tue, 26 Jul 2016 09:11:49 -0500 [thread overview]
Message-ID: <57976FA5.2070802@codeaurora.org> (raw)
In-Reply-To: <20160725163144.GE19209-5wv7dgnIgG8@public.gmane.org>
Will Deacon wrote:
> The kernel really needs to support both of those platforms :/
>
> For the memory-mapped counter registers, the architecture says:
>
> `If the implementation supports 64-bit atomic accesses, then the
> CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>
> which is borderline tautological. If we take the generous reading that
> this means AArch64 CPUs can use readq (and I'm not completely
> comfortable with that assertion, particularly as you say that it breaks
> the model), then you still need to use readq_relaxed here to avoid a
> DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> exist over there, and if you use the generic implementation then it's
> not atomic. In which case, we end up with the current code, as well as a
> readq_relaxed guarded by a questionable #ifdef that is known to break a
> supported platform for an unknown performance improvement. Hardly a big
> win.
I know Fu dropped this patch, and I don't want to kick a dead horse, but
I was wondering if it would be okay to do this:
static u64 arch_counter_get_cntvct_mem(void)
{
#ifdef readq_relaxed
return readq_relaxed(arch_counter_base + CNTVCT_LO);
#else
u32 vct_lo, vct_hi, tmp_hi;
do {
vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
} while (vct_hi != tmp_hi);
return ((u64) vct_hi << 32) | vct_lo;
#endif
}
readq and readq_relaxed are defined in arch/arm64/include/asm/io.h. Why
would the function exist if AArch64 CPUs can't use it?
Do we need something like ARCH_HAS_64BIT_ATOMIC_READ in order to decide
whether readq is safe?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-watchdog" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Timur Tabi <timur@codeaurora.org>
To: Will Deacon <will.deacon@arm.com>, Fu Wei <fu.wei@linaro.org>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Thomas Gleixner <tglx@linutronix.de>,
Marc Zyngier <marc.zyngier@arm.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Hanjun Guo <hanjun.guo@linaro.org>,
linux-arm-kernel@lists.infradead.org,
Linaro ACPI Mailman List <linaro-acpi@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
rruigrok@codeaurora.org, harba@codeaurora.org,
Christopher Covington <cov@codeaurora.org>,
G Gregory <graeme.gregory@linaro.org>,
Al Stone <al.stone@linaro.org>, Jon Masters <jcm@redhat.com>,
wei@redhat.com, Arnd Bergmann <arnd@arndb.de>,
Wim Van Sebroeck <wim@iguana.be>,
Catalin Marinas <catalin.marinas@arm.com>,
Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>,
Leo Duran <leo.duran@amd.com>, Guenter Roeck <linux@roeck-us.net>,
linux-watchdog@vger.kernel.org
Subject: Re: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT
Date: Tue, 26 Jul 2016 09:11:49 -0500 [thread overview]
Message-ID: <57976FA5.2070802@codeaurora.org> (raw)
In-Reply-To: <20160725163144.GE19209@arm.com>
Will Deacon wrote:
> The kernel really needs to support both of those platforms :/
>
> For the memory-mapped counter registers, the architecture says:
>
> `If the implementation supports 64-bit atomic accesses, then the
> CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>
> which is borderline tautological. If we take the generous reading that
> this means AArch64 CPUs can use readq (and I'm not completely
> comfortable with that assertion, particularly as you say that it breaks
> the model), then you still need to use readq_relaxed here to avoid a
> DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> exist over there, and if you use the generic implementation then it's
> not atomic. In which case, we end up with the current code, as well as a
> readq_relaxed guarded by a questionable #ifdef that is known to break a
> supported platform for an unknown performance improvement. Hardly a big
> win.
I know Fu dropped this patch, and I don't want to kick a dead horse, but
I was wondering if it would be okay to do this:
static u64 arch_counter_get_cntvct_mem(void)
{
#ifdef readq_relaxed
return readq_relaxed(arch_counter_base + CNTVCT_LO);
#else
u32 vct_lo, vct_hi, tmp_hi;
do {
vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
} while (vct_hi != tmp_hi);
return ((u64) vct_hi << 32) | vct_lo;
#endif
}
readq and readq_relaxed are defined in arch/arm64/include/asm/io.h. Why
would the function exist if AArch64 CPUs can't use it?
Do we need something like ARCH_HAS_64BIT_ATOMIC_READ in order to decide
whether readq is safe?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
WARNING: multiple messages have this Message-ID (diff)
From: timur@codeaurora.org (Timur Tabi)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT
Date: Tue, 26 Jul 2016 09:11:49 -0500 [thread overview]
Message-ID: <57976FA5.2070802@codeaurora.org> (raw)
In-Reply-To: <20160725163144.GE19209@arm.com>
Will Deacon wrote:
> The kernel really needs to support both of those platforms :/
>
> For the memory-mapped counter registers, the architecture says:
>
> `If the implementation supports 64-bit atomic accesses, then the
> CNTV_CVAL register must be accessible as an atomic 64-bit value.'
>
> which is borderline tautological. If we take the generous reading that
> this means AArch64 CPUs can use readq (and I'm not completely
> comfortable with that assertion, particularly as you say that it breaks
> the model), then you still need to use readq_relaxed here to avoid a
> DSB. Furthermore, what are you going to do for AArch32? readq doesn't
> exist over there, and if you use the generic implementation then it's
> not atomic. In which case, we end up with the current code, as well as a
> readq_relaxed guarded by a questionable #ifdef that is known to break a
> supported platform for an unknown performance improvement. Hardly a big
> win.
I know Fu dropped this patch, and I don't want to kick a dead horse, but
I was wondering if it would be okay to do this:
static u64 arch_counter_get_cntvct_mem(void)
{
#ifdef readq_relaxed
return readq_relaxed(arch_counter_base + CNTVCT_LO);
#else
u32 vct_lo, vct_hi, tmp_hi;
do {
vct_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
vct_lo = readl_relaxed(arch_counter_base + CNTVCT_LO);
tmp_hi = readl_relaxed(arch_counter_base + CNTVCT_HI);
} while (vct_hi != tmp_hi);
return ((u64) vct_hi << 32) | vct_lo;
#endif
}
readq and readq_relaxed are defined in arch/arm64/include/asm/io.h. Why
would the function exist if AArch64 CPUs can't use it?
Do we need something like ARCH_HAS_64BIT_ATOMIC_READ in order to decide
whether readq is safe?
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
next prev parent reply other threads:[~2016-07-26 14:11 UTC|newest]
Thread overview: 69+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-25 15:26 [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer fu.wei
2016-07-25 15:26 ` fu.wei at linaro.org
2016-07-25 15:27 ` [PATCH v9 2/9] clocksource/drivers/arm_arch_timer: Add a new enum for spi type fu.wei
2016-07-25 15:27 ` fu.wei at linaro.org
[not found] ` <1469460427-8643-1-git-send-email-fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-07-25 15:26 ` [PATCH v9 1/9] clocksource/drivers/arm_arch_timer: Move enums and defines to header file fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:26 ` fu.wei at linaro.org
2016-07-25 15:26 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 3/9] clocksource/drivers/arm_arch_timer: Improve printk relevant code fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 5/9] acpi/arm64: Add GTDT table parse driver fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
[not found] ` <1469460427-8643-6-git-send-email-fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2016-07-26 11:50 ` Rafael J. Wysocki
2016-07-26 11:50 ` Rafael J. Wysocki
2016-07-26 11:50 ` Rafael J. Wysocki
[not found] ` <1754781.CC9jSrYt2s-sKB8Sp2ER+y1GS7QM15AGw@public.gmane.org>
2016-07-26 12:40 ` Fu Wei
2016-07-26 12:40 ` Fu Wei
2016-07-26 12:40 ` Fu Wei
2016-07-25 15:27 ` [PATCH v9 6/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 7/9] acpi/arm64: Add memory-mapped timer support in GTDT driver fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 8/9] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 9/9] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver fu.wei-QSEj5FYQhm4dnm+yROfE0A
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:27 ` fu.wei
2016-07-25 15:27 ` [PATCH v9 4/9] clocksource/drivers/arm_arch_timer: use readq to get 64-bit CNTVCT fu.wei
2016-07-25 15:27 ` fu.wei at linaro.org
2016-07-25 15:31 ` Will Deacon
2016-07-25 15:31 ` Will Deacon
[not found] ` <20160725153118.GD19209-5wv7dgnIgG8@public.gmane.org>
2016-07-25 15:50 ` Timur Tabi
2016-07-25 15:50 ` Timur Tabi
2016-07-25 15:50 ` Timur Tabi
2016-07-25 15:55 ` Fu Wei
2016-07-25 15:55 ` Fu Wei
2016-07-25 15:55 ` Fu Wei
[not found] ` <CADyBb7ubKceQiB7+u7sSA=1+9_VMUrGjiabf_FkN2-n4rq7Kgg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-07-25 16:31 ` Will Deacon
2016-07-25 16:31 ` Will Deacon
2016-07-25 16:31 ` Will Deacon
[not found] ` <20160725163144.GE19209-5wv7dgnIgG8@public.gmane.org>
2016-07-25 22:49 ` Russell King - ARM Linux
2016-07-25 22:49 ` Russell King - ARM Linux
2016-07-25 22:49 ` Russell King - ARM Linux
2016-07-26 9:21 ` Fu Wei
2016-07-26 9:21 ` Fu Wei
2016-07-26 9:21 ` Fu Wei
2016-07-26 14:11 ` Timur Tabi [this message]
2016-07-26 14:11 ` Timur Tabi
2016-07-26 14:11 ` Timur Tabi
2016-07-27 3:33 ` Jisheng Zhang
2016-07-27 3:33 ` Jisheng Zhang
2016-07-27 3:33 ` Jisheng Zhang
2016-07-27 4:19 ` Fu Wei
2016-07-27 4:19 ` Fu Wei
2016-07-27 4:19 ` Fu Wei
2016-07-28 13:53 ` Will Deacon
2016-07-28 13:53 ` Will Deacon
2016-07-28 13:53 ` Will Deacon
2016-08-09 11:03 ` [PATCH v9 0/9] acpi, clocksource: add GTDT driver and GTDT support in arm_arch_timer Tomasz Nowicki
2016-08-09 11:03 ` Tomasz Nowicki
[not found] ` <7c11cca2-1eaa-a4fb-a44b-cdb36ea99ae9-nYOzD4b6Jr9Wk0Htik3J/w@public.gmane.org>
2016-08-09 18:12 ` Fu Wei
2016-08-09 18:12 ` Fu Wei
2016-08-09 18:12 ` Fu Wei
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=57976FA5.2070802@codeaurora.org \
--to=timur-sgv2jx0feol9jmxxk+q4oq@public.gmane.org \
--cc=Suravee.Suthikulpanit@a \
--cc=al.stone-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=catalin.marinas-5wv7dgnIgG8@public.gmane.org \
--cc=cov-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=daniel.lezcano-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=fu.wei-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=graeme.gregory-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=hanjun.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=harba-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=jcm-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=lenb-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=linaro-acpi-cunTk1MwBs8s++Sfvej+rw@public.gmane.org \
--cc=linux-acpi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=lorenzo.pieralisi-5wv7dgnIgG8@public.gmane.org \
--cc=marc.zyngier-5wv7dgnIgG8@public.gmane.org \
--cc=rjw-LthD3rsA81gm4RdzfppkhA@public.gmane.org \
--cc=rruigrok-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org \
--cc=sudeep.holla-5wv7dgnIgG8@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=wei-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=will.deacon-5wv7dgnIgG8@public.gmane.org \
--cc=wim-IQzOog9fTRqzQB+pC5nmwQ@public.gmane.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 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.