All of lore.kernel.org
 help / color / mirror / Atom feed
From: dave.martin@linaro.org (Dave Martin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 03/15] ARM: mcpm: introduce helpers for platform coherency exit/setup
Date: Wed, 24 Apr 2013 10:10:18 +0100	[thread overview]
Message-ID: <20130424091007.GA2664@linaro.org> (raw)
In-Reply-To: <20130405230017.GC14308@quad.lixom.net>

On Fri, Apr 05, 2013 at 04:00:17PM -0700, Olof Johansson wrote:
> Hi,
> 
> Just two nits below. One could be fixed incrementally, the other is
> a longer-term potential cleanup.
> 
> On Tue, Feb 05, 2013 at 12:22:00AM -0500, Nicolas Pitre wrote:
> 
> > diff --git a/arch/arm/include/asm/mcpm_entry.h b/arch/arm/include/asm/mcpm_entry.h
> > index 3286d5eb91..e76652209d 100644
> > --- a/arch/arm/include/asm/mcpm_entry.h
> > +++ b/arch/arm/include/asm/mcpm_entry.h
> > @@ -15,8 +15,37 @@
> >  #define MAX_CPUS_PER_CLUSTER	4
> >  #define MAX_NR_CLUSTERS		2
> >  
> > +/* Definitions for mcpm_sync_struct */
> > +#define CPU_DOWN		0x11
> > +#define CPU_COMING_UP		0x12
> > +#define CPU_UP			0x13
> > +#define CPU_GOING_DOWN		0x14
> > +
> > +#define CLUSTER_DOWN		0x21
> > +#define CLUSTER_UP		0x22
> > +#define CLUSTER_GOING_DOWN	0x23
> > +
> > +#define INBOUND_NOT_COMING_UP	0x31
> > +#define INBOUND_COMING_UP	0x32
> > +
> > +/* This is a complete guess. */
> > +#define __CACHE_WRITEBACK_ORDER	6
> > +#define __CACHE_WRITEBACK_GRANULE (1 << __CACHE_WRITEBACK_ORDER)
> 
> Something a little more educational could be useful here. It needs to
> be the max writeback/line size of the supported platforms of the binary
> kernel, i.e. if someone builds an SoC with 128-byte L2 cache lines this
> guess will break.

Will commented on the same thing.  Ideally, a suitable definition should
get selected through Kconfig.

The guess specified here is adequate for known b.L platforms, but a
better framework for configuring this is desirable.

My original comment here is certainly not very informative though --
I'll post a clarification.

> > +/* Offsets for the mcpm_sync_struct members, for use in asm: */
> > +#define MCPM_SYNC_CLUSTER_CPUS	0
> > +#define MCPM_SYNC_CPU_SIZE	__CACHE_WRITEBACK_GRANULE
> > +#define MCPM_SYNC_CLUSTER_CLUSTER \
> > +	(MCPM_SYNC_CLUSTER_CPUS + MCPM_SYNC_CPU_SIZE * MAX_CPUS_PER_CLUSTER)
> > +#define MCPM_SYNC_CLUSTER_INBOUND \
> > +	(MCPM_SYNC_CLUSTER_CLUSTER + __CACHE_WRITEBACK_GRANULE)
> > +#define MCPM_SYNC_CLUSTER_SIZE \
> > +	(MCPM_SYNC_CLUSTER_INBOUND + __CACHE_WRITEBACK_GRANULE)
> > +
> >  #ifndef __ASSEMBLY__
> >  
> > +#include <linux/types.h>
> > +
> >  /*
> >   * Platform specific code should use this symbol to set up secondary
> >   * entry location for processors to use when released from reset.
> > @@ -123,5 +152,39 @@ struct mcpm_platform_ops {
> >   */
> >  int __init mcpm_platform_register(const struct mcpm_platform_ops *ops);
> >  
> > +/* Synchronisation structures for coordinating safe cluster setup/teardown: */
> > +
> > +/*
> > + * When modifying this structure, make sure you update the MCPM_SYNC_ defines
> > + * to match.
> > + */
> 
> It would be nice to introduce something like arch/powerpc/kernel/asm-offsets.c
> on ARM to generate the ASM-side automatically from the C struct instead for
> this and other cases, but that's unrelated to this addition.

ARM already has its own asm-offsets, and we actually used this in an earlier
version of the patches.  However, this felt like pollution of that file for
not a lot of benefit.  Does powerpc have a problem with asm-offsets becoming
a dumping ground for random junk, or is there a better way to organise it?

Cheers
---Dave

> > +struct mcpm_sync_struct {
> > +	/* individual CPU states */
> > +	struct {
> > +		volatile s8 cpu __aligned(__CACHE_WRITEBACK_GRANULE);
> > +	} cpus[MAX_CPUS_PER_CLUSTER];
> > +
> > +	/* cluster state */
> > +	volatile s8 cluster __aligned(__CACHE_WRITEBACK_GRANULE);
> > +
> > +	/* inbound-side state */
> > +	volatile s8 inbound __aligned(__CACHE_WRITEBACK_GRANULE);
> > +};
> 
> 
> -Olof

  parent reply	other threads:[~2013-04-24  9:10 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-05  5:21 [PATCH v4 00/15] multi-cluster power management Nicolas Pitre
2013-02-05  5:21 ` [PATCH v4 01/15] ARM: multi-cluster PM: secondary kernel entry code Nicolas Pitre
2013-04-23 19:19   ` Russell King - ARM Linux
2013-04-23 19:34     ` Nicolas Pitre
2013-04-23 20:09       ` Russell King - ARM Linux
2013-04-23 20:19         ` Nicolas Pitre
2013-02-05  5:21 ` [PATCH v4 02/15] ARM: mcpm: introduce the CPU/cluster power API Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 03/15] ARM: mcpm: introduce helpers for platform coherency exit/setup Nicolas Pitre
2013-04-05 23:00   ` Olof Johansson
2013-04-06 13:41     ` Nicolas Pitre
2013-04-24  9:10     ` Dave Martin [this message]
2013-02-05  5:22 ` [PATCH v4 04/15] ARM: mcpm: Add baremetal voting mutexes Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 05/15] ARM: mcpm_head.S: vlock-based first man election Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 06/15] ARM: mcpm: generic SMP secondary bringup and hotplug support Nicolas Pitre
2013-04-23 19:31   ` Russell King - ARM Linux
2013-04-23 19:36     ` Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 07/15] ARM: introduce common set_auxcr/get_auxcr functions Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 08/15] ARM: vexpress: introduce DCSCB support Nicolas Pitre
2013-02-07 18:14   ` Catalin Marinas
2013-02-07 18:56     ` Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 09/15] ARM: vexpress/dcscb: add CPU use counts to the power up/down API implementation Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 10/15] ARM: vexpress/dcscb: do not hardcode number of CPUs per cluster Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 11/15] drivers/bus: add ARM CCI support Nicolas Pitre
2013-04-23 19:38   ` Russell King - ARM Linux
2013-04-23 19:53     ` Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 12/15] ARM: CCI: ensure powerdown-time data is flushed from cache Nicolas Pitre
2013-04-23 19:40   ` Russell King - ARM Linux
2013-02-05  5:22 ` [PATCH v4 13/15] ARM: vexpress/dcscb: handle platform coherency exit/setup and CCI Nicolas Pitre
2013-02-05  5:22 ` [PATCH v4 14/15] ARM: Enable selection of SMP operations at boot time Nicolas Pitre
2013-04-05 22:43   ` Olof Johansson
2013-04-06 13:43     ` Nicolas Pitre
2013-04-09 16:30   ` Nicolas Pitre
2013-04-09 16:55     ` Jon Medhurst (Tixy)
2013-02-05  5:22 ` [PATCH v4 15/15] ARM: vexpress: Select multi-cluster SMP operation if required Nicolas Pitre
2013-02-06 16:38   ` Pawel Moll
2013-02-06 17:55     ` Nicolas Pitre
2013-04-05 22:48   ` Olof Johansson
2013-04-06 14:02     ` Nicolas Pitre
2013-04-08  9:10       ` Jon Medhurst (Tixy)
2013-04-09  5:41         ` Nicolas Pitre
2013-04-09  6:00           ` Jon Medhurst (Tixy)
2013-04-09 16:34             ` Nicolas Pitre
2013-04-09 17:28               ` Jon Medhurst (Tixy)
2013-04-23 19:42   ` Russell King - ARM Linux
2013-04-23 19:56     ` Nicolas Pitre
2013-04-23 20:04 ` [PATCH v4 00/15] multi-cluster power management Russell King - ARM Linux
2013-04-23 21:03   ` Nicolas Pitre
2013-04-23 21:46     ` Russell King - ARM Linux
2013-04-23 21:56       ` Nicolas Pitre
2013-04-23 22:44         ` Russell King - ARM Linux
2013-04-24  4:11           ` Nicolas Pitre
2013-04-24 20:25             ` Russell King - ARM Linux
2013-04-24 23:31               ` Nicolas Pitre
2013-04-24 14:25     ` Dave Martin
2013-04-23 21:11   ` Nicolas Pitre

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=20130424091007.GA2664@linaro.org \
    --to=dave.martin@linaro.org \
    --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 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.