When building a multi_v7_defconfig kernel it is not possible to configure
DEBUG_LL to use any serial device except a ARM Primecell PL01X, or more
accurately and worse, it is possible to configure a different serial
device but KConfig does not honour this request.
The happens because the multi-platform mode may include ARCH_SPEAR13XX
and this forcibly engages DEBUG_UART_PL01X to provide some kind of
compatibility with single platform builds (SPEAr supports both single and
multi-platform). This in turn causes DEBUG_LL_INCLUDE to wedge at
debug/pl01x.S.
Problem is fixed by only deploying the compatibility options for SPEAr
when ARCH_MULTIPLATFORM is not set.
Signed-off-by: Daniel Thompson <daniel.thompson(a)linaro.org>
---
arch/arm/Kconfig.debug | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0531da8..f10c784 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -991,9 +991,9 @@ config DEBUG_LL_INCLUDE
config DEBUG_UART_PL01X
def_bool ARCH_EP93XX || \
ARCH_INTEGRATOR || \
- ARCH_SPEAR3XX || \
- ARCH_SPEAR6XX || \
- ARCH_SPEAR13XX || \
+ (ARCH_SPEAR3XX && !ARCH_MULTIPLATFORM) || \
+ (ARCH_SPEAR6XX && !ARCH_MULTIPLATFORM) || \
+ (ARCH_SPEAR13XX && !ARCH_MULTIPLATFORM) || \
ARCH_VERSATILE
# Compatibility options for 8250
--
1.9.0
This patchset makes it possible to use the kgdb NMI infrastructure
on ARM platforms.
The kgdb NMI infrastructure works by re-routing an UARTs interrupt
signal from IRQ to FIQ. The UART will no longer function normally
and will instead be managed by kgdb using the polled I/O functions.
Any character delivered to the UART causes the kgdb handler function
to be called. Each serial driver explicitly consents (or not) to this
abuse by calling the appropriate registration functions.
[PATCH 1/8] arm: fiq: Allow EOI to be communicated to the intc
[PATCH 2/8] irqchip: gic: Provide support for interrupt grouping
Both these patches lay the ground work to allow modern ARM
interrupt controllers to support FIQ correctly.
[PATCH 3/8] ARM: Move some macros from entry-armv to entry-header
[PATCH 4/8] ARM: Add KGDB/KDB FIQ debugger generic code
This is the heart of the patch series, allowing FIQs to be
registered with KGDB and handled by KGDB.
[PATCH 5/8] serial: amba-pl011: Pass on FIQ information to KGDB.
[PATCH 6/8] serial: asc: Add support for KGDB's FIQ/NMI mode
Extend to UART drivers to allow the register the appropriate FIQ
(implicitly promising to behave properly when their own IRQ handler
is cut off).
[PATCH 7/8] ARM: VIC: Add vic_set_fiq function to select if an...
[PATCH 8/8] arm: fiq: Hack FIQ routing backdoors into GIC and VIC
Here we hit the serious request-for-comment section. It is not
clear what the best way to get the interrupt controller to re-route
an interrupt source from the IRQ signal to the FIQ signal.
Clearly the approach here is wrong but it has been enough for me
to test my work so far.
Anton Vorontsov (2):
ARM: Move some macros from entry-armv to entry-header
ARM: Add KGDB/KDB FIQ debugger generic code
Arve Hjønnevåg (1):
ARM: VIC: Add vic_set_fiq function to select if an interrupt should
generate an IRQ or FIQ
Daniel Thompson (5):
arm: fiq: Allow EOI to be communicated to the intc
irqchip: gic: Provide support for interrupt grouping
serial: amba-pl011: Pass on FIQ information to KGDB.
serial: asc: Add support for KGDB's FIQ/NMI mode
arm: fiq: Hack FIQ routing backdoors into GIC and VIC
arch/arm/Kconfig | 2 +
arch/arm/Kconfig.debug | 18 ++++
arch/arm/boot/dts/stih416.dtsi | 2 +-
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 2 +-
arch/arm/include/asm/fiq.h | 1 +
arch/arm/include/asm/kgdb.h | 7 ++
arch/arm/kernel/Makefile | 1 +
arch/arm/kernel/entry-armv.S | 151 +----------------------------
arch/arm/kernel/entry-header.S | 164 ++++++++++++++++++++++++++++++++
arch/arm/kernel/fiq.c | 50 ++++++++++
arch/arm/kernel/kgdb_fiq.c | 117 +++++++++++++++++++++++
arch/arm/kernel/kgdb_fiq_entry.S | 87 +++++++++++++++++
drivers/irqchip/irq-gic.c | 62 +++++++++++-
drivers/irqchip/irq-vic.c | 23 +++++
drivers/tty/serial/amba-pl011.c | 18 +++-
drivers/tty/serial/st-asc.c | 25 +++++
include/linux/irqchip/arm-gic.h | 3 +
include/linux/irqchip/arm-vic.h | 1 +
18 files changed, 576 insertions(+), 158 deletions(-)
create mode 100644 arch/arm/kernel/kgdb_fiq.c
create mode 100644 arch/arm/kernel/kgdb_fiq_entry.S
--
1.9.0
Hi Rafael,
I am sending this again, but without the controversial part this time. I have
dropped last two patches which were about detecting clock sharing among CPUs.
Would fix up that later once other Maintainers get in sync about the bindings.
So, what's left here ? These are mostly updates/reorders which can be applied
the patches which I have dropped now. These are all well reviewed and tested
by others. Getting them in shouldn't break anything, I believe. Its better
people start using the updates we already have, otherwise they will keep on
sending fixes they get (The way Pramod Gurav tried it today).
Can we please get them in 3.17 if its still allowed? Or -next otherwise.
V2: https://lkml.org/lkml/2014/7/1/358
Rebased over: 3.17-rc2
git://git.linaro.org/people/viresh.kumar/linux.git cpufreq/cpu0-updates-v3
V2->V3: Dropped few patches, nothing much.
--
Thanks
Viresh
Viresh Kumar (10):
cpufreq: Add support for per-policy driver data
cpufreq: cpu0: Update Module Author
cpufreq: cpu0: don't validate clock on clk_put()
cpufreq: cpu0: print relevant error when we defer probe
cpufreq: cpu0: use dev_{err|warn|dbg} instead of pr_{err|warn|debug}
cpufreq: cpu0: Move per-cluster initialization code to ->init()
cpufreq: cpu0: try regulators with name "cpu-supply"
cpufreq: cpu0: Make allocate_resources() work for any CPU
cpufreq: cpu0: rename driver and internals to 'cpufreq_generic'
cpufreq: generic: set platform_{driver|device} '.name' to
'cpufreq-generic'
.../{cpufreq-cpu0.txt => cpufreq-generic.txt} | 8 +-
arch/arm/mach-imx/imx27-dt.c | 2 +-
arch/arm/mach-imx/mach-imx51.c | 2 +-
arch/arm/mach-omap2/pm.c | 2 +-
arch/arm/mach-shmobile/board-ape6evm-reference.c | 2 +-
arch/arm/mach-shmobile/cpufreq.c | 2 +-
arch/arm/mach-shmobile/setup-sh73a0.c | 4 +-
arch/arm/mach-zynq/common.c | 2 +-
drivers/cpufreq/Kconfig | 10 +-
drivers/cpufreq/Kconfig.arm | 2 +-
drivers/cpufreq/Makefile | 2 +-
drivers/cpufreq/cpufreq-cpu0.c | 248 --------------
drivers/cpufreq/cpufreq-generic.c | 363 +++++++++++++++++++++
drivers/cpufreq/exynos4210-cpufreq.c | 2 +-
drivers/cpufreq/exynos4x12-cpufreq.c | 2 +-
drivers/cpufreq/exynos5250-cpufreq.c | 2 +-
drivers/cpufreq/highbank-cpufreq.c | 6 +-
drivers/cpufreq/s5pv210-cpufreq.c | 2 +-
include/linux/cpufreq.h | 3 +
19 files changed, 392 insertions(+), 274 deletions(-)
rename Documentation/devicetree/bindings/cpufreq/{cpufreq-cpu0.txt => cpufreq-generic.txt} (85%)
delete mode 100644 drivers/cpufreq/cpufreq-cpu0.c
create mode 100644 drivers/cpufreq/cpufreq-generic.c
--
2.0.3.693.g996b0fd
Tomasz Figa <tomasz.figa(a)gmail.com> writes:
> Kukjin,
>
> On 31.07.2014 20:32, Kukjin Kim wrote:
>> On 07/30/14 17:07, Thomas Abraham wrote:
>>> The new CPU clock type allows the use of generic CPUfreq drivers. So for
>>> Exynos4210/5250, switch to using generic cpufreq driver. For Exynos5420,
>>> which did not have CPUfreq driver support, enable the use of generic
>>> CPUfreq driver.
>>>
>>> Suggested-by: Tomasz Figa<t.figa(a)samsung.com>
>>> Cc: Kukjin Kim<kgene.kim(a)samsung.com>
>>
>> Looks good to me,
>>
>> Acked-by: Kukjin Kim <kgene.kim(a)samsung.com>
>>
>> BTW, who will handle this series? I hope see this series in 3.17.
>
> This series consists mostly of clock changes and it likely depends on
> patches already in my for-next, so I would be inclined toward taking it
> through samsung-clk tree.
So has this series been picked up anywhere? I don't see it in your
samsung-clk tree, nor in Kukjin's for-next.
Also, I'm curious whether or how this is has been tested on big.LITTLE
SoCs.
I'm trying it on the 5800/Chromebook2 and it's not terribly stable. I'm
testing along with CPUidle, so there may be some untested interactions
there as it seems a bit more stable without CPUidle enabled.
I'd love to hear from anyone else that's testing CPUidle and CPUfreq
together big.LITTLE 5420/5800, with or without the switcher.
Also, the patch below[2] is needed for 5800.
FWIW, I have a temporary branch[1] based on the v3.17-rc branch of the
exynos-reference tree where I've added the DT patch needed for CPUidle,
this series (and it's dependencies) which is what I'm using for testing.
Kevin
[1] git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux.git wip/exynos/integ
[2]
>From 72ee00246c0fbdcf5dbb0bf910b8a427da4ac002 Mon Sep 17 00:00:00 2001
From: Kevin Hilman <khilman(a)linaro.org>
Date: Fri, 22 Aug 2014 16:04:11 -0700
Subject: [PATCH] ARM: Exynos: use generic cpufreq driver for Exynos5800
As a derivative of the 5420, the 5800 SoC should use the generic
big.LITTLE driver for Exynos5800 as well.
Signed-off-by: Kevin Hilman <khilman(a)linaro.org>
---
arch/arm/mach-exynos/exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-exynos/exynos.c b/arch/arm/mach-exynos/exynos.c
index 8923d37c3e85..debe50bf736a 100644
--- a/arch/arm/mach-exynos/exynos.c
+++ b/arch/arm/mach-exynos/exynos.c
@@ -283,6 +283,7 @@ static void __init exynos_init_irq(void)
static const struct of_device_id exynos_cpufreq_matches[] = {
{ .compatible = "samsung,exynos5420", .data = "arm-bL-cpufreq-dt" },
+ { .compatible = "samsung,exynos5800", .data = "arm-bL-cpufreq-dt" },
{ .compatible = "samsung,exynos5250", .data = "cpufreq-cpu0" },
{ .compatible = "samsung,exynos4210", .data = "cpufreq-cpu0" },
{ .compatible = "samsung,exynos5440", .data = "exynos5440-cpufreq" },
--
1.9.2
Hi,
This patch series adds support for AFTR idle mode on boards with
secure firmware enabled and allows EXYNOS cpuidle driver usage on
Exynos4x12 SoCs.
It has been tested on Trats2 board (using Exynos4412 SoC with secure
firmware enabled) on which AFTR mode reduces power consumption by ~12%
when EXYNOS cpuidle driver is enabled (in both cases the default
exynos_defconfig config is used and CPU1-3 are offlined).
Depends on:
- next-20140804 branch of linux-next kernel tree
- [PATCH v5][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35262.html)
- [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html)
Changes since v4:
- rebased on top of next-20140804 +
[PATCH v5][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35262.html)
[PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html)
- call exynos_save_cp15() only on A9 type core (this is needed for the future
Exynos3250 SoC support)
Changes since v3:
- rebased on top of next-20140804 +
[PATCH v4][next-20140804] ARM: EXYNOS: Fix suspend/resume sequences
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg35192.html)
[PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg34282.html)
- (re-)added patch fixing S5P_CENTRAL_SEQ_OPTION register setup
Changes since v2:
- rebased on top of next-20140708 +
[PATCH 5/6] ARM: EXYNOS: Fix suspend/resume sequencies
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32809.html)
[with rejects fixed]
[PATCH 6/6] ARM: EXYNOS: Register cpuidle device only on Exynos4210 and 5250
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32808.html)
[PATCH 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg32991.html)
[with rejects fixed in patch #2]
- addressed review comments from Tomasz Figa and Daniel Lezcano
Changes since v1:
- synced against next-20140602
- added missing Acked-by-s
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
Bartlomiej Zolnierkiewicz (5):
ARM: EXYNOS: PM: replace EXYNOS_BOOT_VECTOR_* macros by static inlines
ARM: EXYNOS: add AFTR mode support to firmware do_idle method
ARM: EXYNOS: cpuidle: add secure firmware support to AFTR mode code
ARM: EXYNOS: PM: fix register setup for AFTR mode code
ARM: EXYNOS: cpuidle: allow driver usage on Exynos4x12 SoCs
arch/arm/include/asm/firmware.h | 2 +-
arch/arm/mach-exynos/common.h | 5 ++++
arch/arm/mach-exynos/exynos.c | 4 ++-
arch/arm/mach-exynos/firmware.c | 34 ++++++++++++++++-------
arch/arm/mach-exynos/pm.c | 60 ++++++++++++++++++++++++-----------------
5 files changed, 70 insertions(+), 35 deletions(-)
--
1.8.2.3
Many boards share the cpufreq-cpu0 driver meaning that if we enable it in
multi_v7_defconfig we can get a reasonable amount of functional utility for
systems and test coverage for a fairly small increase in kernel size.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 05c0e7c789df..9799e9d2e222 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -414,3 +414,5 @@ CONFIG_DEBUG_FS=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOCKUP_DETECTOR=y
CONFIG_CRYPTO_DEV_TEGRA_AES=y
+CONFIG_CPU_FREQ=y
+CONFIG_GENERIC_CPUFREQ_CPU0=y
--
2.1.0