All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Bowler <nbowler@elliptictech.com>
To: Josh Cartwright <josh.cartwright@ni.com>
Cc: Rob Herring <robherring2@gmail.com>,
	Arnd Bergmann <arnd@arndb.de>,
	arm@kernel.org, linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	John Linn <john.linn@xilinx.com>
Subject: Re: [PATCH v2 2/4] zynq: move static peripheral mappings
Date: Tue, 23 Oct 2012 17:17:42 -0400	[thread overview]
Message-ID: <20121023211742.GA14047@elliptictech.com> (raw)
In-Reply-To: <20121023205304.GJ20593@beefymiracle.amer.corp.natinst.com>

On 2012-10-23 15:53 -0500, Josh Cartwright wrote:
> On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote:
> > On 10/23/2012 09:50 AM, Arnd Bergmann wrote:
> > > On Monday 22 October 2012, Josh Cartwright wrote:
> > >> -#define SCU_PERIPH_PHYS			0xF8F00000
> > >> -#define SCU_PERIPH_VIRT			SCU_PERIPH_PHYS
> > >> +#define SCU_PERIPH_PHYS		0xF8F00000
> > >> +#define SCU_PERIPH_SIZE		SZ_8K
> > >> +#define SCU_PERIPH_VIRT		(PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
> > >
> > > And your patch 3 already obsoletes this mapping.
> >
> > Actually, it's probably still needed. The smp platform code typically
> > reads the number of cores from the SCU and the mapping has to be in
> > place before ioremap is up. I don't think there is an architected way to
> > get the number of cores, but it would be nice to avoid this early SCU
> > access. We could also mandate getting the core count from DT instead.
> >
> > Also, the physical address can be read with this on A9's:
> >
> >         asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
> 
> For the sake of the zynq cleanups, I think it may still make sense to
> remove the SCU peripheral mappings for now.  By the time we're ready to
> push in SMP support for zynq, maybe we can tackle the problem of how to
> solve the SCU mapping problem generically.

Then the static mapping can be removed if and when the we "solve the SCU
mapping problem generically".  There's no point in removing it until
then since it doesn't cause any actual problems, does it?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

WARNING: multiple messages have this Message-ID (diff)
From: nbowler@elliptictech.com (Nick Bowler)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/4] zynq: move static peripheral mappings
Date: Tue, 23 Oct 2012 17:17:42 -0400	[thread overview]
Message-ID: <20121023211742.GA14047@elliptictech.com> (raw)
In-Reply-To: <20121023205304.GJ20593@beefymiracle.amer.corp.natinst.com>

On 2012-10-23 15:53 -0500, Josh Cartwright wrote:
> On Tue, Oct 23, 2012 at 03:09:23PM -0500, Rob Herring wrote:
> > On 10/23/2012 09:50 AM, Arnd Bergmann wrote:
> > > On Monday 22 October 2012, Josh Cartwright wrote:
> > >> -#define SCU_PERIPH_PHYS			0xF8F00000
> > >> -#define SCU_PERIPH_VIRT			SCU_PERIPH_PHYS
> > >> +#define SCU_PERIPH_PHYS		0xF8F00000
> > >> +#define SCU_PERIPH_SIZE		SZ_8K
> > >> +#define SCU_PERIPH_VIRT		(PL310_L2CC_VIRT - SCU_PERIPH_SIZE)
> > >
> > > And your patch 3 already obsoletes this mapping.
> >
> > Actually, it's probably still needed. The smp platform code typically
> > reads the number of cores from the SCU and the mapping has to be in
> > place before ioremap is up. I don't think there is an architected way to
> > get the number of cores, but it would be nice to avoid this early SCU
> > access. We could also mandate getting the core count from DT instead.
> >
> > Also, the physical address can be read with this on A9's:
> >
> >         asm("mrc p15, 4, %0, c15, c0, 0" : "=r" (base));
> 
> For the sake of the zynq cleanups, I think it may still make sense to
> remove the SCU peripheral mappings for now.  By the time we're ready to
> push in SMP support for zynq, maybe we can tackle the problem of how to
> solve the SCU mapping problem generically.

Then the static mapping can be removed if and when the we "solve the SCU
mapping problem generically".  There's no point in removing it until
then since it doesn't cause any actual problems, does it?

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

  reply	other threads:[~2012-10-24  2:24 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 21:10 [PATCH v2 0/4] zynq subarch cleanups Josh Cartwright
2012-10-22 21:10 ` Josh Cartwright
2012-10-22 21:11 ` [PATCH v2 1/4] ARM: annotate VMALLOC_END definition with _AC Josh Cartwright
2012-10-22 21:11   ` Josh Cartwright
2012-10-22 21:12 ` [PATCH v2 2/4] zynq: move static peripheral mappings Josh Cartwright
2012-10-22 21:12   ` Josh Cartwright
2012-10-23 14:50   ` Arnd Bergmann
2012-10-23 14:50     ` Arnd Bergmann
2012-10-23 16:26     ` Josh Cartwright
2012-10-23 16:26       ` Josh Cartwright
2012-10-23 17:48       ` Arnd Bergmann
2012-10-23 17:48         ` Arnd Bergmann
2012-10-23 20:27       ` Nick Bowler
2012-10-23 20:27         ` Nick Bowler
2012-10-23 23:42         ` Josh Cartwright
2012-10-23 23:42           ` Josh Cartwright
2012-10-24 20:19           ` Nick Bowler
2012-10-24 20:19             ` Nick Bowler
2012-10-23 20:09     ` Rob Herring
2012-10-23 20:09       ` Rob Herring
2012-10-23 20:53       ` Josh Cartwright
2012-10-23 20:53         ` Josh Cartwright
2012-10-23 21:17         ` Nick Bowler [this message]
2012-10-23 21:17           ` Nick Bowler
2012-10-23 21:24           ` Josh Cartwright
2012-10-23 21:24             ` Josh Cartwright
2012-10-22 21:12 ` [PATCH v2 3/4] zynq: use GIC device tree bindings Josh Cartwright
2012-10-22 21:12   ` Josh Cartwright
2012-10-22 21:13 ` [PATCH v2 4/4] zynq: remove use of CLKDEV_LOOKUP Josh Cartwright
2012-10-22 21:13   ` Josh Cartwright
2012-10-23 14:41 ` [PATCH v2 0/4] zynq subarch cleanups Arnd Bergmann
2012-10-23 14:41   ` Arnd Bergmann
2012-10-23 20:50   ` Rob Herring
2012-10-23 20:50     ` Rob Herring

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=20121023211742.GA14047@elliptictech.com \
    --to=nbowler@elliptictech.com \
    --cc=arm@kernel.org \
    --cc=arnd@arndb.de \
    --cc=john.linn@xilinx.com \
    --cc=josh.cartwright@ni.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=robherring2@gmail.com \
    /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.