[RFC PATCHv1 0/7] ARM core support for hardware I/O coherency in non-SMP platforms

[catalin.marinas@arm.com (Catalin Marinas)]

On Thu, May 15, 2014 at 03:59:31PM +0100, Rob Herring wrote:
> On Thu, May 15, 2014 at 9:22 AM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > On Thu, May 15, 2014 at 10:50:10AM +0100, Thomas Petazzoni wrote:
> >> On Wed, 14 May 2014 18:04:56 +0100, Catalin Marinas wrote:
> >> > On Wed, May 14, 2014 at 04:50:34PM +0100, Thomas Petazzoni wrote:
> >> > >    - The SCU must be enabled
> >> >
> >> > Again, could the firmware do this?
> >>
> >> See above. If the kernel does it for SMP cases, why wouldn't it do it
> >> also for !SMP I/O coherent cases?
> >
> > The I/O coherency is an SoC property rather than an ARM architecture
> > property. I want to separate the two so that the kernel can boot a
> > significant part assuming sane architecture settings. Once you have DT
> > available and start loading device drivers, you are in the SoC realm and
> > you can do whatever initialisation for buses, interconnects, but not
> > going back to change architected settings.
> 
> The SCU has nothing to do with the architecture and really is part of
> the SOC. 

Indeed, it's not part of the architecture but I don't see it any
different than other early configuration like SDRAM controller.

> Let's look at this another way. Are there any usecases where
> you would not enable the SCU? If any cores are coherent or the ACP is
> coherent, it must be on. So that leaves all core in AMP mode. In this
> case, does it matter if the SCU is enabled or not?

I don't fully follow the question. You may not enable the SCU if you
don't care at all about the SMP mode or other coherency like ACP.
Otherwise it should be enabled, the latest before the secondaries start.

-- 
Catalin