MT8173 is a ARMv8 based SoC with 2 clusters. All CPUs in a single cluster
share the same power and clock domain. This series tries to add cpufreq support
for MT8173 SoC.
changes in v5:
- Move resource allocation code from init() into probe() and remove some unused
functions due to this change
- Fix descriptions for device tree binding document
- Address review comments for last version
- Register CPU cooling device
Changes in v4:
- Add bindings for MT8173 cpufreq driver
- Move OPP table back into device tree
- Address comments for last version
Changes in v3:
- Implement MT8173 specific standalone cpufreq driver instead of using
cpufreq-dt driver
- Define OPP table in the driver source code until new OPP binding is ready
Changes in v2:
- Add intermediate frequency support in cpufreq-dt driver
- Use voltage scaling code of cpufreq-dt for little cluster instead of
implementaion in notifier of mtk-cpufreq driver
- Code refinement for mtk-cpufreq driver
Pi-Cheng Chen (2):
dt-bindings: mediatek: Add MT8173 cpufreq driver binding
cpufreq: mediatek: Add MT8173 cpufreq driver
.../devicetree/bindings/cpufreq/cpufreq-mt8173.txt | 145 ++++++
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/mt8173-cpufreq.c | 520 +++++++++++++++++++++
4 files changed, 673 insertions(+)
create mode 100644 Documentation/devicetree/bindings/cpufreq/cpufreq-mt8173.txt
create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
--
1.9.1
__cpufreq_cooling_register() might fail if some CPU other than first one in
clip_cpu mask is present earlier e.g. CPU hotplug. Iterate all CPUs in the mask
to handle this case.
Signed-off-by: Pi-Cheng Chen <pi-cheng.chen(a)linaro.org>
---
drivers/thermal/cpu_cooling.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
index 6509c61..d5e4ea8 100644
--- a/drivers/thermal/cpu_cooling.c
+++ b/drivers/thermal/cpu_cooling.c
@@ -776,7 +776,13 @@ __cpufreq_cooling_register(struct device_node *np,
char dev_name[THERMAL_NAME_LENGTH];
struct cpufreq_frequency_table *pos, *table;
unsigned int freq, i, num_cpus;
- int ret;
+ int ret, cpu;
+
+ for_each_cpu(cpu, clip_cpus) {
+ table = cpufreq_frequency_get_table(cpu);
+ if (table)
+ break;
+ }
table = cpufreq_frequency_get_table(cpumask_first(clip_cpus));
if (!table) {
--
1.9.1
In the ACPI 5.1 version of the spec, the struct for the GICC subtable
(struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in
ACPI 6.0, the struct is 80 bytes long. But, there is only one definition
in ACPICA for this struct -- and that is the 6.0 version. Hence, when
BAD_MADT_ENTRY() compares the struct size to the length in the GICC
subtable, it fails if 5.1 structs are in use, and there are systems in
the wild that have them.
Note that this was found in linux-next and these patches apply against
that tree and the arm64 kernel tree; 4.1 does not appear to have this
problem since it still has the 5.1 struct definition.
Though there is precedent in ia64 code for ignoring the changes in size,
this patch set instead verifies correctness. The first patch adds the
BAD_MADT_GICC_ENTRY() macro to check the GICC subtable only, accounting
for the difference in specification versions that are possible. The
second patch replaces BAD_MADT_ENTRY usage with the BAD_MADT_GICC_ENTRY
macro in arm64 code, which is currently the only architecture affected.
The BAD_MADT_ENTRY() will continue to work as is for all other MADT
subtables.
I have tested these patches on an APM Mustang with version 1.15 firmware,
where the problem was found, and they fix the problem -- i.e., the system
will boot with either Linux 4.1 or linux-next kernels using the same ACPI
5.1 compatible firmware.
Changes for v4:
-- Reword the cover letter to reflect smaller patch set
-- Simplify BAD_MADT_GICC_ENTRY to the minimum needed; this removed
the need for the first patch containing version number macros (Rafael)
-- Simplify determining the GICC subtable length (Catalin)
Changes for v3:
-- Modified the macros for using spec version numbers in order
to make them clearer (Rafael, Hanjun)
-- Moved the definition of the BAD_MADT_GICC_ENTRY macro to an
arm64-specific header file since only this architecture uses
the GICC subtable (Rafael)
-- Added Reviewed-by (Hanjun) and Acked-by (Will) tags to 3/3, the
only unchanged patch; other tags could be applied but the patches
have changed.
-- Added Fixes: tag to patches
Changes for v2:
-- Replace magic constants with proper defines (Lorenzo)
-- Minor syntax clean-up noted by checkpatch
-- Send out CCs properly this time
-- Minor clean-up of the paragraphs in this cover letter
Al Stone (2):
ACPI / ARM64: add BAD_MADT_GICC_ENTRY() macro
ACPI / ARM64 : use the new BAD_MADT_GICC_ENTRY macro
arch/arm64/include/asm/acpi.h | 8 ++++++++
arch/arm64/kernel/smp.c | 2 +-
drivers/irqchip/irq-gic.c | 2 +-
3 files changed, 10 insertions(+), 2 deletions(-)
--
2.4.3
This patchset implements a clock driver for STM32F42xxx and STM32F43xxx
series devices.
There are a few small caveats at the present:
1. Relies on "Add support to STMicroeletronics STM32 family", v8 by
Maxime Coquelin:
http://thread.gmane.org/gmane.linux.kernel.cross-arch/27569
2. Allocating ~80 clock components appears to fragment memory enough
to prevent busybox (.text is ~300K, non-XIP) from running getty.
I have to use "init=/bin/sh" to avoid OOM problems.
3. Support for I2S and SAI is not included in this patchset.
Daniel Thompson (3):
dt-bindings: Document the STM32F4 clock bindings
clk: stm32: Add clock driver for STM32F4[23]xxx devices
ARM: dts: stm32f429: Adopt STM32F4 clock driver
.../devicetree/bindings/clock/st,stm32-rcc.txt | 65 ++++
arch/arm/boot/dts/stm32f429.dtsi | 83 ++---
drivers/clk/Makefile | 1 +
drivers/clk/clk-stm32f4.c | 365 +++++++++++++++++++++
4 files changed, 457 insertions(+), 57 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/st,stm32-rcc.txt
create mode 100644 drivers/clk/clk-stm32f4.c
--
2.1.0