Re: [linux-pm] [PATCH RESEND] thermal: add generic cpufreq cooling implementation
On Mon, Sep 10, 2012 at 3:25 PM, Zhang Rui rui.zh...@intel.com wrote: Refreshed to remove the notifier mechanism as we do not have a real user of it. if there is no problem, I'll apply the whole patch set to thermal next tree. The removal of notification API looks fine. Thanks for refreshing this. Thanks, Amit Daniel From: Amit Daniel Kachhap amit.kach...@linaro.org Date: Thu, 16 Aug 2012 17:11:40 +0530 This patchset introduces a new generic cooling device based on cpufreq that can be used on non-ACPI platforms. As a proof of concept, we have drivers for the following platforms using this mechanism now: * Samsung Exynos (Exynos4 and Exynos5) in the current patchset. * Freescale i.MX (git://git.linaro.org/people/amitdanielk/linux.git imx6q_thermal) There is a small change in cpufreq cooling registration APIs, so a minor change is needed for Freescale platforms. Brief Description: 1) The generic cooling devices code is placed inside driver/thermal/* as placing inside acpi folder will need un-necessary enabling of acpi code. This code is architecture independent. 2) This patchset adds generic cpu cooling low level implementation through frequency clipping. In future, other cpu related cooling devices may be added here. An ACPI version of this already exists (drivers/acpi/processor_thermal.c) .But this will be useful for platforms like ARM using the generic thermal interface along with the generic cpu cooling devices. The cooling device registration API's return cooling device pointers which can be easily binded with the thermal zone trip points. The important APIs exposed are, a) struct thermal_cooling_device *cpufreq_cooling_register( struct cpumask *clip_cpus) b) void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) 3) Samsung exynos platform thermal implementation is done using the generic cpu cooling APIs and the new trip type. The temperature sensor driver present in the hwmon folder(registered as hwmon driver) is moved to thermal folder and registered as a thermal driver. A simple data/control flow diagrams is shown below, Core Linux thermal - Exynos thermal interface - Temperature Sensor | | \|/| Cpufreq cooling device --- TODO: *Will send the DT enablement patches later after the driver is merged. This patch: Add support for generic cpu thermal cooling low level implementations using frequency scaling up/down based on the registration parameters. Different cpu related cooling devices can be registered by the user and the binding of these cooling devices to the corresponding trip points can be easily done as the registration APIs return the cooling device pointer. The user of these APIs are responsible for passing clipping frequency . The drivers can also register to recieve notification about any cooling action called. Cc: Guenter Roeck guenter.ro...@ericsson.com Cc: SangWook Ju sw...@samsung.com Cc: Durgadoss durgados...@intel.com Cc: Len Brown l...@kernel.org Cc: Jean Delvare kh...@linux-fr.org Cc: Kyungmin Park kmp...@infradead.org Cc: Kukjin Kim kgene@samsung.com Signed-off-by: Zhang Rui rui.zh...@intel.com Signed-off-by: Andrew Morton a...@linux-foundation.org Signed-off-by: Amit Daniel Kachhap amit.dan...@samsung.com --- Documentation/thermal/cpu-cooling-api.txt | 33 ++ drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile |1 + drivers/thermal/cpu_cooling.c | 450 + include/linux/cpu_cooling.h | 58 5 files changed, 553 insertions(+), 0 deletions(-) create mode 100644 Documentation/thermal/cpu-cooling-api.txt create mode 100644 drivers/thermal/cpu_cooling.c create mode 100644 include/linux/cpu_cooling.h diff --git a/Documentation/thermal/cpu-cooling-api.txt b/Documentation/thermal/cpu-cooling-api.txt new file mode 100644 index 000..6fe9cdb --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,33 @@ +CPU cooling APIs How To +=== + +Written by Amit Daniel Kachhap amit.kach...@linaro.org + +Updated: 12 May 2012 + +Copyright (c) 2012 Samsung Electronics Co., Ltd(http://www.samsung.com) + +0. Introduction + +The generic cpu cooling(freq clipping) provides registration/unregistration APIs +to the caller. The binding of the cooling devices to the trip point is left for +the user. The registration APIs returns the cooling device pointer. + +1. cpu cooling APIs + +1.1 cpufreq registration/unregistration APIs +1.1.1 struct thermal_cooling_device *cpufreq_cooling_register( + struct cpumask *clip_cpus) + +This interface function registers the cpufreq cooling device with the name +thermal-cpufreq-%x. This api can support multiple
Re: [PATCH] ARM: EXYNOS5: Add bus clock and set parent clock for FIMD
Hello Jingoo Han,
On Tue, Sep 11, 2012 at 5:52 AM, Jingoo Han jg1@samsung.com wrote:
On Tuesday, September 11, 2012 5:11 AM Leela Krishna Amudala wrote
This patch adds the bus clock for FIMD and changes the device name for lcd
clock
also sets mout_mpll_user as parent clock to fimd
Signed-off-by: Leela Krishna Amudala l.kris...@samsung.com
---
arch/arm/mach-exynos/clock-exynos5.c | 34
+++
arch/arm/plat-samsung/include/plat/clock.h |2 +
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 774533c..f1281cf 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -891,6 +891,13 @@ static struct clk exynos5_clk_mdma1 = {
.ctrlbit= (1 4),
};
+static struct clk exynos5_clk_fimd = {
+ .name = fimd,
+ .devname= exynos5-fb,
Replace 'exynos5-fb' with 'exynos5-fb.1', as exynos4 fimd uses exynos4-fb.0
as devname. Exynos5 can use fimd0 or fimd1. Also, Exynos5250 uses fimd1.
Currently s3c-fb driver using exynos5-fb as device name, hence used
the same name in the clock.
This code is tested with both drm-fimd and s3c-fb fimd and it is
working fine showing the display on LCD.
If I change the device name in clock file then I have to change it in
s3c-fb driver also.
So I feel it is better to keep the name as exynos5-fb in clock file
instead of changing in the driver.
Thanks,
Leela Krishna Amudala.
+ .enable = exynos5_clk_ip_disp1_ctrl,
+ .ctrlbit= (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
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: EXYNOS5: Add bus clock and set parent clock for FIMD
On 09/11/2012 11:19 AM, Leela Krishna Amudala wrote:
diff --git a/arch/arm/mach-exynos/clock-exynos5.c
b/arch/arm/mach-exynos/clock-exynos5.c
index 774533c..f1281cf 100644
--- a/arch/arm/mach-exynos/clock-exynos5.c
+++ b/arch/arm/mach-exynos/clock-exynos5.c
@@ -891,6 +891,13 @@ static struct clk exynos5_clk_mdma1 = {
.ctrlbit= (1 4),
};
+static struct clk exynos5_clk_fimd = {
+ .name = fimd,
+ .devname= exynos5-fb,
Replace 'exynos5-fb' with 'exynos5-fb.1', as exynos4 fimd uses exynos4-fb.0
as devname. Exynos5 can use fimd0 or fimd1. Also, Exynos5250 uses fimd1.
Currently s3c-fb driver using exynos5-fb as device name, hence used
the same name in the clock.
This code is tested with both drm-fimd and s3c-fb fimd and it is
working fine showing the display on LCD.
If I change the device name in clock file then I have to change it in
s3c-fb driver also.
So I feel it is better to keep the name as exynos5-fb in clock file
instead of changing in the driver.
Yeah, makes sense. We can always add a clkdev entry with CLKDEV_INIT()
if driver needs it. There is so much confusion now with having device name
associated with platform clock name. It should be possible to freely define
clock connection id and a platform clock association, not at the platform
clock definition.
I guess we can now clean all this up only during conversion to common clock
framework.
Regards,
--
Sylwester Nawrocki
Samsung Poland RD Center
--
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: MFC Encode on S5PV210 hangs
On 09.09.2012 21:21, Mike Dyer wrote: Hi All, I'm trying to use the MFC encoder to generate an H264 bitstream using the V4L2 interface. I've tried using my own application, and also the example encode application here: git://git.infradead.org/users/kmpark/public-apps Both exhibit the same behavior. Input frames are queued up until the input queue is full, but only one frame is emitted (which I guess is the H264 header). The encoder then just sits there. I'm not sure where to start looking, so any advice is appreciated. Cheers, Mike Hi Mike, Please test with enabled CMA(Device Drivers/Generic.../Contiguous Memory Allocator). I will test it further and update defconfig if necessary. Please also apply latest published MFC patches(not yet in mainline), especially: s5p-mfc: Fix second memory bank alignment v4l/s5p-mfc: added support for end of stream handling in MFC encoder Regards Andrzej -- 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 00/16] ARM: big platform data header rename
As we discussed at the ARM mini summit in San Diego, we are
going to move all platform specific header files that are used
in drivers out of the mach-* directories, at least for those
platforms that we want to have in a multiplatform kernel.
A big step in this direction is to move all the platform_data
definitions into include/linux/platform_data/. This takes
care of about a third of the header files in question and
should be relatively uncontroversial.
I changed the file names after the rename to be
include/linux/${subsystem}-${driver}.h where possible, to
have a more consistent naming there.
I would like to merge the series through the arm-soc tree
as an early branch so other branches can be based on top
or merge this branch into the other one to avoid conflicts.
Platform maintainers: please provide ACKs so I can take
it into the for-next branch as a stable sub-branch.
Driver maintainers: There should be nothing controversial
here, just a heads-up so you know that some one-line changes
are coming through the arm-soc tree that might cause an
occasional merge conflict. I've put a lot of people on
bcc in this mail so they know what the individual ones are
about. If you have specific comments, please reply on the
patches you are Cc'd on.
Arnd
Arnd Bergmann (16):
ARM: at91: move platform_data definitions
ARM: davinci: move platform_data definitions
ARM: ep93xx: move platform_data definitions
ARM: imx: move platform_data definitions
ARM: msm: move platform_data definitions
ARM: netx: move platform_data definitions
ARM: pxa: move platform_data definitions
ARM: sa1100: move platform_data definitions
ARM: tegra: move platform_data definitions
ARM: vt8500: move platform_data definitions
ARM: w90x900: move platform_data definitions
ARM: nomadik: move platform_data definitions
ARM: omap: move platform_data definitions
ARM: orion: move platform_data definitions
ARM: samsung: move platform_data definitions
ARM: spear: move platform_data definitions
Documentation/spi/ep93xx_spi |2 +-
arch/arm/mach-at91/at91sam9g45_devices.c |2 +-
arch/arm/mach-at91/at91sam9rl_devices.c|2 +-
arch/arm/mach-at91/include/mach/at_hdmac.h | 61 ---
arch/arm/mach-at91/include/mach/atmel-mci.h|2 +-
arch/arm/mach-davinci/aemif.c |2 +-
arch/arm/mach-davinci/board-da830-evm.c|8 +-
arch/arm/mach-davinci/board-da850-evm.c|6 +-
arch/arm/mach-davinci/board-dm355-evm.c|8 +-
arch/arm/mach-davinci/board-dm355-leopard.c|8 +-
arch/arm/mach-davinci/board-dm365-evm.c|8 +-
arch/arm/mach-davinci/board-dm644x-evm.c | 10 +-
arch/arm/mach-davinci/board-dm646x-evm.c |6 +-
arch/arm/mach-davinci/board-mityomapl138.c |4 +-
arch/arm/mach-davinci/board-neuros-osd2.c |8 +-
arch/arm/mach-davinci/board-sffsdr.c |4 +-
arch/arm/mach-davinci/davinci.h|4 +-
arch/arm/mach-davinci/devices.c|4 +-
arch/arm/mach-davinci/dm355.c |4 +-
arch/arm/mach-davinci/dm365.c |6 +-
arch/arm/mach-davinci/dm644x.c |2 +-
arch/arm/mach-davinci/dm646x.c |2 +-
arch/arm/mach-davinci/include/mach/aemif.h | 36
arch/arm/mach-davinci/include/mach/asp.h | 137 ---
arch/arm/mach-davinci/include/mach/da8xx.h | 10 +-
arch/arm/mach-davinci/include/mach/i2c.h | 26 ---
arch/arm/mach-davinci/include/mach/keyscan.h | 42 -
arch/arm/mach-davinci/include/mach/mmc.h | 39 -
arch/arm/mach-davinci/include/mach/nand.h | 90 --
arch/arm/mach-davinci/include/mach/spi.h | 89 --
arch/arm/mach-davinci/include/mach/tnetv107x.h |4 +-
arch/arm/mach-davinci/include/mach/usb.h | 59 ---
arch/arm/mach-davinci/usb.c|2 +-
arch/arm/mach-dove/common.c|2 +-
arch/arm/mach-ep93xx/core.c|6 +-
arch/arm/mach-ep93xx/dma.c |2 +-
arch/arm/mach-ep93xx/edb93xx.c |4 +-
arch/arm/mach-ep93xx/include/mach/dma.h| 93 ---
arch/arm/mach-ep93xx/include/mach/ep93xx_keypad.h | 35
arch/arm/mach-ep93xx/include/mach/ep93xx_spi.h | 29
arch/arm/mach-ep93xx/include/mach/fb.h | 56 ---
arch/arm/mach-ep93xx/simone.c |2 +-
arch/arm/mach-ep93xx/snappercl15.c |2 +-
arch/arm/mach-ep93xx/vision_ep9307.c |4 +-
arch/arm/mach-exynos/dev-audio.c |2 +-
arch/arm/mach-exynos/dev-ohci.c|2 +-
arch/arm/mach-exynos/include/mach/ohci.h | 21
RE: [PATCH 15/16] ARM: samsung: move platform_data definitions
Arnd Bergmann wrote: Platform data for device drivers should be defined in include/linux/platform_data/*.h, not in the architecture and platform specific directories. This moves such data out of the samsung include directories Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Kukjin Kim kgene@samsung.com Yeah, basically looks OK on this. Acked-by: Kukjin Kim kgene@samsung.com BTW, how about re-ordering inclusion linux/platform_data/xxx.h after linux/xxx.h rather than just replacing like following? --- #include linux/xxx.h ... #include linux/platform_data/xxx.h ... #include mach/xxx.h ... #include plat/xxx.h ... --- And there are small comments... Cc: Kyungmin Park kyungmin.p...@samsung.com Cc: Ben Dooks ben-li...@fluff.org Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: Jeff Garzik jgar...@pobox.com Cc: Guenter Roeck li...@roeck-us.net Cc: Wolfram Sang (embedded platforms) w.s...@pengutronix.de Cc: Dmitry Torokhov dmitry.torok...@gmail.com Cc: Bryan Wu bryan...@canonical.com Cc: Richard Purdie rpur...@rpsys.net Cc: Sylwester Nawrocki s.nawro...@samsung.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Chris Ball c...@laptop.org Cc: David Woodhouse dw...@infradead.org Cc: Grant Likely grant.lik...@secretlab.ca Cc: Felipe Balbi ba...@ti.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Alan Stern st...@rowland.harvard.edu Cc: Sangbeom Kim sbki...@samsung.com Cc: Liam Girdwood l...@ti.com Cc: linux-samsung-soc@vger.kernel.org --- arch/arm/mach-exynos/dev-audio.c |2 +- arch/arm/mach-exynos/dev-ohci.c|2 +- arch/arm/mach-exynos/mach-nuri.c |6 +++--- arch/arm/mach-exynos/mach-origen.c |6 +++--- arch/arm/mach-exynos/mach-smdk4x12.c |2 +- arch/arm/mach-exynos/mach-smdkv310.c |6 +++--- arch/arm/mach-exynos/mach-universal_c210.c |4 ++-- arch/arm/mach-exynos/setup-i2c0.c |2 +- arch/arm/mach-exynos/setup-i2c1.c |2 +- arch/arm/mach-exynos/setup-i2c2.c |2 +- arch/arm/mach-exynos/setup-i2c3.c |2 +- arch/arm/mach-exynos/setup-i2c4.c |2 +- arch/arm/mach-exynos/setup-i2c5.c |2 +- arch/arm/mach-exynos/setup-i2c6.c |2 +- arch/arm/mach-exynos/setup-i2c7.c |2 +- arch/arm/mach-s3c24xx/common-smdk.c|4 ++-- arch/arm/mach-s3c24xx/mach-amlm5900.c |2 +- arch/arm/mach-s3c24xx/mach-anubis.c|6 +++--- arch/arm/mach-s3c24xx/mach-at2440evb.c |6 +++--- arch/arm/mach-s3c24xx/mach-bast.c |8 arch/arm/mach-s3c24xx/mach-gta02.c | 10 +- arch/arm/mach-s3c24xx/mach-h1940.c |8 arch/arm/mach-s3c24xx/mach-jive.c |6 +++--- arch/arm/mach-s3c24xx/mach-mini2440.c | 10 +- arch/arm/mach-s3c24xx/mach-n30.c |8 arch/arm/mach-s3c24xx/mach-nexcoder.c |2 +- arch/arm/mach-s3c24xx/mach-osiris.c|4 ++-- arch/arm/mach-s3c24xx/mach-otom.c |2 +- arch/arm/mach-s3c24xx/mach-qt2410.c|8 arch/arm/mach-s3c24xx/mach-rx1950.c| 10 +- arch/arm/mach-s3c24xx/mach-rx3715.c|2 +- arch/arm/mach-s3c24xx/mach-smdk2410.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2413.c |4 ++-- arch/arm/mach-s3c24xx/mach-smdk2416.c |8 arch/arm/mach-s3c24xx/mach-smdk2440.c |2 +- arch/arm/mach-s3c24xx/mach-smdk2443.c |2 +- arch/arm/mach-s3c24xx/mach-tct_hammer.c|2 +- arch/arm/mach-s3c24xx/mach-vr1000.c|6 +++--- arch/arm/mach-s3c24xx/mach-vstms.c |4 ++-- arch/arm/mach-s3c24xx/setup-i2c.c |2 +- arch/arm/mach-s3c24xx/simtec-audio.c |2 +- arch/arm/mach-s3c24xx/simtec-usb.c |2 +- arch/arm/mach-s3c64xx/dev-audio.c |2 +- arch/arm/mach-s3c64xx/mach-anw6410.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410-module.c |2 +- arch/arm/mach-s3c64xx/mach-crag6410.c |4 ++-- arch/arm/mach-s3c64xx/mach-hmt.c |4 ++-- arch/arm/mach-s3c64xx/mach-mini6410.c |4 ++-- arch/arm/mach-s3c64xx/mach-ncp.c |2 +- arch/arm/mach-s3c64xx/mach-real6410.c |4 ++-- arch/arm/mach-s3c64xx/mach-smartq.c|8 arch/arm/mach-s3c64xx/mach-smdk6400.c |2 +- arch/arm/mach-s3c64xx/mach-smdk6410.c |6 +++---
