Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
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.
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
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] v4l/omap: fix a compilation error
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
drivers/media/video/omap/omap_vout.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 0d036b1..fdc1fb1 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2305,14 +2305,16 @@ static int __init omap_vout_probe(struct
platform_device *pdev)
if (ret)
goto probe_err2;
- if (!cpu_is_omap54xx()) {
- for (i = 0; i vid_dev-num_displays; i++) {
- struct omap_dss_device *display = vid_dev-displays[i];
+ if (cpu_is_omap54xx())
+ return 0;
+
+ for (i = 0; i vid_dev-num_displays; i++) {
+ struct omap_dss_device *display = vid_dev-displays[i];
if (display-driver display-driver-update)
display-driver-update(display, 0, 0,
- display-panel.timings.x_res,
- display-panel.timings.y_res);
+ display-panel.timings.x_res,
+ display-panel.timings.y_res);
}
return 0;
--
1.7.9.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH tilt-3.2] DSS: export the omap_dss_get_def_disp symbol
Required when building DSS and the generic DPI panel driver as
modules.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
drivers/video/omap2/dss/core.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 108aa24..b937f2f 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -26,6 +26,7 @@
#include linux/module.h
#include linux/clk.h
#include linux/err.h
+#include linux/export.h
#include linux/platform_device.h
#include linux/seq_file.h
#include linux/debugfs.h
@@ -61,6 +62,7 @@ const char* omap_dss_get_def_disp()
{
return def_disp_name;
}
+EXPORT_SYMBOL(omap_dss_get_def_disp);
/* REGULATORS */
--
1.7.9.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: implementing suspend to ram on cortex A8 based on linux 3.0.8
Thanks for your comment. Finally, i find out that i made a mistake. The uart(8250) have not been restore after resume, instead, it use the configuration got from boot. The uart have not been restored correctly, so that ls can not output result correctly resulting in it seems that the busybox can not work correctly. Now, i still have a question about the uart: why the printk can work correctly, but the printf not? Before this, i believe that the printk work correctly, then the uart work ok. but now, i need more reconsidaration about the relation between the printk, printf and uart. Can anyone give me some suggestion? Any comment is welcome, thanks a lot. 在 2012年3月9日 下午10:08，Chenglie He chengjie...@linaro.org写道： Hi, I am doing this on A9, echo mem /sys/power/state is right, will trigger kernel to sleep. -jack some recipient promote: The message contains HTML subpart, therefore we consider it SPAM or Outlook Virus so i resend the email, hope it not disturb u. thanks a lot. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH tilt-3.2] tiler: export the SiTA initializer
This way, tiler can be built as a module.
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
drivers/media/video/tiler/tcm/tcm-sita.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/tiler/tcm/tcm-sita.c
b/drivers/media/video/tiler/tcm/tcm-sita.c
index d0784c6..d081d74 100644
--- a/drivers/media/video/tiler/tcm/tcm-sita.c
+++ b/drivers/media/video/tiler/tcm/tcm-sita.c
@@ -17,6 +17,7 @@
* WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
*
*/
+#include linux/export.h
#include linux/slab.h
#include _tcm-sita.h
@@ -161,6 +162,7 @@ error:
kfree(pvt);
return NULL;
}
+EXPORT_SYMBOL(sita_init);
static void sita_deinit(struct tcm *tcm)
{
--
1.7.9.1
___
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 Fri, Mar 09, 2012 at 11:54:24PM -0800, Mike Turquette wrote: Many platforms support simple gateable clocks, fixed-rate clocks, adjustable divider clocks and multi-parent multiplexer clocks. Hi Mike Please feel free to add: Reviewed-by: Andrew Lunn and...@lunn.ch Tested-by: Andrew Lunn and...@lunn.ch Andrew ___ 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 Fri, Mar 09, 2012 at 11:54:23PM -0800, Mike Turquette wrote: The common clock framework defines a common struct clk useful across most platforms as well as an implementation of the clk api that drivers can use safely for managing clocks. Hi Mike Please feel free to add: Tested-by: Andrew Lunn and...@lunn.ch Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH tilt-3.2] OPP: export symbols for modules
The symbols are currently used the the omap-abe-dsp code. Signed-off-by: Mircea Gherzan mgher...@gmail.com --- drivers/base/power/opp.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c index b1e333a..069d7e5 100644 --- a/drivers/base/power/opp.c +++ b/drivers/base/power/opp.c @@ -14,6 +14,7 @@ #include linux/kernel.h #include linux/errno.h #include linux/err.h +#include linux/export.h #include linux/init.h #include linux/slab.h #include linux/cpufreq.h @@ -219,6 +220,7 @@ int opp_get_opp_count(struct device *dev) return count; } +EXPORT_SYMBOL(opp_get_opp_count); /** * opp_find_freq_exact() - search for an exact frequency @@ -354,6 +356,7 @@ struct opp *opp_find_freq_floor(struct device *dev, unsigned long *freq) return opp; } +EXPORT_SYMBOL(opp_find_freq_floor); /** * opp_add() - Add an OPP table from a table definitions -- 1.7.9.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH tilt-3.2] syslink: add a missing header to fix a build error
drivers/dsp/syslink/multicore_ipc/heap.c:36:2: error: implicit declaration of function 'BUILD_BUG_ON' Signed-off-by: Mircea Gherzan mgher...@gmail.com --- drivers/dsp/syslink/multicore_ipc/heap.c |3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/drivers/dsp/syslink/multicore_ipc/heap.c b/drivers/dsp/syslink/multicore_ipc/heap.c index 479174d..9deb6df 100644 --- a/drivers/dsp/syslink/multicore_ipc/heap.c +++ b/drivers/dsp/syslink/multicore_ipc/heap.c @@ -15,9 +15,8 @@ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR * PURPOSE. */ +#include linux/kernel.h #include linux/types.h -#include linux/bug.h - #include heap.h -- 1.7.9.1 ___ 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 Fri, 9 Mar 2012, Mike Turquette wrote:
+inline unsigned long __clk_get_enable_count(struct clk *clk)
+{
+ return !clk ? -EINVAL : clk-enable_count;
Returning negative error codes in a function with a return value
unsigned long is a bit strange at least. Shouldn't that be long ?
+#ifndef __LINUX_CLK_PRIVATE_H
+#define __LINUX_CLK_PRIVATE_H
+
+#include linux/clk-provider.h
+#include linux/list.h
+
+/*
+ * WARNING: Do not include clk-private.h from any file that implements struct
+ * clk_ops. Doing so is a layering violation!
+ *
+ * This header exists only to allow for statically initialized clock data.
Any
+ * static clock data must be defined in a separate file from the logic that
+ * implements the clock operations for that same data.
Now the question is whether you should provide a data structure which
is explicitely used for static initialization and instead of having
struct clk static you register the static initializer structure, which
would be initdata. I don't think that anything needs clocks before the
memory allocators are up and running. The clocks which are necessary
to get that far have to be enabled in the boot loader anyway.
The static initialization question should not hold off this set from
being merged, though settling it before growing users would be nice.
Otherwise this is a very well done infrastructure implementation!
Thanks a lot Mike!
Reviewed-by: Thomas Gleixner t...@linutronix.de
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] OMAP: remove merge artifacts from the PandaBoard file
Signed-off-by: Mircea Gherzan mgher...@gmail.com
---
arch/arm/mach-omap2/board-omap4panda.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 084e0a6..77ab174 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -63,10 +63,6 @@
#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
#define HDMI_GPIO_HPD 63 /* Hotplug detect */
- current
-/* wl127x BT, FM, GPS connectivity chip */
-static int wl1271_gpios[] = {46, -1, -1};
-===
#define FIXED_REG_VWLAN_ID 0
#define FIXED_REG_V2V1_ID 1
#define FIXED_REG_V1V8_ID 2
@@ -74,7 +70,6 @@ static int wl1271_gpios[] = {46, -1, -1};
/* wl127x BT, FM, GPS connectivity chip */
static int wl1271_gpios[] = {46, -1, -1};
- patched
static struct platform_device wl1271_device = {
.name = kim,
.id = -1,
--
1.7.9.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 1/3] Documentation: common clk API
On Fri, Mar 09, 2012 at 11:54:22PM -0800, Mike Turquette wrote: Provide documentation for the common clk structures and APIs. This code can be found in drivers/clk/ and include/linux/clk*.h. Hi Mike Please feel free to add: Reviewed-by: Andrew Lunn and...@lunn.ch Andrew ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: implementing suspend to ram on cortex A8 based on linux 3.0.8
Thanks for your comment. Finally, i find out that i made a mistake. The uart(8250) have not been restore after resume, instead, it use the configuration got from boot. The uart have not been restored correctly, so that ls can not output result correctly resulting in it seems that the busybox can not work correctly. Now, i still have a question about the uart: why the printk can work correctly, but the printf not? Before this, i believe that the printk work correctly, then the uart work ok. but now, i need more reconsidaration about the relation between the printk, printf and uart. Can anyone give me some suggestion? Any comment is welcome, thanks a lot. 在 2012年3月9日 下午10:08，Chenglie He chengjie...@linaro.org写道： Hi, I am doing this on A9, echo mem /sys/power/state is right, will trigger kernel to sleep. -jack On 7 March 2012 23:05, yang gqyang hustgqy...@gmail.com wrote: dear all: I am working on arm cortex a8 now, trying to implement suspend to ram based on linux 3.0.8. Before i start my work, the soc already support standby(the cpu is on wfi state), so in order to implement suspend to ram, i think i just need to implement the arch-specific related api. The suspend to ram works like this: echo mem /sys/power/state - enter_state - suspend_devices_and_enter -suspend_ops-enter(state) Is that right? Do you think the suspend to ram can be realized in this way? In order to power off the cortex A8, i save all the writable co-processor and all modes's state register set, and restore them when resuming. All the code seems work ok, because when I just does not power off the cortex-A8 and jump to excute the resume code, the system works well. But, when I power off the cpu, and wake up and excute resume code, the kernel seem ok, but the busybox toolkit does not work proper, eg: ls can not output the result through serial port. i add printk statement trying to locate the reason, but at this time, the ls work fine. hence, i doubt something must be corrupted after resume. I have checked all the state register and co-processor, having not found any exception, and I also compared all the dram data before power off and after wake up, nothing have changed. Right now, I do not know what has happened, and what should I do to locate the real problem to make the busybox works ok. I also want to know does the linux kernel 3.0.8 support suspend to ram like this: echo mem /sys/power/state - enter_state - suspend_devices_and_enter -suspend_ops-enter(state)? Can anyone give me some suggestion? Any comment is welcome, thanks a lot. -- 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 ___ 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: Announcing Linarotv-xmbc image
Hi Christian, thank you for the information! Yes, I eventually decided not to use XBMC on hardware without 3D, and use qtmediahub instead. And, I have run XBMC on pandaboard and found out that XBMC requires a lot of CPU(often 90%+). So on hardware without 3D, it is impossilbe to run... On Fri, Mar 9, 2012 at 11:08 PM, Christian Robottom Reis k...@linaro.orgwrote: On Thu, Jan 26, 2012 at 04:29:40PM +0800, Hui Zhang wrote: Thank you, Ricardo! By your experience,do you think xbmc can perform well on boards without hardware OpenGL ES acceleration? I don't know if Ricardo answered, but unless XBMC has a non-composited 2D mode, I think it's unlikely. You're asking a lot of the CPU, and I don't think the memory is fast enough to handle all the copies. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [linux-pm] [PATCH 2/4] thermal: Add generic cpufreq cooling implementation
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. 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? + + 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. + .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? + 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? + 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? 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
Re: Announcing Linarotv-xmbc image
On Sat, Mar 10, 2012 at 9:43 PM, Hui Zhang son...@gmail.com wrote: Hi Christian, thank you for the information! Yes, I eventually decided not to use XBMC on hardware without 3D, and use qtmediahub instead. And, I have run XBMC on pandaboard and found out that XBMC requires a lot of CPU(often 90%+). So on hardware without 3D, it is impossilbe to run... What does impossible to run here mean? I've certainly run xbmc on my panda boards and on both video, audio etc was fine. The interface was displaying at 1080p as would be expected and not unusable. Sure lots of CPU might be in use, but it's not like one is going to be running xbmc and compiling kernels at -j16 or something. On Fri, Mar 9, 2012 at 11:08 PM, Christian Robottom Reis k...@linaro.org wrote: On Thu, Jan 26, 2012 at 04:29:40PM +0800, Hui Zhang wrote: Thank you, Ricardo! By your experience,do you think xbmc can perform well on boards without hardware OpenGL ES acceleration? I don't know if Ricardo answered, but unless XBMC has a non-composited 2D mode, I think it's unlikely. You're asking a lot of the CPU, and I don't think the memory is fast enough to handle all the copies. -- Christian Robottom Reis, Engineering VP Brazil (GMT-3) | [+55] 16 9112 6430 | [+1] 612 216 4935 Linaro.org: Open Source Software for ARM SoCs -- 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
Re: [PATCH v6 2/3] clk: introduce the common clock framework
Looks like you didn't take my comments for v5. http://www.spinics.net/lists/arm-kernel/msg162903.html Regards Richard ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
