[PATCH 3/4] PCI: exynos: Mark the msi cascade handler IRQF_NO_THREAD
The cascade handler must run in hard interrupt context, otherwise
it will cause dead lock if we force threading of all the interrupt
handlers via kernel command parameter threadirqs.
Signed-off-by: Kevin Hao haoke...@gmail.com
---
drivers/pci/host/pci-exynos.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/host/pci-exynos.c b/drivers/pci/host/pci-exynos.c
index f9f468d9a819..7b6be7791d33 100644
--- a/drivers/pci/host/pci-exynos.c
+++ b/drivers/pci/host/pci-exynos.c
@@ -523,7 +523,8 @@ static int __init exynos_add_pcie_port(struct pcie_port *pp,
ret = devm_request_irq(pdev-dev, pp-msi_irq,
exynos_pcie_msi_irq_handler,
- IRQF_SHARED, exynos-pcie, pp);
+ IRQF_SHARED | IRQF_NO_THREAD,
+ exynos-pcie, pp);
if (ret) {
dev_err(pdev-dev, failed to request msi irq\n);
return ret;
--
2.1.0
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
Quoting Kukjin Kim (2015-07-07 07:43:31) Bartlomiej Zolnierkiewicz wrote: Hi, Hi, On Thursday, July 02, 2015 09:42:38 AM Chanwoo Choi wrote: This patchset use cpufreq-dt driver to support Exynos3250 cpufreq and tested it on Exynos3250-based Rinato board. Depends on: - next-20150701 tag (master branch) of linux-next kernel tree - This patch-set is based on Exynos5250 patch-set[1] because two patch-set modify the 'arch/arm/mach-exynos/exynos.c' to add the compatible string. [1] https://lkml.org/lkml/2015/6/29/361 : [PATCH v2 0/4] cpufreq: use generic cpufreq drivers for Exynos5250 platform Changes from v5: (https://lkml.org/lkml/2015/7/1/324) - Reorder the cpu dt node in exynos3250-rinato/monk.dts alpabetically. - Add reviewed-by tag of Krzysztof Kozlowski k.kozlow...@samsung.com Changes from v4: (https://lkml.org/lkml/2014/10/20/215) - Rebased on latest linux-next git repository. - Remove unnecessary divider clock flag from divider of DIV_CPU0/DIV_CPU1 register Changes from v3: - This patchset is based on 3.18-rc1 with new patchset[3] of Thomas Abraham [3] [PATCH v11 0/6] cpufreq: use generic cpufreq drivers for exynos platforms - http://www.spinics.net/lists/arm-kernel/msg370412.html Changes from v2: - Rebased on new patchset of Thomas Abraham and for-next branch of samsunc-clk.git of Tomasz Figa Changes from v1: - Rebased on new patchset[1] by Thomas Abraham [1] [PATCH v10 0/6] cpufreq: use generic cpufreq drivers for exynos platforms - http://www.spinics.net/lists/arm-kernel/msg364790.html - Modify clk-cpu.c to support Exynos3250 - Drop documentation patch on previous patchset[2] [2] http://www.spinics.net/lists/cpufreq/msg10265.html - Add only operating-points for Exynos3250 without armclk-divider-table Chanwoo Choi (3): clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver arch/arm/boot/dts/exynos3250-monk.dts | 4 arch/arm/boot/dts/exynos3250-rinato.dts | 4 arch/arm/boot/dts/exynos3250.dtsi | 15 +++ arch/arm/mach-exynos/exynos.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 32 ++-- include/dt-bindings/clock/exynos3250.h | 1 + 6 files changed, 55 insertions(+), 2 deletions(-) Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Thank you for working on this. +1 Thanks. Mike and Sylwester, if you're OK on this series, I'd like to pick up in Samsung tree together. And if you want, I could provide topic branch for clk tree. Kukjin, A topic branch would be great. Thanks, Mike Thanks, Kukjin -- 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 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
On 07/24/15 09:39, Michael Turquette wrote: Quoting Bartlomiej Zolnierkiewicz (2015-07-01 06:10:35) From: Thomas Abraham thomas...@samsung.com With the addition of the new Samsung specific cpu-clock type, the arm clock can be represented as a cpu-clock type. Add the CPU clock configuration data and instantiate the CPU clock type for Exynos5250. Changes by Bartlomiej: - split Exynos5250 support from the original patch - moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c Cc: Tomasz Figa tomasz.f...@gmail.com Cc: Michael Turquette mturque...@baylibre.com Cc: Javier Martinez Canillas jav...@dowhile0.org Signed-off-by: Thomas Abraham thomas...@samsung.com Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Acked-by: Michael Turquette mturque...@baylibre.com Thanks, Mike. If Kukjin wants to merge this through the samsung tree then an immutable branch would be much appreciated. Here is the topic branch for clk tree and it will not be rebased. git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git v4.3-topic/clk-samsung If any problems, please kindly let me know. Thanks, Kukjin Regards, Mike --- drivers/clk/samsung/clk-exynos5250.c | 31 +++ include/dt-bindings/clock/exynos5250.h | 1 + 2 files changed, 32 insertions(+) -- 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 v6 1/3] clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock
On 07/20/15 09:23, Chanwoo Choi wrote:
Hi Sylwester,
Hi Chanwoo,
Please review this patch.
Applied with Mike's ack BTW please make sure your patch has no problem
with checkpatch before submittingI've fixed them when I applied.
Thanks,
Kukjin
ERROR: code indent should use tabs where possible
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+ (((apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \$
WARNING: please, no spaces at the start of a line
#49: FILE: drivers/clk/samsung/clk-exynos3250.c:779:
+ (((apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \$
ERROR: code indent should use tabs where possible
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+ ((corem) 4))$
WARNING: please, no spaces at the start of a line
#50: FILE: drivers/clk/samsung/clk-exynos3250.c:780:
+ ((corem) 4))$
WARNING: please, no spaces at the start of a line
#55: FILE: drivers/clk/samsung/clk-exynos3250.c:785:
+ { 100, E3250_CPU_DIV0(1, 7, 4, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#56: FILE: drivers/clk/samsung/clk-exynos3250.c:786:
+ { 90, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#57: FILE: drivers/clk/samsung/clk-exynos3250.c:787:
+ { 80, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#58: FILE: drivers/clk/samsung/clk-exynos3250.c:788:
+ { 70, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#59: FILE: drivers/clk/samsung/clk-exynos3250.c:789:
+ { 60, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#60: FILE: drivers/clk/samsung/clk-exynos3250.c:790:
+ { 50, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#61: FILE: drivers/clk/samsung/clk-exynos3250.c:791:
+ { 40, E3250_CPU_DIV0(1, 7, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#62: FILE: drivers/clk/samsung/clk-exynos3250.c:792:
+ { 30, E3250_CPU_DIV0(1, 5, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#63: FILE: drivers/clk/samsung/clk-exynos3250.c:793:
+ { 20, E3250_CPU_DIV0(1, 3, 3, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#64: FILE: drivers/clk/samsung/clk-exynos3250.c:794:
+ { 10, E3250_CPU_DIV0(1, 1, 1, 1), E3250_CPU_DIV1(7, 7), },$
WARNING: please, no spaces at the start of a line
#65: FILE: drivers/clk/samsung/clk-exynos3250.c:795:
+ { 0 },$
total: 2 errors, 13 warnings, 63 lines checked
NOTE: Whitespace errors detected.
You may wish to use scripts/cleanpatch or scripts/cleanfile
[PATCH v6 1_3] clk: samsung: exynos3250: Add cpu clock configuration
data and instaniate cpu clock.eml has style problems, please review.
Best Regards,
Chanwoo Choi
On 07/16/2015 04:46 PM, Krzysztof Kozlowski wrote:
2015-07-02 9:42 GMT+09:00 Chanwoo Choi cw00.c...@samsung.com:
This patch add CPU clock configuration data and instantiate the CPU clock
type
for Exynos3250 to support Samsung specific cpu-clock type.
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Tomasz Figa tomasz.f...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Reviewed-by: Krzysztof Kozlowski k.kozlow...@samsung.com
---
drivers/clk/samsung/clk-exynos3250.c | 32
++--
include/dt-bindings/clock/exynos3250.h | 1 +
Sylwester,
I think this patch also waits for your review or ack.
The patchset is rebased on Bartlomiej's series for Exynos5250 cpufreq
so the easiest way would be to take it through samsung-soc tree.
Best regards,
Krzysztof
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos3250.c
b/drivers/clk/samsung/clk-exynos3250.c
index 538de66a759e..378ad5ad3492 100644
--- a/drivers/clk/samsung/clk-exynos3250.c
+++ b/drivers/clk/samsung/clk-exynos3250.c
@@ -19,6 +19,7 @@
#include dt-bindings/clock/exynos3250.h
#include clk.h
+#include clk-cpu.h
#include clk-pll.h
#define SRC_LEFTBUS0x4200
@@ -319,8 +320,10 @@ static struct samsung_mux_clock mux_clks[] __initdata
= {
MUX(CLK_MOUT_MPLL_USER_C, mout_mpll_user_c, mout_mpll_user_p,
SRC_CPU, 24, 1),
MUX(CLK_MOUT_HPM, mout_hpm, mout_hpm_p, SRC_CPU, 20, 1),
- MUX(CLK_MOUT_CORE, mout_core, mout_core_p, SRC_CPU, 16, 1),
- MUX(CLK_MOUT_APLL, mout_apll, mout_apll_p, SRC_CPU, 0, 1),
+ MUX_F(CLK_MOUT_CORE, mout_core, mout_core_p, SRC_CPU, 16, 1,
+ CLK_SET_RATE_PARENT, 0),
+ MUX_F(CLK_MOUT_APLL, mout_apll, mout_apll_p, SRC_CPU, 0, 1,
+
Re: [PATCH v3 1/4] clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock
Quoting Bartlomiej Zolnierkiewicz (2015-07-01 06:10:35)
From: Thomas Abraham thomas...@samsung.com
With the addition of the new Samsung specific cpu-clock type, the
arm clock can be represented as a cpu-clock type. Add the CPU clock
configuration data and instantiate the CPU clock type for Exynos5250.
Changes by Bartlomiej:
- split Exynos5250 support from the original patch
- moved E5250_CPU_DIV[0,1]() macros to clk-exynos5250.c
Cc: Tomasz Figa tomasz.f...@gmail.com
Cc: Michael Turquette mturque...@baylibre.com
Cc: Javier Martinez Canillas jav...@dowhile0.org
Signed-off-by: Thomas Abraham thomas...@samsung.com
Signed-off-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com
Acked-by: Michael Turquette mturque...@baylibre.com
If Kukjin wants to merge this through the samsung tree then an immutable
branch would be much appreciated.
Regards,
Mike
---
drivers/clk/samsung/clk-exynos5250.c | 31 +++
include/dt-bindings/clock/exynos5250.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 70ec3d2..d87f34d 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -19,6 +19,7 @@
#include linux/syscore_ops.h
#include clk.h
+#include clk-cpu.h
#define APLL_LOCK 0x0
#define APLL_CON0 0x100
@@ -748,6 +749,32 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
+#define E5250_CPU_DIV0(apll, pclk_dbg, atb, periph, acp, cpud) \
+ apll) 24) | ((pclk_dbg) 20) | ((atb) 16) | \
+((periph) 12) | ((acp) 8) | ((cpud) 4)))
+#define E5250_CPU_DIV1(hpm, copy) \
+ (((hpm) 4) | (copy))
+
+static const struct exynos_cpuclk_cfg_data exynos5250_armclk_d[] __initconst
= {
+ { 170, E5250_CPU_DIV0(5, 3, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 160, E5250_CPU_DIV0(4, 1, 7, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 150, E5250_CPU_DIV0(4, 1, 7, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 140, E5250_CPU_DIV0(4, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 130, E5250_CPU_DIV0(3, 1, 6, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 120, E5250_CPU_DIV0(3, 1, 5, 7, 7, 2), E5250_CPU_DIV1(2, 0), },
+ { 110, E5250_CPU_DIV0(3, 1, 5, 7, 7, 3), E5250_CPU_DIV1(2, 0), },
+ { 100, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 90, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 80, E5250_CPU_DIV0(2, 1, 4, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 70, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 60, E5250_CPU_DIV0(1, 1, 3, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 50, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 40, E5250_CPU_DIV0(1, 1, 2, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 30, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 20, E5250_CPU_DIV0(1, 1, 1, 7, 7, 1), E5250_CPU_DIV1(2, 0), },
+ { 0 },
+};
+
static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = samsung,clock-xxti, .data = (void *)0, },
{ },
@@ -797,6 +824,10 @@ static void __init exynos5250_clk_init(struct
device_node *np)
ARRAY_SIZE(exynos5250_div_clks));
samsung_clk_register_gate(ctx, exynos5250_gate_clks,
ARRAY_SIZE(exynos5250_gate_clks));
+ exynos_register_cpu_clock(ctx, CLK_ARM_CLK, armclk,
+ mout_cpu_p[0], mout_cpu_p[1], 0x200,
+ exynos5250_armclk_d, ARRAY_SIZE(exynos5250_armclk_d),
+ CLK_CPU_HAS_DIV1);
/*
* Enable arm clock down (in idle) and set arm divider
diff --git a/include/dt-bindings/clock/exynos5250.h
b/include/dt-bindings/clock/exynos5250.h
index 4273891d..8183d1c 100644
--- a/include/dt-bindings/clock/exynos5250.h
+++ b/include/dt-bindings/clock/exynos5250.h
@@ -21,6 +21,7 @@
#define CLK_FOUT_CPLL 6
#define CLK_FOUT_EPLL 7
#define CLK_FOUT_VPLL 8
+#define CLK_ARM_CLK9
/* gate for special clocks (sclk) */
#define CLK_SCLK_CAM_BAYER 128
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-pm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
On 07/24/15 12:40, Kukjin Kim wrote: On 07/24/15 09:30, Michael Turquette wrote: Quoting Kukjin Kim (2015-07-07 07:43:31) Bartlomiej Zolnierkiewicz wrote: [...] Chanwoo Choi (3): clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver arch/arm/boot/dts/exynos3250-monk.dts | 4 arch/arm/boot/dts/exynos3250-rinato.dts | 4 arch/arm/boot/dts/exynos3250.dtsi | 15 +++ arch/arm/mach-exynos/exynos.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 32 ++-- include/dt-bindings/clock/exynos3250.h | 1 + 6 files changed, 55 insertions(+), 2 deletions(-) Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Thank you for working on this. +1 Thanks. Mike and Sylwester, if you're OK on this series, I'd like to pick up in Samsung tree together. And if you want, I could provide topic branch for clk tree. Kukjin, A topic branch would be great. Sure, BTW it means you did 'ack' on this clk change? If not, please let em know ;-) I'll let you know once the topic branch is ready. Mike, Done, the topic branch 'v4.3-topic/clk-samsung' in samsung tree is for your clk tree. Thanks, Kukjin -- 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] thermal: consistently use int for temperatures
As the original patch has not been in upstream, I'd prefer a refreshed patch,
rather than an incremental fix.
Thanks,
rui
-Original Message-
From: Sascha Hauer [mailto:s.ha...@pengutronix.de]
Sent: Thursday, July 23, 2015 6:38 PM
To: Zhang, Rui
Cc: Punit Agrawal; linux...@vger.kernel.org; Eduardo Valentin; linux-
ker...@vger.kernel.org; Jean Delvare; Peter Feuerer; Heiko Stuebner;
Lukasz Majewski; Stephen Warren; Thierry Reding; linux-
a...@vger.kernel.org; platform-driver-...@vger.kernel.org; linux-arm-
ker...@lists.infradead.org; linux-o...@vger.kernel.org; linux-samsung-
s...@vger.kernel.org; Guenter Roeck; Rafael J. Wysocki; Maxime Ripard;
Darren Hart; lm-sens...@lm-sensors.org
Subject: Re: [PATCH v2] thermal: consistently use int for temperatures
Importance: High
Hi Zhang,
On Tue, Jul 21, 2015 at 01:35:31PM +, Zhang, Rui wrote:
Patch applied.
Thanks for applying. I missed to convert another place, so we get a new
compiler warning. The attached patch fixes this (suitable for git rebase --
autosquash). Please let me know if you can handle this or if you prefer a new
patch instead.
Thanks
Sascha
-8-
From 4907a7c32fd16eaf9f31d9f904276c9a0176b717 Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Thu, 23 Jul 2015 12:32:31 +0200
Subject: [PATCH] fixup! thermal: consistently use int for temperatures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
fixes:
drivers/power/charger-manager.c: In function
‘cm_get_battery_temperature’:
drivers/power/charger-manager.c:622:45: warning: passing argument 2 of
‘thermal_zone_get_temp’ from incompatible pointer type
ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long *)temp);
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/power/charger-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-
manager.c index 1c202cc..907293e 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -619,7 +619,7 @@ static int cm_get_battery_temperature(struct
charger_manager *cm,
#ifdef CONFIG_THERMAL
if (cm-tzd_batt) {
- ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long
*)temp);
+ ret = thermal_zone_get_temp(cm-tzd_batt, temp);
if (!ret)
/* Calibrate temperature unit */
*temp /= 100;
--
2.1.4
--
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- |
Re: [PATCH v6 0/3] cpufreq: Use cpufreq-dt driver for Exynos3250
On 07/24/15 09:30, Michael Turquette wrote: Quoting Kukjin Kim (2015-07-07 07:43:31) Bartlomiej Zolnierkiewicz wrote: [...] Chanwoo Choi (3): clk: samsung: exynos3250: Add cpu clock configuration data and instaniate cpu clock ARM: dts: Add CPU OPP and regulator supply property for Exynos3250 ARM: exynos: Add exynos3250 compatible to use generic cpufreq driver arch/arm/boot/dts/exynos3250-monk.dts | 4 arch/arm/boot/dts/exynos3250-rinato.dts | 4 arch/arm/boot/dts/exynos3250.dtsi | 15 +++ arch/arm/mach-exynos/exynos.c | 1 + drivers/clk/samsung/clk-exynos3250.c| 32 ++-- include/dt-bindings/clock/exynos3250.h | 1 + 6 files changed, 55 insertions(+), 2 deletions(-) Reviewed-by: Bartlomiej Zolnierkiewicz b.zolnier...@samsung.com Thank you for working on this. +1 Thanks. Mike and Sylwester, if you're OK on this series, I'd like to pick up in Samsung tree together. And if you want, I could provide topic branch for clk tree. Kukjin, A topic branch would be great. Sure, BTW it means you did 'ack' on this clk change? If not, please let em know ;-) I'll let you know once the topic branch is ready. Thanks, Kukjin -- 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 v2 2/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42 --
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would use the
event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be samsung,exynos-ppmu.
+- compatible: Should be samsung,exynos-ppmu or samsung,exynos-ppmu-v2.
- reg: physical base address of each PPMU and length of memory mapped region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in clock-names property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1048 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_general: ppmu_d0_general@1049 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1049 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_rt: ppmu_d0_rt@104a {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104a 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_cpu: ppmu_d1_cpu@104b {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104b 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_general: ppmu_d1_general@104c {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104c 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_rt: ppmu_d1_rt@104d {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104d 0x2000;
+ status = disabled;
+ };
--
1.8.5.5
--
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 v2 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
This patch adds the support for PPMU (Platform Performance Monitoring Unit)
version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
quite different from PPMUv1.1. The exynos-ppmu.c driver supports both PPMUv1.1
and PPMUv2.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/devfreq/event/exynos-ppmu.c | 170 ++--
drivers/devfreq/event/exynos-ppmu.h | 70 +++
2 files changed, 233 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
index 7d99d13bacd8..f9901f52a225 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -1,7 +1,7 @@
/*
* exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit) support
*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
* Author : Chanwoo Choi cw00.c...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -82,6 +82,15 @@ struct __exynos_ppmu_events {
PPMU_EVENT(mscl),
PPMU_EVENT(fimd0x),
PPMU_EVENT(fimd1x),
+
+ /* Only for Exynos5433 SoCs */
+ PPMU_EVENT(d0-cpu),
+ PPMU_EVENT(d0-general),
+ PPMU_EVENT(d0-rt),
+ PPMU_EVENT(d1-cpu),
+ PPMU_EVENT(d1-general),
+ PPMU_EVENT(d1-rt),
+
{ /* sentinel */ },
};
@@ -96,6 +105,9 @@ static int exynos_ppmu_find_ppmu_id(struct devfreq_event_dev
*edev)
return -EINVAL;
}
+/*
+ * The devfreq-event ops structure for PPMU v1.1
+ */
static int exynos_ppmu_disable(struct devfreq_event_dev *edev)
{
struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
@@ -200,10 +212,158 @@ static const struct devfreq_event_ops exynos_ppmu_ops = {
.get_event = exynos_ppmu_get_event,
};
+/*
+ * The devfreq-event ops structure for PPMU v2.0
+ */
+static int exynos_ppmu_v2_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc, clear;
+
+ /* Disable all counters */
+ clear = (PPMU_CCNT_MASK | PPMU_PMCNT0_MASK | PPMU_PMCNT1_MASK
+ | PPMU_PMCNT2_MASK | PPMU_PMCNT3_MASK);
+
+ __raw_writel(clear, info-ppmu.base + PPMU_V2_FLAG);
+ __raw_writel(clear, info-ppmu.base + PPMU_V2_INTENC);
+ __raw_writel(clear, info-ppmu.base + PPMU_V2_CNTENC);
+ __raw_writel(clear, info-ppmu.base + PPMU_V2_CNT_RESET);
+
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CIG_CFG0);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CIG_CFG1);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CIG_CFG2);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CIG_RESULT);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CNT_AUTO);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CH_EV0_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CH_EV1_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CH_EV2_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_CH_EV3_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_SM_ID_V);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_SM_ID_A);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_SM_OTHERS_V);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_SM_OTHERS_A);
+ __raw_writel(0x0, info-ppmu.base + PPMU_V2_INTERRUPT_RESET);
+
+ /* Disable PPMU */
+ pmnc = __raw_readl(info-ppmu.base + PPMU_V2_PMNC);
+ pmnc = ~PPMU_PMNC_ENABLE_MASK;
+ __raw_writel(pmnc, info-ppmu.base + PPMU_V2_PMNC);
+
+ return 0;
+}
+
+static int exynos_ppmu_v2_set_event(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ int id = exynos_ppmu_find_ppmu_id(edev);
+ u32 pmnc, cntens;
+
+ /* Enable all counters */
+ cntens = __raw_readl(info-ppmu.base + PPMU_V2_CNTENS);
+ cntens |= (PPMU_CCNT_MASK | (PPMU_ENABLE id));
+ __raw_writel(cntens, info-ppmu.base + PPMU_V2_CNTENS);
+
+ /* Set the event of Read/Write data count */
+ switch (id) {
+ case PPMU_PMNCNT0:
+ case PPMU_PMNCNT1:
+ case PPMU_PMNCNT2:
+ __raw_writel(PPMU_V2_RO_DATA_CNT | PPMU_V2_WO_DATA_CNT,
+ info-ppmu.base + PPMU_V2_CH_EVx_TYPE(id));
+ break;
+ case PPMU_PMNCNT3:
+ __raw_writel(PPMU_V2_EVT3_RW_DATA_CNT,
+ info-ppmu.base + PPMU_V2_CH_EVx_TYPE(id));
+ break;
+ }
+
+ /* Reset cycle counter/performance counter and enable PPMU */
+ pmnc = __raw_readl(info-ppmu.base + PPMU_V2_PMNC);
+ pmnc = ~(PPMU_PMNC_ENABLE_MASK
+ | PPMU_PMNC_COUNTER_RESET_MASK
+ | PPMU_PMNC_CC_RESET_MASK
+ | PPMU_PMNC_CC_DIVIDER_MASK
+ |
[PATCH v2 0/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2
This patch-set add the support of PPMU ((Platform Performance Monitoring Unit)
version 2.0 which is used on Exynos5433. The exynos-ppmu.c driver supports
both PPMUv1.1 and PPMUv2. This patch-set is testd on Exynos5433-based board.
The SoC list using PPMUv1.1
- Exynos4210/4212/4412, Exynos3250, Exynos5260
The SoC list using PPMUv2
- Exynos5433, Exynos7420
Changes from v1:
(https://lkml.org/lkml/2015/7/22/834)
- Add const keyword to the instance of struct devfreq_event_ops/of_device_id
- Modify the register name of PPMU v2 ('PPMUv2_*' - 'PPMU_V2_*')
- Reduce the unneed call function of exynos_bus_get_ops()
Chanwoo Choi (2):
PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
.../bindings/devfreq/event/exynos-ppmu.txt | 42 -
drivers/devfreq/event/exynos-ppmu.c| 170 -
drivers/devfreq/event/exynos-ppmu.h| 70 +
3 files changed, 273 insertions(+), 9 deletions(-)
--
1.8.5.5
--
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 1/2] MAINTAINERS: add Device Tree binding doc for max77686 regulator
On Fri, 17 Jul 2015, Javier Martinez Canillas wrote: The Device Tree binding documentation for the Maxim max77686 regulators has been moved from the Multi-Function Device DT binding section to its own Documentation/devicetree/bindings/regulator/max77686.txt file. Use a wilcard so both the mfd and regulator DT bindings are resolved. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- MAINTAINERS | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. diff --git a/MAINTAINERS b/MAINTAINERS index 2af741410533..d802d19a4ecc 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6583,7 +6583,7 @@ F: drivers/extcon/extcon-max77693.c F: drivers/rtc/rtc-max77686.c F: drivers/clk/clk-max77686.c F: Documentation/devicetree/bindings/mfd/max14577.txt -F: Documentation/devicetree/bindings/mfd/max77686.txt +F: Documentation/devicetree/bindings/*/max77686.txt F: Documentation/devicetree/bindings/mfd/max77693.txt F: Documentation/devicetree/bindings/clock/maxim,max77686.txt F: include/linux/mfd/max14577*.h -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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/2] MAINTAINERS: add an entry for the Maxim MAX77802 PMIC drivers
On Fri, 17 Jul 2015, Javier Martinez Canillas wrote: I added support for the max77802 drivers and have been maintaining them. So add an entry for these drivers to make tools like get_maintainer.pl to work and make people submitting patches add me to the CC list. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- MAINTAINERS | 8 1 file changed, 8 insertions(+) Applied, thanks. diff --git a/MAINTAINERS b/MAINTAINERS index d802d19a4ecc..5d964568f207 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -6570,6 +6570,14 @@ S: Supported F: drivers/power/max14577_charger.c F: drivers/power/max77693_charger.c +MAXIM MAX77802 MULTIFUNCTION PMIC DEVICE DRIVERS +M: Javier Martinez Canillas jav...@osg.samsung.com +L: linux-ker...@vger.kernel.org +S: Supported +F: drivers/*/*max77802.c +F: Documentation/devicetree/bindings/*/*max77802.txt +F: include/dt-bindings/*/*max77802.h + MAXIM PMIC AND MUIC DRIVERS FOR EXYNOS BASED BOARDS M: Chanwoo Choi cw00.c...@samsung.com M: Krzysztof Kozlowski k.kozlow...@samsung.com -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
On Thu, Jul 23, 2015 at 10:14 AM, Chanwoo Choi cw00.c...@samsung.com wrote:
Hi Krzysztof,
On 07/23/2015 04:28 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch adds the support for PPMU (Platform Performance Monitoring Unit)
version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
quite different from PPMUv1.1. The exynos-ppmu.c driver supports both
PPMUv1.1
and PPMUv2.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Hi,
Few comments at the end.
---
drivers/devfreq/event/exynos-ppmu.c | 168
++--
drivers/devfreq/event/exynos-ppmu.h | 70 +++
2 files changed, 231 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
index 7d99d13bacd8..6066dc18fc73 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -1,7 +1,7 @@
/*
* exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit)
support
*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
* Author : Chanwoo Choi cw00.c...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -82,6 +82,15 @@ struct __exynos_ppmu_events {
PPMU_EVENT(mscl),
PPMU_EVENT(fimd0x),
PPMU_EVENT(fimd1x),
(snip)
+static int exynos_ppmu_v2_get_event(struct devfreq_event_dev *edev,
+struct devfreq_event_data *edata)
+{
+struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+int id = exynos_ppmu_find_ppmu_id(edev);
+u32 pmnc, cntenc;
+u32 pmcnt_high, pmcnt_low;
+u64 load_count = 0;
+
+/* Disable PPMU */
+pmnc = __raw_readl(info-ppmu.base + PPMUv2_PMNC);
+pmnc = ~PPMU_PMNC_ENABLE_MASK;
+__raw_writel(pmnc, info-ppmu.base + PPMUv2_PMNC);
+
+/* Read cycle count and performance count */
+edata-total_count = __raw_readl(info-ppmu.base + PPMUv2_CCNT);
+
+switch (id) {
+case PPMU_PMNCNT0:
+case PPMU_PMNCNT1:
+case PPMU_PMNCNT2:
+load_count = __raw_readl(info-ppmu.base + PPMUv2_PMNCT(id));
+break;
+case PPMU_PMNCNT3:
+pmcnt_high = __raw_readl(info-ppmu.base + PPMUv2_PMCNT3_HIGH);
+pmcnt_low = __raw_readl(info-ppmu.base + PPMUv2_PMCNT3_LOW);
+load_count = (u64)((pmcnt_high 0xff) 32) + (u64)pmcnt_low;
+break;
+}
+edata-load_count = load_count;
+
+/* Disable all counters */
+cntenc = __raw_readl(info-ppmu.base + PPMUv2_CNTENC);
+cntenc |= (PPMU_CCNT_MASK | (PPMU_ENABLE id));
+__raw_writel(cntenc, info-ppmu.base + PPMUv2_CNTENC);
+
+dev_dbg(edev-dev, %25s (load: %ld / %ld)\n, edev-desc-name,
+edata-load_count, edata-total_count);
+return 0;
+}
+
+static struct devfreq_event_ops exynos_ppmu_v2_ops = {
This can be const.
OK.
+.disable = exynos_ppmu_v2_disable,
+.set_event = exynos_ppmu_v2_set_event,
+.get_event = exynos_ppmu_v2_get_event,
+};
+
+static struct of_device_id exynos_ppmu_id_match[] = {
In the previous patch this was not present but now it can be made 'const'.
OK for adding the 'const'.
The original 'exynos_ppmu_id_match' is located on below of this patch.
+{
+.compatible = samsung,exynos-ppmu,
+.data = (void *)exynos_ppmu_ops,
+}, {
+.compatible = samsung,exynos-ppmu-v2,
+.data = (void *)exynos_ppmu_v2_ops,
+},
+{ /* sentinel */ },
+};
+
+static struct devfreq_event_ops *exynos_bus_get_ops(struct device_node *np)
+{
+const struct of_device_id *match;
+
+match = of_match_node(exynos_ppmu_id_match, np);
+return (struct devfreq_event_ops *)match-data;
+}
+
static int of_get_devfreq_events(struct device_node *np,
struct exynos_ppmu *info)
{
@@ -238,7 +397,7 @@ static int of_get_devfreq_events(struct device_node *np,
continue;
}
-desc[j].ops = exynos_ppmu_ops;
+desc[j].ops = exynos_bus_get_ops(np);
So for each ops callback (get/set/disable) you will have another layer
of indirection where you will be matching the device each time?
That seems like a waste of CPU time. Just match it once here and use
either old ops or new ops_v2.
OK. I'll rework to reduce the unneeded operation.
desc[j].driver_data = info;
of_property_read_string(node, event-name, desc[j].name);
@@ -354,11 +513,6 @@ static int exynos_ppmu_remove(struct platform_device
*pdev)
return 0;
}
-static struct of_device_id exynos_ppmu_id_match[] = {
-{ .compatible = samsung,exynos-ppmu, },
-{ /* sentinel */ },
-};
-
Re: [PATCH 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
On Thu, Jul 23, 2015 at 11:43 AM, Dan Carpenter
dan.carpen...@oracle.com wrote:
On Thu, Jul 23, 2015 at 10:57:18AM +0900, Chanwoo Choi wrote:
+static int exynos_ppmu_v2_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc, clear;
+
+ /* Disable all counters */
+ clear = (PPMU_CCNT_MASK | PPMU_PMCNT0_MASK | PPMU_PMCNT1_MASK
+ | PPMU_PMCNT2_MASK | PPMU_PMCNT3_MASK);
+
+ __raw_writel(clear, info-ppmu.base + PPMUv2_FLAG);
Why aren't you using normal readl()/writel()? What are the endiannesses
here?
There are no special reason. Usually I used the __raw_readl/writel to
access the SFR registers
Thanks,
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 v2 3/4] mfd: Add DT binding for Maxim MAX77802 IC
Hello Lee,
Thanks for your feedback.
On 07/23/2015 05:16 PM, Lee Jones wrote:
On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:
The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
a RTC and an I2C interface to program the individual components.
The are already DT bindings for the regulators and clocks and
these reference to a bindings/mfd/max77802.txt file, that didn't
exist, for the details about the PMIC.
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
Changes in v2:
- Use the correct maxim,max77802 compatible string.
Suggested by Krzysztof Kozlowski
- Use a pmic generic node name for the max77802 node example.
Suggested by Sergei Shtylyov.
Documentation/devicetree/bindings/mfd/max77802.txt | 26
++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index ..c60cdec50d36
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,26 @@
+Maxim MAX77802 multi-function device
+
+The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
+efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
Would be good to capitalise the works in the acronyms, so
Low-DropOut and Power Management IC.
Ok.
+up application processors and peripherals, a 2-channel 32kHz clock outputs,
+a Real-Time-Clock (RTC) and a I2C interface to program the individual
+regulators, clocks outputs and the RTC.
+
+Binding for the built-in 32k clock generator block is defined separately
+in the bindings/clk/maxim,max77802.txt file and binding for the regulators
s/bindings/../
Ok.
+is defined in the bindings/regulator/max77802.txt file.
+
+Required properties:
+- compatible : Must be maxim,max77802;
+- reg : Specifies the i2c slave address of PMIC block.
s/i2c/I2C/
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
As above.
Ok. I'll change it.
+- interrupt-parent : The parent interrupt controller.
+
+Example:
+
+max77802: pmic@09 {
+compatible = maxim,max77802;
+interrupt-parent = intc;
+interrupts = 26 0;
Is there a define in include/dt-bindings/interrupt-controller to
replace 0? IRQ_TYPE_NONE perhaps.
Yes, I'll change that as well.
+reg = 0x09;
+};
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
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 3/4] mfd: Add DT binding for Maxim MAX77802 IC
On Fri, 17 Jul 2015, Javier Martinez Canillas wrote:
The MAX77802 is a chip that contains regulators, 2 32kHz clocks,
a RTC and an I2C interface to program the individual components.
The are already DT bindings for the regulators and clocks and
these reference to a bindings/mfd/max77802.txt file, that didn't
exist, for the details about the PMIC.
Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com
---
Changes in v2:
- Use the correct maxim,max77802 compatible string.
Suggested by Krzysztof Kozlowski
- Use a pmic generic node name for the max77802 node example.
Suggested by Sergei Shtylyov.
Documentation/devicetree/bindings/mfd/max77802.txt | 26
++
1 file changed, 26 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/max77802.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt
b/Documentation/devicetree/bindings/mfd/max77802.txt
new file mode 100644
index ..c60cdec50d36
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77802.txt
@@ -0,0 +1,26 @@
+Maxim MAX77802 multi-function device
+
+The Maxim MAX77802 is a power management chip (PMIC) that contains 10 high
+efficiency Buck regulators, 32 Low-dropout (LDO) regulators used to power
Would be good to capitalise the works in the acronyms, so
Low-DropOut and Power Management IC.
+up application processors and peripherals, a 2-channel 32kHz clock outputs,
+a Real-Time-Clock (RTC) and a I2C interface to program the individual
+regulators, clocks outputs and the RTC.
+
+Binding for the built-in 32k clock generator block is defined separately
+in the bindings/clk/maxim,max77802.txt file and binding for the regulators
s/bindings/../
+is defined in the bindings/regulator/max77802.txt file.
+
+Required properties:
+- compatible : Must be maxim,max77802;
+- reg : Specifies the i2c slave address of PMIC block.
s/i2c/I2C/
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
As above.
+- interrupt-parent : The parent interrupt controller.
+
+Example:
+
+ max77802: pmic@09 {
+ compatible = maxim,max77802;
+ interrupt-parent = intc;
+ interrupts = 26 0;
Is there a define in include/dt-bindings/interrupt-controller to
replace 0? IRQ_TYPE_NONE perhaps.
+ reg = 0x09;
+ };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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] thermal: consistently use int for temperatures
On Tue 2015-07-21 09:21:32, Sascha Hauer wrote: The thermal code uses int, long and unsigned long for temperatures in different places. Using an unsigned type limits the thermal framework to positive temperatures without need. Also several drivers currently will report temperatures near UINT_MAX for temperatures below 0°C. This will probably immediately shut the machine down due to overtemperature if started below 0°C. 'long' is 64bit on several architectures. This is not needed since INT_MAX °mC is above the melting point of all known materials. Can we do something like typedef millicelsius_t int; ...to document the units? Consistently use a plain 'int' for temperatures throughout the thermal code and the drivers. This only changes the places in the drivers where the temperature is passed around as pointer, when drivers internally use another type this is not changed. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Hi,
On 21 July 2015 at 15:03, Marek Szyprowski m.szyprow...@samsung.com wrote:
Hello,
On 2015-07-16 15:09, Hans Verkuil wrote:
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
From: Kamil Debski ka...@wypas.org
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski ka...@wypas.org
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
snip
diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
new file mode 100644
index 000..0f16d00
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -0,0 +1,283 @@
+/* drivers/media/platform/s5p-cec/s5p_cec.c
+ *
+ * Samsung S5P CEC driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * 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 driver is based on the cec interface driver for exynos soc by
+ * SangPil Moon.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/timer.h
+#include linux/version.h
+#include linux/workqueue.h
+#include media/cec.h
+
+#include exynos_hdmi_cec.h
+#include regs-cec.h
+#include s5p_cec.h
+
+#define CEC_NAME s5p-cec
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
+{
+ struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev,
adap);
+ int ret;
+
+ if (enable) {
+ ret = pm_runtime_get_sync(cec-dev);
+
+ adap-phys_addr = 0x100b;
This is a bogus physical address. The actual physical address has to be
derived
from the EDID that is read by the HDMI transmitter.
I think in the case of this driver it will have to be userspace that
assigns
the physical address after reading the EDID from drm/kms?
How did you test this, Kamil?
If I remember correctly, physical address has been derived from EDID in the
userspace (it is available in /sys/class/drm/*) and passed to s5p-cec driver
by
appropriate ioctl.
I don't know what is the reason for the above 'adap-phys_addr = 0x100b'
assignment.
At some point there was an idea to read the address from the EDID in
kernel. This static address was a hack until the code that reads the
EDID is written. As you say, it is much better to leave the address to
be set by the userspace. So this assignment serves no purpose anymore.
Best regards
--
Marek Szyprowski, PhD
Samsung RD Institute Poland
Best wishes,
Kamil
--
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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 23 July 2015 at 18:46, Michal Suchanek hramr...@gmail.com wrote: On 22 July 2015 at 11:01, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 10:38:14 AM, Michal Suchanek wrote: On 22 July 2015 at 10:24, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 10:18:04 AM, Michal Suchanek wrote: On 22 July 2015 at 09:58, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 09:45:27 AM, Michal Suchanek wrote: On 22 July 2015 at 09:33, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote: On 22 July 2015 at 06:49, Vinod Koul vinod.k...@intel.com wrote: On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote: Or alternatively we could publish the limitations of the channel using capabilities so SPI knows I have a dmaengine channel and it can transfer max N length transfers so would be able to break rather than guessing it or coding in DT. Yes it may come from DT but that should be dmaengine driver rather than client driver :) This can be done by dma_get_slave_caps(chan, caps) And we add max_length as one more parameter to existing set Also all this could be handled in generic SPI-dmaengine layer so that individual drivers don't have to code it in Let me know if this idea is okay, I can push the dmaengine bits... It would be ok if there was a fixed limit. However, the limit depends on SPI slave settings. Presumably for other buses using the dmaengine the limit would depend on the bus or slave settings as well. I do not see a sane way of passing this all the way to the dmaengine driver. I don't see why this should be client (SPI) dependent. The max length supported is a dmaengine constraint, typically flowing from max blocks/length it can transfer. Know this limit can allow clients to split transfers. In practice on the board I have the maximum transfer length before it fails depends on SPI bus speed which is set up per slave. I did not try searching the space of possible settings thorougly and settled for a setting that gives reasonable speed and transfer length. This looks more like a signal integrity issue though. It certainly does on the surface. However, when wrong data is delivered over the SPI bus (such as when I use wrong phase setting) the SPI controller happily delivers wrong data over PIO. The failure I am seeing is that the pl330 DMA program which repeatedly waits for data from the SPI controller never finishes the read loop and does not signal the interrupt. It seems it also leaves some data in a FIFO somewhere so next command on the flash returns garbage and fails. I observed something similar on MXS (mx28) SPI block. Do you use mixed PIO/DMA mode perhaps ? The SPI driver uses PIO for short transfers and DMA for transfers longer than the controller FIFO. This seems to be the standard way to do things.It works flawlessly so long as submitting overly long DMA programs is avoided. Can you try doing JUST DMA, no PIO ? I remember seeing some bus synchronisation issues when I did mixed PIO/DMA on the MXS and it was nasty to track down. Just give pure DMA a go to see if the thing stabilizes somehow. It's probably slower to set up DMA for 2-byte commands but it might work nonetheless. It is, the overhead will be considerable. It might help the stability though. I'm really looking forward to the results! Hello, this does not quite work. My test with spidev: # ./spinor /dev/spidev1.0 Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60 Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8 Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60 I receive correct ID but spi-nor complains it does not know ID 00 c8 60. IIRC garbage should be sent only at the time command is transferred so only one byte of garbage should be received. Also the garbage tends to be the last state of the data output - all 0 or all 1. So it seems using DMA for all transfers including 1-byte commands results in (some?) received data getting an extra 00 prefix. I also managed to lock up the controller completely since there is some error passing the SPI speed somewhere :( [ 1352.977530] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -- 0 [ 1352.977540] spidev spi1.0: spi mode 0 [ 1352.977576] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -- 0 [ 1352.977582] spidev spi1.0: msb first [ 1352.977614] spidev spi1.0: setup mode 0, 8 bits/w, 8000 Hz max -- 0 [ 1352.977620] spidev spi1.0: 0 bits per word [ 1352.977652] spidev spi1.0: setup mode 0, 8 bits/w,
Re: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
On 07/23/2015 06:39 PM, Kamil Debski wrote:
Hi,
On 21 July 2015 at 15:03, Marek Szyprowski m.szyprow...@samsung.com wrote:
Hello,
On 2015-07-16 15:09, Hans Verkuil wrote:
Marek, Kamil,
On 06/29/15 12:14, Hans Verkuil wrote:
From: Kamil Debski ka...@wypas.org
Add CEC interface driver present in the Samsung Exynos range of
SoCs.
The following files were based on work by SangPil Moon:
- exynos_hdmi_cec.h
- exynos_hdmi_cecctl.c
Signed-off-by: Kamil Debski ka...@wypas.org
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
snip
diff --git a/drivers/media/platform/s5p-cec/s5p_cec.c
b/drivers/media/platform/s5p-cec/s5p_cec.c
new file mode 100644
index 000..0f16d00
--- /dev/null
+++ b/drivers/media/platform/s5p-cec/s5p_cec.c
@@ -0,0 +1,283 @@
+/* drivers/media/platform/s5p-cec/s5p_cec.c
+ *
+ * Samsung S5P CEC driver
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ *
+ * 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 driver is based on the cec interface driver for exynos soc by
+ * SangPil Moon.
+ */
+
+#include linux/clk.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/timer.h
+#include linux/version.h
+#include linux/workqueue.h
+#include media/cec.h
+
+#include exynos_hdmi_cec.h
+#include regs-cec.h
+#include s5p_cec.h
+
+#define CEC_NAME s5p-cec
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-2));
+
+static int s5p_cec_enable(struct cec_adapter *adap, bool enable)
+{
+ struct s5p_cec_dev *cec = container_of(adap, struct s5p_cec_dev,
adap);
+ int ret;
+
+ if (enable) {
+ ret = pm_runtime_get_sync(cec-dev);
+
+ adap-phys_addr = 0x100b;
This is a bogus physical address. The actual physical address has to be
derived
from the EDID that is read by the HDMI transmitter.
I think in the case of this driver it will have to be userspace that
assigns
the physical address after reading the EDID from drm/kms?
How did you test this, Kamil?
If I remember correctly, physical address has been derived from EDID in the
userspace (it is available in /sys/class/drm/*) and passed to s5p-cec driver
by
appropriate ioctl.
I don't know what is the reason for the above 'adap-phys_addr = 0x100b'
assignment.
At some point there was an idea to read the address from the EDID in
kernel. This static address was a hack until the code that reads the
EDID is written. As you say, it is much better to leave the address to
be set by the userspace. So this assignment serves no purpose anymore.
Thank you, that's what I thought. It's fixed in my current tree. Still
working on the CEC framework: I'm chasing race conditions and I suspect
that there may be a bug in the adv7604 or adv7511 CEC implementation.
Once I've sorted that I post a new version which has been tested a lot
more thoroughly and should be complete except for the documentation.
Regards,
Hans
--
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 00/19] Update ALSA, and au0828 drivers to use Managed Media Controller API
On 07/22/2015 04:42 PM, Shuah Khan wrote: This patch series updates ALSA driver, and au0828 core driver to use Managed Media controller API to share tuner. Please note that Managed Media Controller API and DVB and V4L2 drivers updates to use Media Controller API have been added in a prior patch series. Media Controller API is enhanced with two new interfaces to register and unregister entity_notify hooks to allow drivers to take appropriate actions when as new entities get added to the shared media device. Tested exclusion between digital, analog, and audio to ensure when tuner has an active link to DVB FE, analog, and audio will detect and honor the tuner busy conditions and vice versa. Changes since v1: Link to v1: http://www.spinics.net/lists/linux-media/msg91697.html I uploaded this patch series to my linux.git media_controller branch on kernel.org: git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git media_controller branch thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 22 July 2015 at 11:01, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 10:38:14 AM, Michal Suchanek wrote: On 22 July 2015 at 10:24, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 10:18:04 AM, Michal Suchanek wrote: On 22 July 2015 at 09:58, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 09:45:27 AM, Michal Suchanek wrote: On 22 July 2015 at 09:33, Marek Vasut ma...@denx.de wrote: On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote: On 22 July 2015 at 06:49, Vinod Koul vinod.k...@intel.com wrote: On Tue, Jul 21, 2015 at 10:14:11AM +0200, Michal Suchanek wrote: Or alternatively we could publish the limitations of the channel using capabilities so SPI knows I have a dmaengine channel and it can transfer max N length transfers so would be able to break rather than guessing it or coding in DT. Yes it may come from DT but that should be dmaengine driver rather than client driver :) This can be done by dma_get_slave_caps(chan, caps) And we add max_length as one more parameter to existing set Also all this could be handled in generic SPI-dmaengine layer so that individual drivers don't have to code it in Let me know if this idea is okay, I can push the dmaengine bits... It would be ok if there was a fixed limit. However, the limit depends on SPI slave settings. Presumably for other buses using the dmaengine the limit would depend on the bus or slave settings as well. I do not see a sane way of passing this all the way to the dmaengine driver. I don't see why this should be client (SPI) dependent. The max length supported is a dmaengine constraint, typically flowing from max blocks/length it can transfer. Know this limit can allow clients to split transfers. In practice on the board I have the maximum transfer length before it fails depends on SPI bus speed which is set up per slave. I did not try searching the space of possible settings thorougly and settled for a setting that gives reasonable speed and transfer length. This looks more like a signal integrity issue though. It certainly does on the surface. However, when wrong data is delivered over the SPI bus (such as when I use wrong phase setting) the SPI controller happily delivers wrong data over PIO. The failure I am seeing is that the pl330 DMA program which repeatedly waits for data from the SPI controller never finishes the read loop and does not signal the interrupt. It seems it also leaves some data in a FIFO somewhere so next command on the flash returns garbage and fails. I observed something similar on MXS (mx28) SPI block. Do you use mixed PIO/DMA mode perhaps ? The SPI driver uses PIO for short transfers and DMA for transfers longer than the controller FIFO. This seems to be the standard way to do things.It works flawlessly so long as submitting overly long DMA programs is avoided. Can you try doing JUST DMA, no PIO ? I remember seeing some bus synchronisation issues when I did mixed PIO/DMA on the MXS and it was nasty to track down. Just give pure DMA a go to see if the thing stabilizes somehow. It's probably slower to set up DMA for 2-byte commands but it might work nonetheless. It is, the overhead will be considerable. It might help the stability though. I'm really looking forward to the results! Hello, this does not quite work. My test with spidev: # ./spinor /dev/spidev1.0 Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60 Sending 90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff ff ff ff c8 15 c8 15 c8 15 c8 15 c8 15 c8 Sending 9f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Received 00 ff c8 60 16 c8 60 16 c8 60 16 c8 60 16 c8 60 I receive correct ID but spi-nor complains it does not know ID 00 c8 60. IIRC garbage should be sent only at the time command is transferred so only one byte of garbage should be received. Also the garbage tends to be the last state of the data output - all 0 or all 1. So it seems using DMA for all transfers including 1-byte commands results in (some?) received data getting an extra 00 prefix. [ 26.702690] spi spi1.0: setup mode 0, 8 bits/w, 4000 Hz max -- 0 [ 26.703474] spi_master spi1: s3c64xx_spi_config: clk_from_cmu 1 src_clk sclk_spi1 mode bpw 8 [ 26.703534] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: xfer bpw 8 speed 4000 [ 26.703543] spi_master spi1: spi1.0 s3c64xx_spi_transfer_one: using dma [ 26.703568] dma-pl330 121b.pdma: setting up request on thread 1 [ 26.703576] bc041200:DMAMOV CCR 0x800201 [ 26.703585] bc041206:DMAMOV SAR 0x6e151280 [ 26.703593] bc04120c:DMAMOV DAR 0x12d30018 [ 26.703601] bc041212:DMAWFPS 5 [
Re: [PATCH 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch adds the support for PPMU (Platform Performance Monitoring Unit)
version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
quite different from PPMUv1.1. The exynos-ppmu.c driver supports both PPMUv1.1
and PPMUv2.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Hi,
Few comments at the end.
---
drivers/devfreq/event/exynos-ppmu.c | 168
++--
drivers/devfreq/event/exynos-ppmu.h | 70 +++
2 files changed, 231 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
index 7d99d13bacd8..6066dc18fc73 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -1,7 +1,7 @@
/*
* exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit) support
*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
* Author : Chanwoo Choi cw00.c...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -82,6 +82,15 @@ struct __exynos_ppmu_events {
PPMU_EVENT(mscl),
PPMU_EVENT(fimd0x),
PPMU_EVENT(fimd1x),
+
+ /* Only for Exynos5433 SoCs */
+ PPMU_EVENT(d0-cpu),
+ PPMU_EVENT(d0-general),
+ PPMU_EVENT(d0-rt),
+ PPMU_EVENT(d1-cpu),
+ PPMU_EVENT(d1-general),
+ PPMU_EVENT(d1-rt),
+
{ /* sentinel */ },
};
@@ -96,6 +105,9 @@ static int exynos_ppmu_find_ppmu_id(struct
devfreq_event_dev *edev)
return -EINVAL;
}
+/*
+ * The devfreq-event ops structure for PPMU v1.1
+ */
static int exynos_ppmu_disable(struct devfreq_event_dev *edev)
{
struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
@@ -200,6 +212,153 @@ static const struct devfreq_event_ops exynos_ppmu_ops =
{
.get_event = exynos_ppmu_get_event,
};
+/*
+ * The devfreq-event ops structure for PPMU v2.0
+ */
+static int exynos_ppmu_v2_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc, clear;
+
+ /* Disable all counters */
+ clear = (PPMU_CCNT_MASK | PPMU_PMCNT0_MASK | PPMU_PMCNT1_MASK
+ | PPMU_PMCNT2_MASK | PPMU_PMCNT3_MASK);
+
+ __raw_writel(clear, info-ppmu.base + PPMUv2_FLAG);
+ __raw_writel(clear, info-ppmu.base + PPMUv2_INTENC);
+ __raw_writel(clear, info-ppmu.base + PPMUv2_CNTENC);
+ __raw_writel(clear, info-ppmu.base + PPMUv2_CNT_RESET);
+
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CIG_CFG0);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CIG_CFG1);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CIG_CFG2);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CIG_RESULT);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CNT_AUTO);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CH_EV0_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CH_EV1_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CH_EV2_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_CH_EV3_TYPE);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_SM_ID_V);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_SM_ID_A);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_SM_OTHERS_V);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_SM_OTHERS_A);
+ __raw_writel(0x0, info-ppmu.base + PPMUv2_INTERRUPT_RESET);
+
+ /* Disable PPMU */
+ pmnc = __raw_readl(info-ppmu.base + PPMUv2_PMNC);
+ pmnc = ~PPMU_PMNC_ENABLE_MASK;
+ __raw_writel(pmnc, info-ppmu.base + PPMUv2_PMNC);
+
+ return 0;
+}
+
+static int exynos_ppmu_v2_set_event(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ int id = exynos_ppmu_find_ppmu_id(edev);
+ u32 pmnc, cntens;
+
+ /* Enable all counters */
+ cntens = __raw_readl(info-ppmu.base + PPMUv2_CNTENS);
+ cntens |= (PPMU_CCNT_MASK | (PPMU_ENABLE id));
+ __raw_writel(cntens, info-ppmu.base + PPMUv2_CNTENS);
+
+ /* Set the event of Read/Write data count */
+ switch (id) {
+ case PPMU_PMNCNT0:
+ case PPMU_PMNCNT1:
+ case PPMU_PMNCNT2:
+ __raw_writel(PPMUv2_RO_DATA_CNT | PPMUv2_WO_DATA_CNT,
+ info-ppmu.base + PPMUv2_CH_EVx_TYPE(id));
+ break;
+ case PPMU_PMNCNT3:
+ __raw_writel(PPMUv2_EVT3_RW_DATA_CNT,
+ info-ppmu.base + PPMUv2_CH_EVx_TYPE(id));
+ break;
+ }
+
+ /* Reset cycle counter/performance counter and enable PPMU */
+ pmnc = __raw_readl(info-ppmu.base + PPMUv2_PMNC);
+ pmnc = ~(PPMU_PMNC_ENABLE_MASK
+ | PPMU_PMNC_COUNTER_RESET_MASK
+ | PPMU_PMNC_CC_RESET_MASK
+ |
Re: [PATCH 2/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42
--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would use
the event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be samsung,exynos-ppmu.
+- compatible: Should be samsung,exynos-ppmu or samsung,exynos-ppmu-v2.
I have doubts about -v2 suffix. Why not using SoCs compatible suffix?
Is it related to ARM Performance Monitoring Unit v2 or maybe Samsung
just labelled it v2 for marketing purposes?
Best regards,
Krzysztof
- reg: physical base address of each PPMU and length of memory mapped region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in clock-names property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1048 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_general: ppmu_d0_general@1049 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1049 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_rt: ppmu_d0_rt@104a {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104a 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_cpu: ppmu_d1_cpu@104b {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104b 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_general: ppmu_d1_general@104c {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104c 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_rt: ppmu_d1_rt@104d {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104d 0x2000;
+ status = disabled;
+ };
--
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] ARM: EXYNOS: mach: Improvements for 4.3
Kukjin Kim wrote: Krzysztof Kozlowski wrote: On 21.07.2015 14:21, Krzysztof Kozlowski wrote: 2015-07-21 14:13 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com: 2015-07-21 14:02 GMT+09:00 Kukjin Kim kg...@kernel.org: Krzysztof Kozlowski wrote: [...] -- Applied above changes into fixes/non-critical, next/cleanup-samsung, next/dt-samsung and next/cpufreq-clk-samsung according to the change. Cc-ed Bartlomiej, One issue found: splitting DTS change for Exynos 5250 cpufreq to separate branch will break bisectability. The commit ARM: dts: Exynos5250: add CPU OPP and regulator supply property: 1. MUST be put after clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock to prevent build failures, 2. should be put before ARM: Exynos: switch to using generic cpufreq driver for Exynos5250 to prevent lost cpufreq functionality. Doing otherwise would lose bisectability which is really unfortunate when you can simply avoid it. This should remain in the same branch - next/cpufreq-clk-samsung. Dear Kukjin, Nothing changed since yesterday... so let me point this in a more clear way. The way you divided the patchset causes build errors: -- HEAD is now at 565872a601c4... ARM: dts: add CPU OPP and regulator supply property for exynos5250 ERROR: Failed build: -A arm -c exynos on 565872a601c4d91a75b917b1fb40ff27ad7ebb08 LOGS: Error: ../arch/arm/boot/dts/exynos5250.dtsi:65.21-22 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** [dtbs] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 -- This breaks bisectability without any special valid reason. Hi, I couldn't check e-mail yesterday because of annual health check. Anyway, I'll look at the error and handle it soon. OK, the change for the include/dt-bindings/clock/exynos5250.h file which is in next/cpufreq-clk-samsung branch should be provided in next/dt-samsung branch. It should be fine tonight in my time. One more thing, the splitting changes into dt and driver side would be required generally and if it has dependency like this, proper merge topic branch is required by maintainer. But I've missed last action :( Thanks, Kukjin -- 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] ARM: EXYNOS: mach: Improvements for 4.3
Krzysztof Kozlowski wrote: On 21.07.2015 14:21, Krzysztof Kozlowski wrote: 2015-07-21 14:13 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com: 2015-07-21 14:02 GMT+09:00 Kukjin Kim kg...@kernel.org: Krzysztof Kozlowski wrote: [...] -- Applied above changes into fixes/non-critical, next/cleanup-samsung, next/dt-samsung and next/cpufreq-clk-samsung according to the change. Cc-ed Bartlomiej, One issue found: splitting DTS change for Exynos 5250 cpufreq to separate branch will break bisectability. The commit ARM: dts: Exynos5250: add CPU OPP and regulator supply property: 1. MUST be put after clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock to prevent build failures, 2. should be put before ARM: Exynos: switch to using generic cpufreq driver for Exynos5250 to prevent lost cpufreq functionality. Doing otherwise would lose bisectability which is really unfortunate when you can simply avoid it. This should remain in the same branch - next/cpufreq-clk-samsung. Dear Kukjin, Nothing changed since yesterday... so let me point this in a more clear way. The way you divided the patchset causes build errors: -- HEAD is now at 565872a601c4... ARM: dts: add CPU OPP and regulator supply property for exynos5250 ERROR: Failed build: -A arm -c exynos on 565872a601c4d91a75b917b1fb40ff27ad7ebb08 LOGS: Error: ../arch/arm/boot/dts/exynos5250.dtsi:65.21-22 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** [dtbs] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 -- This breaks bisectability without any special valid reason. Hi, I couldn't check e-mail yesterday because of annual health check. Anyway, I'll look at the error and handle it soon. Thanks for your check. Kukjin -- 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/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
On 23.07.2015 16:48, Chanwoo Choi wrote:
On 07/23/2015 04:37 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42
--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would use
the event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be samsung,exynos-ppmu.
+- compatible: Should be samsung,exynos-ppmu or samsung,exynos-ppmu-v2.
I have doubts about -v2 suffix. Why not using SoCs compatible suffix?
Is it related to ARM Performance Monitoring Unit v2 or maybe Samsung
just labelled it v2 for marketing purposes?
As I knew, the version of PPMU was decided by SoC designer without any
dependency.
If we prefer to use the SoC name instead of '-v2' version on compatible name,
we can change them as following:
- samsung,exynos-ppmu - samsung,exynos4210-ppmu
(because Exynos4210 used the PPMU v1 for the first time)
- samsung,exynos-ppmu-v2 - samsung,exynos5433-ppmu
(because Exynos5433 used the PPMU v2 for the first time)
Does the Exynos5433 datasheet mention the version 2? I could not find
such annotation in mine.
Krzysztof
Best Regards,
Chanwoo Choi
Best regards,
Krzysztof
- reg: physical base address of each PPMU and length of memory mapped
region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in clock-names property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1048 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_general: ppmu_d0_general@1049 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1049 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_rt: ppmu_d0_rt@104a {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104a 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_cpu: ppmu_d1_cpu@104b {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104b 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_general: ppmu_d1_general@104c {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104c 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_rt: ppmu_d1_rt@104d {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104d 0x2000;
+ status = disabled;
+ };
--
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/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
On 07/23/2015 04:37 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42
--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would use
the event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be samsung,exynos-ppmu.
+- compatible: Should be samsung,exynos-ppmu or samsung,exynos-ppmu-v2.
I have doubts about -v2 suffix. Why not using SoCs compatible suffix?
Is it related to ARM Performance Monitoring Unit v2 or maybe Samsung
just labelled it v2 for marketing purposes?
As I knew, the version of PPMU was decided by SoC designer without any
dependency.
If we prefer to use the SoC name instead of '-v2' version on compatible name,
we can change them as following:
- samsung,exynos-ppmu - samsung,exynos4210-ppmu
(because Exynos4210 used the PPMU v1 for the first time)
- samsung,exynos-ppmu-v2 - samsung,exynos5433-ppmu
(because Exynos5433 used the PPMU v2 for the first time)
Best Regards,
Chanwoo Choi
Best regards,
Krzysztof
- reg: physical base address of each PPMU and length of memory mapped
region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in clock-names property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x1048 0x2000;
+status = disabled;
+};
+
+ppmu_d0_general: ppmu_d0_general@1049 {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x1049 0x2000;
+status = disabled;
+};
+
+ppmu_d0_rt: ppmu_d0_rt@104a {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x104a 0x2000;
+status = disabled;
+};
+
+ppmu_d1_cpu: ppmu_d1_cpu@104b {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x104b 0x2000;
+status = disabled;
+};
+
+ppmu_d1_general: ppmu_d1_general@104c {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x104c 0x2000;
+status = disabled;
+};
+
+ppmu_d1_rt: ppmu_d1_rt@104d {
+compatible = samsung,exynos-ppmu-v2;
+reg = 0x104d 0x2000;
+status = disabled;
+};
--
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/2] PM / devfreq: exynos-ppmu: Update documentation to support PPMUv2
On 07/23/2015 04:58 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 16:48, Chanwoo Choi wrote:
On 07/23/2015 04:37 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch updates the documentation to include the information of PPMUv2.
The PPMUv2 is used for Exynos5433 and Exynos7420 to monitor the performance
of each IP in Exynos SoC.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
.../bindings/devfreq/event/exynos-ppmu.txt | 42
--
1 file changed, 40 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
index b54bf3a2ff57..e8fa6b6a1827 100644
--- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
+++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
@@ -11,7 +11,7 @@ to various devfreq devices. The devfreq devices would
use the event data when
derterming the current state of each IP.
Required properties:
-- compatible: Should be samsung,exynos-ppmu.
+- compatible: Should be samsung,exynos-ppmu or samsung,exynos-ppmu-v2.
I have doubts about -v2 suffix. Why not using SoCs compatible suffix?
Is it related to ARM Performance Monitoring Unit v2 or maybe Samsung
just labelled it v2 for marketing purposes?
As I knew, the version of PPMU was decided by SoC designer without any
dependency.
If we prefer to use the SoC name instead of '-v2' version on compatible name,
we can change them as following:
- samsung,exynos-ppmu - samsung,exynos4210-ppmu
(because Exynos4210 used the PPMU v1 for the first time)
- samsung,exynos-ppmu-v2 - samsung,exynos5433-ppmu
(because Exynos5433 used the PPMU v2 for the first time)
Does the Exynos5433 datasheet mention the version 2? I could not find
such annotation in mine.
Yes, Exynos5433 datasheet don't include the detailed information of PPMU.
I check the version of PPMU on the released kernel source by System L.S.I.
Krzysztof
Best Regards,
Chanwoo Choi
Best regards,
Krzysztof
- reg: physical base address of each PPMU and length of memory mapped
region.
Optional properties:
@@ -19,7 +19,7 @@ Optional properties:
- clocks : phandles for clock specified in clock-names property
- #clock-cells: should be 1.
-Example1 : PPMU nodes in exynos3250.dtsi are listed below.
+Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a {
compatible = samsung,exynos-ppmu;
@@ -108,3 +108,41 @@ Example2 : Events of each PPMU node in
exynos3250-rinato.dts are listed below.
};
};
};
+
+Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
+
+ ppmu_d0_cpu: ppmu_d0_cpu@1048 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1048 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_general: ppmu_d0_general@1049 {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x1049 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d0_rt: ppmu_d0_rt@104a {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104a 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_cpu: ppmu_d1_cpu@104b {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104b 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_general: ppmu_d1_general@104c {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104c 0x2000;
+ status = disabled;
+ };
+
+ ppmu_d1_rt: ppmu_d1_rt@104d {
+ compatible = samsung,exynos-ppmu-v2;
+ reg = 0x104d 0x2000;
+ status = disabled;
+ };
--
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 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
Hi Krzysztof,
On 07/23/2015 04:28 PM, Krzysztof Kozlowski wrote:
On 23.07.2015 10:57, Chanwoo Choi wrote:
This patch adds the support for PPMU (Platform Performance Monitoring Unit)
version 2.0 for Exynos5433 SoC. Exynos5433 SoC must need PPMUv2 which is
quite different from PPMUv1.1. The exynos-ppmu.c driver supports both
PPMUv1.1
and PPMUv2.
Cc: MyungJoo Ham myungjoo@samsung.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
Hi,
Few comments at the end.
---
drivers/devfreq/event/exynos-ppmu.c | 168
++--
drivers/devfreq/event/exynos-ppmu.h | 70 +++
2 files changed, 231 insertions(+), 7 deletions(-)
diff --git a/drivers/devfreq/event/exynos-ppmu.c
b/drivers/devfreq/event/exynos-ppmu.c
index 7d99d13bacd8..6066dc18fc73 100644
--- a/drivers/devfreq/event/exynos-ppmu.c
+++ b/drivers/devfreq/event/exynos-ppmu.c
@@ -1,7 +1,7 @@
/*
* exynos_ppmu.c - EXYNOS PPMU (Platform Performance Monitoring Unit)
support
*
- * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Copyright (c) 2014-2015 Samsung Electronics Co., Ltd.
* Author : Chanwoo Choi cw00.c...@samsung.com
*
* This program is free software; you can redistribute it and/or modify
@@ -82,6 +82,15 @@ struct __exynos_ppmu_events {
PPMU_EVENT(mscl),
PPMU_EVENT(fimd0x),
PPMU_EVENT(fimd1x),
(snip)
+static int exynos_ppmu_v2_get_event(struct devfreq_event_dev *edev,
+struct devfreq_event_data *edata)
+{
+struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+int id = exynos_ppmu_find_ppmu_id(edev);
+u32 pmnc, cntenc;
+u32 pmcnt_high, pmcnt_low;
+u64 load_count = 0;
+
+/* Disable PPMU */
+pmnc = __raw_readl(info-ppmu.base + PPMUv2_PMNC);
+pmnc = ~PPMU_PMNC_ENABLE_MASK;
+__raw_writel(pmnc, info-ppmu.base + PPMUv2_PMNC);
+
+/* Read cycle count and performance count */
+edata-total_count = __raw_readl(info-ppmu.base + PPMUv2_CCNT);
+
+switch (id) {
+case PPMU_PMNCNT0:
+case PPMU_PMNCNT1:
+case PPMU_PMNCNT2:
+load_count = __raw_readl(info-ppmu.base + PPMUv2_PMNCT(id));
+break;
+case PPMU_PMNCNT3:
+pmcnt_high = __raw_readl(info-ppmu.base + PPMUv2_PMCNT3_HIGH);
+pmcnt_low = __raw_readl(info-ppmu.base + PPMUv2_PMCNT3_LOW);
+load_count = (u64)((pmcnt_high 0xff) 32) + (u64)pmcnt_low;
+break;
+}
+edata-load_count = load_count;
+
+/* Disable all counters */
+cntenc = __raw_readl(info-ppmu.base + PPMUv2_CNTENC);
+cntenc |= (PPMU_CCNT_MASK | (PPMU_ENABLE id));
+__raw_writel(cntenc, info-ppmu.base + PPMUv2_CNTENC);
+
+dev_dbg(edev-dev, %25s (load: %ld / %ld)\n, edev-desc-name,
+edata-load_count, edata-total_count);
+return 0;
+}
+
+static struct devfreq_event_ops exynos_ppmu_v2_ops = {
This can be const.
OK.
+.disable = exynos_ppmu_v2_disable,
+.set_event = exynos_ppmu_v2_set_event,
+.get_event = exynos_ppmu_v2_get_event,
+};
+
+static struct of_device_id exynos_ppmu_id_match[] = {
In the previous patch this was not present but now it can be made 'const'.
OK for adding the 'const'.
The original 'exynos_ppmu_id_match' is located on below of this patch.
+{
+.compatible = samsung,exynos-ppmu,
+.data = (void *)exynos_ppmu_ops,
+}, {
+.compatible = samsung,exynos-ppmu-v2,
+.data = (void *)exynos_ppmu_v2_ops,
+},
+{ /* sentinel */ },
+};
+
+static struct devfreq_event_ops *exynos_bus_get_ops(struct device_node *np)
+{
+const struct of_device_id *match;
+
+match = of_match_node(exynos_ppmu_id_match, np);
+return (struct devfreq_event_ops *)match-data;
+}
+
static int of_get_devfreq_events(struct device_node *np,
struct exynos_ppmu *info)
{
@@ -238,7 +397,7 @@ static int of_get_devfreq_events(struct device_node *np,
continue;
}
-desc[j].ops = exynos_ppmu_ops;
+desc[j].ops = exynos_bus_get_ops(np);
So for each ops callback (get/set/disable) you will have another layer
of indirection where you will be matching the device each time?
That seems like a waste of CPU time. Just match it once here and use
either old ops or new ops_v2.
OK. I'll rework to reduce the unneeded operation.
desc[j].driver_data = info;
of_property_read_string(node, event-name, desc[j].name);
@@ -354,11 +513,6 @@ static int exynos_ppmu_remove(struct platform_device
*pdev)
return 0;
}
-static struct of_device_id exynos_ppmu_id_match[] = {
-{ .compatible = samsung,exynos-ppmu, },
-{ /* sentinel */ },
-};
-
static struct platform_driver exynos_ppmu_driver = {
.probe
RE: [GIT PULL] Samsung 1st fixes for v4.2
Olof Johansson wrote: Hi Kukjin, Hi Olof, On Tue, Jul 21, 2015 at 12:40:04PM +0900, Kukjin Kim wrote: Hi, Please pull samsung fixes for v4.2. Thanks, Kukjin The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git tags/samsung-fixes-1 for you to fetch changes up to 300bde79f3d86b1af6fcde7b7b2439ecffccbff4: ARM: dts: add CPU OPP and regulator supply property for exynos4210 (2015-07-21 12:32:29 +0900) Was there a reason you rebased Krzystztof's branch? The contents is identical. In cases like those, feel free to just forward the pull request to us and we can do it directly. If you have more patches you want to add into the same fixes branch then you can just merge his in and apply yours on top. That's for example how Tony Lindgren tends to handle OMAP -- he'll forward a pull request from Paul Walmsley if that's the only contents he has. Yeah, I know what you're saying and I agreed. Actually the OMAP model would be helpful. BTW in this case, I wanted to change the subject title that's why I did cherry-pick. Anyway, merged. Thanks, Kukjin -- 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 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
On Thu, Jul 23, 2015 at 10:57:18AM +0900, Chanwoo Choi wrote:
+static int exynos_ppmu_v2_disable(struct devfreq_event_dev *edev)
+{
+ struct exynos_ppmu *info = devfreq_event_get_drvdata(edev);
+ u32 pmnc, clear;
+
+ /* Disable all counters */
+ clear = (PPMU_CCNT_MASK | PPMU_PMCNT0_MASK | PPMU_PMCNT1_MASK
+ | PPMU_PMCNT2_MASK | PPMU_PMCNT3_MASK);
+
+ __raw_writel(clear, info-ppmu.base + PPMUv2_FLAG);
Why aren't you using normal readl()/writel()? What are the endiannesses
here?
regards,
dan carpenter
--
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] PM / devfreq: event: Remove incorrect property in exynos-ppmu DT binding
Hi Javier, On 07/13/2015 03:58 PM, Javier Martinez Canillas wrote: The exynos-ppmu driver is only a clock consumer and not a clock provider but its Device Tree binding listed #clock-cells as an optional property. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt index b54bf3a2ff57..aed486692880 100644 --- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt @@ -17,7 +17,6 @@ Required properties: Optional properties: - clock-names : the name of clock used by the PPMU, ppmu - clocks : phandles for clock specified in clock-names property -- #clock-cells: should be 1. Example1 : PPMU nodes in exynos3250.dtsi are listed below. Reviewed-by: Chanwoo Choi cw00.c...@samsung.com + Devfreq maintainer (Myungjoo Ham) I think that this patch will be more appropriate on devfreq git tree than linux-samsung git tree. Thanks, 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: [GIT PULL] ARM: EXYNOS: mach: Improvements for 4.3
On 23.07.2015 17:11, Kukjin Kim wrote: Kukjin Kim wrote: Krzysztof Kozlowski wrote: On 21.07.2015 14:21, Krzysztof Kozlowski wrote: 2015-07-21 14:13 GMT+09:00 Krzysztof Kozlowski k.kozlow...@samsung.com: 2015-07-21 14:02 GMT+09:00 Kukjin Kim kg...@kernel.org: Krzysztof Kozlowski wrote: [...] -- Applied above changes into fixes/non-critical, next/cleanup-samsung, next/dt-samsung and next/cpufreq-clk-samsung according to the change. Cc-ed Bartlomiej, One issue found: splitting DTS change for Exynos 5250 cpufreq to separate branch will break bisectability. The commit ARM: dts: Exynos5250: add CPU OPP and regulator supply property: 1. MUST be put after clk: samsung: exynos5250: add cpu clock configuration data and instantiate cpu clock to prevent build failures, 2. should be put before ARM: Exynos: switch to using generic cpufreq driver for Exynos5250 to prevent lost cpufreq functionality. Doing otherwise would lose bisectability which is really unfortunate when you can simply avoid it. This should remain in the same branch - next/cpufreq-clk-samsung. Dear Kukjin, Nothing changed since yesterday... so let me point this in a more clear way. The way you divided the patchset causes build errors: -- HEAD is now at 565872a601c4... ARM: dts: add CPU OPP and regulator supply property for exynos5250 ERROR: Failed build: -A arm -c exynos on 565872a601c4d91a75b917b1fb40ff27ad7ebb08 LOGS: Error: ../arch/arm/boot/dts/exynos5250.dtsi:65.21-22 syntax error FATAL ERROR: Unable to parse input tree make[2]: *** [arch/arm/boot/dts/exynos5250-arndale.dtb] Error 1 make[1]: *** [dtbs] Error 2 make[1]: *** Waiting for unfinished jobs make: *** [sub-make] Error 2 -- This breaks bisectability without any special valid reason. Hi, I couldn't check e-mail yesterday because of annual health check. Anyway, I'll look at the error and handle it soon. OK, the change for the include/dt-bindings/clock/exynos5250.h file which is in next/cpufreq-clk-samsung branch should be provided in next/dt-samsung branch. It should be fine tonight in my time. One more thing, the splitting changes into dt and driver side would be required generally and if it has dependency like this, proper merge topic branch is required by maintainer. But I've missed last action :( You prepared a topic branch - next/cpufreq-clk-samsung. I think everything can be put in it and this would solve any issues. Best regards, Krzysztof -- 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] PM / devfreq: event: Remove incorrect property in exynos-ppmu DT binding
Hello Chanwoo, On 07/23/2015 10:19 AM, Chanwoo Choi wrote: Hi Javier, On 07/13/2015 03:58 PM, Javier Martinez Canillas wrote: The exynos-ppmu driver is only a clock consumer and not a clock provider but its Device Tree binding listed #clock-cells as an optional property. Signed-off-by: Javier Martinez Canillas jav...@osg.samsung.com --- Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt | 1 - 1 file changed, 1 deletion(-) diff --git a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt index b54bf3a2ff57..aed486692880 100644 --- a/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt +++ b/Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt @@ -17,7 +17,6 @@ Required properties: Optional properties: - clock-names : the name of clock used by the PPMU, ppmu - clocks : phandles for clock specified in clock-names property -- #clock-cells: should be 1. Example1 : PPMU nodes in exynos3250.dtsi are listed below. Reviewed-by: Chanwoo Choi cw00.c...@samsung.com + Devfreq maintainer (Myungjoo Ham) Thanks for the review and for cc'ing Myungjoo. The get_maintainer.pl script didn't tell me that so I think Documentation/devicetree/bindings/devfreq/ sub-dir should be added to the DEVICE FREQUENCY (DEVFREQ) entry in the MAINTAINERS file. I think that this patch will be more appropriate on devfreq git tree than linux-samsung git tree. Agreed. Thanks, Chanwoo Choi -- Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] thermal: consistently use int for temperatures
Hi Zhang,
On Tue, Jul 21, 2015 at 01:35:31PM +, Zhang, Rui wrote:
Patch applied.
Thanks for applying. I missed to convert another place, so we get a new
compiler warning. The attached patch fixes this (suitable for git rebase
--autosquash). Please let me know if you can handle this or if you
prefer a new patch instead.
Thanks
Sascha
-8-
From 4907a7c32fd16eaf9f31d9f904276c9a0176b717 Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Thu, 23 Jul 2015 12:32:31 +0200
Subject: [PATCH] fixup! thermal: consistently use int for temperatures
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
fixes:
drivers/power/charger-manager.c: In function ‘cm_get_battery_temperature’:
drivers/power/charger-manager.c:622:45: warning: passing argument 2 of
‘thermal_zone_get_temp’ from incompatible pointer type
ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long *)temp);
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/power/charger-manager.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/charger-manager.c b/drivers/power/charger-manager.c
index 1c202cc..907293e 100644
--- a/drivers/power/charger-manager.c
+++ b/drivers/power/charger-manager.c
@@ -619,7 +619,7 @@ static int cm_get_battery_temperature(struct
charger_manager *cm,
#ifdef CONFIG_THERMAL
if (cm-tzd_batt) {
- ret = thermal_zone_get_temp(cm-tzd_batt, (unsigned long
*)temp);
+ ret = thermal_zone_get_temp(cm-tzd_batt, temp);
if (!ret)
/* Calibrate temperature unit */
*temp /= 100;
--
2.1.4
--
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- |
--
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
