[GIT PULL] Non-critical fixes for v4.3
Dear Kukjin, Previously you did not picked up the fix for cpufreq memory leak. I am sending it again with respective acks from LKML. Also another minor improvement in the set. Best regards, Krzysztof The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93: Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-fixes-non-critical-v4.3-2 for you to fetch changes up to 434213f727c12fab8657c8db3d23da4b0463365d: video: fbdev: s3c-fb: Constify platform_device_id (2015-07-24 15:17:32 +0900) Improvements for Exynos boards: 1. Fix memory leak in cpufreq error path. 2. Constify platform_device_id in video/fbdev/s3c-fb. Krzysztof Kozlowski (1): video: fbdev: s3c-fb: Constify platform_device_id Shailendra Verma (1): cpufreq: exynos: Fix for memory leak in case SOC name does not match drivers/cpufreq/exynos-cpufreq.c | 6 -- drivers/video/fbdev/s3c-fb.c | 2 +- 2 files changed, 5 insertions(+), 3 deletions(-) -- 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: defconfig: Improvements for 4.3
2015-07-17 15:51 GMT+09:00 Krzysztof Kozlowski : > Dear Kukjin, > > Few defconfig related changes. > > Description along with a tag. > You can find them also on the lists with my reviewed-by. > > Best regards, > Krzysztof Any comments on this pull request? Best regards, Krzysztof > > > The following changes since commit 1c4c7159ed2468f3ac4ce5a7f08d79663d381a93: > > Merge tag 'ext4_for_linus_stable' of > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4 (2015-07-05 16:24:54 > -0700) > > are available in the git repository at: > > > https://github.com/krzk/linux.git tags/samsung-defconfig-4.3 > > for you to fetch changes up to 5efedc7617df7add295702f21f11dd7e7a67b76e: > > ARM: multi_v7_defconfig: Enable max77802 regulator (2015-07-16 15:57:31 > +0900) > > > Defconfig changes around Exynos based boards: > 1. Enable sound on Odroid XU3 on exynos defconfig. > 2. Enable NTC thermistors for Chromebooks on exynos and multi_v7. > 3. Enable main PMIC regulator for Chromebooks on multi_v7. > 4. Clean up in multi_v7 - remove old (non-existing) configs. > > > Anand Moon (1): > ARM: exynos_defconfig: Enable CONFIG_SND_SOC_ODROIDX2 for Odroid-XU3 > > Javier Martinez Canillas (4): > ARM: multi_v7_defconfig: Remove old Samsung USB PHY configs > ARM: multi_v7_defconfig: Enable NTC Thermistors support > ARM: exynos_defconfig: Enable NTC Thermistors support > ARM: multi_v7_defconfig: Enable max77802 regulator > > arch/arm/configs/exynos_defconfig | 3 +++ > arch/arm/configs/multi_v7_defconfig | 5 +++-- > 2 files changed, 6 insertions(+), 2 deletions(-) > -- > 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 -- 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 Thu, Jul 23, 2015 at 02:07:59PM +0200, Pavel Machek wrote: > 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? I am not very fond of typedefs and I am not sure this adds any value. I could change it when more people ask for it, but I just sent the new version without this. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 24.07.2015 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 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. Dear Kukjin, Will you handle this patchset and dependants (ARM: dts: Add CPU cooling binding for Exynos3250-based Rinato/Monk board) for v4.3? 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
[PATCH v3] thermal: consistently use int for temperatures
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.
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.
Signed-off-by: Sascha Hauer
Acked-by: Geert Uytterhoeven
Reviewed-by: Jean Delvare
Reviewed-by: Lukasz Majewski
Reviewed-by: Darren Hart
Reviewed-by: Heiko Stuebner
Reviewed-by: Peter Feuerer
Cc: Punit Agrawal
Cc: Zhang Rui
Cc: Eduardo Valentin
Cc: linux...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Cc: Jean Delvare
Cc: Peter Feuerer
Cc: Heiko Stuebner
Cc: Lukasz Majewski
Cc: Stephen Warren
Cc: Thierry Reding
Cc: linux-a...@vger.kernel.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-samsung-soc@vger.kernel.org
Cc: Guenter Roeck
Cc: Rafael J. Wysocki
Cc: Maxime Ripard
Cc: Darren Hart
Cc: lm-sens...@lm-sensors.org
Signed-off-by: Zhang Rui
---
changes since v2:
- Add missing conversion for charger-manager driver
changes since v1:
- Add missing pieces for power_allocator driver
drivers/acpi/thermal.c | 12 +-
drivers/hwmon/lm75.c | 2 +-
drivers/hwmon/ntc_thermistor.c | 2 +-
drivers/hwmon/tmp102.c | 2 +-
drivers/input/touchscreen/sun4i-ts.c | 8 +++
drivers/platform/x86/acerhdf.c | 9
drivers/platform/x86/intel_mid_thermal.c | 9
drivers/power/charger-manager.c| 2 +-
drivers/power/power_supply_core.c | 2 +-
drivers/thermal/armada_thermal.c | 2 +-
drivers/thermal/db8500_thermal.c | 7 +++---
drivers/thermal/dove_thermal.c | 2 +-
drivers/thermal/fair_share.c | 2 +-
drivers/thermal/gov_bang_bang.c| 5 ++--
drivers/thermal/hisi_thermal.c | 4 ++--
drivers/thermal/imx_thermal.c | 27 +++---
drivers/thermal/int340x_thermal/int3400_thermal.c | 2 +-
.../thermal/int340x_thermal/int340x_thermal_zone.c | 10
.../thermal/int340x_thermal/int340x_thermal_zone.h | 8 +++
.../int340x_thermal/processor_thermal_device.c | 4 ++--
drivers/thermal/intel_quark_dts_thermal.c | 13 +--
drivers/thermal/intel_soc_dts_iosf.c | 8 +++
drivers/thermal/kirkwood_thermal.c | 2 +-
drivers/thermal/of-thermal.c | 14 +--
drivers/thermal/power_allocator.c | 16 ++---
drivers/thermal/qcom-spmi-temp-alarm.c | 2 +-
drivers/thermal/rcar_thermal.c | 7 +++---
drivers/thermal/rockchip_thermal.c | 10
drivers/thermal/samsung/exynos_tmu.c | 23 +-
drivers/thermal/spear_thermal.c| 2 +-
drivers/thermal/st/st_thermal.c| 5 ++--
drivers/thermal/step_wise.c| 4 ++--
drivers/thermal/tegra_soctherm.c | 4 ++--
drivers/thermal/thermal_core.c | 26 ++---
drivers/thermal/thermal_hwmon.c| 10
drivers/thermal/ti-soc-thermal/ti-thermal-common.c | 10
drivers/thermal/x86_pkg_temp_thermal.c | 10
include/linux/thermal.h| 26 +
include/trace/events/thermal_power_allocator.h | 6 ++---
39 files changed, 152 insertions(+), 167 deletions(-)
diff --git a/drivers/acpi/thermal.c b/drivers/acpi/thermal.c
index 6d4e44e..e66ad25 100644
--- a/drivers/acpi/thermal.c
+++ b/drivers/acpi/thermal.c
@@ -529,8 +529,7 @@ static void acpi_thermal_check(void *data)
/* sys I/F for generic thermal sysfs support */
-static int thermal_get_temp(struct thermal_zone_device *thermal,
- unsigned long *temp)
+static int thermal_get_temp(struct thermal_zone_device *thermal, int *temp)
{
struct acpi_thermal *tz = thermal->devdata;
int result;
@@ -637,7 +636,7 @@ static int thermal_get_trip_type(struct thermal_zone_device
*thermal,
}
static int thermal_get_trip_temp(struct thermal_zone_device *thermal,
-int trip, unsigned long *tem
[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
---
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
[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
[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
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
.../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
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
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
*
* 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
+ | PPMU_V2_PMNC_START_MODE_MASK);
+ pmnc |= (PPMU_ENABLE << PPM
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 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 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 :
>>> 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
>>> Cc: Tomasz Figa
>>> Signed-off-by: Chanwoo Choi
>>> Acked-by: Kyungmin Park
>>> Reviewed-by: Krzysztof Kozlowski
>>> ---
>>> 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
>>>
>>> #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
On 07/24/15 09:39, Michael Turquette wrote: > Quoting Bartlomiej Zolnierkiewicz (2015-07-01 06:10:35) >> From: Thomas Abraham >> >> 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 >> Cc: Michael Turquette >> Cc: Javier Martinez Canillas >> Signed-off-by: Thomas Abraham >> Signed-off-by: Bartlomiej Zolnierkiewicz > > Acked-by: Michael Turquette > 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 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 >>> >>> 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
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
> 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
> ---
> 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 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
>
> 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
> Cc: Michael Turquette
> Cc: Javier Martinez Canillas
> Signed-off-by: Thomas Abraham
> Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Michael Turquette
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
>
> #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
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 > > > > > > 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 > > > > 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 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: [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 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
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
Signed-off-by: Hans Verkuil
---
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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#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 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 23 July 2015 at 18:46, Michal Suchanek wrote: > On 22 July 2015 at 11:01, Marek Vasut wrote: >> On Wednesday, July 22, 2015 at 10:38:14 AM, Michal Suchanek wrote: >>> On 22 July 2015 at 10:24, Marek Vasut wrote: >>> > On Wednesday, July 22, 2015 at 10:18:04 AM, Michal Suchanek wrote: >>> >> On 22 July 2015 at 09:58, Marek Vasut wrote: >>> >> > On Wednesday, July 22, 2015 at 09:45:27 AM, Michal Suchanek wrote: >>> >> >> On 22 July 2015 at 09:33, Marek Vasut wrote: >>> >> >> > On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote: >>> >> >> >> On 22 July 2015 at 06:49, Vinod Koul 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
Re: [PATCH 08/11] MTD: m25p80: Add option to limit SPI transfer size.
On 22 July 2015 at 11:01, Marek Vasut wrote: > On Wednesday, July 22, 2015 at 10:38:14 AM, Michal Suchanek wrote: >> On 22 July 2015 at 10:24, Marek Vasut wrote: >> > On Wednesday, July 22, 2015 at 10:18:04 AM, Michal Suchanek wrote: >> >> On 22 July 2015 at 09:58, Marek Vasut wrote: >> >> > On Wednesday, July 22, 2015 at 09:45:27 AM, Michal Suchanek wrote: >> >> >> On 22 July 2015 at 09:33, Marek Vasut wrote: >> >> >> > On Wednesday, July 22, 2015 at 09:30:54 AM, Michal Suchanek wrote: >> >> >> >> On 22 July 2015 at 06:49, Vinod Koul 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
Re: [PATCHv7 14/15] cec: s5p-cec: Add s5p-cec driver
Hi,
On 21 July 2015 at 15:03, Marek Szyprowski 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
>>>
>>> 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
>>> Signed-off-by: Hans Verkuil
>>> ---
>>
>>
>>
>>> 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
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +
>>> +#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 R&D 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 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
>>
>> ---
>>
>> 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
>
> ---
>
> 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 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 > > --- > > 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 > +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 > M: Krzysztof Kozlowski -- 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 11:43 AM, Dan Carpenter
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 1/2] PM / devfreq: exynos-ppmu: Add the support of PPMUv2 for Exynos5433
On Thu, Jul 23, 2015 at 10:14 AM, Chanwoo Choi 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
>>> Cc: Kyungmin Park
>>> Signed-off-by: Chanwoo Choi
>>
>> 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
>>> *
>>> * 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;
>>>
>>>
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 > --- > > 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 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: [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
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
---
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
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
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 >> >> --- >> >> 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 > > + 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] 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 > > --- > > 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 + 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 : > 2015-07-21 14:02 GMT+09:00 Kukjin Kim : >> 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 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
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>
> 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
>> *
>> * 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;
>> }
>>
>> -stat
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: [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 : > > >> 2015-07-21 14:02 GMT+09:00 Kukjin Kim : > > >>> 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: [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
Cc: Kyungmin Park
Signed-off-by: Chanwoo Choi
---
.../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 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
>>> Cc: Kyungmin Park
>>> Signed-off-by: Chanwoo Choi
>>> ---
>>> .../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: [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 : > >> 2015-07-21 14:02 GMT+09:00 Kukjin Kim : > >>> 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 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
>> Cc: Kyungmin Park
>> Signed-off-by: Chanwoo Choi
>> ---
>> .../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 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
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
> ---
> .../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: [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
> Cc: Kyungmin Park
> Signed-off-by: Chanwoo Choi
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
> *
> * 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
> +
