Re: [PATCH] ARM: EXYNOS: Remove the L2 cache latency setting for EXYNOS5
Hi,
2012/6/21 Kukjin Kim kgene@samsung.com:
From: Boojin Kim boojin@samsung.com
Since SYSRAM set the L2 cache latency on EXYNOS5 SoCs,
I don't understand this. Do you mean that BL1 codes do it?
I also wonder how enable L2 cache at the exynos5.
no longer need that in the kernel. It helps to reduce
booting time (no need cache disable and cache enable).
Signed-off-by: Boojin Kim boojin@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
arch/arm/mach-exynos/common.c | 25 -
1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 742edd3..0ec1a91 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -712,31 +712,6 @@ static int __init exynos4_l2x0_cache_init(void)
early_initcall(exynos4_l2x0_cache_init);
#endif
-static int __init exynos5_l2_cache_init(void)
-{
- unsigned int val;
-
- if (!soc_is_exynos5250())
- return 0;
-
- asm volatile(mrc p15, 0, %0, c1, c0, 0\n
- bic %0, %0, #(1 2)\n /* cache disable */
- mcr p15, 0, %0, c1, c0, 0\n
- mrc p15, 1, %0, c9, c0, 2\n
- : =r(val));
-
- val |= (1 9) | (1 5) | (2 6) | (2 0);
-
- asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
- asm volatile(mrc p15, 0, %0, c1, c0, 0\n
- orr %0, %0, #(1 2)\n /* cache enable */
- mcr p15, 0, %0, c1, c0, 0\n
- : : r(val));
-
- return 0;
-}
-early_initcall(exynos5_l2_cache_init);
-
static int __init exynos_init(void)
{
printk(KERN_INFO EXYNOS: Initializing architecture\n);
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
- Joonyoung Shim
--
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 v4 1/5] thermal: Add generic cpufreq cooling implementation
Hey Rob and Amit, On Tue, Jun 26, 2012 at 6:12 AM, Rob Lee rob@linaro.org wrote: Hey Amit, I was just re-organizing the imx thermal driver that uses this cpu cooling interface and noticed a couple of small issues here. If While rewriting the OMAP BG driver on top of this series I noticed similar issues. Apart from those pointed by Rob, I have another minor fix. these suggestions are agreed upon and if it's too late for these issues be changed with this patchset, I can submit them separately unless you'd prefer to. On Sat, May 12, 2012 at 4:40 AM, 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 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. Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org --- Documentation/thermal/cpu-cooling-api.txt | 60 drivers/thermal/Kconfig | 11 + drivers/thermal/Makefile | 3 +- drivers/thermal/cpu_cooling.c | 483 + include/linux/cpu_cooling.h | 99 ++ 5 files changed, 655 insertions(+), 1 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..557adb8 --- /dev/null +++ b/Documentation/thermal/cpu-cooling-api.txt @@ -0,0 +1,60 @@ +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, cpuhotplug etc) 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 freq_clip_table *tab_ptr, unsigned int tab_size) + + This interface function registers the cpufreq cooling device with the name + thermal-cpufreq-%x. This api can support multiple instances of cpufreq + cooling devices. + + tab_ptr: The table containing the maximum value of frequency to be clipped + for each cooling state. + .freq_clip_max: Value of frequency to be clipped for each allowed + cpus. + .temp_level: Temperature level at which the frequency clamping will + happen. + .mask_val: cpumask of the allowed cpu's + tab_size: the total number of cpufreq cooling states. + +1.1.2 void cpufreq_cooling_unregister(struct thermal_cooling_device *cdev) + + This interface function unregisters the thermal-cpufreq-%x cooling device. + + cdev: Cooling device pointer which has to be unregistered. + + +1.2 CPU cooling action notifier register/unregister interface +1.2.1 int cputherm_register_notifier(struct notifier_block *nb, + unsigned int list) + + This interface registers a driver with cpu cooling layer. The driver will + be notified when any cpu cooling action is called. + + nb: notifier function to register + list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP + +1.2.2 int cputherm_unregister_notifier(struct notifier_block *nb, + unsigned int list) + + This interface registers a driver with cpu cooling layer. The driver will + be notified when any cpu cooling action is called. + + nb: notifier function to register + list: CPUFREQ_COOLING_START or CPUFREQ_COOLING_STOP diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index 514a691..d9c529f 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -19,6 +19,17 @@ config THERMAL_HWMON depends on HWMON=y || HWMON=THERMAL default y +config CPU_THERMAL Perhaps the name CPU_COOLING or CPUFREQ_COOLING would more accurately describe this functionality? I like the latter since now this mechanism only supports cooling by using cpufreq. + bool generic cpu cooling support If we use CPUFREQ_COOLING, then perhaps this could say: bool cpu cooling through cpufreq frequency limiting + depends on THERMAL CPU_FREQ + help + This implements the generic cpu cooling
RE: [PATCH] ARM: EXYNOS: Remove the L2 cache latency setting for EXYNOS5
Joonyoung Shim wrote:
I don't understand this. Do you mean that BL1 codes do it?
I also wonder how enable L2 cache at the exynos5.
Yes, the latency configuration of L2 cache is located on IROM or BL1 code.
It can remove the overhead about cache reset and cache flush.
And, Kernel enables L2 cache.
Thanks.
no longer need that in the kernel. It helps to reduce
booting time (no need cache disable and cache enable).
Signed-off-by: Boojin Kim boojin@samsung.com
Signed-off-by: Kukjin Kim kgene@samsung.com
---
쟞rch/arm/mach-exynos/common.c | � 25 -
�1 files changed, 0 insertions(+), 25 deletions(-)
diff --git a/arch/arm/mach-exynos/common.c b/arch/arm/mach-exynos/common.c
index 742edd3..0ec1a91 100644
--- a/arch/arm/mach-exynos/common.c
+++ b/arch/arm/mach-exynos/common.c
@@ -712,31 +712,6 @@ static int __init exynos4_l2x0_cache_init(void)
쟢arly_initcall(exynos4_l2x0_cache_init);
�#endif
-static int __init exynos5_l2_cache_init(void)
-{
- � � � unsigned int val;
-
- � � � if (!soc_is_exynos5250())
- � � � � � � � return 0;
-
- � � � asm volatile(mrc p15, 0, %0, c1, c0, 0\n
- � � � � � � � � � �bic %0, %0, #(1 2)\n �/* cache disable */
- � � � � � � � � � �mcr p15, 0, %0, c1, c0, 0\n
- � � � � � � � � � �mrc p15, 1, %0, c9, c0, 2\n
- � � � � � � � � � �: =r(val));
-
- � � � val |= (1 9) | (1 5) | (2 6) | (2 0);
-
- � � � asm volatile(mcr p15, 1, %0, c9, c0, 2\n : : r(val));
- � � � asm volatile(mrc p15, 0, %0, c1, c0, 0\n
- � � � � � � � � � �orr %0, %0, #(1 2)\n �/* cache enable */
- � � � � � � � � � �mcr p15, 0, %0, c1, c0, 0\n
- � � � � � � � � � �: : r(val));
-
- � � � return 0;
-}
-early_initcall(exynos5_l2_cache_init);
-
쟳tatic int __init exynos_init(void)
�{
� � � 쟰rintk(KERN_INFO EXYNOS: Initializing architecture\n);
--
1.7.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
- Joonyoung Shim
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails
-Original Message-
From: Subash Patel [mailto:subas...@gmail.com]
Sent: Tuesday, June 26, 2012 3:23 AM
To: dri-de...@lists.freedesktop.org; linux-samsung-soc@vger.kernel.org;
linaro-mm-...@lists.linaro.org
Cc: ol...@chromium.org; inki@samsung.com; airl...@redhat.com; Subash
Patel; Subash Patel
Subject: [PATCH 1/2] DRM: Exynos: return NULL if exynos_pages_to_sg fails
From: Subash Patel subash...@samsung.com
exynos_pages_to_sg() internally calls sg_kmalloc() which can return
no pages when the system is under high memory crunch. One such instance
is chromeos-install in the chromeos. This patch adds check for the return
value of the function in subject to return NULL on failure.
Change-Id: I541ed30491a926ebe72738225041c9f2d88007bc
Signed-off-by: Subash Patel subash.ramasw...@linaro.org
CC: dri-de...@lists.freedesktop.org
CC: linux-samsung-soc@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 97325c1..52cf761 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -87,6 +87,10 @@ static struct sg_table *
npages = buf-size / buf-page_size;
sgt = exynos_pages_to_sg(buf-pages, npages, buf-page_size);
+ if (!sgt) {
+ DRM_DEBUG_PRIME(exynos_pages_to_sg returned NULL!\n);
+ goto err_unlock;
+ }
nents = dma_map_sg(attach-dev, sgt-sgl, sgt-nents, dir);
DRM_DEBUG_PRIME(npages = %d buffer size = 0x%lx page_size =
0x%lx\n,
--
1.7.9.5
Applied.
Thanks,
Inki Dae
--
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] DRM: Exynos: check for null in return value of dma_buf_map_attachment()
-Original Message-
From: Subash Patel [mailto:subas...@gmail.com]
Sent: Tuesday, June 26, 2012 3:23 AM
To: dri-de...@lists.freedesktop.org; linux-samsung-soc@vger.kernel.org;
linaro-mm-...@lists.linaro.org
Cc: ol...@chromium.org; inki@samsung.com; airl...@redhat.com; Subash
Patel; Subash Patel
Subject: [PATCH 2/2] DRM: Exynos: check for null in return value of
dma_buf_map_attachment()
From: Subash Patel subash...@samsung.com
dma_buf_map_attachment() can return NULL and valid sg as return
value. Hence the check for the returned scatter-gather must be using
the inline function IS_ERR_OR_NULL() in place of IS_ERR()
Change-Id: I33218480e220f6a26a1e726b336bf533a95363de
Signed-off-by: Subash Patel subash.ramasw...@linaro.org
CC: dri-de...@lists.freedesktop.org
CC: linux-samsung-soc@vger.kernel.org
CC: linaro-mm-...@lists.linaro.org
CC: inki@samsung.com
CC: airl...@redhat.com
CC: ol...@chromium.org
---
drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 52cf761..c908a29 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -245,7 +245,7 @@ struct drm_gem_object
*exynos_dmabuf_prime_import(struct drm_device *drm_dev,
sgt = dma_buf_map_attachment(attach, DMA_BIDIRECTIONAL);
- if (IS_ERR(sgt)) {
+ if (IS_ERR_OR_NULL(sgt)) {
ret = PTR_ERR(sgt);
goto err_buf_detach;
}
--
1.7.9.5
Applied.
Thanks,
Inki Dae
--
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
