Re: Announcing Linarotv-xmbc image
On 12 March 2012 11:28, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Thu, Jan 26, 2012 at 12:30 AM, Tom Gall tom.g...@linaro.org wrote: For the 12.01 cycle the Linaro Platforms team is pleased to announce the availability of the new linarotv-xbmc based image. This combines the xbmc media server project with linaro's leb to result in a works out of the box arm based media server image. It can be found at http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/ Just tyring to unpack linaro-xbmc with linaro-media-create tool on 2GB SD card but when creating rootfs I get error no space left on device. Do I need bigger SD card or I'm doing something wrong? Yes, you need a bigger SD card. Currently the best experience can be found on Panda/Panda ES however boards with hardware video acceleration enabled should work well. We welcome feedback and suggestions on the image. Support is on a as best can basis. Bugs if found should be written against linaro-ubuntu in lauchpad. Enjoy! -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev regards, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Regards, Avik ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
hi, Where does XBMC output its video stream? to X11/fb? or other? thanks! On Thu, Jan 26, 2012 at 7:30 AM, Tom Gall tom.g...@linaro.org wrote: For the 12.01 cycle the Linaro Platforms team is pleased to announce the availability of the new linarotv-xbmc based image. This combines the xbmc media server project with linaro's leb to result in a works out of the box arm based media server image. It can be found at http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/ Currently the best experience can be found on Panda/Panda ES however boards with hardware video acceleration enabled should work well. We welcome feedback and suggestions on the image. Support is on a as best can basis. Bugs if found should be written against linaro-ubuntu in lauchpad. Enjoy! -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
On 03/10/2012 07:52 PM, Chenglie He wrote:
I am doing the suspend and resume of s3cfb on exynos. the clk_on and
clk_off just failed. I think this is a related issue.
Without this patch, the probe for s3cfb driver itself fails - hence what
you are seeing must be different.
On 29 February 2012 13:45, Tushar Behera tushar.beh...@linaro.org wrote:
Hi Kukjin,
On 12/01/2011 11:20 AM, Tushar Behera wrote:
The framebuffer driver needs the clock named 'lcd' as its bus
clock but the equivalent clock on Exynos4 is named as 'fimd'.
Hence, create a clkdev lookup entry with the name 'lcd' that
references the 'fimd' clock.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos/clock.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 5d8d483..607ec28 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -489,11 +489,6 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit= (1 3),
}, {
- .name = fimd,
- .devname= exynos4-fb.0,
- .enable = exynos4_clk_ip_lcd0_ctrl,
- .ctrlbit= (1 0),
- }, {
.name = hsmmc,
.devname= s3c-sdhci.0,
.parent = clk_aclk_133.clk,
@@ -782,6 +777,13 @@ static struct clk clk_pdma1 = {
.ctrlbit= (1 1),
};
+static struct clk clk_fimd0 = {
+ .name = fimd,
+ .devname= exynos4-fb.0,
+ .enable = exynos4_clk_ip_lcd0_ctrl,
+ .ctrlbit= (1 0),
+};
+
struct clk *clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = clk_xusbxti,
@@ -1294,6 +1296,7 @@ static struct clksrc_clk *sysclks[] = {
static struct clk *clk_cdev[] = {
clk_pdma0,
clk_pdma1,
+ clk_fimd0,
};
static struct clksrc_clk *clksrc_cdev[] = {
@@ -1318,6 +1321,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(s3c-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk, clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, clk_pdma1),
+ CLKDEV_INIT(exynos4-fb.0, lcd, clk_fimd0),
};
static int xtal_rate;
Would you please review this patch and let me know your opinion? Without
this patch, frame-buffer support on EXYNOS4 is broken.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v12] Regulator: Add Anatop regulator driver
On Sat, Mar 10, 2012 at 11:13:08AM +0800, Ying-Chun Liu (PaulLiu) wrote: From: Ying-Chun Liu (PaulLiu) paul@linaro.org Anatop is an integrated regulator inside i.MX6 SoC. There are 3 digital regulators which controls PU, CORE (ARM), and SOC. And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB). This patch adds the Anatop regulator driver. This looks OK but doesn't apply against current regulator code due to sorting in Kconfig and Makefile, you should always submit against current development versions of the subsystem. Please rebase and resend, this will also give you an opportunity to build test against the current subsystem :) signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Saturday, March 03, 2012 4:36 PM
To: linux...@lists.linux-foundation.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; lm-
sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
Durgadoss; patc...@linaro.org
Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
thermal layer
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/Kconfig |8 +
drivers/thermal/Makefile |1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
If you want this support, you should say Y or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL)+= thermal_sys.o
obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d sec\n,
+ th_zone-therm_dev-polling_delay/1000);
+ return 0;
+}
+
+/*This may be called from interrupt based temperature sensor*/
+void exynos4_report_trigger(void)
+{
+ unsigned int monitor_temp;
+
+ if (!th_zone ||
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Sun, Mar 11, 2012 at 02:24:46PM -0700, Turquette, Mike wrote:
On Sun, Mar 11, 2012 at 4:34 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
Hi Mike,
I was about to give my tested-by when I decided to test the set_rate
function. Unfortunately this is broken for several reasons. I'll try
to come up with a fixup series later the day.
I haven't tested clk_set_rate since V4, but I also haven't changed the
code appreciably. I'll retest on my end also.
On Fri, Mar 09, 2012 at 11:54:23PM -0800, Mike Turquette wrote:
+ /* find the new rate and see if parent rate should change too */
+ WARN_ON(!clk-ops-round_rate);
+
+ new_rate = clk-ops-round_rate(clk-hw, rate, parent_new_rate);
You don't need a WARN_ON when you derefence clk-ops-round_rate anyway.
Agreed that the WARN_ON should not be there.
The v6 Documentation/clk.txt states that .round_rate is mandatory for
clocks that can adjust their rate, but I need to clarify this a bit
more. Ideally we want to be able to call clk_set_rate on any clock
and get a changed rate (if possible) by either adjusting that clocks
rate direction (e.g. a PLL or an adjustable divider) or by propagating
__clk_set_rate up the parents (assuming of course that
CLK_SET_RATE_PARENT flag is set appropriately).
Also, even when the current clock does not have a set_rate function it
can still change its rate when the CLK_SET_RATE_PARENT is set.
Correct. I'll clean this up and make the documentation a bit more
verbose on when .set_rate/.round_rate/.recalc_rate are mandatory.
+
+ /* NOTE: pre-rate change notifications will stack */
+ if (clk-notifier_count)
+ ret = __clk_notify(clk, PRE_RATE_CHANGE, clk-rate,
new_rate);
+
+ if (ret == NOTIFY_BAD)
+ return clk;
+
+ /* speculate rate changes down the tree */
+ hlist_for_each_entry(child, tmp, clk-children, child_node) {
+ ret = __clk_speculate_rates(child, new_rate);
+ if (ret == NOTIFY_BAD)
+ return clk;
+ }
+
+ /* change the rate of this clk */
+ if (clk-ops-set_rate)
+ ret = clk-ops-set_rate(clk-hw, new_rate);
I don't know the reason why you change the child clock before the parent
clock, but it cannot work since this clock will change its rate based on
the old parent rate and not the new one.
This depends on the .round_rate implementation, which I admit to
having lost some sleep over. A clever .round_rate will request the
intermediate rate for a clock when propagating a request to change
the parent rate later on. Take for instance the following:
pll @ 200MHz (locked)
|
parent @ 100MHz (can divide by 1 or 2; currently divider is 2)
|
child @ 25MHz (can divide by 2 or 4; currently divider is 4)
If we want child to run at 100MHz then the desirable configuration
would be to have parent divide-by-1 and child divide-by-2. When we
call,
clk_set_rate(child, 100MHz);
Its .round_rate should return 50MHz, and parent_new_rate should be
200MHz. So 50MHz is an intermediate rate, but it gets us the
divider we want. And in fact 50MHz reflects reality because that will
be the rate of child until the parent propagation completes and we can
adjust parent's dividers. (this is one reason why I prefer for
pre-rate change notifiers to stack on top of each other).
So now that parent_new_rate is 0, __clk_set_rate will propagate the
request up and parent's .round_rate will simply return 200MHz and
leave it's own parent_new_rate at 0. This will change from
divide-by-2 to divide-by-1 and from this highest point in the tree we
will propagate post-rate change notifiers downstream, as part of the
recalc_rate tree walk.
I have tested this with OMAP4's CPUfreq driver and I think, while
complicated, it is a sound way to approach the problem. Maybe the API
can be cleaned up, if you have any suggestions.
I cannot see all implications this way will have. All this rate
propagation is more complex than I thought it would be. I tried another
approach on the weekend which basically does not try to do all in a
single recursion but instead sets the rate in multiple steps:
1) call a function which calculates all new rates of affected clocks
in a rate change and safes the value in a clk-new_rate field. This
function returns the topmost clock which has to be changed.
2) starting from the topmost clock notify all clients. This walks the
whole subtree even if a notfifier refuses the change. If necessary
we can walk the whole subtree again to abort the change.
3) actually change rates starting from the topmost clocks and notify
all clients on the way. I changed the set_rate callback to void.
Instead of failing (what is failing in case of set_rate? The clock
will still have some rate) I check for the result with
clk_ops-recalc_rate.
In the end what's more important than the
[PATCH v2 3/4] arm/dts: OMAP4: Add mmc controller nodes and board data
Add omap mmc related device tree data for OMAP4.
Currenly limited to only omap4-panda and omap4-sdp
boards.
Signed-off-by: Rajendra Nayak rna...@ti.com
---
arch/arm/boot/dts/omap4-panda.dts | 22 ++
arch/arm/boot/dts/omap4-sdp.dts | 24
arch/arm/boot/dts/omap4.dtsi | 31 +++
3 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 29646dc..ea6f5bb 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -52,3 +52,25 @@
i2c4 {
clock-frequency = 40;
};
+
+mmc1 {
+ vmmc-supply = vmmc;
+ ti,bus-width = 8;
+};
+
+mmc2 {
+ status = disable;
+};
+
+mmc3 {
+ status = disable;
+};
+
+mmc4 {
+ status = disable;
+};
+
+mmc5 {
+ ti,non-removable;
+ ti,bus-width = 4;
+};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 01db8b7..852657a 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -70,3 +70,27 @@
reg = 0x1e;
};
};
+
+mmc1 {
+ vmmc-supply = vmmc;
+ ti,bus-width = 8;
+};
+
+mmc2 {
+ vmmc-supply = vaux1;
+ ti,bus-width = 8;
+ ti,non-removable;
+};
+
+mmc3 {
+ status = disable;
+};
+
+mmc4 {
+ status = disable;
+};
+
+mmc5 {
+ ti,bus-width = 4;
+ ti,non-removable;
+};
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 29f4589..9226543 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -155,5 +155,36 @@
#size-cells = 0;
ti,hwmods = i2c4;
};
+
+ mmc1: mmc@1 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc1;
+ ti,dual-volt;
+ ti,needs-special-reset;
+ };
+
+ mmc2: mmc@2 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc2;
+ ti,needs-special-reset;
+ };
+
+ mmc3: mmc@3 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc3;
+ ti,needs-special-reset;
+ };
+
+ mmc4: mmc@4 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc4;
+ ti,needs-special-reset;
+ };
+
+ mmc5: mmc@5 {
+ compatible = ti,omap4-hsmmc;
+ ti,hwmods = mmc5;
+ ti,needs-special-reset;
+ };
};
};
--
1.7.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
boot failure with __iounmap changes in v3.3
I'm working on getting out of tree support for the NXP LPC31xx ARM926EJS based CPUs ready for submission. Everything was working fine on v3.2 but I lost the ability to boot with v3.3. The boot failure is very early in the boot process. I did a bisect and came up with: [6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap() when dealing with section based mapping I tried to revert it but there have been a bunch of edits in this file. Not sure how to go about debugging this. -- Jon Smirl jonsm...@gmail.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 3/3] clk: basic clock hardware types
On Mon, Mar 12, 2012 at 1:18 PM, Rob Herring robherri...@gmail.com wrote:
On 03/10/2012 01:54 AM, Mike Turquette wrote:
Many platforms support simple gateable clocks, fixed-rate clocks,
adjustable divider clocks and multi-parent multiplexer clocks.
This patch introduces basic clock types for the above-mentioned hardware
which share some common characteristics.
Based on original work by Jeremy Kerr and contribution by Jamie Iles.
Dividers and multiplexor clocks originally contributed by Richard Zhao
Sascha Hauer.
Signed-off-by: Mike Turquette mturque...@linaro.org
Signed-off-by: Mike Turquette mturque...@ti.com
Cc: Russell King li...@arm.linux.org.uk
Cc: Jeremy Kerr jeremy.k...@canonical.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Arnd Bergman arnd.bergm...@linaro.org
Cc: Paul Walmsley p...@pwsan.com
Cc: Shawn Guo shawn@freescale.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Jamie Iles ja...@jamieiles.com
Cc: Richard Zhao richard.z...@linaro.org
Cc: Saravana Kannan skan...@codeaurora.org
Cc: Magnus Damm magnus.d...@gmail.com
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Linus Walleij linus.wall...@stericsson.com
Cc: Stephen Boyd sb...@codeaurora.org
Cc: Amit Kucheria amit.kuche...@linaro.org
Cc: Deepak Saxena dsax...@linaro.org
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Andrew Lunn and...@lunn.ch
One issue with spinlocks below, but otherwise:
Reviewed-by: Rob Herring rob.herr...@calxeda.com
---
Changes since v5:
* standardized the hw-specific locking in the basic clock types
* export the individual ops for each basic clock type
* improve registration for single-parent basic clocks (thanks Sascha)
* fixed bugs in gate clock's static initializers (thanks Andrew)
drivers/clk/Makefile | 3 +-
drivers/clk/clk-divider.c | 204
++
drivers/clk/clk-fixed-rate.c | 82 +
drivers/clk/clk-gate.c | 157
drivers/clk/clk-mux.c | 123 +
include/linux/clk-private.h | 124 +
include/linux/clk-provider.h | 127 ++
7 files changed, 819 insertions(+), 1 deletions(-)
create mode 100644 drivers/clk/clk-divider.c
create mode 100644 drivers/clk/clk-fixed-rate.c
create mode 100644 drivers/clk/clk-gate.c
create mode 100644 drivers/clk/clk-mux.c
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ff362c4..1f736bc 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o
-obj-$(CONFIG_COMMON_CLK) += clk.o
+obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \
+ clk-mux.o clk-divider.o
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
new file mode 100644
index 000..c0c4e0b
--- /dev/null
+++ b/drivers/clk/clk-divider.c
@@ -0,0 +1,204 @@
+/*
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix s.ha...@pengutronix.de
+ * Copyright (C) 2011 Richard Zhao, Linaro richard.z...@linaro.org
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd
mturque...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Adjustable divider clock implementation
+ */
+
+#include linux/clk-provider.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/io.h
+#include linux/err.h
+#include linux/string.h
+
+/*
+ * DOC: basic adjustable divider clock that cannot gate
+ *
+ * Traits of this clock:
+ * prepare - clk_prepare only ensures that parents are prepared
+ * enable - clk_enable only ensures that parents are enabled
+ * rate - rate is adjustable. clk-rate = parent-rate / divisor
+ * parent - fixed parent. No clk_set_parent support
+ */
+
+#define to_clk_divider(_hw) container_of(_hw, struct clk_divider, hw)
+
+static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned int div;
+ unsigned long flags = 0;
+
+ if (divider-lock)
+ spin_lock_irqsave(divider-lock, flags);
+
+ div = readl(divider-reg) divider-shift;
+ div = (1 divider-width) - 1;
+
+ if (divider-lock)
+ spin_unlock_irqrestore(divider-lock, flags);
What are you locking against? You are only reading the register.
Hi Rob,
These register-level locks originally came in from the divider
multiplexer patches from Richard and Sascha and I'm sure they can give
you more details than I.
Basically on their platform they have some 32-bits regs that have a
lot of overlapping clock functions in them, such as enable/disable and
adjusting a divider all in one
Re: boot failure with __iounmap changes in v3.3
On Mon, Mar 12, 2012 at 4:18 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
I'm working on getting out of tree support for the NXP LPC31xx
ARM926EJS based CPUs ready for submission. Everything was working fine
on v3.2 but I lost the ability to boot with v3.3. The boot failure is
very early in the boot process. I did a bisect and came up with:
[6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap()
when dealing with section based mapping
I tried to revert it but there have been a bunch of edits in this
file. Not sure how to go about debugging this.
The first thing to look for is any overlap in the virtual memory ranges
used in your struct map_desc array. No overlap is allowed anymore.
There appear to be overlaps. I'll have to study things for a while to
figure out how to eliminate them. This is from a three year old NXP
BSP. We have a product based on the CPU and want to use a more recent
kernel.
They've defined multiple large peripheral regions...
/* APB4 address range*/
#define IO_APB4_PHYS (0x1700)
#define IO_APB4_SIZE (0x1000)
{
.virtual= io_p2v(IO_APB4_PHYS),
.pfn= __phys_to_pfn(IO_APB4_PHYS),
.length = IO_APB4_SIZE,
.type = MT_DEVICE
},
and then declared various devices inside of them...
/* DMA registers address range*/
#define DMA_PHYS (0x1700)
#define IO_DMA_REG_PHYS (DMA_PHYS)
#define IO_DMA_REG_SIZE (0x800)
{
.virtual= io_p2v(IO_DMA_REG_PHYS),
.pfn= __phys_to_pfn(IO_DMA_REG_PHYS),
.length = IO_DMA_REG_SIZE,
.type = MT_DEVICE
},
Then make sure those virtual addresses are between VMALLOC_START
(typically 0xf000 or below depending on the armount of RAM your
system has) and VMALLOC_END which is 0xff00.
Nicolas
--
Jon Smirl
jonsm...@gmail.com
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [git pull] Consolidate cpuidle functionality
Len and Andrew, Please consider this an official merge request of this cpuidle patchset for v3.4. There were two small conflicts Stephen Rothwell found when merging to linux-next. The first conflict is with patch 1/9 in the drivers/cpuidle/cpuidle.c file which is trivially to resolve. I'm told this fixup is trivially enough to not require anyone to carry it. The second is with patch 2/9 in mach-at91/cpuidle.c due to some minor cleanup changes. The fix is also pretty simple but I'm waiting to hear back about who will carry it. Please let me know if you need any other action or information on my part. Thanks, Rob On Fri, Mar 9, 2012 at 12:40 AM, Stephen Rothwell s...@canb.auug.org.au wrote: Hi Rob, On Thu, 8 Mar 2012 19:58:23 -0600 Rob Lee rob@linaro.org wrote: git://git.linaro.org/people/rob_lee/linux.git cpuidle_consol_pull These changes move various functionality duplicated in platform cpuidle drivers to the core cpuidle driver and common arch arm code. Also, the irq disabling in the platform code was removed as all calls into cpuidle_call_idle() will have already called local_irq_disable(). This patchset is bisect safe. Also, the core cpuidle and arch changes of the first commit do not require any changes to the arch and platform cpuidle drivers, though those arch and platform change should be made to take advantage of the new consolidation function. Stephen, this patch has been reviewed, tested, and ACK'd per the list above but cpuidle maintainer Len Brown has been out on vacation for a couple of weeks so I am sending you this pull request as time is running out to get this into v3.4. I've had a brief communication with Andrew Morton about this as well so he is aware of this situation. I am fairly new to the community so please let me know if you see anything that needs my attention or anything I should be doing differently. I will add this tree from today. Lets see if anyone screams. Thanks for adding your subsystem tree as a participant of linux-next. As you may know, this is not a judgment of your code. The purpose of linux-next is for integration testing and to lower the impact of conflicts between subsystems in the next merge window. You will need to ensure that the patches/commits in your tree/series have been: * submitted under GPL v2 (or later) and include the Contributor's Signed-off-by, * posted to the relevant mailing list, * reviewed by you (or another maintainer of your subsystem tree), * successfully unit tested, and * destined for the current or next Linux merge window. Basically, this should be just what you would send to Linus (or ask him to fetch). It is allowed to be rebased if you deem it necessary. -- Cheers, Stephen Rothwell s...@canb.auug.org.au Legal Stuff: By participating in linux-next, your subsystem tree contributions are public and will be included in the linux-next trees. You may be sent e-mail messages indicating errors or other issues when the patches/commits from your subsystem tree are merged and tested in linux-next. These messages may also be cross-posted to the linux-next mailing list, the linux-kernel mailing list, etc. The linux-next tree project and IBM (my employer) make no warranties regarding the linux-next project, the testing procedures, the results, the e-mails, etc. If you don't agree to these ground rules, let me know and I'll remove your tree from participation in linux-next. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot failure with __iounmap changes in v3.3
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:18 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
I'm working on getting out of tree support for the NXP LPC31xx
ARM926EJS based CPUs ready for submission. Everything was working fine
on v3.2 but I lost the ability to boot with v3.3. The boot failure is
very early in the boot process. I did a bisect and came up with:
[6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap()
when dealing with section based mapping
I tried to revert it but there have been a bunch of edits in this
file. Not sure how to go about debugging this.
The first thing to look for is any overlap in the virtual memory ranges
used in your struct map_desc array. No overlap is allowed anymore.
There appear to be overlaps. I'll have to study things for a while to
figure out how to eliminate them. This is from a three year old NXP
BSP. We have a product based on the CPU and want to use a more recent
kernel.
They've defined multiple large peripheral regions...
/* APB4 address range*/
#define IO_APB4_PHYS (0x1700)
#define IO_APB4_SIZE (0x1000)
{
.virtual= io_p2v(IO_APB4_PHYS),
.pfn= __phys_to_pfn(IO_APB4_PHYS),
.length = IO_APB4_SIZE,
.type = MT_DEVICE
},
and then declared various devices inside of them...
/* DMA registers address range*/
#define DMA_PHYS (0x1700)
#define IO_DMA_REG_PHYS (DMA_PHYS)
#define IO_DMA_REG_SIZE (0x800)
{
.virtual= io_p2v(IO_DMA_REG_PHYS),
.pfn= __phys_to_pfn(IO_DMA_REG_PHYS),
.length = IO_DMA_REG_SIZE,
.type = MT_DEVICE
},
Just get rid of the map_desc entryes corresponding to subsets of a
larger entry that already covers them and you should be fine.
Nicolas___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 3/3] clk: basic clock hardware types
On 03/12/2012 03:58 PM, Turquette, Mike wrote:
On Mon, Mar 12, 2012 at 1:18 PM, Rob Herring robherri...@gmail.com wrote:
On 03/10/2012 01:54 AM, Mike Turquette wrote:
Many platforms support simple gateable clocks, fixed-rate clocks,
adjustable divider clocks and multi-parent multiplexer clocks.
This patch introduces basic clock types for the above-mentioned hardware
which share some common characteristics.
Based on original work by Jeremy Kerr and contribution by Jamie Iles.
Dividers and multiplexor clocks originally contributed by Richard Zhao
Sascha Hauer.
snip
+static unsigned long clk_divider_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct clk_divider *divider = to_clk_divider(hw);
+ unsigned int div;
+ unsigned long flags = 0;
+
+ if (divider-lock)
+ spin_lock_irqsave(divider-lock, flags);
+
+ div = readl(divider-reg) divider-shift;
+ div = (1 divider-width) - 1;
+
+ if (divider-lock)
+ spin_unlock_irqrestore(divider-lock, flags);
What are you locking against? You are only reading the register.
Hi Rob,
These register-level locks originally came in from the divider
multiplexer patches from Richard and Sascha and I'm sure they can give
you more details than I.
Basically on their platform they have some 32-bits regs that have a
lot of overlapping clock functions in them, such as enable/disable and
adjusting a divider all in one reg. Those operations are protected by
different locks (enable spinlock and prepare mutex, respectively) so
some synchronization mechanism is necessary. On OMAP we don't use
this since we have a billion registers that typically only map to one
clock each. I also wonder if having device type memory for the
affected regions makes a this irrelevant on ARM... but that wouldn't
matter for non-ARM architectures. Just a thought.
In fact, I pointed out that locking for a register access was needed in
an early version of this series as well. However, locking is only needed
if you are doing a read-mod-write on a field in a shared register or
reading from multiple registers. It makes no sense if you are *only*
reading a single shared register as is the case here. That's already an
atomic operation.
Rob
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: boot failure with __iounmap changes in v3.3
On Mon, Mar 12, 2012 at 5:35 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote:
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
On Mon, Mar 12, 2012 at 4:18 PM, Nicolas Pitre nicolas.pi...@linaro.org
wrote:
On Mon, 12 Mar 2012, jonsm...@gmail.com wrote:
I'm working on getting out of tree support for the NXP LPC31xx
ARM926EJS based CPUs ready for submission. Everything was working fine
on v3.2 but I lost the ability to boot with v3.3. The boot failure is
very early in the boot process. I did a bisect and came up with:
[6ee723a6570a897208b76ab3e9a495e9106b2f8c] ARM: simplify __iounmap()
when dealing with section based mapping
I tried to revert it but there have been a bunch of edits in this
file. Not sure how to go about debugging this.
The first thing to look for is any overlap in the virtual memory ranges
used in your struct map_desc array. No overlap is allowed anymore.
There appear to be overlaps. I'll have to study things for a while to
figure out how to eliminate them. This is from a three year old NXP
BSP. We have a product based on the CPU and want to use a more recent
kernel.
They've defined multiple large peripheral regions...
/* APB4 address range*/
#define IO_APB4_PHYS (0x1700)
#define IO_APB4_SIZE (0x1000)
{
.virtual = io_p2v(IO_APB4_PHYS),
.pfn = __phys_to_pfn(IO_APB4_PHYS),
.length = IO_APB4_SIZE,
.type = MT_DEVICE
},
and then declared various devices inside of them...
/* DMA registers address range*/
#define DMA_PHYS (0x1700)
#define IO_DMA_REG_PHYS (DMA_PHYS)
#define IO_DMA_REG_SIZE (0x800)
{
.virtual = io_p2v(IO_DMA_REG_PHYS),
.pfn = __phys_to_pfn(IO_DMA_REG_PHYS),
.length = IO_DMA_REG_SIZE,
.type = MT_DEVICE
},
Just get rid of the map_desc entryes corresponding to subsets of a
larger entry that already covers them and you should be fine.
Thanks, that fixed it. Now I'm booting up to the point where I have
printk which makes things a lot easier.
Nicolas
--
Jon Smirl
jonsm...@gmail.com
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Mon, Mar 12, 2012 at 4:51 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Sun, Mar 11, 2012 at 02:24:46PM -0700, Turquette, Mike wrote:
On Sun, Mar 11, 2012 at 4:34 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
Hi Mike,
I was about to give my tested-by when I decided to test the set_rate
function. Unfortunately this is broken for several reasons. I'll try
to come up with a fixup series later the day.
I haven't tested clk_set_rate since V4, but I also haven't changed the
code appreciably. I'll retest on my end also.
On Fri, Mar 09, 2012 at 11:54:23PM -0800, Mike Turquette wrote:
+ /* find the new rate and see if parent rate should change too */
+ WARN_ON(!clk-ops-round_rate);
+
+ new_rate = clk-ops-round_rate(clk-hw, rate, parent_new_rate);
You don't need a WARN_ON when you derefence clk-ops-round_rate anyway.
Agreed that the WARN_ON should not be there.
The v6 Documentation/clk.txt states that .round_rate is mandatory for
clocks that can adjust their rate, but I need to clarify this a bit
more. Ideally we want to be able to call clk_set_rate on any clock
and get a changed rate (if possible) by either adjusting that clocks
rate direction (e.g. a PLL or an adjustable divider) or by propagating
__clk_set_rate up the parents (assuming of course that
CLK_SET_RATE_PARENT flag is set appropriately).
Also, even when the current clock does not have a set_rate function it
can still change its rate when the CLK_SET_RATE_PARENT is set.
Correct. I'll clean this up and make the documentation a bit more
verbose on when .set_rate/.round_rate/.recalc_rate are mandatory.
+
+ /* NOTE: pre-rate change notifications will stack */
+ if (clk-notifier_count)
+ ret = __clk_notify(clk, PRE_RATE_CHANGE, clk-rate,
new_rate);
+
+ if (ret == NOTIFY_BAD)
+ return clk;
+
+ /* speculate rate changes down the tree */
+ hlist_for_each_entry(child, tmp, clk-children, child_node) {
+ ret = __clk_speculate_rates(child, new_rate);
+ if (ret == NOTIFY_BAD)
+ return clk;
+ }
+
+ /* change the rate of this clk */
+ if (clk-ops-set_rate)
+ ret = clk-ops-set_rate(clk-hw, new_rate);
I don't know the reason why you change the child clock before the parent
clock, but it cannot work since this clock will change its rate based on
the old parent rate and not the new one.
This depends on the .round_rate implementation, which I admit to
having lost some sleep over. A clever .round_rate will request the
intermediate rate for a clock when propagating a request to change
the parent rate later on. Take for instance the following:
pll @ 200MHz (locked)
|
parent @ 100MHz (can divide by 1 or 2; currently divider is 2)
|
child @ 25MHz (can divide by 2 or 4; currently divider is 4)
If we want child to run at 100MHz then the desirable configuration
would be to have parent divide-by-1 and child divide-by-2. When we
call,
clk_set_rate(child, 100MHz);
Its .round_rate should return 50MHz, and parent_new_rate should be
200MHz. So 50MHz is an intermediate rate, but it gets us the
divider we want. And in fact 50MHz reflects reality because that will
be the rate of child until the parent propagation completes and we can
adjust parent's dividers. (this is one reason why I prefer for
pre-rate change notifiers to stack on top of each other).
So now that parent_new_rate is 0, __clk_set_rate will propagate the
request up and parent's .round_rate will simply return 200MHz and
leave it's own parent_new_rate at 0. This will change from
divide-by-2 to divide-by-1 and from this highest point in the tree we
will propagate post-rate change notifiers downstream, as part of the
recalc_rate tree walk.
I have tested this with OMAP4's CPUfreq driver and I think, while
complicated, it is a sound way to approach the problem. Maybe the API
can be cleaned up, if you have any suggestions.
I cannot see all implications this way will have. All this rate
propagation is more complex than I thought it would be.
Hi Sascha,
Yes it is very complicated. The solution I have now (recursive
__clk_set_rate, clever .round_rate which requests parent rate) was not
something I arrived at immediately.
I decided to validate the v6 patches more thoroughly today, based on
your claim that clk_set_rate is broken and here is what I found:
1) clk_set_rate works. I pulled in the latest OMAP4 CPUfreq code into
my common clk branch and it Just Worked. This is a dumb
implementation involving no upwards parent propagation, and the clock
changing is of type struct clk_hw_omap (relocking a PLL)
2) while I was at it I verified the rate change notifiers +
clk_set_parent, which also work (I had not touched these since v4 and
wanted to make sure nothing was broken)
Here is where things get interesting. I tried the same parent rate
Re: [PATCH v6 3/3] clk: basic clock hardware types
Hi Mike, Can I suggest/we discuss that we support fractional (i.e. represented by fixed point value with integer and fractional part) dividers in the common divider clock case, simplistically just adding a divider fractional width and shifting all the calculations by it (and fixing the maxdiv calculation as in a fractional case width of the divider area in the register is not an indicator of the actual maximum divider)? (I guess for the standard integer divider case, it would be continually shifting by 0 which might make the code a bit bigger, I don't think that would truly be a concern though?) Is there a particular reason why this case also cannot support set_parent? I have a use case here (i.MX51/53/6 IPU DI output pixel clock) which could be handled by this code if only those two were solved, it would save reimplementing the whole thing as a special case. I am at a loss to think of another particular case in any other SoC where there is a fractional divider on a clock where it might come in handy, though, I thought maybe someone could speak up and give an example that would come in handy for them (I can think of Marvel PXA and OMAP DSS display units having the exact same need which could be implemented using the clock API rather than opencoded inside the framebuffer drivers, but whether anyone actually cares about that is another matter entirely...) -- Matt Sealey m...@genesi-usa.com Product Development Analyst, Genesi USA, Inc. On Sat, Mar 10, 2012 at 1:54 AM, Mike Turquette mturque...@linaro.org wrote: Many platforms support simple gateable clocks, fixed-rate clocks, adjustable divider clocks and multi-parent multiplexer clocks. This patch introduces basic clock types for the above-mentioned hardware which share some common characteristics. Based on original work by Jeremy Kerr and contribution by Jamie Iles. Dividers and multiplexor clocks originally contributed by Richard Zhao Sascha Hauer. Signed-off-by: Mike Turquette mturque...@linaro.org Signed-off-by: Mike Turquette mturque...@ti.com Cc: Russell King li...@arm.linux.org.uk Cc: Jeremy Kerr jeremy.k...@canonical.com Cc: Thomas Gleixner t...@linutronix.de Cc: Arnd Bergman arnd.bergm...@linaro.org Cc: Paul Walmsley p...@pwsan.com Cc: Shawn Guo shawn@freescale.com Cc: Sascha Hauer s.ha...@pengutronix.de Cc: Jamie Iles ja...@jamieiles.com Cc: Richard Zhao richard.z...@linaro.org Cc: Saravana Kannan skan...@codeaurora.org Cc: Magnus Damm magnus.d...@gmail.com Cc: Rob Herring rob.herr...@calxeda.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Linus Walleij linus.wall...@stericsson.com Cc: Stephen Boyd sb...@codeaurora.org Cc: Amit Kucheria amit.kuche...@linaro.org Cc: Deepak Saxena dsax...@linaro.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Andrew Lunn and...@lunn.ch --- Changes since v5: * standardized the hw-specific locking in the basic clock types * export the individual ops for each basic clock type * improve registration for single-parent basic clocks (thanks Sascha) * fixed bugs in gate clock's static initializers (thanks Andrew) drivers/clk/Makefile | 3 +- drivers/clk/clk-divider.c | 204 ++ drivers/clk/clk-fixed-rate.c | 82 + drivers/clk/clk-gate.c | 157 drivers/clk/clk-mux.c | 123 + include/linux/clk-private.h | 124 + include/linux/clk-provider.h | 127 ++ 7 files changed, 819 insertions(+), 1 deletions(-) create mode 100644 drivers/clk/clk-divider.c create mode 100644 drivers/clk/clk-fixed-rate.c create mode 100644 drivers/clk/clk-gate.c create mode 100644 drivers/clk/clk-mux.c diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index ff362c4..1f736bc 100644 --- a/drivers/clk/Makefile +++ b/drivers/clk/Makefile @@ -1,3 +1,4 @@ obj-$(CONFIG_CLKDEV_LOOKUP) += clkdev.o -obj-$(CONFIG_COMMON_CLK) += clk.o +obj-$(CONFIG_COMMON_CLK) += clk.o clk-fixed-rate.o clk-gate.o \ + clk-mux.o clk-divider.o diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c new file mode 100644 index 000..c0c4e0b --- /dev/null +++ b/drivers/clk/clk-divider.c @@ -0,0 +1,204 @@ +/* + * Copyright (C) 2011 Sascha Hauer, Pengutronix s.ha...@pengutronix.de + * Copyright (C) 2011 Richard Zhao, Linaro richard.z...@linaro.org + * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd mturque...@linaro.org + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * Adjustable divider clock implementation + */ + +#include linux/clk-provider.h +#include linux/module.h +#include linux/slab.h +#include linux/io.h +#include linux/err.h +#include linux/string.h
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
On 03/03/2012 04:36 PM, Amit Daniel Kachhap wrote:
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
If you are resubmitting the patchset, it would be good if you can
address the nitpicks. Sorry for being so late in pointing them out now,
none of the comments below are pertaning to the code flow - so you can
ignore these comments if there are no plans for resubmission.
---
drivers/thermal/Kconfig |8 +
drivers/thermal/Makefile |1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
If you want this support, you should say Y or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL)+= thermal_sys.o
obj-$(CONFIG_CPU_THERMAL)+= cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d sec\n,
+ th_zone-therm_dev-polling_delay/1000);
+ return 0;
+}
+
+/*This may be called from interrupt based temperature sensor*/
+void exynos4_report_trigger(void)
+{
+ unsigned int monitor_temp;
+
+ if (!th_zone || !th_zone-therm_dev)
+ return;
+
+ monitor_temp = th_zone-sensor_conf-trip_data.trip_val[0];
+
+ thermal_zone_device_update(th_zone-therm_dev);
+
+
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
Hi Durgadoss,
Thanks for the detailed review.
On 12 March 2012 16:21, R, Durgadoss durgados...@intel.com wrote:
Hi Amit,
Thanks for keeping this up. And Sorry for late reply.
-Original Message-
From: amit kachhap [mailto:amitdani...@gmail.com] On Behalf Of Amit Daniel
Kachhap
Sent: Saturday, March 03, 2012 4:36 PM
To: linux...@lists.linux-foundation.org; linux-samsung-...@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; mj...@srcf.ucam.org; linux-
a...@vger.kernel.org; l...@kernel.org; linaro-dev@lists.linaro.org; lm-
sens...@lm-sensors.org; amit.kach...@linaro.org; eduardo.valen...@ti.com; R,
Durgadoss; patc...@linaro.org
Subject: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux
thermal layer
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
If you want this support, you should say Y or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
If it is 'DISABLED' mode, shouldn't the polling delay be just 0 ?
Yes Ideally this should be zero. But I wanted thermal monitoring to
always happen with some long interval in case of error scenarios.
Anyway I will check this again.
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
On 13 March 2012 09:24, Tushar Behera tushar.beh...@linaro.org wrote:
On 03/03/2012 04:36 PM, Amit Daniel Kachhap wrote:
This codes uses the generic linux thermal layer and creates a bridge
between temperature sensors, linux thermal framework and cooling devices
for samsung exynos platform. This layer recieves or monitor the
temperature from the sensor and informs the generic thermal layer to take
the necessary cooling action.
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
If you are resubmitting the patchset, it would be good if you can
address the nitpicks. Sorry for being so late in pointing them out now,
none of the comments below are pertaning to the code flow - so you can
ignore these comments if there are no plans for resubmission.
Thanks tushar. I will include your suggestion for next patchset submission.
---
drivers/thermal/Kconfig | 8 +
drivers/thermal/Makefile | 1 +
drivers/thermal/exynos_thermal.c | 272
++
include/linux/exynos_thermal.h | 72 ++
4 files changed, 353 insertions(+), 0 deletions(-)
create mode 100644 drivers/thermal/exynos_thermal.c
create mode 100644 include/linux/exynos_thermal.h
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 298c1cd..4e8df56 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,3 +29,11 @@ config CPU_THERMAL
This will be useful for platforms using the generic thermal interface
and not the ACPI interface.
If you want this support, you should say Y or M here.
+
+config SAMSUNG_THERMAL_INTERFACE
+ bool Samsung Thermal interface support
+ depends on THERMAL CPU_THERMAL
+ help
+ This is a samsung thermal interface which will be used as
+ a link between sensors and cooling devices with linux thermal
+ framework.
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 655cbc4..c67b6b2 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -4,3 +4,4 @@
obj-$(CONFIG_THERMAL) += thermal_sys.o
obj-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
+obj-$(CONFIG_SAMSUNG_THERMAL_INTERFACE) += exynos_thermal.o
diff --git a/drivers/thermal/exynos_thermal.c
b/drivers/thermal/exynos_thermal.c
new file mode 100644
index 000..878d45c
--- /dev/null
+++ b/drivers/thermal/exynos_thermal.c
@@ -0,0 +1,272 @@
+/* linux/drivers/thermal/exynos_thermal.c
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/thermal.h
+#include linux/platform_device.h
+#include linux/cpufreq.h
+#include linux/err.h
+#include linux/slab.h
+#include linux/cpu_cooling.h
+#include linux/exynos_thermal.h
+
+#define MAX_COOLING_DEVICE 4
+struct exynos4_thermal_zone {
+ unsigned int idle_interval;
+ unsigned int active_interval;
+ struct thermal_zone_device *therm_dev;
+ struct thermal_cooling_device *cool_dev[MAX_COOLING_DEVICE];
+ unsigned int cool_dev_size;
+ struct platform_device *exynos4_dev;
+ struct thermal_sensor_conf *sensor_conf;
+};
+
+static struct exynos4_thermal_zone *th_zone;
+
+static int exynos4_get_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode *mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (th_zone-sensor_conf) {
+ pr_info(Temperature sensor not initialised\n);
+ *mode = THERMAL_DEVICE_DISABLED;
+ } else
+ *mode = THERMAL_DEVICE_ENABLED;
+ return 0;
+}
+
+static int exynos4_set_mode(struct thermal_zone_device *thermal,
+ enum thermal_device_mode mode)
Space here for intending is not required, we can go with TABs only.
+{
+ if (!th_zone-therm_dev) {
+ pr_notice(thermal zone not registered\n);
+ return 0;
+ }
+ if (mode == THERMAL_DEVICE_ENABLED)
+ th_zone-therm_dev-polling_delay =
+ th_zone-active_interval*1000;
+ else
+ th_zone-therm_dev-polling_delay =
+ th_zone-idle_interval*1000;
+
+ thermal_zone_device_update(th_zone-therm_dev);
+ pr_info(thermal polling set for duration=%d sec\n,
+ th_zone-therm_dev-polling_delay/1000);
+ return 0;
+}
+
+/*This may be called from interrupt based temperature sensor*/
+void exynos4_report_trigger(void)
+{
+ unsigned int monitor_temp;
+
+ if (!th_zone || !th_zone-therm_dev)
+
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
On 11 March 2012 09:41, Sundar sunder.s...@gmail.com wrote: Hi Amit, I am new here; so please bear with my questions/doubts :) On Wed, Feb 22, 2012 at 3:44 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: This patch adds support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the request from user. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding Different cpu related cooling devices: Do you mean cooling devices for different CPUs (num_cpus) or are you referring to different customers aka consumer drivers who could use this framework and impose the cooling. Correct but the consumer driver only has to use the other thermal-sys.c functions. Only register cpu cooling devices is implemented in this work. trip points can be easily done as the registration API's return the cooling device pointer. The user of these api's are responsible for passing clipping frequency in percentages. Why do you want to pass the clipping frequency in percentages? Wouldnt it be simpler for any platform sensor driver to just pass the frequency it wants to throttle the CPU? Yes i also agree. + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq-%x. This api can support multiple instance of cpufreq cooling + devices. When you refer to cooling devices, is it the number of instances per-CPU that is supported? Sorry I am unable to follow. CPU cooling apis can be used as below 1)per cpus if different frequency clipping is needed. so multiple instance of this api can be called. 2)for all the cpus as provided with mask when same frequency clipping is needed. In this case single instance is fine. + .polling_interval: polling interval for this cooling state. + tab_size: the total number of cooling state. By cooling_state, I assume you are referring to the thermal state for the platform? or only for the CPU? Yes thermal state of the platform. + mask_val: all the allowed cpu's where frequency clipping can happen. Why should this be a new variable? The policy-affected_cpus should be the same as this IMO? yes this should be same. I will check this. + help + This implements the generic cpu cooling mechanism through frequency + reduction, cpu hotplug and any other ways of reducing temperature. An Apart from reducing the CPU frequency, (probably) CPU hotplug, what other means of reducing CPU temperature? Or are you referring to any platform temperature controls? No only CPU related. Other control ways I thought was cpuidle with low power states and cpu_power factor modifications used in the schedular. It isnt very clear from the documentation (at least to me) if this is only for CPU cooling or generic platform cooling. Cheers! -- - The views expressed in this email are personal and do not necessarily echo my employers'. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
