[PATCHv1 0/2] ARM: socfpga: Soft reset, hotplug and device tree clocks

From: dinguyen@altera.com (Dinh Nguyen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv1 0/2] ARM: socfpga: Soft reset, hotplug and device tree clocks
Date: Mon, 18 Mar 2013 09:39:02 -0500	[thread overview]
Message-ID: <1363617542.8044.0.camel@linux-builds1> (raw)
In-Reply-To: <20130318142432.GA4110@amd.pavel.ucw.cz>

Hi Pavel,

On Mon, 2013-03-18 at 15:24 +0100, ZY - pavel wrote:
> Hi!
> 
> > >>> Just 2 patches for mach-socfpga:
> > >>>
> > >>> 0001: ARM: socfpga: Enable hotplug and soft reset
> > >>> 	- Able to hotplug CPU1 by putting it into reset and bringing back online.
> > >>>
> > >>
> > >> Have you seen the discussion on PSCI? There's an ARM doc on it and
> > >> Linaro session from last week. Is there a possibility you can use that?
> > >> You would need to be able to run in non-secure mode and implement
> > >> smc calls.
> > > 
> > > What would be the advantage?
> > 
> > It gets rid of some platform code. If you do an A15 part, it abstracts
> > out the differences between the cores on entering/exiting coherency. It
> > should also save you from writing suspend/resume and cpuidle support for
> > your platform.
> 
> I don't see how PSCI would be useful at this point. Clock framework is
> needed for basic MMC and Ethernet support; PSCI would not help there. 
> 
> > > We do not have suitable hypervisor at the moment. Nor I see why it
> > > would be good to push power management into it.
> > 
> > It's not a hypervisor. A minimal implementation is only about 100 lines
> > of assembly.
> 
> So... we could reduce some complexity of the kernel by inventing
> another component, inventing API, and putting the complex code into
> the newly invented component... when no other arm32 architecture does
> that. (Where would you put the 100 lines? u-boot?)

Let me just rework the patches to have just the clock framework and a
soft reset support for SOCFPGA. I'll work on add PSCI for hotplug in a
separate patch.

Dinh
> 
> > > (Plus, the implementation seems pretty incomplete for arm32.).
> > 
> > That's the point. The linux side is simple. The secure monitor side is
> > also simplified somewhat. When you enter secure monitor mode, you are
> > automatically running with the cache and mmu off. This avoids the side
> > effects of cache allocations while trying to flush the caches.
> 
> This is clock framework. It does not touch any caches, and does not
> have problems with MMU. Even if we would implement PSCI in future,
> this code would stay the same AFAICT.
> 									Pavel