linux-arm-kernel.lists.infradead.org archive mirror
 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 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).