Re: [PATCH v2 1/2] ARM: IMX5: cpuidle driver
Hi Sascha, + local_irq_disable(); + do_gettimeofday(before); + + plat_lpc = __raw_readl(MXC_CORTEXA8_PLAT_LPC) + ~(MXC_CORTEXA8_PLAT_LPC_DSM); One thing that strikes me here is the fact that this code can probably run on i.MX53 aswell, right? It's only that these registers have different addresses on i.MX53. The MXC_ prefix is therefore not a good idea. Switching this to MX51_ and having an additional MX53_ register leads to code duplication. This shows that it's a bad idea to code fixed addresses in the code. We should go for base + offset instead so that this code will have a better start on i.MX53. This of course needs changes in the current crm_regs.h and probably in the i.MX51/53 clock code. Yes, for mx53, it is similar. But for the case you are talking about, is it easier that we keep MXC_ prefix in this file and define MXC_ to MX51 or MX53 in crm_regs.h according to which board is running? In addition, registers for this code are not in one section, which means many BASEx + offset there, if I understand right. Do you have a sample for 'base + offset' case? since mx53 just came in, I am not sure about such case. yong ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v2 1/2] ARM: IMX5: cpuidle driver
On Fri, Feb 11, 2011 at 10:36:12AM +0100, yong.s...@linaro.org wrote:
From: Yong Shen yong.s...@freescale.com
implement cpuidle driver for iMX5 SOCs, leave cpuidle params to board
related code.
Signed-off-by: Yong Shen yong.s...@freescale.com
---
arch/arm/mach-mx5/Makefile |1 +
arch/arm/mach-mx5/cpuidle.c | 113
+++
arch/arm/mach-mx5/cpuidle.h | 26 ++
3 files changed, 140 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx5/cpuidle.c
create mode 100644 arch/arm/mach-mx5/cpuidle.h
diff --git a/arch/arm/mach-mx5/Makefile b/arch/arm/mach-mx5/Makefile
index 0d43be9..12239e0 100644
--- a/arch/arm/mach-mx5/Makefile
+++ b/arch/arm/mach-mx5/Makefile
@@ -7,6 +7,7 @@ obj-y := cpu.o mm.o clock-mx51-mx53.o devices.o
obj-$(CONFIG_SOC_IMX50) += mm-mx50.o
obj-$(CONFIG_CPU_FREQ_IMX)+= cpu_op-mx51.o
+obj-$(CONFIG_CPU_IDLE) += cpuidle.o
obj-$(CONFIG_MACH_MX51_BABBAGE) += board-mx51_babbage.o
obj-$(CONFIG_MACH_MX51_3DS) += board-mx51_3ds.o
obj-$(CONFIG_MACH_MX53_EVK) += board-mx53_evk.o
diff --git a/arch/arm/mach-mx5/cpuidle.c b/arch/arm/mach-mx5/cpuidle.c
new file mode 100644
index 000..9d77c47
--- /dev/null
+++ b/arch/arm/mach-mx5/cpuidle.c
@@ -0,0 +1,113 @@
+/*
+ * arch/arm/mach-mx5/cpuidle.c
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include linux/io.h
+#include linux/cpuidle.h
+#include asm/proc-fns.h
+#include mach/hardware.h
+#include cpuidle.h
+#include crm_regs.h
+
+static struct imx_cpuidle_params *imx_cpuidle_params;
+void imx_cpuidle_board_params(struct imx_cpuidle_params *cpuidle_params)
+{
+ imx_cpuidle_params = cpuidle_params;
+}
+
+extern int tzic_enable_wake(int is_idle);
+static int imx_enter_idle(struct cpuidle_device *dev,
+struct cpuidle_state *state)
+{
+ struct timeval before, after;
+ int idle_time;
+ u32 plat_lpc, arm_srpgcr, ccm_clpcr;
+ u32 empgc0, empgc1;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ plat_lpc = __raw_readl(MXC_CORTEXA8_PLAT_LPC)
+ ~(MXC_CORTEXA8_PLAT_LPC_DSM);
One thing that strikes me here is the fact that this code can probably
run on i.MX53 aswell, right? It's only that these registers have
different addresses on i.MX53. The MXC_ prefix is therefore not a good
idea. Switching this to MX51_ and having an additional MX53_ register
leads to code duplication. This shows that it's a bad idea to code
fixed addresses in the code. We should go for base + offset instead
so that this code will have a better start on i.MX53. This of course
needs changes in the current crm_regs.h and probably in the i.MX51/53
clock code.
+ ccm_clpcr = __raw_readl(MXC_CCM_CLPCR) ~(MXC_CCM_CLPCR_LPM_MASK);
+ arm_srpgcr = __raw_readl(MXC_SRPG_ARM_SRPGCR) ~(MXC_SRPGCR_PCR);
+ empgc0 = __raw_readl(MXC_SRPG_EMPGC0_SRPGCR) ~(MXC_SRPGCR_PCR);
+ empgc1 = __raw_readl(MXC_SRPG_EMPGC1_SRPGCR) ~(MXC_SRPGCR_PCR);
+
+ if (state == dev-states[WAIT_CLK_ON])
+ ;
+ else if (state == dev-states[WAIT_CLK_OFF])
+ ccm_clpcr |= (0x1 MXC_CCM_CLPCR_LPM_OFFSET);
+ else if (state == dev-states[WAIT_CLK_OFF_POWER_OFF]) {
+ /* Wait unclocked, power off */
+ plat_lpc |= MXC_CORTEXA8_PLAT_LPC_DSM
+ | MXC_CORTEXA8_PLAT_LPC_DBG_DSM;
+ arm_srpgcr |= MXC_SRPGCR_PCR;
+ ccm_clpcr |= (0x1 MXC_CCM_CLPCR_LPM_OFFSET);
+ ccm_clpcr = ~MXC_CCM_CLPCR_VSTBY;
+ ccm_clpcr = ~MXC_CCM_CLPCR_SBYOS;
+ if (tzic_enable_wake(1) != 0) {
+ local_irq_enable();
+ return 0;
+ }
+ }
+
+ __raw_writel(plat_lpc, MXC_CORTEXA8_PLAT_LPC);
+ __raw_writel(ccm_clpcr, MXC_CCM_CLPCR);
+ __raw_writel(arm_srpgcr, MXC_SRPG_ARM_SRPGCR);
+
+ cpu_do_idle();
+
+ do_gettimeofday(after);
+ local_irq_enable();
+ idle_time = (after.tv_sec - before.tv_sec) * USEC_PER_SEC +
+ (after.tv_usec - before.tv_usec);
+ return idle_time;
+}
+
+static struct cpuidle_driver imx_cpuidle_driver = {
+ .name = imx_idle,
+ .owner =THIS_MODULE,
+};
+
+static DEFINE_PER_CPU(struct cpuidle_device, imx_cpuidle_device);
+
+static int __init imx_cpuidle_init(void)
+{
+ struct cpuidle_device *device;
+ int i;
+
+ if (imx_cpuidle_params == NULL)
+ return -ENODEV;
+
+ cpuidle_register_driver(imx_cpuidle_driver);
+
+ device = per_cpu(imx_cpuidle_device, smp_processor_id());
+ device-state_count = IMX_MAX_CPUIDLE_STATE;
+
+ for (i = 0; i IMX_MAX_CPUIDLE_STATE i CPUIDLE_STATE_MAX; i++) {
+ device-states[i].enter
Re: [RFC] agent-based remote validation invocation for LAVA
Hi all! This is very good analysis you have done, and I would just add that Monkey is only one simpler example where the test execution using abrek is not an option. Another example from Android world is CTS: http://source.android.com/compatibility/cts-intro.html. Most certainly, all test suites and frameworks are not only DUT-based. Some of them have more or less dependencies and functions on the PC side as well. Zygmunt has already identified key points for Job Dispatcher to support this, but one thing I would like to comment: Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job would use abrek and some other tools to invoke tests, process results and send them to the dashboard while other job (one for android) would not run abrek at all, instead it would call some other helper, while still reusing identical components for process results and send to result storage phases. This is still in flux but has some advantages: 0) Jobs are simple text files that can be stored and shared with others 1) Jobs can encapsulate device information like which android device to connect to and how. 2) Jobs can still call to other parts of the LAVA stack such as result submission 3) Jobs can be extended locally (by LAVA plugins) so that anyone can develop specialized use cases for their very specific needs without altering the stack or having to write something completely custom. I think exposing Job Dispatcher directly would not be a good idea for validation farm, where test jobs are queued for execution via Scheduler (see LAVA architecture). Bypassing the job queue on the Dispatcher level should only be allowed in exceptional cases, i.e. canceling jobs for server/board update or similar. There might be scenarios where the unrestricted direct control is desirable, but that should be only allowed for local development environments. It would be good to have this specified/discussed somewhere already now, maybe in the Dispatcher blueprint, or maybe we need additional blueprint or wiki spec for it? Thanks! Mirsad ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: /latest link now active on snapshots.linaro.org
On Tue, Feb 8, 2011 at 1:10 PM, Jamie Bennett jamie.benn...@linaro.org wrote: Hi, There is now a much easier way to download the daily Linaro images and hardware packs, the /latest link. Inside each build directory a /latest link will always point to the latest successful build. The following urls are currently setup: http://snapshots.linaro.org/11.05-daily/linaro-alip/latest http://snapshots.linaro.org/11.05-daily/linaro-developer/latest http://snapshots.linaro.org/11.05-daily/linaro-headless/latest http://snapshots.linaro.org/11.05-daily/linaro-netbook-efl/latest Please note that the headless and netbook-efl images will be replaced by the Nano and Evaluation Ubuntu Desktop builds soon. The following hardware packs are also built: http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/igep/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/imx51/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/lt-s5pv310/latest http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/omap3/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/omap3-x11-base/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/overo/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/panda/latest/ http://snapshots.linaro.org/11.05-daily/linaro-hwpacks/vexpress/latest/ So far, so good, but we still don't shapshort linaro-image-tools along with releases. This will become a problem because l-i-t evolves over time -- I've already had to start explaining to people how to check out old versions of l-i-t in order to make use of the linaro-m release images. Installing the (unsupported) linaro-m release for panda doesn't work with current l-i-t, for example. To be fair, this is more of an issue for releases.linaro.org (where people will tend to need a specific, old version of l-i-t) than for snapshots.linaro.org. But it's something we need to think about. Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
2011/2/16 Mirsad Vojnikovic mirsad.vojniko...@linaro.org: Hi all! hi Mirsad, This is very good analysis you have done, and I would just add that Monkey is only one simpler example where the test execution using abrek is not an option. True. Another example from Android world is CTS: http://source.android.com/compatibility/cts-intro.html. Most certainly, all test suites and frameworks are not only DUT-based. Some of them have more or less dependencies and functions on the PC side as well. Yes, in fact, Android CTS replies on PC side, too. The device will try to reset adb (through USB gadget) for several times in order to probe the compatibility to host (Windows/Linux/MacOSX). Zygmunt has already identified key points for Job Dispatcher to support this, but one thing I would like to comment: Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job would use abrek and some other tools to invoke tests, process results and send them to the dashboard while other job (one for android) would not run abrek at all, instead it would call some other helper, while still reusing identical components for process results and send to result storage phases. This is still in flux but has some advantages: 0) Jobs are simple text files that can be stored and shared with others 1) Jobs can encapsulate device information like which android device to connect to and how. 2) Jobs can still call to other parts of the LAVA stack such as result submission 3) Jobs can be extended locally (by LAVA plugins) so that anyone can develop specialized use cases for their very specific needs without altering the stack or having to write something completely custom. I think exposing Job Dispatcher directly would not be a good idea for validation farm, where test jobs are queued for execution via Scheduler (see LAVA architecture). Bypassing the job queue on the Dispatcher level should only be allowed in exceptional cases, i.e. canceling jobs for server/board update or similar. There might be scenarios where the unrestricted direct control is desirable, but that should be only allowed for local development environments. Thanks for pointing out this. It would be good to have this specified/discussed somewhere already now, maybe in the Dispatcher blueprint, or maybe we need additional blueprint or wiki spec for it? Yes, it would be great. Cheers, Jim Huang (jserv) http://0xlab.org/ ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
W dniu 16.02.2011 15:10, Paul Larson pisze: Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job I hope you don't really think this is a crazy idea, because it's *exactly* what we discussed doing, and I think it is still the direction I did not give it much thought when I wrote that email but I think the direction is sensible and would be much more flexible than anything else. After more conversations and some experiments I think this is the way forward for all testing. forward. Even back at the sprint, we talked about the fact that though we don't know exactly what our android images will look like yet (so specifics are hard to plan around), we do have a pretty good idea that things like abrek are not going to be a good fit there. Additionally, there are other tests that may eventually need to run from the outside. For that matter, the boot test itself is exactly one of those things. If a system doesn't boot, we still want to capture the serial log and save it for later debugging. We certainly need, and have already discussed the fact that the dispatcher has a server component that drives execution of such things. This isn't, in any way, bypassing the dispatcher, but rather using a different interface of it to run a non-abrek based test. Yeah, when you mentioned this now I started thinking. Do we really need a daemon-like component for the dispatcher in general or just in the farm environment. Can we assume that having the implementation the daemon can be replaced with a command line tool that simply interacts with one device - strictly for development purpose? I'm thinking about stuff like volatile device state and device monitoring requirements. Other than that it seems that our device overwatch + dispatcher looks quite similar to android debug bridge. I think this is good. Thanks ZK ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
On 16 February 2011 06:10, Paul Larson paul.lar...@linaro.org wrote: Another crazy option would be to expose LAVA Job Dispatcher directly and allow people to run jobs. In this case one job would use abrek and some other tools to invoke tests, process results and send them to the dashboard while other job (one for android) would not run abrek at all, instead it would call some other helper, while still reusing identical components for process results and send to result storage phases. This is still in flux but has some advantages: 0) Jobs are simple text files that can be stored and shared with others 1) Jobs can encapsulate device information like which android device to connect to and how. 2) Jobs can still call to other parts of the LAVA stack such as result submission 3) Jobs can be extended locally (by LAVA plugins) so that anyone can develop specialized use cases for their very specific needs without altering the stack or having to write something completely custom. I think exposing Job Dispatcher directly would not be a good idea for validation farm, where test jobs are queued for execution via Scheduler (see LAVA architecture). Bypassing the job queue on the Dispatcher level should only be allowed in exceptional cases, i.e. canceling jobs for server/board update or similar. There might be scenarios where the unrestricted direct control is desirable, but that should be only allowed for local development environments. I hope you don't really think this is a crazy idea, because it's *exactly* what we discussed doing, and I think it is still the direction forward. Even back at the sprint, we talked about the fact that though we don't know exactly what our android images will look like yet (so specifics are hard to plan around), we do have a pretty good idea that things like abrek are not going to be a good fit there. Additionally, there are other tests that may eventually need to run from the outside. For that matter, the boot test itself is exactly one of those things. If a system doesn't boot, we still want to capture the serial log and save it for later debugging. We certainly need, and have already discussed the fact that the dispatcher has a server component that drives execution of such things. This isn't, in any way, bypassing the dispatcher, but rather using a different interface of it to run a non-abrek based test. Maybe I expressed myself wrongly. With bypassing I meant bypassing the job queue, not Dispatcher. I think it is a bad idea on the validation farm to bypass the job queue and execute jobs directly on the Dispatcher, regardless of if they are using abrek or some other test process or framework. I can understand that we need this functionality when developing the system, just in order to enable and validate different parts separately from others. But if this is how it should work in the end version, then we need to specify a way to track these direct test jobs from Dispatcher in some way. Despite that, this is still a useful exercise, and many thanks to Jim for putting this together to show us a proof of concept for how we can run tests remotely on android systems! Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] agent-based remote validation invocation for LAVA
On 16 February 2011 06:24, Paul Larson paul.lar...@linaro.org wrote: On Wed, Feb 16, 2011 at 8:16 AM, Zygmunt Krynicki zygmunt.kryni...@linaro.org wrote: Yeah, when you mentioned this now I started thinking. Do we really need a daemon-like component for the dispatcher in general or just in the farm environment. Can we assume that having the implementation the daemon can be replaced with a command line tool that simply interacts with one device - strictly for development purpose? I'm thinking about stuff like volatile device state and device monitoring requirements. The only reason I see for having a daemon at all is to pick up jobs from the queue. In reality, I think even having the queue is overkill for the moment. The actual job dispatcher portion, that is, the piece that takes a job control file, parses it, initiates deployment to a device, ... can absolutely be a command line piece. We're going to have to have one of these processes running for each job running anyway, and it greatly simplifies things not only for us, but for anyone who wants to run a smaller-scale version of this. Totally agree, that is what I meant with three-layered Dispatcher, you can see it in the awful picture I sent previously when reviewing the Dispatcher. First layer to pick up jobs from queue and assign them to second layer, which we call server dispatcher today, and which then uses the third layer called client dispatcher on the board. Having a smaller-scale version would be very useful as well. -Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: /latest link now active on snapshots.linaro.org
On Wed, Feb 16, 2011 at 12:55:31PM +, Dave Martin wrote: So far, so good, but we still don't shapshort linaro-image-tools along with releases. This will become a problem because l-i-t evolves over time -- I've already had to start explaining to people how to check out old versions of l-i-t in order to make use of the linaro-m release images. Installing the (unsupported) linaro-m release for panda doesn't work with current l-i-t, for example. What error do you get in this case? The current version of l-i-t /is/ supposed to work for installing old linaro-m images, and if it doesn't that's something we should fix. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
Speaking for the Linaro graphics working group, I think it's great. And, I think you're right, that if enough of the KMS support in xf86-video-* is similar enough (I was only aware of intel and nouveau supporting it properly at current), pulling it out into a common layer would make it easier to support in new drivers (including fbdev). cheers, Jesse On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 15 February 2011, Clark, Rob wrote: I'd been experimenting a bit on the side w/ the DRM driver framework ( http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu ), but had to add a good chunk of mostly boilerplate code to our xorg driver in order just to test it. Maybe some generic support for KMS in xf86-video-fbdev would have made this easier to develop the kernel part without in parallel having to implement the userspace part. I'm not sure if this is the sort of thing the linaro-wg has in mind? I'm not sure what the the linaro multimedia wg thinks of this, but the kernel code you linked looks like it's doing exactly the right thing. Arnd ___ 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: /latest link now active on snapshots.linaro.org
On Wed, 16 Feb 2011 12:55:31 +, Dave Martin dave.mar...@linaro.org wrote: So far, so good, but we still don't shapshort linaro-image-tools along with releases. This will become a problem because l-i-t evolves over time -- I've already had to start explaining to people how to check out old versions of l-i-t in order to make use of the linaro-m release images. Installing the (unsupported) linaro-m release for panda doesn't work with current l-i-t, for example. I would consider this a bug. I think it is impractical for us to ask everyone to use a different l-i-t for every release that they consume. I also think it would be a massive headache for maintainence of l-i-t as well. Please file bugs when you see these issues, and we will deal with them appropriately. Thanks, James ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: /latest link now active on snapshots.linaro.org
On Wed, Feb 16, 2011 at 2:53 PM, James Westby james.wes...@canonical.com wrote: On Wed, 16 Feb 2011 12:55:31 +, Dave Martin dave.mar...@linaro.org wrote: So far, so good, but we still don't shapshort linaro-image-tools along with releases. This will become a problem because l-i-t evolves over time -- I've already had to start explaining to people how to check out old versions of l-i-t in order to make use of the linaro-m release images. Installing the (unsupported) linaro-m release for panda doesn't work with current l-i-t, for example. I would consider this a bug. I think it is impractical for us to ask everyone to use a different l-i-t for every release that they consume. I also think it would be a massive headache for maintainence of l-i-t as well. Please file bugs when you see these issues, and we will deal with them appropriately. OK I'll try to reproduce it--- but unless we test every l-m-c with all old releases, surely we're going to get regressions over time? Cheers ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: /latest link now active on snapshots.linaro.org
On Wed, Feb 16, 2011 at 2:56 PM, Dave Martin dave.mar...@linaro.org wrote: On Wed, Feb 16, 2011 at 2:53 PM, James Westby james.wes...@canonical.com wrote: On Wed, 16 Feb 2011 12:55:31 +, Dave Martin dave.mar...@linaro.org wrote: So far, so good, but we still don't shapshort linaro-image-tools along with releases. This will become a problem because l-i-t evolves over time -- I've already had to start explaining to people how to check out old versions of l-i-t in order to make use of the linaro-m release images. Installing the (unsupported) linaro-m release for panda doesn't work with current l-i-t, for example. I would consider this a bug. I think it is impractical for us to ask everyone to use a different l-i-t for every release that they consume. I also think it would be a massive headache for maintainence of l-i-t as well. Please file bugs when you see these issues, and we will deal with them appropriately. OK I'll try to reproduce it--- but unless we test every l-m-c with all old releases, surely we're going to get regressions over time? Seems to be reproducible. Bug raised here: https://bugs.launchpad.net/linaro-image-tools/+bug/720114 ---Dave ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: /latest link now active on snapshots.linaro.org
On 16 February 2011 14:56, Dave Martin dave.mar...@linaro.org wrote: OK I'll try to reproduce it--- but unless we test every l-m-c with all old releases, surely we're going to get regressions over time? Sounds like something it would be worth automating in hudson... -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PM] 16/02/2011 - Minutes for the Power Management WG weekly call
Hi All, The minutes of the power management weekly call can be found at : https://wiki.linaro.org/WorkingGroups/PowerManagement/Meetings/2011-02-16 Regards, Vincent ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: OMAP DVFS feature for Linaro
On Tue, 15 Feb 2011, Vishwanath Sripathy wrote: Hi Nicolas, Pls find attached the patch set for supporting DVFS feature on OMAP. These patches have been generated against latest Linaro 2.6.37 tree and tested on OMAP3430 and ZOOM3. Note that these patches are already posted to linux omap mailing list (https://patchwork.kernel.org/patch/495021/) and they are under discussion. So I have prefixed these patches as WIP. Kindly merge these patches for 11.05 release. A few notes on those patches: 1) Please CC linaro-dev next time so other people are aware of what you did, what you sent me, etc. I've added it to this reply. This way at least if nothing happens with your patches it's easier to put the blame on me. :-) 2) Your cover message contains this in plain sight in the diffstat part: mode change 100644 = 100755 arch/arm/mach-omap2/voltage.c mode change 100644 = 100755 arch/arm/plat-omap/cpu-omap.c This is clearly wrong to flag .c files as executables, so you should take care to fix that and understand why this happened in the first place. Incidentally this mode change does not appear in any of your patches. 3) All your patches were numbered, except for: V4-OMAP3-PM-Set-clear-T2-bit-for-Smartreflex-on-TWL.patch Since I'm sure you know better than I do where that patch should be applied in the series (if at all) you should rename it appropriately, or at least let me know in which order to apply it (I initially applied it last based on the date recorded in the patch but that didn't work out). 4) This patch is a bit thin on explanation: [PATCH 08/13] [PM WIP OMAP] OMAP3: cpufreq driver changes for DVFS support Changes in the omap cpufreq driver for DVFS support. Signed-off-by: Vishwanath BS vishwanath...@ti.com What are those changes? It is not obvious to me looking at the patch. All the other patches are sufficiently documented. I've applied them to the linaro-2.6.37 branch. Please note that the 11.05 Linaro release will be based on a 2.6.38 branch I'm about to create. Can you tell me what is the likelyhood for those patches to be merged upstream for the next merge window? Nicolas ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: GCC ICE compiling glibc with latest linaro gcc 4.5
On (12/01/11 07:54), Michael Hope wrote: On Tue, Jan 11, 2011 at 3:40 PM, Khem Raj raj.k...@gmail.com wrote: Hi Commit r99457 on linaro 4.5 branch is causing a ICE when compiling the attached file with following options gcc-4_5-branch/build.i686-linux.armeb-oe-linux-gnueabi/gcc/cc1 -O2 -mtune=xscale a.i It only happens when I use -mtune=xscale otherwise it compiles fine It was tested on armeb I have not done a test on LE. I have attached the testcase to this email as well. Hi Khem. I'm afraid we're all at the Linaro Sprint at the moment. We should be able to have a look at it next week, FWIW This problem has resurfaced with commit 99475 again. It was gone when r99457 was reverted in r99461 and it happens on both BE and LE ARM the key is -O2 -mtune=xscale options -Khem ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[linaro-android][PATCH 1/1] Add virtual battery driver
From 494eb1f2bb56261815e4230e582d27311f32ae81 Mon Sep 17 00:00:00 2001
From: Akihiro MAEDA sola.198...@gmail.com
Date: Thu, 17 Feb 2011 07:16:37 +0900
Subject: [PATCH 1/1] Add virtual battery driver
This patch adds virtual battery driver.
This is based on
git://git.linaro.org/people/jstultz/linux.git dev/linaro.android
Signed-off-by: Akihiro MAEDA sola.198...@gmail.com
---
drivers/power/Kconfig |5 +
drivers/power/Makefile |1 +
drivers/power/virtual_battery.c | 427 +++
3 files changed, 433 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/virtual_battery.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index 60d83d9..7258bc9 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -185,4 +185,9 @@ config CHARGER_TWL4030
help
Say Y here to enable support for TWL4030 Battery Charge Interface.
+config BATTERY_VIRTUAL
+ tristate Virtual Battery Driver
+ help
+ Say Y to include support for Virtual Battery.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index c75772e..71f8b36 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -32,3 +32,4 @@ obj-$(CONFIG_BATTERY_JZ4740) += jz4740-battery.o
obj-$(CONFIG_BATTERY_INTEL_MID)+= intel_mid_battery.o
obj-$(CONFIG_CHARGER_ISP1704) += isp1704_charger.o
obj-$(CONFIG_CHARGER_TWL4030) += twl4030_charger.o
+obj-$(CONFIG_BATTERY_VIRTUAL) += virtual_battery.o
diff --git a/drivers/power/virtual_battery.c b/drivers/power/virtual_battery.c
new file mode 100644
index 000..a85baac
--- /dev/null
+++ b/drivers/power/virtual_battery.c
@@ -0,0 +1,427 @@
+/*
+ * drivers/power/virtual_battery.c
+ *
+ * Virtual battery driver
+ *
+ * Copyright (C) 2008 Pylone, Inc.
+ * Author: Masashi YOKOTA yok...@pylone.jp
+ * Modified by: Akihiro MAEDA sola.198...@gmail.com
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/kernel.h
+#include linux/types.h
+#include linux/err.h
+#include linux/string.h
+#include linux/device.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+#include linux/version.h
+
+
+/* module parameters */
+static int ac_status= 1; /* online */
+static int battery_status = POWER_SUPPLY_STATUS_CHARGING;
+static int battery_health = POWER_SUPPLY_HEALTH_GOOD;
+static int battery_present = 1; /* true */
+static int battery_technology = POWER_SUPPLY_TECHNOLOGY_LION;
+static int battery_capacity = 50;
+
+
+static struct platform_device *bat_pdev;
+
+static enum power_supply_property virtual_ac_props[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static enum power_supply_property virtual_battery_props[] = {
+ POWER_SUPPLY_PROP_STATUS,
+ POWER_SUPPLY_PROP_HEALTH,
+ POWER_SUPPLY_PROP_PRESENT,
+ POWER_SUPPLY_PROP_TECHNOLOGY,
+ POWER_SUPPLY_PROP_CAPACITY,
+};
+
+static int virtual_ac_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ dev_dbg(bat_pdev-dev, %s: psp=%d\n, __func__, psp);
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ val-intval = ac_status;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
+
+static int virtual_battery_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ int ret = 0;
+
+ dev_dbg(bat_pdev-dev, %s: psp=%d\n, __func__, psp);
+ switch (psp) {
+ case POWER_SUPPLY_PROP_STATUS:
+ val-intval = battery_status;
+ break;
+ case POWER_SUPPLY_PROP_HEALTH:
+ val-intval = battery_health;
+ break;
+ case POWER_SUPPLY_PROP_PRESENT:
+ val-intval = battery_present;
+ break;
+ case POWER_SUPPLY_PROP_TECHNOLOGY:
+ val-intval = battery_technology;
+ break;
+ case POWER_SUPPLY_PROP_CAPACITY:
+ val-intval = battery_capacity;
+ break; default: ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static struct power_supply power_supply_ac = {
+ .properties = virtual_ac_props,
+ .num_properties =
Re: [PATCH 4/7] watchdog: s3c2410: Add support for device tree based probe
On Sat, Feb 12, 2011 at 06:17:02PM +0530, Thomas Abraham wrote:
This patch adds the of_match_table to enable s3c2410-wdt driver
to be probed when watchdog device node is found in the device tree.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/watchdog/s3c2410_wdt.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
Need to add documentation for compatible = samsung,s3c2410-wdt to
Documentation/devicetree/bindings/wdt before this patch can be merged.
A couple more comments below, but I'm okay with this one. I'd go
ahead and submit it to the linux-watch...@vger.kernel.org list and cc:
Wim. It can be mainlined right away after fixing up the comments.
I'll ack it when you repost and then work out with Wim if it should be
merged through his tree or through mine.
diff --git a/drivers/watchdog/s3c2410_wdt.c b/drivers/watchdog/s3c2410_wdt.c
index ae53662..a9edd50 100644
--- a/drivers/watchdog/s3c2410_wdt.c
+++ b/drivers/watchdog/s3c2410_wdt.c
@@ -592,6 +592,13 @@ static int s3c2410wdt_resume(struct platform_device *dev)
#define s3c2410wdt_resume NULL
#endif /* CONFIG_PM */
+#ifdef CONFIG_OF
+static const struct of_device_id s3c2410_wdt_match[] = {
+ { .compatible = samsung,s3c2410-wdt },
+ {},
+};
+MODULE_DEVICE_TABLE(of, s3c2410_wdt_match);
+#endif
#else
#define s3c2410_wdt_match NULL
#endif
static struct platform_driver s3c2410wdt_driver = {
.probe = s3c2410wdt_probe,
@@ -602,6 +609,9 @@ static struct platform_driver s3c2410wdt_driver = {
.driver = {
.owner = THIS_MODULE,
.name = s3c2410-wdt,
+#ifdef CONFIG_OF
+ .of_match_table = s3c2410_wdt_match,
+#endif
The #ifdef can be dropped here now. .of_match_table is no longer conditional.
},
};
--
1.6.6.rc2
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 5/7] serial: samsung: Get console register defaults from device tree
On Sat, Feb 12, 2011 at 06:17:03PM +0530, Thomas Abraham wrote:
The uart ports are used as console and due to console_init, the uart ports
are initialized prior to the uart driver's probe function is called.
During this intialization stage, the driver obtains the default port
register values from the platform data.
This patch adds support for obtaining the default port register values
from the device tree. The default values should be specified in the
'chosen' node of the device tree.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/tty/serial/samsung.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 2335eda..66fece9 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -43,6 +43,7 @@
#include linux/delay.h
#include linux/clk.h
#include linux/cpufreq.h
+#include linux/of.h
#include asm/irq.h
@@ -1384,11 +1385,24 @@ static int s3c24xx_serial_init_ports(struct
s3c24xx_uart_info **info)
struct s3c24xx_uart_port *ptr = s3c24xx_serial_ports;
struct platform_device **platdev_ptr;
int i;
+ unsigned int *condefs , len;
+ struct s3c2410_uartcfg *cfg;
dbg(s3c24xx_serial_init_ports: initialising ports...\n);
platdev_ptr = s3c24xx_uart_devs;
+ condefs = (u32 *)of_get_property(of_chosen, console-defaults, len);
of_get_property returns (const void *) for a reason. Make condefs a
'const u32 *' instead of overriding the compiler warning.
Pulling the uart configuration out of a console-defaults property in
the chosen node is not the way to do this. Each uart device should
have its own node in the device tree, and the per-port configuration
belongs there.
g.
+ if (condefs (len / sizeof(unsigned int)) == 3) {
+ for (i = 0; i CONFIG_SERIAL_SAMSUNG_UARTS; i++) {
+ cfg = s3c24xx_dev_to_cfg((*platdev_ptr)-dev);
+ cfg-ucon = be32_to_cpu(condefs[0]);
+ cfg-ulcon = be32_to_cpu(condefs[1]);
+ cfg-ufcon = be32_to_cpu(condefs[2]);
+ platdev_ptr++;
+ }
+ }
+ platdev_ptr = s3c24xx_uart_devs;
for (i = 0; i CONFIG_SERIAL_SAMSUNG_UARTS; i++, ptr++, platdev_ptr++)
{
s3c24xx_serial_init_port(ptr, info[i], *platdev_ptr);
}
--
1.6.6.rc2
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 7/7] serial: samsung: Get default port register settings from device tree
On Sat, Feb 12, 2011 at 06:17:05PM +0530, Thomas Abraham wrote:
The default uart port register settings are obtained from the platform data.
In addition to that, this patch adds support for obtaining the default uart
port
register values from the uart node in device tree.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
---
drivers/tty/serial/samsung.c | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 66fece9..dda1d52 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
@@ -1148,9 +1148,22 @@ int s3c24xx_serial_probe(struct platform_device *dev,
{
struct s3c24xx_uart_port *ourport;
int ret;
+ unsigned int len, *regdef;
+ struct s3c2410_uartcfg *cfg;
dbg(s3c24xx_serial_probe(%p, %p) %d\n, dev, info, probe_index);
+ if (dev-dev.of_node) {
+ regdef = (u32 *)of_get_property(dev-dev.of_node,
+ reg-defaults, len);
+ if (regdef (len / sizeof(unsigned int)) == 3) {
+ cfg = s3c24xx_dev_to_cfg(dev-dev);
+ cfg-ucon = be32_to_cpu(regdef[0]);
+ cfg-ulcon = be32_to_cpu(regdef[1]);
+ cfg-ufcon = be32_to_cpu(regdef[2]);
+ }
+ }
+
Same comment as before, per-uart configuration belongs in each ports
device tree node.
Also, don't forget to add binding documentation do
Documentation/devicetree/bindings for the properties that you define
for the samsung uart.
g.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/7] ARM: s5pv310-dt: Add a basic dts file for SMDKV310 machine
On Sat, Feb 12, 2011 at 06:17:00PM +0530, Thomas Abraham wrote:
This patch adds a basic dts file for Samsung's SMDKV310 board which
is based on the s5pv310 machine.
Signed-off-by: Thomas Abraham thomas.abra...@linaro.org
Structure looks good. Some comments below, but it is getting close.
---
arch/arm/mach-s5pv310/mach-smdkv310.dts | 78
+++
1 files changed, 78 insertions(+), 0 deletions(-)
create mode 100755 arch/arm/mach-s5pv310/mach-smdkv310.dts
diff --git a/arch/arm/mach-s5pv310/mach-smdkv310.dts
b/arch/arm/mach-s5pv310/mach-smdkv310.dts
new file mode 100755
index 000..75aa76d
--- /dev/null
+++ b/arch/arm/mach-s5pv310/mach-smdkv310.dts
@@ -0,0 +1,78 @@
+/dts-v1/;
+
+/ {
+ model = smdkv310;
You can be verbose and human-friendly here. ie. Samsung SMDKv310 eval board
+ compatible = samsung,s5pv310,samsung,smdkv310;
The specific board should come first (most compatible) followed by the
value for the soc (less specific).
+ #address-cells = 1;
+ #size-cells = 1;
+
+ cpus {
#address-cells = 1;
#size-cells = 0;
+ cpu@0{
+ compatible = arm,cortex-a9;
reg = 0;
+ };
+
+ cpu@1 {
+ compatible = arm,cortex-a9;
reg = 1;
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x4000 0x0800;
+ };
+
+ chosen {
+ bootargs = root=/dev/ram0 rw ramdisk=8192 initrd=0x4100,8M
console=ttySAC1,115200 init=/linuxrc;
initrd address should be passed via the linux,initrd-start and
linux,initrd-end properties. U-Boot already knows how to do this so
it shouldn't be encoded in the kernel parameters list.
+ console-defaults = 0x3c5 0x3 0x111;
Drop console-defaults. The configuration should be encoded in the
uart's device tree node.
+ xtal-frequency = 2400;
It looks like this is misplaced. If this is the primary frequency for
the system, then it should go either in the root node, the soc node,
or the cpu nodes.
+ };
+
+ soc {
+ #address-cells = 1;
+ #size-cells = 1;
+ interrupt-parent = GIC;
+ compatible = samsung,s5pv310-soc,simple-bus;
+ ranges;
+
+ GIC:gic@0x1050 {
+ #interrupt-cells = 1;
+ interrupt-controller;
+ reg = 0x1050 0x1000;
+ compatible = samsung,s5pv310-gic,arm,gic;
+ };
+
+ watchdog@0x1006 {
+ reg = 0x1006 0x400;
+ interrupts = 552;
This of course will need to be fixed up when we get the irq
infrastructure properly handling cascaded irq controllers. It is fine
for the time being though.
+ compatible =
samsung,s5pv310-wdt,samsung,s3c2410-wdt;
+ };
+
+ serial@0x1380 {
+ reg = 0x1380 0x100;
+ interrupts = 16 18 17;
+ reg-defaults = 0x3c5 0x3 0x111;
reg-defaults doesn't sound like a very good binding. It's better when
the properties reflect what is trying to be configured instead of a
set of magic values. (That said, sometimes magic values are
appropriate, but even then it needs to be well documented so that
mere-mortals have a fighting chance of understanding and manipulating it).
+ compatible =
samsung,s5pv310-uart,samsung,s3c2410-uart;
+ };
+
+ serial@0x1381 {
+ reg = 0x1381 0x100;
+ interrupts = 20 22 21;
+ reg-defaults = 0x3c5 0x3 0x111;
+ compatible =
samsung,s5pv310-uart,samsung,s3c2410-uart;
+ };
+
+ serial@0x1382 {
+ reg = 0x1382 0x100;
+ interrupts = 24 26 25;
+ reg-defaults = 0x3c5 0x3 0x111;
+ compatible =
samsung,s5pv310-uart,samsung,s3c2410-uart;
+ };
+
+ serial@0x1383 {
+ reg = 0x1383 0x100;
+ interrupts = 28 30 29;
+ reg-defaults = 0x3c5 0x3 0x111;
+ compatible =
samsung,s5pv310-uart,samsung,s3c2410-uart;
+ };
+ };
+};
--
1.6.6.rc2
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/7] Add Samsung's s5pv310 machine with device tree enabled
On Sat, Feb 12, 2011 at 5:46 AM, Thomas Abraham thomas.abra...@linaro.org wrote: This patchset adds Samsung's s5pv310 machine with device tree support. This is based on git://git.secretlab.ca/git/linux-2.6 devicetree/test A new machine s5pv310-dt is added along with a dts file for the smdkv310 board. Some of the features introduced in this patchset are 1. Tested on smdkv310 board and information such as bootargs, memory information and console port register defaults are obtained from the device tree. 2. Add basic device tree file for smdkv310 board. 3. Device tree based probe enabled in watchdog timer driver (s3c2410-wdt). 4. UART driver modified to obtain default console register values from device tree. Thanks Thomas, I've picked up patches 1-3 into my devicetree/test branch. They still require some work, but they are close enough that I'm happy to at least have them in my series. You can either send me replacement patches as need be, or build on top of devicetree/test. The remainder I've commented on and I'll leave alone until I get the next version. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i.MX23/28 framebuffer driver
I'm still in the learning-as-I-go phase here, so definitely not ready to propose a solution, but it does seem to me like there is room for some sort of kms-helper library here to handle more of the boilerplate xf86-video-* stuff.. I guess I'll have a better picture once I have a chance to add support for the various multi-monitor configurations. But certainly would be interested if anyone already has some ideas. BR, -R On Wed, Feb 16, 2011 at 8:42 AM, Jesse Barker jesse.bar...@linaro.org wrote: Speaking for the Linaro graphics working group, I think it's great. And, I think you're right, that if enough of the KMS support in xf86-video-* is similar enough (I was only aware of intel and nouveau supporting it properly at current), pulling it out into a common layer would make it easier to support in new drivers (including fbdev). cheers, Jesse On Wed, Feb 16, 2011 at 4:22 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 15 February 2011, Clark, Rob wrote: I'd been experimenting a bit on the side w/ the DRM driver framework ( http://gitorious.com/~robclark/pandaboard/robclarks-kernel-omap4/commits/omap_gpu ), but had to add a good chunk of mostly boilerplate code to our xorg driver in order just to test it. Maybe some generic support for KMS in xf86-video-fbdev would have made this easier to develop the kernel part without in parallel having to implement the userspace part. I'm not sure if this is the sort of thing the linaro-wg has in mind? I'm not sure what the the linaro multimedia wg thinks of this, but the kernel code you linked looks like it's doing exactly the right thing. Arnd ___ 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: [linaro-android][PATCH 1/1] Add virtual battery driver
Thanks john. I recreate the patch. I'll post again. Regards, Akihiro ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
