Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Marc Zyngier marc.zyng...@arm.com [150115 09:31]: On 15/01/15 17:04, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:53]: On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote: On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. For the -rc, it seems the wakeupen still needs a fix as based on grepping for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? I think this one is fine. It computes the SPI number based on the hwirq coming from the GIC. That direction is completely unaffected by the linear domain stuff. It is only when you try to use a hardware IRQ as a Linux IRQ that you run into trouble. Yes OK that makes sense. Thanks, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
* Tony Lindgren t...@atomide.com [150115 10:04]: * Marc Zyngier marc.zyng...@arm.com [150115 09:31]: On 15/01/15 17:04, Tony Lindgren wrote: * Marc Zyngier marc.zyng...@arm.com [150115 06:53]: On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote: On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. For the -rc, it seems the wakeupen still needs a fix as based on grepping for OMAP44XX_IRQ_GIC_START. Got any great ideas for that? I think this one is fine. It computes the SPI number based on the hwirq coming from the GIC. That direction is completely unaffected by the linear domain stuff. It is only when you try to use a hardware IRQ as a Linux IRQ that you run into trouble. Yes OK that makes sense. And suspend and resume seem to work with your fix. FYI, to test suspend and resume with wakeups from the serial console, the uart wakeup events need to be enabled under sys: #!/bin/bash uarts=$(find /sys/class/tty/tty[SO]*/power/ -type d 2/dev/null) for uart in $uarts; do echo enabled $uart/wakeup 21 done And after that suspending with echo mem /sys/power/state should wake to a serial interrupt. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: SAMSUNG: remove unused DMA infrastructure
Am Donnerstag, 15. Januar 2015, 16:16:03 schrieb Arnd Bergmann: Everything uses dmaengine now, so there is no reason to keep this around any longer. Thanks to everyone who was involved in moving the users over to use the dmaengine APIs. Signed-off-by: Arnd Bergmann a...@arndb.de very nice to see this finished :-) Reviewed-by: Heiko Stuebner he...@sntech.de -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: SAMSUNG: remove unused DMA infrastructure
Everything uses dmaengine now, so there is no reason to keep this around any longer. Thanks to everyone who was involved in moving the users over to use the dmaengine APIs. Signed-off-by: Arnd Bergmann a...@arndb.de --- Documentation/arm/Samsung-S3C24XX/DMA.txt| 46 - arch/arm/mach-exynos/include/mach/dma.h | 26 - arch/arm/mach-s3c24xx/Kconfig| 42 - arch/arm/mach-s3c24xx/Makefile |7 - arch/arm/mach-s3c24xx/dma-s3c2410.c | 182 --- arch/arm/mach-s3c24xx/dma-s3c2412.c | 150 --- arch/arm/mach-s3c24xx/dma-s3c2440.c | 193 --- arch/arm/mach-s3c24xx/dma-s3c2443.c | 179 --- arch/arm/mach-s3c24xx/dma.c | 1465 -- arch/arm/mach-s3c24xx/include/mach/dma.h | 159 --- arch/arm/mach-s3c64xx/include/mach/dma.h | 15 - arch/arm/plat-samsung/Kconfig| 15 - arch/arm/plat-samsung/Makefile |6 - arch/arm/plat-samsung/dma-ops.c | 146 --- arch/arm/plat-samsung/dma.c | 84 -- arch/arm/plat-samsung/include/plat/dma-core.h| 22 - arch/arm/plat-samsung/include/plat/dma-ops.h | 69 - arch/arm/plat-samsung/include/plat/dma-pl330.h | 121 -- arch/arm/plat-samsung/include/plat/dma-s3c24xx.h | 73 -- arch/arm/plat-samsung/include/plat/dma.h | 130 -- arch/arm/plat-samsung/include/plat/regs-dma.h| 151 --- arch/arm/plat-samsung/s3c-dma-ops.c | 146 --- drivers/dma/Kconfig |2 +- 23 files changed, 1 insertion(+), 3428 deletions(-) diff --git a/Documentation/arm/Samsung-S3C24XX/DMA.txt b/Documentation/arm/Samsung-S3C24XX/DMA.txt deleted file mode 100644 index 3ed82383efea.. --- a/Documentation/arm/Samsung-S3C24XX/DMA.txt +++ /dev/null @@ -1,46 +0,0 @@ - S3C2410 DMA - === - -Introduction - - - The kernel provides an interface to manage DMA transfers - using the DMA channels in the CPU, so that the central - duty of managing channel mappings, and programming the - channel generators is in one place. - - -DMA Channel Ordering - - - Many of the range do not have connections for the DMA - channels to all sources, which means that some devices - have a restricted number of channels that can be used. - - To allow flexibility for each CPU type and board, the - DMA code can be given a DMA ordering structure which - allows the order of channel search to be specified, as - well as allowing the prohibition of certain claims. - - struct s3c24xx_dma_order has a list of channels, and - each channel within has a slot for a list of DMA - channel numbers. The slots are searched in order for - the presence of a DMA channel number with DMA_CH_VALID - or-ed in. - - If the order has the flag DMA_CH_NEVER set, then after - checking the channel list, the system will return no - found channel, thus denying the request. - - A board support file can call s3c24xx_dma_order_set() - to register a complete ordering set. The routine will - copy the data, so the original can be discarded with - __initdata. - - -Authour - -Ben Dooks, -Copyright (c) 2007 Ben Dooks, Simtec Electronics -Licensed under the GPL v2 diff --git a/arch/arm/mach-exynos/include/mach/dma.h b/arch/arm/mach-exynos/include/mach/dma.h deleted file mode 100644 index 201842a3769e.. --- a/arch/arm/mach-exynos/include/mach/dma.h +++ /dev/null @@ -1,26 +0,0 @@ -/* - * Copyright (C) 2010 Samsung Electronics Co. Ltd. - * Jaswinder Singh jassi.b...@samsung.com - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License as published by - * the Free Software Foundation; either version 2 of the License, or - * (at your option) any later version. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - * - * You should have received a copy of the GNU General Public License - * along with this program; if not, write to the Free Software - * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. - */ - -#ifndef __MACH_DMA_H -#define __MACH_DMA_H - -/* This platform uses the common DMA API driver for PL330 */ -#include plat/dma-pl330.h - -#endif /* __MACH_DMA_H */ diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig index 9eb22297cbe1..79c49ff77f6e 100644 --- a/arch/arm/mach-s3c24xx/Kconfig +++ b/arch/arm/mach-s3c24xx/Kconfig @@ -29,7 +29,6 @@ config CPU_S3C2410 default y select CPU_ARM920T select S3C2410_COMMON_CLK - select S3C2410_DMA if S3C24XX_DMA select
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Could it be because of the polling interval being too long thus it being too slow to ramp up? That's a problem with all polling devfreq drivers, it has been proposed before using pm_qos to to reduce the polling interval when some event indicates that the utilization may grow abruptly in the near future. I don't think pm_qos is the best mechanism for that, maybe something new needs to be devised. Regards, Tomeu Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/16] thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c
Hi Eduardo,
On Wed, Jan 14, 2015 at 02:41:11PM +0100, Lukasz Majewski wrote:
Presented device tree bindings provide data already hardcoded in the
exynos_tmu_data.c file.
After this commit, it should be possible to reuse common thermal
core framework in Exynos SoCs.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Add proper TMU entries for exynos3250.dtsi
Changes for v3:
- Remove type DT properties, which will be extracted from
compatible
- samsung,tmu_ prefix for TMU specific properties has been added
---
arch/arm/boot/dts/exynos3250.dtsi | 2 ++
arch/arm/boot/dts/exynos4.dtsi| 4
arch/arm/boot/dts/exynos4210.dtsi | 21 -
arch/arm/boot/dts/exynos4x12.dtsi | 1 +
arch/arm/boot/dts/exynos5250.dtsi | 5 +++--
arch/arm/boot/dts/exynos5420.dtsi | 28
arch/arm/boot/dts/exynos5440.dtsi | 18 ++
7 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi index 2246549..8cc078c 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -18,6 +18,7 @@
*/
#include skeleton.dtsi
+#include exynos4-cpu-thermal.dtsi
#include dt-bindings/clock/exynos3250.h
/ {
@@ -188,6 +189,7 @@
interrupts = 0 216 0;
clocks = cmu CLK_TMU_APBIF;
clock-names = tmu_apbif;
+ #include exynos4412-tmu-sensor-conf.dtsi
status = disabled;
};
diff --git a/arch/arm/boot/dts/exynos4.dtsi
b/arch/arm/boot/dts/exynos4.dtsi index b8168f1..f18d746 100644
--- a/arch/arm/boot/dts/exynos4.dtsi
+++ b/arch/arm/boot/dts/exynos4.dtsi
@@ -645,4 +645,8 @@
samsung,sysreg = sys_reg;
status = disabled;
};
+
+ tmu: tmu@100C {
+ #include exynos4412-tmu-sensor-conf.dtsi
+ };
};
diff --git a/arch/arm/boot/dts/exynos4210.dtsi
b/arch/arm/boot/dts/exynos4210.dtsi index 2e66df8..7f0e012 100644
--- a/arch/arm/boot/dts/exynos4210.dtsi
+++ b/arch/arm/boot/dts/exynos4210.dtsi
@@ -21,6 +21,7 @@
#include exynos4.dtsi
#include exynos4210-pinctrl.dtsi
+#include exynos4-cpu-thermal.dtsi
/ {
compatible = samsung,exynos4210, samsung,exynos4;
@@ -146,16 +147,34 @@
reg = 0x0386 0x1000;
};
- tmu@100C {
+ tmu: tmu@100C {
compatible = samsung,exynos4210-tmu;
interrupt-parent = combiner;
reg = 0x100C 0x100;
interrupts = 2 4;
clocks = clock CLK_TMU_APBIF;
clock-names = tmu_apbif;
+ samsung,tmu_gain = 15;
+ samsung,tmu_reference_voltage = 7;
status = disabled;
};
+ thermal-zones {
+ cpu_thermal: cpu-thermal {
+ trips {
+ cpu_alert0: cpu-alert-0 {
+ temperature = 85000; /*
millicelsius */
+ };
+ cpu_alert1: cpu-alert-1 {
+ temperature = 10; /*
millicelsius */
+ };
+ cpu_alert2: cpu-alert-2 {
+ temperature = 11; /*
millicelsius */
+ };
+ };
+ };
+ };
+
g2d@1280 {
compatible = samsung,s5pv210-g2d;
reg = 0x1280 0x1000;
diff --git a/arch/arm/boot/dts/exynos4x12.dtsi
b/arch/arm/boot/dts/exynos4x12.dtsi index 93b7040..3ee2031 100644
--- a/arch/arm/boot/dts/exynos4x12.dtsi
+++ b/arch/arm/boot/dts/exynos4x12.dtsi
@@ -19,6 +19,7 @@
#include exynos4.dtsi
#include exynos4x12-pinctrl.dtsi
+#include exynos4-cpu-thermal.dtsi
/ {
aliases {
diff --git a/arch/arm/boot/dts/exynos5250.dtsi
b/arch/arm/boot/dts/exynos5250.dtsi index dd5c3a0..07fd73a 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -20,7 +20,7 @@
#include dt-bindings/clock/exynos5250.h
#include exynos5.dtsi
#include exynos5250-pinctrl.dtsi
-
+#include exynos4-cpu-thermal.dtsi
#include dt-bindings/clock/exynos-audss-clk.h
/ {
@@ -236,12 +236,13 @@
status = disabled;
};
- tmu@1006 {
+ tmu: tmu@1006 {
compatible = samsung,exynos5250-tmu;
reg = 0x1006 0x100;
interrupts = 0 65 0;
clocks = clock CLK_TMU;
clock-names = tmu_apbif;
+ #include exynos4412-tmu-sensor-conf.dtsi
};
thermal-zones {
diff --git a/arch/arm/boot/dts/exynos5420.dtsi
b/arch/arm/boot/dts/exynos5420.dtsi index 517e50f..f5771e5 100644
---
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. -- Regards, Nishanth Menon -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 14/16] thermal: samsung: core: Exynos TMU rework to use device tree for configuration
Hi Eduardo,
On Wed, Jan 14, 2015 at 02:41:12PM +0100, Lukasz Majewski wrote:
This patch brings support for providing configuration via device
tree. Previously this data has been hardcoded in the
exynos_tmu_data.c file. Such approach was not scalable and very
often required copying the whole data.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
---
Changes for v2:
- Adjust exynos_tmu.c code to the newest ti-soc-thermal repository
- Usage of of-thermal.c exported trip points table
Changes for v3:
- Adding exynos_of_get_soc_type() method to set SOC type from
device's compatible string
- samsung,tmu_ prefix for TMU specific properties has been added
---
drivers/thermal/samsung/Makefile | 2 -
drivers/thermal/samsung/exynos_tmu.c | 345
+++
drivers/thermal/samsung/exynos_tmu.h | 53 +- 3 files changed,
226 insertions(+), 174 deletions(-)
diff --git a/drivers/thermal/samsung/Makefile
b/drivers/thermal/samsung/Makefile index c09d830..1e47d0d 100644
--- a/drivers/thermal/samsung/Makefile
+++ b/drivers/thermal/samsung/Makefile
@@ -3,5 +3,3 @@
#
obj-$(CONFIG_EXYNOS_THERMAL) +=
exynos_thermal.o exynos_thermal-y :=
exynos_tmu.o -exynos_thermal-y +=
exynos_tmu_data.o
Can this makefile change be part of the patch that removes
exynos_tmu_data.c?
-exynos_thermal-$(CONFIG_EXYNOS_THERMAL_CORE) +=
exynos_thermal_common.o
Can this makefile change be part of the patch that removes
exynos_thermal_common.c?
Unfortunately, this code cannot be moved to the next patch, in which I
remove the files, since this causes build break of the series.
The code structure as is, provides working, bisectable thermal
solution - thermal and cpu_cooling functionality is preserved across
all commits in the series.
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index ae30f6a..633a9e2 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1,6 +1,10 @@
/*
* exynos_tmu.c - Samsung EXYNOS TMU (Thermal Management Unit)
*
+ * Copyright (C) 2014 Samsung Electronics
+ * Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
+ * Lukasz Majewski l.majew...@samsung.com
+ *
* Copyright (C) 2011 Samsung Electronics
* Donggeun Kim dg77@samsung.com
* Amit Daniel Kachhap amit.kach...@linaro.org
@@ -31,8 +35,8 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
-#include exynos_thermal_common.h
#include exynos_tmu.h
+#include ../thermal_core.h
/* Exynos generic registers */
#define EXYNOS_TMU_REG_TRIMINFO0x0
@@ -115,6 +119,7 @@
#define EXYNOS5440_TMU_TH_RISE4_SHIFT 24
#define EXYNOS5440_EFUSE_SWAP_OFFSET 8
+#define MCELSIUS 1000
/**
* struct exynos_tmu_data : A structure to hold the private data
of the TMU driver
@@ -150,7 +155,8 @@ struct exynos_tmu_data {
struct clk *clk, *clk_sec;
u8 temp_error1, temp_error2;
struct regulator *regulator;
- struct thermal_sensor_conf *reg_conf;
+ struct thermal_zone_device *tzd;
+
int (*tmu_initialize)(struct platform_device *pdev);
void (*tmu_control)(struct platform_device *pdev, bool on);
int (*tmu_read)(struct exynos_tmu_data *data);
@@ -159,6 +165,33 @@ struct exynos_tmu_data {
void (*tmu_clear_irqs)(struct exynos_tmu_data *data);
};
+static void exynos_report_trigger(struct exynos_tmu_data *p)
+{
+ char data[10], *envp[] = { data, NULL };
+ struct thermal_zone_device *tz = p-tzd;
+ unsigned long temp;
+ unsigned int i;
+
+ if (!p) {
+ pr_err(Wrong temperature configuration data\n);
+ return;
+ }
+
+ thermal_zone_device_update(tz);
+
+ mutex_lock(tz-lock);
+ /* Find the level for which trip happened */
+ for (i = 0; i of_thermal_get_ntrips(tz); i++) {
+ tz-ops-get_trip_temp(tz, i, temp);
+ if (tz-last_temperature temp)
+ break;
+ }
+
+ snprintf(data, sizeof(data), %u, i);
+ kobject_uevent_env(tz-device.kobj, KOBJ_CHANGE, envp);
+ mutex_unlock(tz-lock);
+}
+
/*
* TMU treats temperature as a mapped temperature code.
* The temperature is converted differently depending on the
calibration type. @@ -234,14 +267,25 @@ static void
sanitize_temp_error(struct exynos_tmu_data *data, u32 trim_info)
static u32 get_th_reg(struct exynos_tmu_data *data, u32 threshold,
bool falling) {
- struct exynos_tmu_platform_data *pdata = data-pdata;
+ struct thermal_zone_device *tz = data-tzd;
+ const struct thermal_trip * const trips =
+ of_thermal_get_trip_points(tz);
+ unsigned long temp;
int i;
- for (i = 0; i
Re: [v3,06/16] arm: dts: Adding CPU cooling binding for Exynos SoCs
Hi Tobias, Hello, I noticed that this patch mixes spaces and tabs a lot for indentation. Thanks for spotting. It is going to be fixed in v4 of this patch. With best wishes, Tobias -- Best regards, Lukasz Majewski Samsung RD Institute Poland (SRPOL) | Linux Platform Group -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On Thu, Jan 15 2015 at 2:40:16 pm GMT, Nishanth Menon n...@ti.com wrote: On 14:28-20150115, Marc Zyngier wrote: Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). crossbar will never work with legacy static interrupts anyways - since there was never a static interrupt possible - I believe we had removed all the legacy hardcoded interrupt definitions for DRA7. ideally, they should all be dt only now. Yes, I guessed as much after looking at the DRA7XX hwmod. So only OMAP4/5 is b0rken at the moment. I can probably work around it as I did in this example patch, just by changing the compatible strings for the xlate callback. Very ugly. M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL RE-SEND] Samsung fixes for v3.19
On Thu, Jan 15, 2015 at 12:05:18AM +0900, Kukjin Kim wrote: Hi, Oops, it's totally my fault and mistake. Actually my git command for pull-request was correct but the git tool was old version :-( because there are two git in my laptop, anyway sorry for that and I'm resending with signed tag has been created before. Please pull if you're OK with my comments on your questions below. The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-fixes-3.19 for you to fetch changes up to 26d13bf77b8e59adf4953577ba48e1903545bf7f: ARM: exynos_defconfig: Enable LM90 driver (2015-01-12 17:16:32 +0900) Samsung fixes for v3.19 - exynos_defconfig: enable LM90 driver and display panel support - HWMON - SENSORS_LM90 - Direct Rendering Manager (DRM) - DRM bridge registration and lookup framework - Parade ps8622/ps8625 eDP/LVDS bridge - NXP ptn3460 eDP/LVDS bridge - Exynos Fully Interactive Mobile Display controller (FIMD) - Panel registration and lookup framework - Simple panels - Backlight LCD device support - use pmu_system_controller phandle for dp phy : DP PHY requires pmu_system_controller to handle PMU reg. now Merged. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello! Marek Szyprowski wrote: I hope that HDMI display works fine for you. I checked with my panel just now and played around a bit with the DRM (opening, vsync, etc.). However on deinitialization the entire system locked up. I currently haven't hooked the board up to the serial console, otherwise I would've tried to extract some more meaningful information. Going to check again more thoroughly on the weekend what exactly triggers the lockup. With best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL RE-SEND] Samsung exynos7 updates for v3.20
On Thu, Jan 15, 2015 at 12:07:16AM +0900, Kukjin Kim wrote: Hi, Sorry, I'm resending this pull-request because of missing signed-tag. Please pull. If any problems, please let me know. Thanks, Kukjin The following changes since commit 97bf6af1f928216fd6c5a66e8a57bfa95a659672: Linux 3.19-rc1 (2014-12-20 17:08:50 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-dt-64 for you to fetch changes up to 6f56eef1f9aba3747c811780a4768618167d5c97: arm64: Enable ARMv8 based exynos7 SoC support (2014-12-23 00:19:08 +0900) Merged. -Olof -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On 01/15/2015 10:34 PM, Mark Rutland wrote: On Thu, Jan 15, 2015 at 12:52:38PM +, Chanwoo Choi wrote: On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi cwcho...@gmail.com wrote: Hi Mark, On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: Hi Kukjin, On 01/15/2015 01:02 AM, Daniel Lezcano wrote: On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know arch_timer. As you comment, ARCH timer would be used for system timer for ARMv8. But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it on Exynos5433/EXynos7 User-manaual and tested it. I think that exynos_mct.c should support the Exynos 64-bit SoC because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual never includes the detailed information about for ARCH timer(e.g, clock for ARCH timer). I knew that I can get the document of ARCH timer for ARM official site but I think it is insufficient to implement ARCH timer on Exynos SoC. What do you mean by insufficient to implement ARCH timer? As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find I'm so sorry about this mistake. I pressed the send button before completing reply. As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find the clock information for ARCH timer on Exynos SoC user-manual. When I tried to use ARCH timer on Exynos3250, It is not working. We can check this ARCH timer issue of Exynos3250 on following patch[1]: [1] http://www.spinics.net/lists/arm-kernel/msg322943.html Hmm. That is annoying. Your boot code should have been initialising this already. Right, I want to resolve the issue for Exynos3250 but I don't have any information. Maybe this issue should be fixed by the architector of Exynos SoC or any samsung developer who can contact the information of ARCH timer. The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. I agree that ARCH timer is mandatory. I just think that existing exynos-mct.c driver should support the Exynos5/7 SoC because released Exynos5/7 SoC includes already MCT IP for system timer. I'm not opposed to the MCT. My only concern is that a configured and enabled architected timer is mandated by the boot protocol, and is a prerequisite for a functioning kernel. Thanks for your opinion. As I replyed on previous mail, I agree that ARCH timer is necessary. Your initial response made it sound like you expected the MCT alone to be sufficient. I didn't mean it. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 00/16] thermal: exynos: Thermal code rework to use device tree
Hello, while looking through the patchset I noticed the following. In patch 07/16 code is added to drivers/cpufreq/exynos-cpufreq.c, which reminded me of the cpufreq patchset by Thomas Abraham. If I remember correctly then the ultimate goal of the cpufreq 'conversion' is to get rid of the exynos-cpufreq driver is use the cpufreq-cpu0 (now cpufreq-dt) driver for everything. Now, this cpufreq patchset hasn't been updated in a while, so I'm not sure if maybe plans have changed already. But if the goal still is to remove exynos-cpufreq in the end, wouldn't it be better to not add new (functionality-providing) code to it, like this series does? With best wishes, Tobias Lukasz Majewski wrote: 1. Introduction Following patches aim to clean up the current implementation of the thermal framework on Exynos devices. The main goal was to use a generic code for reading thermal configuration (of-thermal.c). Due to that redundant exynos_thermal_common.[h|c] files were removed. Around 400 lines of code (LOC) were removed directly by this patch, which is around 20% of the Exynos thermal code base. This work should NOT bring any functional changes to Exynos thermal subsystem. 2. Patch-set structure Then the cpu_cooling functionality has been preserved to allow cooling devices by reducing operating frequency. Definition of trip points and cpufreq's cooling properties were moved to device tree. Then the rework of the way in which configuration data is provided to the Exynos thermal subsystem was performed. Now device tree is used for configuration. 3. Dead code removal Thermal support for some SoCs, previously available in the exynos_tmu_data.c file, was removed since, as of (almost) 3.19-rc3, they didn't have TMU bindings. Moreover, support for cpu_cooling devices was preserved only on those SoCs which had available and working cpufreq driver. 4. Testing Test devices: - Exynos4210 - Trats (TMU zone + cpu_cooling) - Exynos4412 - Trats2/Odroid U3 (TMU zone + cpu_cooling) - Exynos5250 - Arndale (TMU zone + cpu_cooling) - Exynos5420 - Arndale-octa (only TMU zones) Unfortunately, I don't posses Exynos5440 for testing. Its functionality has been preserved in the code, but not tested on the hardware. I would be grateful for help in testing. 5. This work apply on the following tree: kernel.org: 'linux-soc-thermal/next' - Eduardo Velentin's tree SHA1: 1813d80874699145f04af6b05ebab0a6419001fb Lukasz Majewski (16): thermal: exynos: cosmetic: Correct comment format thermal: exynos: Provide thermal_exynos.h file to be included in device tree files arm: dts: trats: Enable TMU on the Exynos4210 trats device arm: dts: odroid: Add LD010 regulator node necessary for TMU on Odroid thermal: dts: Enable TMU at Exynos4412 based Odroid U3 device arm: dts: Adding CPU cooling binding for Exynos SoCs thermal: exynos: Modify exynos thermal code to use device tree for cpu cooling configuration thermal: exynos: dts: Add default definition of the TMU sensor parameter dts: Documentation: Extending documentation entry for exynos-thermal thermal: dts: Default trip points definition for Exynos5420 SoCs thermal: exynos: dts: Define default thermal-zones for Exynos4 thermal: dts: exynos: Trip points and sensor configuration data for Exynos5440 thermal: exynos: dts: Provide device tree bindings identical to the one in exynos_tmu_data.c thermal: samsung: core: Exynos TMU rework to use device tree for configuration thermal: exynos: Remove exynos_thermal_common.[c|h] files thermal: exynos: Remove exynos_tmu_data.c file .../devicetree/bindings/thermal/exynos-thermal.txt | 17 + arch/arm/boot/dts/exynos3250.dtsi | 2 + arch/arm/boot/dts/exynos4-cpu-thermal.dtsi | 52 +++ arch/arm/boot/dts/exynos4.dtsi | 4 + arch/arm/boot/dts/exynos4210-trats.dts | 19 + arch/arm/boot/dts/exynos4210.dtsi | 26 +- arch/arm/boot/dts/exynos4212.dtsi | 5 +- arch/arm/boot/dts/exynos4412-odroid-common.dtsi| 27 ++ arch/arm/boot/dts/exynos4412-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos4412-trats2.dts| 15 + arch/arm/boot/dts/exynos4412.dtsi | 5 +- arch/arm/boot/dts/exynos4x12.dtsi | 1 + arch/arm/boot/dts/exynos5250.dtsi | 25 +- arch/arm/boot/dts/exynos5420-trip-points.dtsi | 35 ++ arch/arm/boot/dts/exynos5420.dtsi | 28 ++ arch/arm/boot/dts/exynos5440-tmu-sensor-conf.dtsi | 24 ++ arch/arm/boot/dts/exynos5440-trip-points.dtsi | 25 ++ arch/arm/boot/dts/exynos5440.dtsi | 18 + drivers/cpufreq/exynos-cpufreq.c | 30 +- drivers/thermal/samsung/Makefile | 2 - drivers/thermal/samsung/exynos_thermal_common.c| 427
Re: [PATCH 2/2] clk: exynos-audss: Fix memory leak on driver unbind or probe failure
On śro, 2015-01-14 at 14:25 -0800, Mike Turquette wrote:
Quoting Stephen Boyd (2015-01-08 13:23:13)
On 01/05/2015 01:52 AM, Krzysztof Kozlowski wrote:
The memory allocated by basic clock divider/gate/mux (struct clk_gate,
clk_divider and clk_mux) was leaking. During driver unbind or probe
failure the driver only unregistered the clocks.
Use clk_unregister_{gate,divider,mux} to release all resources.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Stephen Boyd sb...@codeaurora.org
I've applied both patches to clk-next. Krzysztof, let me know if you
would prefer to take the audss patch through the samsung clock branch
instead (to include it in a later pull request).
Thanks! I'm fine with applying them to clk-next.
Best regards,
Krzysztof
Regards,
Mike
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
+ Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: + Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Best regards, Krzysztof I think this boils done to how DVFS transitions can be triggered from the clock drivers, right? Currently the clock framework supports this through clock rate change notifiers. Should we have clock notifiers for clk_prepare|unprepare() as well? I do remember that someone posted patches for that a while ago, but those were rejected. Mike, Stephen - comments? Kind regards Uffe The patchset adds MMC card as a devfreq device and uses simple_ondemand as governor. In idle this gave benefits (less energy consumed during idle): 1. Trats2 (Exynos4412): 2.6% 2. Rinato (Exynos3250): 1% but (especially on Rinato) it had impact on performance (probably because ondemand triggering a little to late). What is interesting manually changing the clock (without this patchset) gave slightly bigger benefits. Maybe the devfreq introduces noticeable overhead? Comments are welcomed. Maybe on other platforms this has bigger impact? Best regards, Krzysztof Krzysztof Kozlowski (3): mmc: Add dynamic frequency scaling ARM: dts: Specify MSHC realistic clocks and use frequency scaling ARM: dts: Use frequency scaling for MSHC Documentation/devicetree/bindings/mmc/mmc.txt | 2 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4412-trats2.dts | 4 +- drivers/mmc/card/block.c | 247 ++ drivers/mmc/core/Kconfig | 16 ++ drivers/mmc/core/core.h | 1 - drivers/mmc/core/host.c | 2 + include/linux/mmc/card.h | 8 + include/linux/mmc/host.h | 3 + 9 files changed, 282 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/7] ARM: Exynos: add support for sub-power domains
Hello All,
I'm sorry for missing some CC: in this patch, when I posted v3 to
mailing list.
It looks that CC: lines got lost after git am + git format-patch.
Ulf, could you also ack this patch, so Kukjin can finally merge the whole
series to Samsung kernel tree?
On 2015-01-14 14:44, Marek Szyprowski wrote:
This patch adds support for making one power domain a sub-domain of
other domain. This is useful for modeling power dependences for devices
like TV Mixer or Camera ISP, which needs to have more than one power
domain enabled to be operational.
Based on previous work by Amit Daniel Kachhap amit.dan...@samsung.com.
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
---
.../bindings/arm/exynos/power_domain.txt | 2 ++
arch/arm/mach-exynos/pm_domains.c | 28 ++
2 files changed, 30 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
index f4445e5..1e09703 100644
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -22,6 +22,8 @@ Optional Properties:
- pclkN, clkN: Pairs of parent of input clock and input clock to the
devices in this power domain. Maximum of 4 pairs (N = 0 to 3)
are supported currently.
+- power-domains: phandle pointing to the parent power domain, for more details
+see Documentation/devicetree/bindings/power/power_domain.txt
Node of a device using power domains must have a power-domains property
defined with a phandle to respective power domain.
diff --git a/arch/arm/mach-exynos/pm_domains.c
b/arch/arm/mach-exynos/pm_domains.c
index 20f2671..37266a8 100644
--- a/arch/arm/mach-exynos/pm_domains.c
+++ b/arch/arm/mach-exynos/pm_domains.c
@@ -161,6 +161,34 @@ no_clk:
of_genpd_add_provider_simple(np, pd-pd);
}
+ /* Assign the child power domains to their parents */
+ for_each_compatible_node(np, NULL, samsung,exynos4210-pd) {
+ struct generic_pm_domain *child_domain, *parent_domain;
+ struct of_phandle_args args;
+
+ args.np = np;
+ args.args_count = 0;
+ child_domain = of_genpd_get_from_provider(args);
+ if (!child_domain)
+ continue;
+
+ if (of_parse_phandle_with_args(np, power-domains,
+#power-domain-cells, 0, args) != 0)
+ continue;
+
+ parent_domain = of_genpd_get_from_provider(args);
+ if (!parent_domain)
+ continue;
+
+ if (pm_genpd_add_subdomain(parent_domain, child_domain))
+ pr_warn(%s failed to add subdomain: %s\n,
+ parent_domain-name, child_domain-name);
+ else
+ pr_info(%s has as child subdomain: %s.\n,
+ parent_domain-name, child_domain-name);
+ of_node_put(np);
+ }
+
return 0;
}
arch_initcall(exynos4_pm_init_power_domain);
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: power: reset: add driver for Hardkernel's Odroid boards
Marek Szyprowski wrote: Right. This patch was posted some time ago and reboot handling on ARM SoCs have been changed recently in v3.19-rc1. I will post an updated version of this patch soon. Best regards Thanks for the update! Going to wait for the new version then. Wish best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello, On 2015-01-15 11:10, Tobias Jakobi wrote: Marek Szyprowski wrote: This is on a ODROID-X2. The issues with FIMC / DRM FIMC are not related to HDMI patches. They will be handled separately. For the time being simply please disable Exynos IPP (or Exynos DRM FIMC) feature in your kernel configuration. I hope that HDMI display works fine for you. OK, I'll check without FIMC again later this day, but what about the warning (?) from the mixer: exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! Should this go away as well, when I disable the FIMC? Well, I also got this warning. It looks that pm_runtime in Exynos DRM got changed recently and the bug is somewhere there. We will also check this issue. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: Hi Kukjin, On 01/15/2015 01:02 AM, Daniel Lezcano wrote: On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know arch_timer. As you comment, ARCH timer would be used for system timer for ARMv8. But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it on Exynos5433/EXynos7 User-manaual and tested it. I think that exynos_mct.c should support the Exynos 64-bit SoC because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual never includes the detailed information about for ARCH timer(e.g, clock for ARCH timer). I knew that I can get the document of ARCH timer for ARM official site but I think it is insufficient to implement ARCH timer on Exynos SoC. What do you mean by insufficient to implement ARCH timer? The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
+Cc Inki Dae. Hi, On 01/15/2015 07:26 PM, Marek Szyprowski wrote: Hello, On 2015-01-15 11:10, Tobias Jakobi wrote: Marek Szyprowski wrote: This is on a ODROID-X2. The issues with FIMC / DRM FIMC are not related to HDMI patches. They will be handled separately. For the time being simply please disable Exynos IPP (or Exynos DRM FIMC) feature in your kernel configuration. I hope that HDMI display works fine for you. OK, I'll check without FIMC again later this day, but what about the warning (?) from the mixer: exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! Should this go away as well, when I disable the FIMC? Well, I also got this warning. It looks that pm_runtime in Exynos DRM got changed recently and the bug is somewhere there. We will also check this issue. I posted a patch to fix it already. http://www.spinics.net/lists/dri-devel/msg75039.html Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] ARM: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators
Add suspend to RAM configuration for max77686 regulators. Some LDOs and
bucks are disabled. This reduces energy consumption during S2R,
approximately from 17 mA to 9 mA.
Additionally remove old and not supported bindings:
- regulator-mem-off
- regulator-mem-idle
- regulator-mem-on
The max77686 driver does not parse them and they are not documented
anywere.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Reviewed-by: Chanwoo Choi cw00.c...@samsung.com
---
Previously this was part of [1] patchset. There were no changes in this
patch since last version (v6) of that patchset.
[1] https://lkml.org/lkml/2014/10/29/261
---
arch/arm/boot/dts/exynos4412-trats2.dts | 72 +++--
1 file changed, 42 insertions(+), 30 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 595ad4ba6977..ef05139506e6 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -227,7 +227,6 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
};
ldo2_reg: ldo2 {
@@ -236,7 +235,9 @@
regulator-min-microvolt = 120;
regulator-max-microvolt = 120;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo3_reg: ldo3 {
@@ -245,7 +246,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
- regulator-mem-on;
};
ldo4_reg: ldo4 {
@@ -254,7 +254,6 @@
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
regulator-always-on;
- regulator-mem-on;
};
ldo5_reg: ldo5 {
@@ -263,7 +262,6 @@
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
- regulator-mem-on;
};
ldo6_reg: ldo6 {
@@ -272,7 +270,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo7_reg: ldo7 {
@@ -281,7 +281,9 @@
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
regulator-always-on;
- regulator-mem-on;
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
};
ldo8_reg: ldo8 {
@@ -289,7 +291,9 @@
regulator-name = VMIPI_1.0V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 100;
- regulator-mem-off;
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
};
ldo9_reg: ldo9 {
@@ -297,7 +301,6 @@
regulator-name = CAM_ISP_MIPI_1.2V;
regulator-min-microvolt = 120;
[PATCH 3/3] ARM: dts: exynos4412-trats2: Switch max77686 regulators to GPIO control
Remove fixed regulators (duplicating what max77686 provides) and
add GPIO enable control to max77686 regulators.
This gives the system full control over those regulators. Previously
the state of such regulators was a mixture of what max77686 driver set
over I2C and what regulator-fixed set through GPIO.
Removal of 'regulator-always-on' from CAM_ISP_CORE_1.2V (buck9) allows
disabling it when it is not used. Previously this regulator was always
enabled because its enable state is a OR of:
- ENB9 GPIO (turned always on by regulator-fixed),
- BUCK9EN field in BUCK9CTRL register (off by max77686 through I2C).
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 25 +
1 file changed, 5 insertions(+), 20 deletions(-)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index ef05139506e6..8611c07c2e41 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -58,15 +58,6 @@
#address-cells = 1;
#size-cells = 0;
- vemmc_reg: regulator-0 {
- compatible = regulator-fixed;
- regulator-name = VMEM_VDD_2.8V;
- regulator-min-microvolt = 280;
- regulator-max-microvolt = 280;
- gpio = gpk0 2 0;
- enable-active-high;
- };
-
cam_io_reg: voltage-regulator-1 {
compatible = regulator-fixed;
regulator-name = CAM_SENSOR_A;
@@ -94,16 +85,6 @@
enable-active-high;
};
- cam_isp_core_reg: voltage-regulator-4 {
- compatible = regulator-fixed;
- regulator-name = CAM_ISP_CORE_1.2V_EN;
- regulator-min-microvolt = 120;
- regulator-max-microvolt = 120;
- gpio = gpm0 3 0;
- enable-active-high;
- regulator-always-on;
- };
-
ps_als_reg: voltage-regulator-5 {
compatible = regulator-fixed;
regulator-name = LED_A_3.0V;
@@ -405,6 +386,7 @@
regulator-name = VTF_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
+ maxim,ena-gpios = gpy2 0
GPIO_ACTIVE_HIGH;
};
ldo22_reg: ldo22 {
@@ -412,6 +394,7 @@
regulator-name = VMEM_VDD_2.8V;
regulator-min-microvolt = 280;
regulator-max-microvolt = 280;
+ maxim,ena-gpios = gpk0 2
GPIO_ACTIVE_HIGH;
};
ldo23_reg: ldo23 {
@@ -518,6 +501,7 @@
regulator-name = VMEM_VDDF_3.0V;
regulator-min-microvolt = 285;
regulator-max-microvolt = 285;
+ maxim,ena-gpios = gpk0 2
GPIO_ACTIVE_HIGH;
};
buck9_reg: buck9 {
@@ -525,6 +509,7 @@
regulator-name = CAM_ISP_CORE_1.2V;
regulator-min-microvolt = 100;
regulator-max-microvolt = 120;
+ maxim,ena-gpios = gpm0 3
GPIO_ACTIVE_HIGH;
};
};
};
@@ -587,7 +572,7 @@
broken-cd;
non-removable;
card-detect-delay = 200;
- vmmc-supply = vemmc_reg;
+ vmmc-supply = ldo22_reg;
clock-frequency = 4;
samsung,dw-mshc-ciu-div = 0;
samsung,dw-mshc-sdr-timing = 2 3;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] thermal: Provide stub for thermal_of_cooling_device_register() function
Hi Eduardo,
On Wed, Jan 14, 2015 at 04:01:06PM +0100, Lukasz Majewski wrote:
Hi Eduardo,
On Fri, Jan 02, 2015 at 02:54:28PM -0400, Eduardo Valentin wrote:
On Mon, Dec 22, 2014 at 05:27:41PM +0100, Lukasz Majewski wrote:
Odroid U3 fan can work without being registered as OF cooling
device (with CONFIG_THERMAL_OF disabled).
In this situation it can be controlled via PWM entry at
/sys/class/hwmon/hwmon0/pwm1.
Therefore, the thermal_of_cooling_device_register() function
needs a stub to allow clean compilation.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Acked-by: Eduardo Valentin edubez...@gmail.com
Sorry, too fast,
This is actually
Nacked-by: Eduardo Valentin edubez...@gmail.com
:-)
I get this error:
drivers/thermal/thermal_core.c:1210:1: error: redefinition of
‘thermal_of_cooling_device_register’
thermal_of_cooling_device_register(struct device_node *np,
^
In file included from drivers/thermal/thermal_core.c:34:0:
include/linux/thermal.h:321:1: note: previous definition of
‘thermal_of_cooling_device_register’ was here
thermal_of_cooling_device_register(struct device_node *np,
^
We provide the function in thermal core even if CONFIG_THERMAL_OF
is not set.
Unfortunately the PWM fan subsystem can work perfectly fine without
CONFIG_THERMAL.
Now I understand what you are trying to do.
I think that it would be enough to make something like this in
the ./include/linux/thermal.h:
#ifdef CONFIG_THERMAL
Well, I think it should be the opposite here:
#ifndef CONFIG_THERMAL
that is, if no config thermal, then you provide the stub not the other
way around.
This seems like a better solution :-).
Thanks.
static inline struct thermal_cooling_device *
thermal_of_cooling_device_register(struct
device_node *np, char *type, void *devdata,
const struct
thermal_cooling_device_ops *ops) {
return NULL;
}
#else
[ already present declaration of
thermal_of_cooling_device_register() ]
#endif /* CONFIG_THERMAL */
---
Changes for v2:
- None
---
include/linux/thermal.h | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 2de3d9e..871123c 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -328,6 +328,10 @@ thermal_zone_of_sensor_register(struct
device *dev, int id, void *data, const struct
thermal_zone_of_device_ops *ops); void
thermal_zone_of_sensor_unregister(struct device *dev, struct
thermal_zone_device *tz); +struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+char *type, void *devdata,
+const struct
thermal_cooling_device_ops *); #else
static inline struct thermal_zone_device *
thermal_zone_of_sensor_register(struct device *dev, int id,
void *data, @@ -342,6 +346,13 @@ void
thermal_zone_of_sensor_unregister(struct device *dev, {
}
+static inline struct thermal_cooling_device *
+thermal_of_cooling_device_register(struct device_node *np,
+char *type, void *devdata,
+const struct
thermal_cooling_device_ops *ops) +{
+ return NULL;
+}
#endif
struct thermal_zone_device
*thermal_zone_device_register(const char *, int, int, void *,
struct thermal_zone_device_ops *, @@ -357,9 +368,6 @@ void
thermal_zone_device_update(struct thermal_zone_device *);
struct thermal_cooling_device
*thermal_cooling_device_register(char *, void *, const struct
thermal_cooling_device_ops *); -struct thermal_cooling_device
* -thermal_of_cooling_device_register(struct device_node *np,
char *, void *,
-const struct
thermal_cooling_device_ops *); void
thermal_cooling_device_unregister(struct
thermal_cooling_device *); struct thermal_zone_device
*thermal_zone_get_zone_by_name(const char *name); int
thermal_zone_get_temp(struct thermal_zone_device *tz, unsigned
long *temp); -- 2.0.0.rc2
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform Group
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] ARM: dts: Regulator changes and fuel gauge for exynos4412-trats2
Hi Kukjin, I grouped into one patchset already posted patches for Trats2 board: 1. Fuel gauge: https://lkml.org/lkml/2015/1/7/167 2. Suspend configuration for max77686 regulators: https://lkml.org/lkml/2014/10/29/262 3. GPIO control for max77686 regulators: https://lkml.org/lkml/2015/1/5/230 The necessary changes in max77686 regulator driver were already applied by Mark Brown. Best regards, Krzysztof Krzysztof Kozlowski (3): ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node ARM: dts: exynos4412-trats2: Add suspend configuration for max77686 regulators ARM: dts: exynos4412-trats: Switch max77686 regulators to GPIO control arch/arm/boot/dts/exynos4412-trats2.dts | 115 ++-- 1 file changed, 65 insertions(+), 50 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] ARM: dts: exynos4412-trats2: Add Maxim 77693 fuel gauge node
Add node for fuel gauge present in Maxim 77693 PMIC. This allows control
over battery charging state on Trats2 board.
The fuel gauge is compatible with max17042 battery driver (Maxim
17042/17047/17050). Although datasheet rev 2.2 for MAX77693 describes
fuel gauge as Maxim 17042-like, the chip on Trats2 board identifies
itself as Maxim 17047-like.
Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
arch/arm/boot/dts/exynos4412-trats2.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 29231b452643..595ad4ba6977 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -15,6 +15,7 @@
/dts-v1/;
#include exynos4412.dtsi
#include dt-bindings/gpio/gpio.h
+#include dt-bindings/interrupt-controller/irq.h
/ {
model = Samsung Trats 2 based on Exynos4412;
@@ -24,6 +25,7 @@
i2c9 = i2c_ak8975;
i2c10 = i2c_cm36651;
i2c11 = i2c_max77693;
+ i2c12 = i2c_max77693_fuel;
};
memory {
@@ -552,6 +554,22 @@
};
};
+ i2c_max77693_fuel: i2c-gpio-3 {
+ compatible = i2c-gpio;
+ gpios = gpf1 5 GPIO_ACTIVE_HIGH, gpf1 4 GPIO_ACTIVE_HIGH;
+ i2c-gpio,delay-us = 2;
+ #address-cells = 1;
+ #size-cells = 0;
+ status = okay;
+
+ max77693-fuel-gauge@36 {
+ compatible = maxim,max17047;
+ interrupt-parent = gpx2;
+ interrupts = 3 IRQ_TYPE_EDGE_FALLING;
+ reg = 0x36;
+ };
+ };
+
mmc@1255 {
num-slots = 1;
broken-cd;
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Marek Szyprowski wrote: This is on a ODROID-X2. The issues with FIMC / DRM FIMC are not related to HDMI patches. They will be handled separately. For the time being simply please disable Exynos IPP (or Exynos DRM FIMC) feature in your kernel configuration. I hope that HDMI display works fine for you. Best regards OK, I'll check without FIMC again later this day, but what about the warning (?) from the mixer: exynos-mixer 12c1.mixer: Unbalanced pm_runtime_enable! Should this go away as well, when I disable the FIMC? With best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] hwmon: dts: Doc: Add DTS doc to explain how to use PWM FAN as a cooling device
On Wed, 2015-01-14 at 14:56 +0100, Lukasz Majewski wrote: Hi Sjoerd, Could you review v2 of this patch series? http://www.spinics.net/lists/devicetree/msg63159.html I skimmed it yesterday, I'll try to find some time to send you my review comments later in the week/start of next. Do you happen to have a git branch with these patches in? That would make it convenient for me to give your patches a spin on my XU3 -- Sjoerd Simons sjoerd.sim...@collabora.co.uk Collabora Ltd. smime.p7s Description: S/MIME cryptographic signature
Re: [RFC 0/3] mmc: Add dynamic frequency scaling
On 15 January 2015 at 10:20, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: On czw, 2015-01-15 at 09:20 +0100, Ulf Hansson wrote: + Mike, Stephen (Clock maintainers) On 12 January 2015 at 10:23, Krzysztof Kozlowski k.kozlow...@samsung.com wrote: Hi, I would like to hear some comments about idea of scaling MMC clock frequency. The basic idea is to lower the clock when device is completely idle or not busy enough. We already have host drivers that implements runtime PM support. Typically that would mean the clock will be gated once the device becomes runtime PM suspended. Why should we decrease the frequency of an already gated clock? In case of idle state you're right that clkgate would be better. But what about finding a compromise between high performance (high frequency) and energy saving for different loads on MMC? I guess a compromise could be beneficial for some SOC and use cases. At least I remember, ST-Ericsson's UX500 SOC had such an out of tree hack to track MMC load. The frequency scaling could help in that case. Anyway I should prepare some more benchmarks for such conditions. Seems reasonable and please do! Kind regards Uffe -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/6] Enable HDMI support on Exynos platforms
Hello,
On 2015-01-14 16:25, Tobias Jakobi wrote:
Hello,
I've applied v6 of the HDMI patchset (together with the patches the set
depends on) onto torvalds/master, but I'm seeing a lot of warnings
(coming from __clk_{unprepare,disable}) that seem to originate from the
fimc subsystem.
Since the patchset also changes PM domain handling (which shows up in
the log as well), I was wondering if this is related?
Full boot log here:
http://www.math.uni-bielefeld.de/~tjakobi/archive/clk_warnings.txt
That's the tree I'm currently using:
https://github.com/tobiasjakobi/linux-odroid/commits/odroid-3.19.y
(maybe I'm missing something here?)
With best wishes,
Tobias
PS: This is on a ODROID-X2.
The issues with FIMC / DRM FIMC are not related to HDMI patches. They will
be handled separately. For the time being simply please disable Exynos IPP
(or Exynos DRM FIMC) feature in your kernel configuration.
I hope that HDMI display works fine for you.
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi cwcho...@gmail.com wrote: Hi Mark, On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: Hi Kukjin, On 01/15/2015 01:02 AM, Daniel Lezcano wrote: On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know arch_timer. As you comment, ARCH timer would be used for system timer for ARMv8. But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it on Exynos5433/EXynos7 User-manaual and tested it. I think that exynos_mct.c should support the Exynos 64-bit SoC because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual never includes the detailed information about for ARCH timer(e.g, clock for ARCH timer). I knew that I can get the document of ARCH timer for ARM official site but I think it is insufficient to implement ARCH timer on Exynos SoC. What do you mean by insufficient to implement ARCH timer? As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find I'm so sorry about this mistake. I pressed the send button before completing reply. As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find the clock information for ARCH timer on Exynos SoC user-manual. When I tried to use ARCH timer on Exynos3250, It is not working. We can check this ARCH timer issue of Exynos3250 on following patch[1]: [1] http://www.spinics.net/lists/arm-kernel/msg322943.html The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. I agree that ARCH timer is mandatory. I just think that existing exynos-mct.c driver should support the Exynos5/7 SoC because released Exynos5/7 SoC includes already MCT IP for system timer. Best Regards, Chanwoo Choi -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
Hi Mark, On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: Hi Kukjin, On 01/15/2015 01:02 AM, Daniel Lezcano wrote: On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know arch_timer. As you comment, ARCH timer would be used for system timer for ARMv8. But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it on Exynos5433/EXynos7 User-manaual and tested it. I think that exynos_mct.c should support the Exynos 64-bit SoC because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual never includes the detailed information about for ARCH timer(e.g, clock for ARCH timer). I knew that I can get the document of ARCH timer for ARM official site but I think it is insufficient to implement ARCH timer on Exynos SoC. What do you mean by insufficient to implement ARCH timer? As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. Thanks, Mark. ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESEND PATCH v3] clocksource: exynos_mct: Add the support for Exynos 64bit SoC
On Thu, Jan 15, 2015 at 12:52:38PM +, Chanwoo Choi wrote: On Thu, Jan 15, 2015 at 9:46 PM, Chanwoo Choi cwcho...@gmail.com wrote: Hi Mark, On Thu, Jan 15, 2015 at 8:29 PM, Mark Rutland mark.rutl...@arm.com wrote: On Wed, Jan 14, 2015 at 11:57:00PM +, Chanwoo Choi wrote: Hi Kukjin, On 01/15/2015 01:02 AM, Daniel Lezcano wrote: On 01/14/2015 04:51 PM, Kukjin Kim wrote: On 01/14/15 14:33, Chanwoo Choi wrote: Hi, + Doug, Olof This patch adds the support for Exynos 64bit SoC. The delay_timer is only used for Exynos 32bit SoC. Yes, the Exynos MCT(Multi-Core Timer) is 64bit timer and it is available on 64bit exynos SoC such as exynos7. But basically ARMv8 architecture is including ARM ARCH timer (ARM Generic Timer) and exynos7 also has implemented it and additionally its access is faster than using memory mapped register called SFR for MCT...so Doug submitted patch to use MCT on 32bit exynos SoCs before. I know arch_timer. As you comment, ARCH timer would be used for system timer for ARMv8. But, Exynos5433/Exynos7 (ARMv8) include MCT (Multi-Core Timer) IP. I checked it on Exynos5433/EXynos7 User-manaual and tested it. I think that exynos_mct.c should support the Exynos 64-bit SoC because Exynos5433/Exynos7 include already MCT (Multi-Core Timer) IP. Also, I have a problem to verify ARCH timer on Exynos SoC. Exynos User-manual never includes the detailed information about for ARCH timer(e.g, clock for ARCH timer). I knew that I can get the document of ARCH timer for ARM official site but I think it is insufficient to implement ARCH timer on Exynos SoC. What do you mean by insufficient to implement ARCH timer? As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find I'm so sorry about this mistake. I pressed the send button before completing reply. As I knew, timer must need the source clock. The clock for ARCH timer has dependency on Exynos SoC, But I cannot find the clock information for ARCH timer on Exynos SoC user-manual. When I tried to use ARCH timer on Exynos3250, It is not working. We can check this ARCH timer issue of Exynos3250 on following patch[1]: [1] http://www.spinics.net/lists/arm-kernel/msg322943.html Hmm. That is annoying. Your boot code should have been initialising this already. The architected timer is mandatory in ARMv8, and required by the arm64 kernel. Additional timers may be requried if you want to put all CPUs into low power states where the timer logic may be disabled and/or lose state, but regardless the architected timers are necessary. I agree that ARCH timer is mandatory. I just think that existing exynos-mct.c driver should support the Exynos5/7 SoC because released Exynos5/7 SoC includes already MCT IP for system timer. I'm not opposed to the MCT. My only concern is that a configured and enabled architected timer is mandated by the boot protocol, and is a prerequisite for a functioning kernel. Your initial response made it sound like you expected the MCT alone to be sufficient. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3,06/16] arm: dts: Adding CPU cooling binding for Exynos SoCs
Hello, I noticed that this patch mixes spaces and tabs a lot for indentation. With best wishes, Tobias -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] clk: samsung: exynos7: add clocks for audio block
Hi, On 15/01/15 06:49, Padma Venkat wrote: I posted patches after re-basing on your tree and after incorporating all comments from Vivek. Below is the link http://www.spinics.net/lists/linux-samsung-soc/msg40992.html Can you pick the patches? Sure, I'm not forgetting it. I've updated the exynos7 branch with your v2 patches. Thanks! Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 13/21] ARM: omap: convert wakeupgen to stacked domains
On Wed, Jan 14 2015 at 10:28:14 pm GMT, Tony Lindgren t...@atomide.com wrote: * Marc Zyngier marc.zyng...@arm.com [150112 10:30]: OMAP4/5 has been (ab)using the gic_arch_extn to provide wakeup from suspend, and it makes a lot of sense to convert this code to use stacked domains instead. This patch does just this, updating the DT files to actually reflect what the HW provides. BIG FAT WARNING: because the DTs were so far lying by not exposing the WUGEN HW block, kernels with this patch applied won't have any suspend-resume facility when booted with old DTs, and old kernels with updated DTs won't even boot. On a platform with this patch applied, the system looks like this: root@bacon-fat:~# cat /proc/interrupts CPU0 CPU1 16: 0 0 WUGEN 37 gp_timer 19: 233799 155916 GIC 27 arch_timer 23: 0 0 WUGEN 9 l3-dbg-irq 24: 1 0 WUGEN 10 l3-app-irq 27:282 0 WUGEN 13 omap-dma-engine 44: 0 0 4ae1.gpio 13 DMA FYI, the legacy irq numbers are now all wrong since commit 9a1091ef0017 (irqchip: gic: Support hierarchy irq domain.). Started a separate thread Regression with legacy IRQ numbers caused by 9a1091ef0017 on it, will give these a try once that's sorted out. Assuming the workaround I posted earlier works, the OMAP/DRA7 part of this series is going to require some rework too (I need to know where these legacy interrupts are attached: crossbar, WUGEN, or GIC?). Thanks, M. -- Jazz is not dead. It just smells funny. -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
