From mboxrd@z Thu Jan 1 00:00:00 1970 From: lorenzo.pieralisi@arm.com (Lorenzo Pieralisi) Date: Fri, 11 Jan 2013 12:05:39 +0000 Subject: [PATCH 01/16] ARM: b.L: secondary kernel entry code In-Reply-To: <20130111114552.GB12560@localhost.cambridge.arm.com> References: <1357777251-13541-1-git-send-email-nicolas.pitre@linaro.org> <1357777251-13541-2-git-send-email-nicolas.pitre@linaro.org> <20130111114552.GB12560@localhost.cambridge.arm.com> Message-ID: <20130111120539.GD30538@e102568-lin.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Fri, Jan 11, 2013 at 11:45:53AM +0000, Catalin Marinas wrote: > On Thu, Jan 10, 2013 at 04:47:09PM +0000, Nicolas Pitre wrote: > > On Thu, 10 Jan 2013, Catalin Marinas wrote: > > > On 10 January 2013 00:20, Nicolas Pitre wrote: > > > > --- /dev/null > > > > +++ b/arch/arm/common/bL_entry.c > > > ... > > > > +extern volatile unsigned long bL_entry_vectors[BL_NR_CLUSTERS][BL_CPUS_PER_CLUSTER]; > > > > > > IMHO, we should keep this array linear and ignore the cluster grouping > > > at this stage. This information could be added to latter patches that > > > actually need to know about the b.L topology. > > > > That's virtually all of them. Everything b.L related is always > > expressed in terms of a cpu,cluster tuple at the low level. > > > > > This would also imply that we treat the MPIDR just as an ID without > > > digging into its bit layout. > > > > That makes for too large an index space. We always end up needing to > > break the MPIDR into a cpu,cluster thing as the MPIDR bits are too > > sparse. > > You could find a way to compress this with some mask and shifts. We can > look at this later if we are to generalise this to non-b.L systems. The MPIDR linearization (a simple hash to convert it to a linear index) is planned anyway since code paths like cpu_{suspend/resume} do not work for multi-cluster systems as things stand. Lorenzo