From: thomas.petazzoni@free-electrons.com (Thomas Petazzoni)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 02/14] ARM: mvebu: ll_set_cpu_coherent no more uses the coherency address as parameter
Date: Mon, 14 Oct 2013 16:20:41 +0200 [thread overview]
Message-ID: <20131014162041.185d797a@skate> (raw)
In-Reply-To: <1381759106-15004-3-git-send-email-gregory.clement@free-electrons.com>
Dear Gregory CLEMENT,
On Mon, 14 Oct 2013 15:58:14 +0200, Gregory CLEMENT wrote:
> Until now the calling functions of ll_set_cpu_coherent() have to know
> the base address of the coherency registers. This commit doesn't
> expose anymore this address, and replace the argument by a flag to
> indicate if we have to use the physical or the virtual address.
Why is this necessary? Passing the base address (either physical or
virtual) seems much better than the boolean you're introducing.
The title of the commit is also badly worded I believe, "no more uses"
is not a really great way of expressing what it is doing. It should
probably be:
ARM: mvebu: make ll_set_cpu_coherent use a boolean to choose coherency fabric address
Nonetheless, a few comments below.
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/mach-mvebu/coherency.c | 6 +++---
> arch/arm/mach-mvebu/coherency_ll.S | 18 +++++++++++++++++-
> arch/arm/mach-mvebu/headsmp.S | 10 ++--------
> 3 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/mach-mvebu/coherency.c b/arch/arm/mach-mvebu/coherency.c
> index 58adf2f..d492fb3 100644
> --- a/arch/arm/mach-mvebu/coherency.c
> +++ b/arch/arm/mach-mvebu/coherency.c
> @@ -29,7 +29,7 @@
> #include "armada-370-xp.h"
>
> unsigned long coherency_phys_base;
> -static void __iomem *coherency_base;
> +void __iomem *coherency_base;
> static void __iomem *coherency_cpu_base;
>
> /* Coherency fabric registers */
> @@ -43,7 +43,7 @@ static struct of_device_id of_coherency_table[] = {
> };
>
> /* Function defined in coherency_ll.S */
> -int ll_set_cpu_coherent(void __iomem *base_addr, unsigned int hw_cpu_id);
> +int ll_set_cpu_coherent(bool use_virt_addr, unsigned int hw_cpu_id);
>
> int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> {
> @@ -53,7 +53,7 @@ int set_cpu_coherent(unsigned int hw_cpu_id, int smp_group_id)
> return 1;
> }
>
> - return ll_set_cpu_coherent(coherency_base, hw_cpu_id);
> + return ll_set_cpu_coherent(true, hw_cpu_id);
> }
>
> static inline void mvebu_hwcc_sync_io_barrier(void)
> diff --git a/arch/arm/mach-mvebu/coherency_ll.S b/arch/arm/mach-mvebu/coherency_ll.S
> index 5476669..8d4e22f 100644
> --- a/arch/arm/mach-mvebu/coherency_ll.S
> +++ b/arch/arm/mach-mvebu/coherency_ll.S
> @@ -22,10 +22,22 @@
>
> .text
> /*
> - * r0: Coherency fabric base register address
> + * r0: if r0==0 => physical addres, else virtual address
address, not addres. Also, which address are we talking about?
* r0: if r0 equal 0, then the function will use access the coherency
fabric through its physical address (to be used when the MMU is
disabled). Otherwise, the virtual address at which the coherency
fabric has been mapped will be used (to be used when the MMU is
enabled).
But I still complain that the original solution of passing the address
was better. If you really have a strong explanation to switch to this
boolean, then don't use a boolean at all: test if the MMU is enabled,
and if not, use the physical address automatically, otherwise, use the
virtual address automatically.
> * r1: HW CPU id
> */
> ENTRY(ll_set_cpu_coherent)
> + cmp r0, #0
> + bne 1f
> + /* use physical address */
Bad indentation for the comment: it should be one tab and not spaces,
not match the other code around.
> + adr r0, 3f
> + ldr r3, [r0]
> + ldr r0, [r0, r3]
> + b 2f
> +1:
> + /* use virtual address */
Same comment for the indentation.
> + ldr r0, =(coherency_base)
Are the parenthesis needed?
> + ldr r0, [r0]
> +2:
> /* Create bit by cpu index */
> mov r3, #(1 << 24)
> lsl r1, r3, r1
> @@ -53,3 +65,7 @@ ENTRY(ll_set_cpu_coherent)
> mov r0, #0
> mov pc, lr
> ENDPROC(ll_set_cpu_coherent)
> +
> + .align 2
> +3:
> + .long coherency_phys_base - .
> diff --git a/arch/arm/mach-mvebu/headsmp.S b/arch/arm/mach-mvebu/headsmp.S
> index 8a1b0c9..bffaabc 100644
> --- a/arch/arm/mach-mvebu/headsmp.S
> +++ b/arch/arm/mach-mvebu/headsmp.S
> @@ -27,10 +27,8 @@
> * startup
> */
> ENTRY(armada_xp_secondary_startup)
> - /* Get coherency fabric base physical address */
> - adr r0, 1f
> - ldr r1, [r0]
> - ldr r0, [r0, r1]
> + /* Use physical addrss */
addrss -> address. Please pay attention to typos, there are such typos
everywhere.
Also, address of what?
> + mov r0, #0
>
> /* Read CPU id */
> mrc p15, 0, r1, c0, c0, 5
> @@ -41,7 +39,3 @@ ENTRY(armada_xp_secondary_startup)
> b secondary_startup
>
> ENDPROC(armada_xp_secondary_startup)
> -
> - .align 2
> -1:
> - .long coherency_phys_base - .
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2013-10-14 14:20 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-14 13:58 [PATCH v3 00/14] CPU idle for Armada XP Gregory CLEMENT
2013-10-14 13:58 ` [PATCH v3 01/14] ARM: PJ4B: Add cpu_suspend/cpu_resume hooks for PJ4B Gregory CLEMENT
2013-10-14 13:58 ` [PATCH v3 02/14] ARM: mvebu: ll_set_cpu_coherent no more uses the coherency address as parameter Gregory CLEMENT
2013-10-14 14:20 ` Thomas Petazzoni [this message]
2013-10-14 13:58 ` [PATCH v3 03/14] ARM: mvebu: ll_set_cpu_coherent always uses the current CPU Gregory CLEMENT
2013-10-14 14:22 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 04/14] ARM: mvebu: Remove the unused argument of set_cpu_coherent() Gregory CLEMENT
2013-10-14 14:23 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 05/14] ARM: mvebu: Make ll_set_cpu_coherent() more configurable Gregory CLEMENT
2013-10-14 14:26 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 06/14] ARM: mvebu: Low level functions to disable cache snooping Gregory CLEMENT
2013-10-14 14:32 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 07/14] ARM: mvebu: Add a new set of registers for pmsu Gregory CLEMENT
2013-10-14 14:34 ` Thomas Petazzoni
2013-10-14 14:36 ` Jason Cooper
2013-10-14 13:58 ` [PATCH v3 08/14] ARM: mvebu: Allow to power down L2 cache controller in idle mode Gregory CLEMENT
2013-10-14 14:44 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 09/14] ARM: mvebu: Add the PMSU related part of the cpu idle functions Gregory CLEMENT
2013-10-14 14:54 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 10/14] ARM: mvebu: Set the start address of a CPU in a separate function Gregory CLEMENT
2013-10-14 13:58 ` [PATCH v3 11/14] ARM: mvebu: Add CPU idle low level support for Marvell Armada XP Gregory CLEMENT
2013-10-14 16:28 ` Thomas Petazzoni
2013-10-14 13:58 ` [PATCH v3 12/14] cpuidle: mvebu: Add initial CPU idle support for Armada 370/XP SoC Gregory CLEMENT
2013-10-14 16:36 ` Thomas Petazzoni
2013-10-17 10:15 ` Daniel Lezcano
2013-10-14 13:58 ` [PATCH v3 13/14] ARM: mvebu: register the cpuidle driver for the Armada XP SoCs Gregory CLEMENT
2013-10-14 13:58 ` [PATCH v3 14/14] ARM: dts: mvebu: Add a new set of registers to the PMSU node Gregory CLEMENT
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=20131014162041.185d797a@skate \
--to=thomas.petazzoni@free-electrons.com \
--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;
as well as URLs for NNTP newsgroup(s).