[RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra

[Peter De Schrijver]

On Mon, Jun 30, 2014 at 12:25:12PM +0200, Catalin Marinas wrote:
> On Sat, Jun 28, 2014 at 12:27:58AM +0100, Thierry Reding wrote:
> > On Fri, Jun 27, 2014 at 01:30:04PM -0400, Santosh Shilimkar wrote:
> > > On Friday 27 June 2014 12:58 PM, Thierry Reding wrote:
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra114.c (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra20.c (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle-tegra30.c (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.c (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/cpuidle.h (91%)
> > > This should go into drivers/idle/*. if you have dependencies, please sort
> > > them out.
> > 
> > What exactly is the difference between drivers/idle and drivers/cpuidle?
> > There's an intel_idle driver in drivers/idle that includes cpuidle.h and
> > registers with that subsystem. But there's also an i7300_idle driver
> > that doesn't.
> > 
> > drivers/cpuidle seems like a better fit. I'll look into moving the code
> > there.
> 
> Actually, please look at Lorenzo's generic cpuidle series. Basically
> most cpuidle drivers simply define some C states and call the
> corresponding platform back-end. On arm64, we aim to separate the
> back-end in the cpu_operations structure and just have a generic cpuidle
> driver with states defined in the DT (and passed to the back-end).
> 
> As for the back-end, what about using PSCI?
> 
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset-handler.S (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.c (100%)
> > > >  rename {arch/arm/mach-tegra => drivers/soc/tegra}/reset.h (97%)
> > > subsystem: drivers/power/reset/
> > 
> > drivers/power/reset seems to be for drivers that register functions to
> > reset a board. The above code for Tegra doesn't do that. Rather it sets
> > up the reset handlers for secondary CPUs and for suspend/resume.
> 
> PSCI again?

Not possible for boards where linux runs in NS (roth and tn7). The secure
monitor on those is outside our control and does not implement PSCI. There
might be some value for Tegra114 and Tegra124 if we would like to use HYP
mode, but that's not on the radar today. It's a waste of time for Tegra20
and Tegra30.

Cheers,

Peter.