* [PATCH v2 3/3] clk: uniphier: add cpufreq data for LD11, LD20 SoCs
From: Masahiro Yamada @ 2016-11-24 5:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967061-25975-1-git-send-email-yamada.masahiro@socionext.com>
Add more data to 64bit SoCs for the cpufreq support.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- Drop clock data of 32 bit SoCs. Add 64 bit SoC data for now.
drivers/clk/uniphier/clk-uniphier-sys.c | 32 ++++++++++++++++++++++++++++++++
drivers/clk/uniphier/clk-uniphier.h | 30 +++++++++++++++++++++++++++++-
2 files changed, 61 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/uniphier/clk-uniphier-sys.c b/drivers/clk/uniphier/clk-uniphier-sys.c
index 5d02999..d049316 100644
--- a/drivers/clk/uniphier/clk-uniphier-sys.c
+++ b/drivers/clk/uniphier/clk-uniphier-sys.c
@@ -125,16 +125,35 @@ const struct uniphier_clk_data uniphier_pxs2_sys_clk_data[] = {
};
const struct uniphier_clk_data uniphier_ld11_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("cpll", -1, "ref", 392, 5), /* 1960 MHz */
+ UNIPHIER_CLK_FACTOR("mpll", -1, "ref", 64, 1), /* 1600 MHz */
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("vspll", -1, "ref", 80, 1), /* 2000 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
UNIPHIER_LD11_SYS_CLK_STDMAC(8), /* HSC, MIO */
UNIPHIER_CLK_FACTOR("usb2", -1, "ref", 24, 25),
+ /* CPU gears */
+ UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("mpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV3("spll", 3, 4, 8),
+ /* Note: both gear1 and gear4 are spll/4. This is not a bug. */
+ UNIPHIER_CLK_CPUGEAR("cpu-ca53", 33, 0x8080, 0xf, 8,
+ "cpll/2", "spll/4", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ipp", 34, 0x8100, 0xf, 8,
+ "mpll/2", "spll/4", "mpll/3", "spll/3",
+ "spll/4", "spll/8", "mpll/4", "mpll/8"),
{ /* sentinel */ }
};
const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] = {
+ UNIPHIER_CLK_FACTOR("cpll", -1, "ref", 88, 1), /* ARM: 2200 MHz */
+ UNIPHIER_CLK_FACTOR("gppll", -1, "ref", 52, 1), /* Mali: 1300 MHz */
+ UNIPHIER_CLK_FACTOR("mpll", -1, "ref", 64, 1), /* Codec: 1600 MHz */
UNIPHIER_CLK_FACTOR("spll", -1, "ref", 80, 1), /* 2000 MHz */
+ UNIPHIER_CLK_FACTOR("s2pll", -1, "ref", 88, 1), /* IPP: 2200 MHz */
+ UNIPHIER_CLK_FACTOR("vppll", -1, "ref", 504, 5), /* 2520 MHz */
UNIPHIER_CLK_FACTOR("uart", 0, "spll", 1, 34),
UNIPHIER_CLK_FACTOR("i2c", 1, "spll", 1, 40),
UNIPHIER_LD20_SYS_CLK_SD,
@@ -147,5 +166,18 @@ const struct uniphier_clk_data uniphier_ld20_sys_clk_data[] = {
UNIPHIER_CLK_GATE("usb30", 14, NULL, 0x210c, 14),
UNIPHIER_CLK_GATE("usb30-phy0", 16, NULL, 0x210c, 12),
UNIPHIER_CLK_GATE("usb30-phy1", 17, NULL, 0x210c, 13),
+ /* CPU gears */
+ UNIPHIER_CLK_DIV4("cpll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("spll", 2, 3, 4, 8),
+ UNIPHIER_CLK_DIV4("s2pll", 2, 3, 4, 8),
+ UNIPHIER_CLK_CPUGEAR("cpu-ca72", 32, 0x8000, 0xf, 8,
+ "cpll/2", "spll/2", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ca53", 33, 0x8080, 0xf, 8,
+ "cpll/2", "spll/2", "cpll/3", "spll/3",
+ "spll/4", "spll/8", "cpll/4", "cpll/8"),
+ UNIPHIER_CLK_CPUGEAR("cpu-ipp", 34, 0x8100, 0xf, 8,
+ "s2pll/2", "spll/2", "s2pll/3", "spll/3",
+ "spll/4", "spll/8", "s2pll/4", "s2pll/8"),
{ /* sentinel */ }
};
diff --git a/drivers/clk/uniphier/clk-uniphier.h b/drivers/clk/uniphier/clk-uniphier.h
index 62816f8..81d7e5c 100644
--- a/drivers/clk/uniphier/clk-uniphier.h
+++ b/drivers/clk/uniphier/clk-uniphier.h
@@ -75,6 +75,20 @@ struct uniphier_clk_data {
};
};
+#define UNIPHIER_CLK_CPUGEAR(_name, _idx, _regbase, _mask, \
+ _num_parents, ...) \
+ { \
+ .name = (_name), \
+ .type = UNIPHIER_CLK_TYPE_CPUGEAR, \
+ .idx = (_idx), \
+ .cpugear = { \
+ .parent_names = { __VA_ARGS__ }, \
+ .num_parents = (_num_parents), \
+ .regbase = (_regbase), \
+ .mask = (_mask) \
+ }, \
+ }
+
#define UNIPHIER_CLK_FACTOR(_name, _idx, _parent, _mult, _div) \
{ \
.name = (_name), \
@@ -87,7 +101,6 @@ struct uniphier_clk_data {
}, \
}
-
#define UNIPHIER_CLK_GATE(_name, _idx, _parent, _reg, _bit) \
{ \
.name = (_name), \
@@ -100,6 +113,21 @@ struct uniphier_clk_data {
}, \
}
+#define UNIPHIER_CLK_DIV(parent, div) \
+ UNIPHIER_CLK_FACTOR(parent "/" #div, -1, parent, 1, div)
+
+#define UNIPHIER_CLK_DIV2(parent, div0, div1) \
+ UNIPHIER_CLK_DIV(parent, div0), \
+ UNIPHIER_CLK_DIV(parent, div1)
+
+#define UNIPHIER_CLK_DIV3(parent, div0, div1, div2) \
+ UNIPHIER_CLK_DIV2(parent, div0, div1), \
+ UNIPHIER_CLK_DIV(parent, div2)
+
+#define UNIPHIER_CLK_DIV4(parent, div0, div1, div2, div3) \
+ UNIPHIER_CLK_DIV2(parent, div0, div1), \
+ UNIPHIER_CLK_DIV2(parent, div2, div3)
+
struct clk_hw *uniphier_clk_register_cpugear(struct device *dev,
struct regmap *regmap,
const char *name,
--
2.7.4
^ permalink raw reply related
* [PATCH v4 0/2] da8xx: fix section mismatch in new drivers
From: Sekhar Nori @ 2016-11-24 6:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479908400-10136-1-git-send-email-bgolaszewski@baylibre.com>
On Wednesday 23 November 2016 07:09 PM, Bartosz Golaszewski wrote:
> Sekhar noticed there's a section mismatch in the da8xx-mstpri and
> da8xx-ddrctl drivers. This is caused by calling
> of_flat_dt_get_machine_name() which has an __init annotation.
>
> This series makes the drivers drop the call and not print the
> machine name in the error message.
Applied both. Thanks!
Regards,
Sekhar
^ permalink raw reply
* ath9k ARMv7 OOPS in v4.8.6, v4.2.8
From: miaoqing at codeaurora.org @ 2016-11-24 6:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aaba8b1e30dd4c22be52e50befb202b2@aptaiexm02f.ap.qualcomm.com>
>> Okay, so i was 0, so running UP probably isn't going to help. r7 is
>> also spec_priv->rfs_chan_spec_scan.
>>
>> So, I think the question is... how is this NULL - and has it always
>> been NULL...
>
> The problem appears to be that ath_cmn_process_fft() isn't called that
> often. When it is, it crashes in ath_cmn_is_fft_buf_full() because
> spec_priv->rfs_chan_spec_scan is NULL when ATH9K_DEBUGFS=n. :-(
>
> I'm running with ATH9K_DEBUGFS=y now. If it goes a couple of days
> without crashing, I'll gin up a patch.
>
A similar patch was applied to ath-next branch:
https://patchwork.kernel.org/patch/9431163/.
--
Miaoqing
^ permalink raw reply
* [GIT PULL 0/3] ARM: exynos: Second round for v4.10
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
Second, probably last round of patches for v4.10.
Best regards,
Krzysztof
^ permalink raw reply
* [GIT PULL 1/3] ARM: exynos: Soc/mach for v4.10
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
This contains previous dts branch because SCU node in dts is needed
prior to removing it from mach code.
Below you will find full pull request and one stripped from dependency.
Best regards,
Krzysztof
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-soc-4.10
for you to fetch changes up to c689de56c0a7c8387ea00509f94fa483ae61d979:
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms (2016-11-23 19:34:55 +0200)
----------------------------------------------------------------
Samsung mach/soc update for v4.10:
1. Use SCU mapping from Device Tree instead of statically mapped one.
2. Drop fixed requirement for HZ=200 on Samsung platforms.
----------------------------------------------------------------
Javier Martinez Canillas (1):
ARM: dts: exynos: Document eMMC/SD/SDIO devices in Snow and Peach boards
Krzysztof Kozlowski (3):
ARM: dts: exynos: Remove exynos4415.dtsi
Merge tag 'samsung-dt-4.10' into next/soc
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
Pankaj Dubey (4):
ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
ARM: dts: exynos: Add SCU device node to exynos4.dtsi
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
Randy Li (2):
ARM: dts: exynos: Add TOPEET itop core board SCP package version
ARM: dts: exynos: Add TOPEET itop elite based board
Sylwester Nawrocki (3):
ARM: dts: exynos: Remove "simple-bus" compatible from fimc-is node
ARM: dts: exynos: Add entries for sound support on Odroid-XU board
ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
.../bindings/arm/samsung/samsung-boards.txt | 3 +
arch/arm/Kconfig | 3 +-
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/exynos4.dtsi | 5 +
arch/arm/boot/dts/exynos4412-itop-elite.dts | 240 ++++++++
arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi | 501 ++++++++++++++++
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 575 ------------------
arch/arm/boot/dts/exynos4415.dtsi | 650 ---------------------
arch/arm/boot/dts/exynos4x12.dtsi | 2 +-
arch/arm/boot/dts/exynos5250-snow-common.dtsi | 4 +
arch/arm/boot/dts/exynos5410-odroidxu.dts | 69 +++
arch/arm/boot/dts/exynos5410-pinctrl.dtsi | 9 +
arch/arm/boot/dts/exynos5410.dtsi | 59 ++
arch/arm/boot/dts/exynos5420-peach-pit.dts | 3 +
arch/arm/boot/dts/exynos5800-peach-pi.dts | 3 +
arch/arm/mach-exynos/common.h | 6 +-
arch/arm/mach-exynos/exynos.c | 22 -
arch/arm/mach-exynos/include/mach/map.h | 2 -
arch/arm/mach-exynos/platsmp.c | 65 +--
arch/arm/mach-exynos/pm.c | 4 +-
arch/arm/mach-exynos/suspend.c | 4 +-
arch/arm/mach-s3c24xx/common.c | 76 +++
arch/arm/plat-samsung/include/plat/map-s5p.h | 4 -
23 files changed, 1004 insertions(+), 1306 deletions(-)
create mode 100644 arch/arm/boot/dts/exynos4412-itop-elite.dts
create mode 100644 arch/arm/boot/dts/exynos4412-itop-scp-core.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415-pinctrl.dtsi
delete mode 100644 arch/arm/boot/dts/exynos4415.dtsi
Pull request details for Soc only:
##################################
----------------------------------------------------------------
Samsung mach/soc update for v4.10:
1. Use SCU mapping from Device Tree instead of statically mapped one.
2. Drop fixed requirement for HZ=200 on Samsung platforms.
----------------------------------------------------------------
Krzysztof Kozlowski (1):
ARM: Drop fixed 200 Hz timer requirement from Samsung platforms
Pankaj Dubey (3):
ARM: EXYNOS: Remove static mapping of SCU SFR
ARM: EXYNOS: Remove unused soc_is_exynos{4,5}
ARM: EXYNOS: Remove smp_init_cpus hook from platsmp.c
Sylwester Nawrocki (1):
ARM: S3C24XX: Add DMA slave maps for remaining s3c24xx SoCs
^ permalink raw reply
* [GIT PULL 2/3] ARM: dts: exynos: DT for v4.10, second round
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
On top of previous pull/tag.
Possible trivial conflict:
--- a/arch/arm/boot/dts/exynos5440.dtsi
+++ b/arch/arm/boot/dts/exynos5440.dtsi
@@@ -197,10 -188,10 +197,10 @@@
};
gmac: ethernet at 00230000 {
- compatible = "snps,dwmac-3.70a";
+ compatible = "snps,dwmac-3.70a", "snps,dwmac";
reg = <0x00230000 0x8000>;
interrupt-parent = <&gic>;
- interrupts = <0 31 4>;
+ interrupts = <GIC_SPI 31 4>;
interrupt-names = "macirq";
phy-mode = "sgmii";
clocks = <&clock CLK_GMAC0>;
Best regards,
Krzysztof
The following changes since commit 05a3589f46f913fbe91704f12fdca46a0eb0a27b:
ARM: dts: exynos: Add SCU device node to exynos4.dtsi (2016-11-05 17:39:50 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt-4.10-2
for you to fetch changes up to 79700041b37f0aca5da3ea27858ad6c42f99a474:
ARM: dts: exynos: Remove the cd-gpios property for eMMC of Odroid XU3/4 (2016-11-23 19:17:11 +0200)
----------------------------------------------------------------
Samsung DeviceTree second update for v4.10:
1. Cleanups in MSHC nodes.
2. Enable ADC on Odroid boards.
3. Fix interrupt flags on recently added DMA sound nodes in Exynos5410.
----------------------------------------------------------------
Jaehoon Chung (2):
ARM: dts: exynos: Replace "clock-freq-min-max" with "max-frequency"
ARM: dts: exynos: Remove the cd-gpios property for eMMC of Odroid XU3/4
Krzysztof Kozlowski (1):
ARM: dts: exynos: Fix invalid GIC interrupt flags in audio block of Exynos5410
Markus Reichl (1):
ARM: dts: exynos: Add ADCs on 4412 and 5422 based odroid boards.
Niklas Cassel (1):
ARM: dts: exynos: Specify snps, dwmac in compatible string for gmac
arch/arm/boot/dts/exynos3250-artik5-eval.dts | 2 +-
arch/arm/boot/dts/exynos3250-artik5.dtsi | 2 +-
arch/arm/boot/dts/exynos3250-monk.dts | 2 +-
arch/arm/boot/dts/exynos3250-rinato.dts | 2 +-
arch/arm/boot/dts/exynos4412-odroidx.dts | 5 +++++
arch/arm/boot/dts/exynos5410.dtsi | 4 ++--
arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 12 +++++++++++-
arch/arm/boot/dts/exynos5440.dtsi | 2 +-
8 files changed, 23 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL 3/3] arm64: dts: exynos: DT for v4.10, second round
From: Krzysztof Kozlowski @ 2016-11-24 6:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479967709-6619-1-git-send-email-krzk@kernel.org>
Hi,
On top of previous pull/tag.
Best regards,
Krzysztof
The following changes since commit 8ac46fc57df82efbc19194dddd335b6c7a960c31:
arm64: dts: exynos: Add dts file for Exynos5433-based TM2E board (2016-11-03 22:19:57 +0200)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux.git tags/samsung-dt64-4.10-2
for you to fetch changes up to 2a4c744fcb1549023478e4b9e724d268d8202158:
arm64: dts: exynos: Enable HS400 mode for eMMC for TM2 (2016-11-23 19:27:56 +0200)
----------------------------------------------------------------
Samsung DeviceTree arm64 second update for v4.10:
1. Add Performance Monitor Unit to Exynos7.
2. Add MFC, JPEG and Gscaler to Exynos5433 based TM2 board.
3. Cleanups and fixes for recently added TM2 and TM2E boards.
----------------------------------------------------------------
Alim Akhtar (1):
arm64: dts: Add ARM PMU node for exynos7
Jaehoon Chung (2):
arm64: dts: exynos: Add the mshc_2 node for supporting T-Flash
arm64: dts: exynos: Enable HS400 mode for eMMC for TM2
Marek Szyprowski (8):
arm64: dts: exynos: Fix IRQ type flags for Exynos5433 SoC
arm64: dts: exynos: Fix FSYS CMU parent clocks in Exynos5433 SoC
arm64: dts: exynos: Add missing parent clocks to audio block in Exynos5433 SoC
arm64: dts: exynos: Move FSYS CMU configuration from Exynos5433 dtsi to TM2 dts
arm64: dts: exynos: TM2 - remove unused UART3 and set clocks directly on CMU
arm64: dts: exynos: TM2 - add support for GScaler devices
arm64: dts: exynos: TM2 - add support for JPEG codec device
arm64: dts: exynos: TM2 - add support for MFC video codec device
Sylwester Nawrocki (1):
arm64: dts: exynos: Assign parent clock of the clkout clock for TM2 board
arch/arm64/boot/dts/exynos/exynos5433-pinctrl.dtsi | 22 +-
arch/arm64/boot/dts/exynos/exynos5433-tm2.dts | 85 +++++-
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 286 ++++++++++++++-------
arch/arm64/boot/dts/exynos/exynos7.dtsi | 18 +-
4 files changed, 306 insertions(+), 105 deletions(-)
^ permalink raw reply
* Re: [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: MyungJoo Ham @ 2016-11-24 6:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CGME20161124061416epcms1p44a0152bca14312f1229cab835ea0297f@epcms1p4>
On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
> Hi MyungJoo Ham,
[]
>>
>> We still need to sync the all status even i call target() in
>> devfreq_suspend/resume_device
>> directly, so still need update_devfreq() other setp except
>> devfreq->governor->get_target_freq(devfreq, &freq);
>
> And i think it better to be governor behaviors, for userspace they may not
> want to change
> the suspend frequency like other governor, the frequency should decide by
> the user, if they
> want this function, they should like other governor to rigister a
> devfreq_monitor_suspend().
> What do you think about my rev6 patch?
If I understand the intention correctly, this is for the stability of
the device due to the behavior or bootloader/SoC-initializer, which
has nothing to do with governors.
Even if users are using userspace, as long as they set the custom
frequencies lower than the default, they have the possibility of
being unstable as ondemand is going to have.
To reuse the update_devfreq() code, you may do something like:
static int _update_freq(struct devfreq *devfreq, bool is_suspending)
{
/* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
}
int update_freq(struct devfreq *devfreq)
{
return _update_freq(devfreq, false);
}
There should be other good non-invasive methods that are not governoe-specific as well.
Cheers,
MyungJoo
^ permalink raw reply
* [PATCH 1/2] ARM: omap2: am437x: rollback to use omap3_gptimer_timer_init()
From: Keerthy @ 2016-11-24 6:19 UTC (permalink / raw)
To: linux-arm-kernel
From: Grygorii Strashko <grygorii.strashko@ti.com>
The commit 55ee7017ee31 ("arm: omap2: board-generic: use
omap4_local_timer_init for AM437x") unintentionally changes the
clocksource devices for AM437x from OMAP GP Timer to SyncTimer32K.
Unfortunately, the SyncTimer32K is starving from frequency deviation
as mentioned in commit 5b5c01359152 ("ARM: OMAP2+: AM43x: Use gptimer
as clocksource") and, as reported by Franklin [1], even its monotonic
nature is under question (most probably there is a HW issue, but it's
still under investigation).
Taking into account above facts It's reasonable to rollback to the use
of omap3_gptimer_timer_init().
[1] http://www.spinics.net/lists/linux-omap/msg127425.html
Reported-by: Cooper Jr., Franklin <fcooper@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 2 +-
arch/arm/mach-omap2/timer.c | 9 +++++----
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 36d9943..dc9e34e 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -304,7 +304,7 @@ static void __init rx51_reserve(void)
.init_late = am43xx_init_late,
.init_irq = omap_gic_of_init,
.init_machine = omap_generic_init,
- .init_time = omap4_local_timer_init,
+ .init_time = omap3_gptimer_timer_init,
.dt_compat = am43_boards_compat,
.restart = omap44xx_restart,
MACHINE_END
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 5e2e221..b2f2448 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -510,18 +510,19 @@ void __init omap3_secure_sync32k_timer_init(void)
}
#endif /* CONFIG_ARCH_OMAP3 */
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX)
+#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_SOC_AM33XX) || \
+ defined(CONFIG_SOC_AM43XX)
void __init omap3_gptimer_timer_init(void)
{
__omap_sync32k_timer_init(2, "timer_sys_ck", NULL,
1, "timer_sys_ck", "ti,timer-alwon", true);
-
- clocksource_probe();
+ if (of_have_populated_dt())
+ clocksource_probe();
}
#endif
#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5) || \
- defined(CONFIG_SOC_DRA7XX) || defined(CONFIG_SOC_AM43XX)
+ defined(CONFIG_SOC_DRA7XX)
static void __init omap4_sync32k_timer_init(void)
{
__omap_sync32k_timer_init(1, "timer_32k_ck", "ti,timer-alwon",
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] ARM: omap: timers: reduce rating of gp_timer clocksource
From: Keerthy @ 2016-11-24 6:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479968355-18860-1-git-send-email-j-keerthy@ti.com>
From: Grygorii Strashko <grygorii.strashko@ti.com>
Now ARM Global timer (rating 300) will not be selected as clocksource,
because it's initialized after OMAP GP Timer (rating 300) and
Timekeeping core will not allow to replace clocksource with new one if
both of them have the same rating.
Reduce rating of OMAP GP Timer (300->290) when it's used as
clocksource device - this will allow to select ARM Global timer (300)
as clocksource when enabled.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index b2f2448..a0dbb0b 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -376,7 +376,7 @@ static cycle_t clocksource_read_cycles(struct clocksource *cs)
}
static struct clocksource clocksource_gpt = {
- .rating = 300,
+ .rating = 290,
.read = clocksource_read_cycles,
.mask = CLOCKSOURCE_MASK(32),
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
--
1.9.1
^ permalink raw reply related
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 6:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123171302.GD19856@linaro.org>
On Wed, Nov 23, 2016 at 10:13:02AM -0700, Mathieu Poirier wrote:
> On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives characters, this needs help from the UART drivers. The
> > LED triggers are registered in uart_add_led_triggers() called from
> > the UART drivers which want to support LED triggers. All the driver
> > has to do then is to call uart_led_trigger_[tx|rx] to indicate
> > activite.
>
> Hello Sascha,
>
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> > drivers/tty/serial/serial_core.c | 73 ++++++++++++++++++++++++++++++++++++++++
> > include/linux/serial_core.h | 10 ++++++
> > 2 files changed, 83 insertions(+)
> >
> > diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
> > index f2303f3..3e8afb7 100644
> > --- a/drivers/tty/serial/serial_core.c
> > +++ b/drivers/tty/serial/serial_core.c
> > @@ -34,6 +34,7 @@
> > #include <linux/serial_core.h>
> > #include <linux/delay.h>
> > #include <linux/mutex.h>
> > +#include <linux/leds.h>
> >
> > #include <asm/irq.h>
> > #include <asm/uaccess.h>
> > @@ -2703,6 +2704,77 @@ static const struct attribute_group tty_dev_attr_group = {
> > .attrs = tty_dev_attrs,
> > };
> >
> > +void uart_led_trigger_tx(struct uart_port *uport)
> > +{
> > + unsigned long delay = 50;
> > +
> > + led_trigger_blink_oneshot(uport->led_trigger_tx, &delay, &delay, 0);
> > +}
> > +
> > +void uart_led_trigger_rx(struct uart_port *uport)
> > +{
> > + unsigned long delay = 50;
> > +
> > + led_trigger_blink_oneshot(uport->led_trigger_rx, &delay, &delay, 0);
>
> For both rx/tx the core constrains the delay_on/off along with the inversion.
> Instead of adding the led_trigger_rx/tx and led_trigger_rx/tx_name to the
> struct uart_port, wouldn't it be better to add a new struct led_trigger that
> would encapsulate those along wit the on/off delay and the inversion?
>
> That way those values could be communicated to the core at registration time
> instead of hard-coding things.
Not sure this goes into the right direction. Looking at the other
callers of led_trigger_blink_oneshot() most of them use an arbitrary
blink time of 30 or 50ms and the users seem to be happy with it. There
doesn't seem to be the desire to make that value configurable. If we
want to make it configurable, it's probably better to move the option
to the led device rather than putting the burden on every user of the
led triggers.
I don't think the inversion flag is meant for being configurable. It's
rather used for the default state of the LED. The CAN layer for example
turns the LED on when the interface is up and then blinks (turns off and
on again) on activity. For this it uses the inversion flag.
>
> > +}
> > +
> > +/**
> > + * uart_add_led_triggers - register LED triggers for a UART
> > + * @drv: pointer to the uart low level driver structure for this port
> > + * @uport: uart port structure to use for this port.
> > + *
> > + * Called by the driver to register LED triggers for a UART. It's the
> > + * drivers responsibility to call uart_led_trigger_rx/tx on received
> > + * and transmitted chars then.
> > + */
> > +int uart_add_led_triggers(struct uart_driver *drv, struct uart_port *uport)
> > +{
> > + int ret;
> > +
> > + if (!IS_ENABLED(CONFIG_LEDS_TRIGGERS))
> > + return 0;
>
> Since this is a public interface, checking for valid led_trigger_tx/rx before
> moving on with the rest of the initialisation is probably a good idea.
What do you mean? Should we return an error when CONFIG_LEDS_TRIGGERS is
disabled?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 0/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
This series disables the display pipeline by default, and re-enables
it for the A31 Hummingbird, which already had its display pipeline
enabled.
The series can go in after 4.10-rc1, as a fix, but should not be delayed
till the next release.
Regards
ChenYu
Chen-Yu Tsai (2):
ARM: dts: sun6i: Disable display pipeline by default
ARM: dts: sun6i: hummingbird: Enable display engine again
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
2 files changed, 5 insertions(+)
--
2.10.2
^ permalink raw reply
* [PATCH 1/2] ARM: dts: sun6i: Disable display pipeline by default
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
While we now support the internal display pipeline found on sun6i, it
is possible that we are unable to enable the display for some boards,
due to a lack of drivers for the panels or bridges found on them. If
the display pipeline is enabled, the driver will try to enable, and
possibly screw up the simple framebuffer U-boot had configured.
Disable the display pipeline by default.
Fixes: 6d0e5b70be13 ("ARM: dts: sun6i: Add device nodes for first
display pipeline")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 20a0331ddfb5..4662d3344cd2 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -234,6 +234,7 @@
de: display-engine {
compatible = "allwinner,sun6i-a31-display-engine";
allwinner,pipelines = <&fe0>;
+ status = "disabled";
};
soc at 01c00000 {
--
2.10.2
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sun6i: hummingbird: Enable display engine again
From: Chen-Yu Tsai @ 2016-11-24 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124064339.12615-1-wens@csie.org>
Now that we disable the display engine by default, we need to re-enable
it for the Hummingbird A31, which already had its display pipeline
enabled.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
---
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index b168d6df2b30..83643bbd51dc 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -140,6 +140,10 @@
cpu-supply = <®_dcdc3>;
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
status = "okay";
};
--
2.10.2
^ permalink raw reply related
* [GIT PULL] Qualcomm Driver Updates for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit e1ae0a7ee8849e12050933723e433a3d3ee26f7e:
Merge tag 'qcom-drivers-for-4.10' into drivers-for-4.10-2 (2016-11-23 11:01:54 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-drivers-for-4.10-2
for you to fetch changes up to ed19b86e817c5f30d557042f2e8ab68dc93940d4:
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails (2016-11-23 11:03:00 -0600)
----------------------------------------------------------------
Qualcomm ARM Based Driver Updates for v4.10 - Part 2
* Fixup QCOM SCM to support MSM8996
----------------------------------------------------------------
spjoshi at codeaurora.org (3):
dt-bindings: firmware: scm: Add MSM8996 DT bindings
firmware: qcom: scm: Remove core, iface and bus clocks dependency
firmware: qcom: scm: Return PTR_ERR when devm_clk_get fails
.../devicetree/bindings/firmware/qcom,scm.txt | 2 +
drivers/firmware/qcom_scm.c | 49 ++++++++++++++++------
2 files changed, 39 insertions(+), 12 deletions(-)
^ permalink raw reply
* [GIT PULL] Qualcomm ARM64 DT Updates for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit 58432d74c9a7233bcfb23ef1108308dd17980e44:
Merge tag 'qcom-arm64-for-4.10' into arm64-for-4.10-2 (2016-11-23 11:10:57 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-arm64-for-4.10-2
for you to fetch changes up to c987775aa4af1034186ba17f67c21636451dc6d4:
arm64: dts: qcom: msm8916: Add ddr support to sdhc1 (2016-11-24 00:33:26 -0600)
----------------------------------------------------------------
Qualcomm ARM64 Updates for v4.10 - Part 2
* Add SDHC xo clk and 1.8V DDR support
----------------------------------------------------------------
Ritesh Harjani (2):
ARM: dts: Add xo to sdhc clock node on qcom platforms
arm64: dts: qcom: msm8916: Add ddr support to sdhc1
arch/arm64/boot/dts/qcom/msm8916.dtsi | 11 +++++++----
arch/arm64/boot/dts/qcom/msm8996.dtsi | 9 +++++----
2 files changed, 12 insertions(+), 8 deletions(-)
^ permalink raw reply
* [GIT PULL] Qualcomm Device Tree Changes for v4.10 - Part 2
From: Andy Gross @ 2016-11-24 7:05 UTC (permalink / raw)
To: linux-arm-kernel
Hi Olof, Kevin, and Arnd,
Please consider taking this additional set of updates for 4.10. These
apply on top of the previous tagged set of changes.
The following changes since commit d4714a5ab2132e899a531bcd267bd13555244927:
Merge tag 'qcom-dts-for-4.10-1' into dts-for-4.10-2 (2016-11-24 00:24:40 -0600)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/agross/linux.git tags/qcom-dts-for-4.10-2
for you to fetch changes up to a91b2e690d409476d711523be8a83062b9083fb2:
ARM: dts: Add xo to sdhc clock node on qcom platforms (2016-11-24 00:31:02 -0600)
----------------------------------------------------------------
Qualcomm Device Tree Changes for v4.10 - Part 2
* Add SDHC xo clk
----------------------------------------------------------------
Ritesh Harjani (1):
ARM: dts: Add xo to sdhc clock node on qcom platforms
arch/arm/boot/dts/qcom-apq8084.dtsi | 16 ++++++++++------
arch/arm/boot/dts/qcom-msm8974.dtsi | 16 ++++++++++------
2 files changed, 20 insertions(+), 12 deletions(-)
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-24 7:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58368C91.8030502@rock-chips.com>
+ Tobias Jakobi,
Hi Lin,
We need to discuss how to support the suspend-opp of devfreq device.
Now, there are two patch thread for suspend-opp of devfreq.
The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
The Tobias's approach[1] add new devfreq_suspend() and then call it on dpm_suspend()
when entering the suspend state.
[1] [RFC 0/4] PM / devfreq: draft for OPP suspend impl
- https://patchwork.kernel.org/patch/9443323/
- https://patchwork.kernel.org/patch/9443325/
- https://patchwork.kernel.org/patch/9443329/
- https://patchwork.kernel.org/patch/9443331/
I think we need to discuss it together.
Regards,
Chanwoo Choi
On 2016? 11? 24? 15:45, hl wrote:
> Hi MyungJoo Ham,
>
> On 2016?11?24? 14:14, MyungJoo Ham wrote:
>> On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
>>> Hi MyungJoo Ham,
>> []
>>>> We still need to sync the all status even i call target() in
>>>> devfreq_suspend/resume_device
>>>> directly, so still need update_devfreq() other setp except
>>>> devfreq->governor->get_target_freq(devfreq, &freq);
>>> And i think it better to be governor behaviors, for userspace they may not
>>> want to change
>>> the suspend frequency like other governor, the frequency should decide by
>>> the user, if they
>>> want this function, they should like other governor to rigister a
>>> devfreq_monitor_suspend().
>>
>>> What do you think about my rev6 patch?
>> If I understand the intention correctly, this is for the stability of
>> the device due to the behavior or bootloader/SoC-initializer, which
>> has nothing to do with governors.
>>
>> Even if users are using userspace, as long as they set the custom
>> frequencies lower than the default, they have the possibility of
>> being unstable as ondemand is going to have.
>>
>>
>> To reuse the update_devfreq() code, you may do something like:
>>
>> static int _update_freq(struct devfreq *devfreq, bool is_suspending)
>> {
>> /* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
>> }
>> int update_freq(struct devfreq *devfreq)
>> {
>> return _update_freq(devfreq, false);
>> }
>>
>>
>> There should be other good non-invasive methods that are not governoe-specific as well.
>>
> Thanks for your suggestion, i will update the new version soon.
>>
>> Cheers,
>> MyungJoo
>>
>>
>>
>>
>> _______________________________________________
>> Linux-rockchip mailing list
>> Linux-rockchip at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
> --
> Lin Huang
>
^ permalink raw reply
* [PATCH][v2] arm64: Add DTS support for FSL's LS1012A SoC
From: Yao Yuan @ 2016-11-24 7:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479320647-24460-1-git-send-email-harninder.rai@nxp.com>
Hi Shawn and All,
Any comment for this LS1012A platform support patch?
Is this a good enough base for consequence dts update patches?
If yes, I'd like to send some dts patches for DSPI and QSPI based on this patch.
Thanks.
Yao
On 11/17/2016 02:24 AM, Harninder Rai wrote:
> LS1012A features an advanced 64-bit ARM v8 CortexA53 processor with 32 KB
> of parity protected L1-I cache, 32 KB of ECC protected L1-D cache, as well as 256
> KB of ECC protected L2 cache.
>
> Features summary
> One 64-bit ARM-v8 Cortex-A53 core with the following capabilities
> - Arranged as a cluster of one core supporting a 256 KB L2 cache with ECC
> protection
> - Speed up to 800 MHz
> - Parity-protected 32 KB L1 instruction cache and 32 KB L1 data cache
> - Neon SIMD engine
> - ARM v8 cryptography extensions
> One 16-bit DDR3L SDRAM memory controller ARM core-link CCI-400 cache
> coherent interconnect Cryptography acceleration (SEC) One Configurable x3
> SerDes One PCI Express Gen2 controller, supporting x1 operation One serial
> ATA (SATA Gen 3.0) controller One USB 3.0/2.0 controller with integrated PHY
>
> Following levels of DTSI/DTS files have been created for the LS1012A
> SoC family:
>
> - fsl-ls1012a.dtsi:
> DTS-Include file for FSL LS1012A SoC.
>
> - fsl-ls1012a-frdm.dts:
> DTS file for FSL LS1012A FRDM board.
>
> - fsl-ls1012a-qds.dts:
> DTS file for FSL LS1012A QDS board.
>
> - fsl-ls1012a-rdb.dts:
> DTS file for FSL LS1012A RDB board.
>
> Signed-off-by: Harninder Rai <harninder.rai@nxp.com>
> Signed-off-by: Bhaskar Upadhaya <Bhaskar.Upadhaya@nxp.com>
> ---
> Changes in v2: Incorporated Shawn's comments
> - Brief introduction of the SoC in commit message
> - Alphabetic ordering of labeled nodes
> - Better naming to be used for regulator node
> - Make timer node's comments more readable
> - Sort nodes with unit-address in order of the address
>
> arch/arm64/boot/dts/freescale/Makefile | 3 +
> arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts | 115 ++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts | 128 +++++++++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts | 59 +++++
> arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi | 245
> +++++++++++++++++++++
> 5 files changed, 550 insertions(+)
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-qds.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a-rdb.dts
> create mode 100644 arch/arm64/boot/dts/freescale/fsl-ls1012a.dtsi
>
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-24 7:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836927B.9010205@samsung.com>
Hi Chanwoo Choi,
I think the dev_pm_opp_get_suspend_opp() have implement most of
the funtion, all we need is just define the node in dts, like following:
&dmc_opp_table {
opp06 {
opp-suspend;
};
};
so i think my way semm more simple.
On 2016?11?24? 15:10, Chanwoo Choi wrote:
> + Tobias Jakobi,
>
> Hi Lin,
>
> We need to discuss how to support the suspend-opp of devfreq device.
> Now, there are two patch thread for suspend-opp of devfreq.
>
> The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
> The Tobias's approach[1] add new devfreq_suspend() and then call it on dpm_suspend()
> when entering the suspend state.
>
> [1] [RFC 0/4] PM / devfreq: draft for OPP suspend impl
> - https://patchwork.kernel.org/patch/9443323/
> - https://patchwork.kernel.org/patch/9443325/
> - https://patchwork.kernel.org/patch/9443329/
> - https://patchwork.kernel.org/patch/9443331/
>
> I think we need to discuss it together.
>
> Regards,
> Chanwoo Choi
>
> On 2016? 11? 24? 15:45, hl wrote:
>> Hi MyungJoo Ham,
>>
>> On 2016?11?24? 14:14, MyungJoo Ham wrote:
>>> On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
>>>> Hi MyungJoo Ham,
>>> []
>>>>> We still need to sync the all status even i call target() in
>>>>> devfreq_suspend/resume_device
>>>>> directly, so still need update_devfreq() other setp except
>>>>> devfreq->governor->get_target_freq(devfreq, &freq);
>>>> And i think it better to be governor behaviors, for userspace they may not
>>>> want to change
>>>> the suspend frequency like other governor, the frequency should decide by
>>>> the user, if they
>>>> want this function, they should like other governor to rigister a
>>>> devfreq_monitor_suspend().
>>>> What do you think about my rev6 patch?
>>> If I understand the intention correctly, this is for the stability of
>>> the device due to the behavior or bootloader/SoC-initializer, which
>>> has nothing to do with governors.
>>>
>>> Even if users are using userspace, as long as they set the custom
>>> frequencies lower than the default, they have the possibility of
>>> being unstable as ondemand is going to have.
>>>
>>>
>>> To reuse the update_devfreq() code, you may do something like:
>>>
>>> static int _update_freq(struct devfreq *devfreq, bool is_suspending)
>>> {
>>> /* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
>>> }
>>> int update_freq(struct devfreq *devfreq)
>>> {
>>> return _update_freq(devfreq, false);
>>> }
>>>
>>>
>>> There should be other good non-invasive methods that are not governoe-specific as well.
>>>
>> Thanks for your suggestion, i will update the new version soon.
>>> Cheers,
>>> MyungJoo
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Linux-rockchip mailing list
>>> Linux-rockchip at lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>> --
>> Lin Huang
>>
>
>
>
--
Lin Huang
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: Chanwoo Choi @ 2016-11-24 8:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836980F.6050006@rock-chips.com>
Hi Lin,
On 2016? 11? 24? 16:34, hl wrote:
> Hi Chanwoo Choi,
>
> I think the dev_pm_opp_get_suspend_opp() have implement most of
> the funtion, all we need is just define the node in dts, like following:
>
> &dmc_opp_table {
> opp06 {
> opp-suspend;
> };
> };
Two approaches use the 'opp-suspend' property.
I think that the method to support suspend-opp have to
guarantee following conditions:
- Support the all of devfreq's governors.
- Devfreq framework have the responsibility to change the
frequency/voltage for suspend-opp. If we uses the
new devfreq_suspend(), each devfreq device don't care
how to support the suspend-opp. Just the developer of each
devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
Best Regards,
Chanwoo Choi
>
> so i think my way semm more simple.
>
> On 2016?11?24? 15:10, Chanwoo Choi wrote:
>> + Tobias Jakobi,
>>
>> Hi Lin,
>>
>> We need to discuss how to support the suspend-opp of devfreq device.
>> Now, there are two patch thread for suspend-opp of devfreq.
>>
>> The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
>> The Tobias's approach[1] add new devfreq_suspend() and then call it on dpm_suspend()
>> when entering the suspend state.
>>
>> [1] [RFC 0/4] PM / devfreq: draft for OPP suspend impl
>> - https://patchwork.kernel.org/patch/9443323/
>> - https://patchwork.kernel.org/patch/9443325/
>> - https://patchwork.kernel.org/patch/9443329/
>> - https://patchwork.kernel.org/patch/9443331/
>>
>> I think we need to discuss it together.
>>
>> Regards,
>> Chanwoo Choi
>>
>> On 2016? 11? 24? 15:45, hl wrote:
>>> Hi MyungJoo Ham,
>>>
>>> On 2016?11?24? 14:14, MyungJoo Ham wrote:
>>>> On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
>>>>> Hi MyungJoo Ham,
>>>> []
>>>>>> We still need to sync the all status even i call target() in
>>>>>> devfreq_suspend/resume_device
>>>>>> directly, so still need update_devfreq() other setp except
>>>>>> devfreq->governor->get_target_freq(devfreq, &freq);
>>>>> And i think it better to be governor behaviors, for userspace they may not
>>>>> want to change
>>>>> the suspend frequency like other governor, the frequency should decide by
>>>>> the user, if they
>>>>> want this function, they should like other governor to rigister a
>>>>> devfreq_monitor_suspend().
>>>>> What do you think about my rev6 patch?
>>>> If I understand the intention correctly, this is for the stability of
>>>> the device due to the behavior or bootloader/SoC-initializer, which
>>>> has nothing to do with governors.
>>>>
>>>> Even if users are using userspace, as long as they set the custom
>>>> frequencies lower than the default, they have the possibility of
>>>> being unstable as ondemand is going to have.
>>>>
>>>>
>>>> To reuse the update_devfreq() code, you may do something like:
>>>>
>>>> static int _update_freq(struct devfreq *devfreq, bool is_suspending)
>>>> {
>>>> /* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
>>>> }
>>>> int update_freq(struct devfreq *devfreq)
>>>> {
>>>> return _update_freq(devfreq, false);
>>>> }
>>>>
>>>>
>>>> There should be other good non-invasive methods that are not governoe-specific as well.
>>>>
>>> Thanks for your suggestion, i will update the new version soon.
>>>> Cheers,
>>>> MyungJoo
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Linux-rockchip mailing list
>>>> Linux-rockchip at lists.infradead.org
>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>> --
>>> Lin Huang
>>>
>>
>>
>>
>
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 8:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9fc12b8-d4a7-067d-ef87-03f0aae39bd7@gmail.com>
On Wed, Nov 23, 2016 at 10:57:13AM -0800, Florian Fainelli wrote:
> On 11/23/2016 02:01 AM, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives characters, this needs help from the UART drivers.
>
> Looking at 8250, we call serial8250_tx_chars from __start_tx which is
> called form the uart_ops::start_tx, for RX I sort of agree, since this
> happens in interrupt handler. I suppose some drivers could actually
> queue work but not do it right away though?
RX is not the problem. When characters are received all drivers call
tty_flip_buffer_push() which could be used for LED triggering (either
directly or we replace the calls to tty_flip_buffer_push() with some
wrapper function).
The problem comes with TX. The serial core has a FIFO which gets
characters from the tty layer. There is no function which the serial
drivers could call to read from this FIFO, instead they have to open code
this.
Continuing with the 8250 driver serial8250_tx_chars() is not only called
from __start_tx(), but also from the interrupt handler. Transmission
works without the serial_core ever noticing.
>
> > The LED triggers are registered in uart_add_led_triggers() called from
> > the UART drivers which want to support LED triggers. All the driver
> > has to do then is to call uart_led_trigger_[tx|rx] to indicate
> > activity.
>
> Could we somehow remedy the lack of knowledge from the core as whether
> the HW sends/receives characters first before adding support for LED
> triggers? It would be more generic and future proof to require UART
> drivers to report to the core when they actually TX/RX, and then at the
> core level, utilize that knowledge to perform the LED trigger.
Maybe we could introduce a function to read from the TX FIFO. Having
open coded this in each and every driver is not nice anyway.
>
> Side note: are you positive using drv->dev_name is robust enough on
> systems with many different UART drivers, yet all of them being ttyS*?
If we have different UART drivers, only one of them provides ttyS*, no?
Other drivers will have to use another namespace.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v3] clk: qoriq: added ls1012a clock configuration
From: Scott Wood @ 2016-11-24 8:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479955015-37514-1-git-send-email-yuantian.tang@nxp.com>
On 11/23/2016 08:50 PM, yuantian.tang at nxp.com wrote:
> From: Tang Yuantian <Yuantian.Tang@nxp.com>
>
> Signed-off-by: Tang Yuantian <yuantian.tang@nxp.com>
> ---
> v3:
> - rebased to latest kernel and re-sorted the code
[snip]
> @@ -1316,6 +1334,7 @@ CLK_OF_DECLARE(qoriq_clockgen_2, "fsl,qoriq-clockgen-2.0", clockgen_init);
> CLK_OF_DECLARE(qoriq_clockgen_ls1021a, "fsl,ls1021a-clockgen", clockgen_init);
> CLK_OF_DECLARE(qoriq_clockgen_ls1043a, "fsl,ls1043a-clockgen", clockgen_init);
> CLK_OF_DECLARE(qoriq_clockgen_ls1046a, "fsl,ls1046a-clockgen", clockgen_init);
> +CLK_OF_DECLARE(qoriq_clockgen_ls1012a, "fsl,ls1012a-clockgen", clockgen_init);
> CLK_OF_DECLARE(qoriq_clockgen_ls2080a, "fsl,ls2080a-clockgen", clockgen_init);
You need a better sorting algorithm. :-P
-Scott
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Sascha Hauer @ 2016-11-24 8:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161123100819.GA20137@kroah.com>
On Wed, Nov 23, 2016 at 11:08:19AM +0100, Greg Kroah-Hartman wrote:
> On Wed, Nov 23, 2016 at 11:01:03AM +0100, Sascha Hauer wrote:
> > With this patch the serial core provides LED triggers for RX and TX.
> >
> > As the serial core layer does not know when the hardware actually sends
> > or receives characters, this needs help from the UART drivers. The
> > LED triggers are registered in uart_add_led_triggers() called from
> > the UART drivers which want to support LED triggers. All the driver
> > has to do then is to call uart_led_trigger_[tx|rx] to indicate
> > activity.
BTW last time LED triggers were discussed
(https://patchwork.kernel.org/patch/9212885/) You and Arnd mandated the
triggers should be implemented in the tty layer. By tty layer did you
really mean the tty layer or did you mean serial_core?
We could implement it in the tty layer, but tty doesn't know when the
characters are actually sent. There could be arbitrary time passing
between a tty_operations->put_char and the character being on the wire.
Also I am not sure if we want to have LED triggers for each and every
tty in the system
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v1 & v6 1/2] PM/devfreq: add suspend frequency support
From: hl @ 2016-11-24 8:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5836A1E0.1070707@samsung.com>
Hi Chanwoo Choi,
On 2016?11?24? 16:16, Chanwoo Choi wrote:
> Hi Lin,
>
> On 2016? 11? 24? 16:34, hl wrote:
>> Hi Chanwoo Choi,
>>
>> I think the dev_pm_opp_get_suspend_opp() have implement most of
>> the funtion, all we need is just define the node in dts, like following:
>>
>> &dmc_opp_table {
>> opp06 {
>> opp-suspend;
>> };
>> };
> Two approaches use the 'opp-suspend' property.
>
> I think that the method to support suspend-opp have to
> guarantee following conditions:
> - Support the all of devfreq's governors.
As MyungJoo Ham suggestion, i will set the suspend frequency in
devfreq_suspend_device(),
which will ingore governor.
> - Devfreq framework have the responsibility to change the
> frequency/voltage for suspend-opp. If we uses the
> new devfreq_suspend(), each devfreq device don't care
> how to support the suspend-opp. Just the developer of each
> devfreq device need to add 'opp-suspend' propet to OPP entry in DT file.
Why should support change the voltage in devfreq framework, i think it
shuold be handle in
specific driver, i think the devfreq only handle it can get the right
frequency, then pass it to
specific driver, i think the voltage should handle in the
devfreq->profile->target();
> Best Regards,
> Chanwoo Choi
>
>> so i think my way semm more simple.
>>
>> On 2016?11?24? 15:10, Chanwoo Choi wrote:
>>> + Tobias Jakobi,
>>>
>>> Hi Lin,
>>>
>>> We need to discuss how to support the suspend-opp of devfreq device.
>>> Now, there are two patch thread for suspend-opp of devfreq.
>>>
>>> The Lin's approach modify the devfreq_suspend_device() to support suspend-opp.
>>> The Tobias's approach[1] add new devfreq_suspend() and then call it on dpm_suspend()
>>> when entering the suspend state.
>>>
>>> [1] [RFC 0/4] PM / devfreq: draft for OPP suspend impl
>>> - https://patchwork.kernel.org/patch/9443323/
>>> - https://patchwork.kernel.org/patch/9443325/
>>> - https://patchwork.kernel.org/patch/9443329/
>>> - https://patchwork.kernel.org/patch/9443331/
>>>
>>> I think we need to discuss it together.
>>>
>>> Regards,
>>> Chanwoo Choi
>>>
>>> On 2016? 11? 24? 15:45, hl wrote:
>>>> Hi MyungJoo Ham,
>>>>
>>>> On 2016?11?24? 14:14, MyungJoo Ham wrote:
>>>>> On Thu, Nov 24, 2016 at 11:18 AM, hl <hl@rock-chips.com> wrote:
>>>>>> Hi MyungJoo Ham,
>>>>> []
>>>>>>> We still need to sync the all status even i call target() in
>>>>>>> devfreq_suspend/resume_device
>>>>>>> directly, so still need update_devfreq() other setp except
>>>>>>> devfreq->governor->get_target_freq(devfreq, &freq);
>>>>>> And i think it better to be governor behaviors, for userspace they may not
>>>>>> want to change
>>>>>> the suspend frequency like other governor, the frequency should decide by
>>>>>> the user, if they
>>>>>> want this function, they should like other governor to rigister a
>>>>>> devfreq_monitor_suspend().
>>>>>> What do you think about my rev6 patch?
>>>>> If I understand the intention correctly, this is for the stability of
>>>>> the device due to the behavior or bootloader/SoC-initializer, which
>>>>> has nothing to do with governors.
>>>>>
>>>>> Even if users are using userspace, as long as they set the custom
>>>>> frequencies lower than the default, they have the possibility of
>>>>> being unstable as ondemand is going to have.
>>>>>
>>>>>
>>>>> To reuse the update_devfreq() code, you may do something like:
>>>>>
>>>>> static int _update_freq(struct devfreq *devfreq, bool is_suspending)
>>>>> {
>>>>> /* original contents of update_freq with if statement with is_suspending wrapping get_target_freq */
>>>>> }
>>>>> int update_freq(struct devfreq *devfreq)
>>>>> {
>>>>> return _update_freq(devfreq, false);
>>>>> }
>>>>>
>>>>>
>>>>> There should be other good non-invasive methods that are not governoe-specific as well.
>>>>>
>>>> Thanks for your suggestion, i will update the new version soon.
>>>>> Cheers,
>>>>> MyungJoo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Linux-rockchip mailing list
>>>>> Linux-rockchip at lists.infradead.org
>>>>> http://lists.infradead.org/mailman/listinfo/linux-rockchip
>>>> --
>>>> Lin Huang
>>>>
>>>
>>>
>
>
>
--
Lin Huang
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox