These (mostly minor) patches fix a few typos, improve points that
were agreed upon when the Trusted Foundation series was initially
submitted, and more importantly add support for the do_idle() firmware
operation that is needed for cpuidle to be supported. Tegra's cpuidle
driver is also updated accordingly.
These patches should be the last step before the device trees for NVIDIA
SHIELD and Tegra Note 7 can be submitted.
Alexandre Courbot (5):
ARM: trusted_foundations: fix vendor prefix typos
ARM: trusted_foundations: fallback when TF support is missing
ARM: firmware: enable Trusted Foundations by default
ARM: trusted_foundations: implement do_idle()
ARM: tegra: cpuidle: use firmware call for power down
arch/arm/configs/tegra_defconfig | 1 -
arch/arm/firmware/Kconfig | 3 ++-
arch/arm/firmware/trusted_foundations.c | 20 +++++++++++++++++++-
arch/arm/include/asm/trusted_foundations.h | 13 +++++++++----
arch/arm/mach-tegra/cpuidle-tegra114.c | 3 +++
5 files changed, 33 insertions(+), 7 deletions(-)
--
1.8.5.3
When Trusted Foundations is detected as present on the system, but
Trusted Foundations support is not built into the kernel, the kernel
used to issue a panic very early during boot, leaving little clue to the
user as to what is going wrong.
It turns out that even without TF support built-in, the kernel can boot
on a TF-enabled system provided that SMP and cpuidle are disabled. This
patch does this and continue booting on one CPU, leaving the user with a
usable (however degraded) system.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/include/asm/trusted_foundations.h | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
@@ -47,10 +49,13 @@ static inline void register_trusted_foundations(structtrusted_foundations_platform_data*pd){/*-*IfwetrytoregisterTF,thismeansthesystemneedsittocontinue.-*Itsabsenceifthusafatalerror.+*IfthesystemrequiresTFandwecannotprovideit,continuebooting+*butdisablefeaturesthatcannotbeprovided.*/-panic("No support for Trusted Foundations, stopping...\n");+pr_err("No support for Trusted Foundations, continuing in degraded mode.\n");+pr_err("Secondary processors as well as CPU PM will be disabled.\n");+setup_max_cpus=0;+cpu_idle_poll_ctrl(true);}staticinlinevoidof_register_trusted_foundations(void)
Invoke the do_idle() firmware call before suspending a CPU so that the
underlying firmware (if any) can take necessary action.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/mach-tegra/cpuidle-tegra114.c | 3 +++
1 file changed, 3 insertions(+)
Support the do_idle() firmware call, which is necessary to properly
support cpuidle.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/firmware/trusted_foundations.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
Trusted Foundation support by default since it already depends on a
supporting architecture being selected.
Doing so allows us to remove it from tegra_defconfig.
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
---
arch/arm/configs/tegra_defconfig | 1 -
arch/arm/firmware/Kconfig | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
From: Stephen Warren <hidden> Date: 2014-01-22 20:42:45
On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
Trusted Foundation support by default since it already depends on a
supporting architecture being selected.
Doing so allows us to remove it from tegra_defconfig.
Can we split out the defconfig and code changes into separate patches?
They need to go through seperate branches, possibly even separate repos.
The defconfig change might not even be necessary; at some point I'll
just rebuild it via "make tegra_defconfig; make savedefconfig" on top of
some linux-next that includes the Kconfig change, and it'll happen
automatically. Still, I guess there's no harm explicitly sending the patch.
Hmm. This must be Tegra-specific, not generic to any TF client, since
aren't the names of the suspend states (LP0, LP1, LP2) entirely specific
to Tegra?
Don't you need to have the kernel also *not* do something when entering
idle; doesn't the FW op replace some of the register writes that the
kernel would otherwise be doing?
From: Stephen Warren <hidden> Date: 2014-01-22 20:47:13
On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
These (mostly minor) patches fix a few typos, improve points that
were agreed upon when the Trusted Foundation series was initially
submitted, and more importantly add support for the do_idle() firmware
operation that is needed for cpuidle to be supported. Tegra's cpuidle
driver is also updated accordingly.
These patches should be the last step before the device trees for NVIDIA
SHIELD and Tegra Note 7 can be submitted.
Russell, once these patches are reviewed, should Alex submit them to the
ARM patch tracker, or will you Ack them so they can go through the Tegra
tree? Either way I can put them in a separate branch based on 3.14-rc1
in order to easily resolve any conflicts.
On Thu, Jan 23, 2014 at 5:42 AM, Stephen Warren [off-list ref] wrote:
On 01/21/2014 03:10 AM, Alexandre Courbot wrote:
quoted
As discussed previously (https://lkml.org/lkml/2013/11/26/289), enable
Trusted Foundation support by default since it already depends on a
supporting architecture being selected.
Doing so allows us to remove it from tegra_defconfig.
Can we split out the defconfig and code changes into separate patches?
They need to go through seperate branches, possibly even separate repos.
The defconfig change might not even be necessary; at some point I'll
just rebuild it via "make tegra_defconfig; make savedefconfig" on top of
some linux-next that includes the Kconfig change, and it'll happen
automatically. Still, I guess there's no harm explicitly sending the patch.
If we can do without the defconfig change then I will just omit it in
the next version - I don't like sending too many oneliners. :P
Hmm. This must be Tegra-specific, not generic to any TF client, since
aren't the names of the suspend states (LP0, LP1, LP2) entirely specific
to Tegra?
The names are negligence on my part, actually. I arbitrarily named
them that way without thinking this was Tegra-only denomination. The
downstream kernel does not even use these, they hardcode the values
directly. Will fix that, thanks for spotting it.
Don't you need to have the kernel also *not* do something when entering
idle; doesn't the FW op replace some of the register writes that the
kernel would otherwise be doing?
It seems like the operation is actually to inform the firmware that we
are going to suspend the CPU. Downstream kernel also uses it that way.
But you are right in that we should expect do_idle() to actually
perform the suspend operation. Maybe a prepare_idle() operation should
be added to the firmware interface for this purpose?
Don't you need to have the kernel also *not* do something when entering
idle; doesn't the FW op replace some of the register writes that the
kernel would otherwise be doing?
It seems like the operation is actually to inform the firmware that we
are going to suspend the CPU. Downstream kernel also uses it that way.
But you are right in that we should expect do_idle() to actually
perform the suspend operation. Maybe a prepare_idle() operation should
be added to the firmware interface for this purpose?
That sounds like a reasonable change. Is it easy to plumb in?
Don't you need to have the kernel also *not* do something when entering
idle; doesn't the FW op replace some of the register writes that the
kernel would otherwise be doing?
It seems like the operation is actually to inform the firmware that we
are going to suspend the CPU. Downstream kernel also uses it that way.
But you are right in that we should expect do_idle() to actually
perform the suspend operation. Maybe a prepare_idle() operation should
be added to the firmware interface for this purpose?
That sounds like a reasonable change. Is it easy to plumb in?
I think so. Will post a v2 of this soon.
Thanks,
Alex.