From: catalin.marinas@arm•com (Catalin Marinas)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra
Date: Mon, 30 Jun 2014 15:13:34 +0100 [thread overview]
Message-ID: <20140630141334.GK28951@arm.com> (raw)
In-Reply-To: <20140630114621.GT3679@tbergstrom-lnx.Nvidia.com>
On Mon, Jun 30, 2014 at 12:46:21PM +0100, Peter De Schrijver wrote:
> 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).
That's one of the main use-cases for PSCI - Linux running in NS mode.
AFAIK, the boards that you mentioned are not ARMv8? We don't intend to
enforce PSCI on ARMv7 platforms, mainly because of the legacy firmware
(though where starting from scratch it would be nice). That means that
the code won't be shared with arm64 and you can leave it under arch/arm
(it's a lot of AArch32 assembly anyway).
> The secure monitor on those is outside our control and does not
> implement PSCI.
As I said, I don't think we should change firmware on existing ARMv7
SoCs but for a new ARMv8 SoC I strongly recommend PSCI. The firmware
needs to be written anyway (different AArch64 exception model), so you
can raise such requirement with your firmware provider (ARM also
provides Trusted Firmware freely as a quick start which implements PSCI,
though you can only use it as an example).
> 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.
I think you should keep the Hyp support in mind anyway and test Linux
booting in NS mode on your platforms. It may not be on your radar today
for a SoC but if you later decide that it is, we end up with needing
different code paths in Linux for the same SoC depending on how it boots
(and you can't easily detect this at boot time, nor you can pass it via
DT).
--
Catalin
next prev parent reply other threads:[~2014-06-30 14:13 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 16:58 [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra Thierry Reding
2014-06-27 16:58 ` [RFC 2/4] ARM: tegra: Add legacy interrupt controller nodes Thierry Reding
2014-06-27 20:58 ` Stephen Warren
2014-06-27 23:44 ` Thierry Reding
2014-06-27 16:58 ` [RFC 3/4] soc/tegra: Initialize interrupt controller from DT Thierry Reding
2014-06-27 21:03 ` Stephen Warren
2014-06-28 1:12 ` Thierry Reding
2014-06-30 11:30 ` Peter De Schrijver
2014-06-30 19:51 ` Thierry Reding
2014-06-27 16:58 ` [RFC 4/4] soc/tegra: Remove unused defines Thierry Reding
2014-06-27 21:03 ` Stephen Warren
2014-06-28 1:12 ` Thierry Reding
2014-06-27 17:30 ` [RFC 1/4] ARM: tegra: Move SoC drivers to drivers/soc/tegra Santosh Shilimkar
2014-06-27 23:27 ` Thierry Reding
2014-06-28 17:15 ` Santosh Shilimkar
2014-06-28 20:40 ` Thierry Reding
2014-06-30 7:20 ` Arnd Bergmann
2014-06-30 9:01 ` Thierry Reding
2014-06-30 10:36 ` Catalin Marinas
2014-06-30 10:48 ` Thierry Reding
2014-06-30 13:16 ` Lorenzo Pieralisi
2014-06-30 19:36 ` Thierry Reding
2014-07-01 10:50 ` Catalin Marinas
2014-07-01 15:05 ` Stephen Warren
2014-07-01 17:00 ` Catalin Marinas
2014-06-30 19:21 ` Thierry Reding
2014-07-01 7:51 ` Peter De Schrijver
2014-07-16 19:31 ` Olof Johansson
2014-07-16 19:47 ` Thierry Reding
2014-07-17 9:31 ` Catalin Marinas
2014-07-17 16:21 ` Olof Johansson
2014-06-30 7:23 ` Arnd Bergmann
2014-06-30 9:44 ` Catalin Marinas
2014-06-30 18:45 ` Stephen Warren
2014-06-30 10:25 ` Catalin Marinas
2014-06-30 10:49 ` Thierry Reding
2014-06-30 11:46 ` Peter De Schrijver
2014-06-30 14:13 ` Catalin Marinas [this message]
2014-06-30 14:42 ` Peter De Schrijver
2014-06-30 14:50 ` Peter De Schrijver
2014-06-30 16:08 ` Catalin Marinas
2014-06-27 21:10 ` Stephen Warren
2014-06-28 1:24 ` Thierry Reding
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=20140630141334.GK28951@arm.com \
--to=catalin.marinas@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox