about n810 integration status
Hi everyone, Does anybody knows about n810 integration status on Kernel? I have one n810, and I try to update the newest kernel and filesystem image freely. And, if anyone know about , please let me know. The information which I know is just the flasher from Nokia is needed for updating. And, I can compile kernel and handle a litte. Any clues about this are welcome. Thanks! Regards, Heungjun Kim-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] USB: OTG: Use work_queue in set_vbus for TWL6030 transciever
On Fri, Jun 24, 2011 at 10:14:03AM -0500, Moiz Sonasath wrote: ... + if (enabled) + twl-vbus_enable = 1; + else + twl-vbus_enable = 0; + Suggest twl-vbus_enable = enabled; /* * Start driving VBUS. Set OPA_MODE bit in CHARGERUSB_CTRL1 * register. This enables boost mode. */ - if (enabled) - twl6030_writeb(twl, TWL_MODULE_MAIN_CHARGE , 0x40, - CHARGERUSB_CTRL1); - else - twl6030_writeb(twl, TWL_MODULE_MAIN_CHARGE , 0x00, - CHARGERUSB_CTRL1); + + schedule_work(twl-set_vbus_work); + Suggest also moving the comments together with the new location of the code to write CHARGERUSB_CTRL1. Add a cancel_work_sync(twl-set_vbus_work) at twl6030_usb_remove(), prior to kfree(twl). -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. What's the reason for switching away from gptimer12? Nothing in your patch or changelog says why.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 9/9] OMAP2+: cpuidle only influences the MPU state
On 6/24/2011 7:38 AM, jean.pi...@newoldbits.com wrote:
From: Jean Pihetj-pi...@ti.com
Since cpuidle is a CPU centric framework it decides the MPU
next power state based on the MPU exit_latency and target_residency
figures.
The rest of the power domains get their next power state programmed
from the PM_QOS_DEV_WAKEUP_LATENCY class of the PM QoS framework,
via the device wake-up latency constraints.
Note: the exit_latency and target_residency figures of the MPU
include the MPU itself and the peripherals needed for the MPU to
execute instructions (e.g. main memory, caches, IRQ controller,
MMU etc). Some of those peripherals can belong to other power domains
than the MPU subsystem and so the corresponding latencies must be
included in this figure.
With above comment, I was expecting that the latency numbers
in the table will change.
Tested on OMAP3 Beagleboard in RET/OFF using wake-up latency constraints
on MPU, CORE and PER.
Signed-off-by: Jean Pihetj-pi...@ti.com
---
arch/arm/mach-omap2/cpuidle34xx.c | 42 +++-
1 files changed, 13 insertions(+), 29 deletions(-)
diff --git a/arch/arm/mach-omap2/cpuidle34xx.c
b/arch/arm/mach-omap2/cpuidle34xx.c
index 4bf6e6e..b43d1d2 100644
--- a/arch/arm/mach-omap2/cpuidle34xx.c
+++ b/arch/arm/mach-omap2/cpuidle34xx.c
@@ -37,26 +37,26 @@
#ifdef CONFIG_CPU_IDLE
/*
- * The latencies/thresholds for various C states have
+ * The MPU latencies/thresholds for various C states have
* to be configured from the respective board files.
* These are some default values (which might not provide
* the best power savings) used on boards which do not
* pass these details from the board file.
*/
static struct cpuidle_params cpuidle_params_table[] = {
- /* C1 */
+ /* C1 . MPU WFI + Core active */
{2 + 2, 5, 1},
- /* C2 */
+ /* C2 . MPU WFI + Core inactive */
{10 + 10, 30, 1},
- /* C3 */
+ /* C3 . MPU CSWR + Core inactive */
{50 + 50, 300, 1},
- /* C4 */
+ /* C4 . MPU OFF + Core inactive */
{1500 + 1800, 4000, 1},
- /* C5 */
+ /* C5 . MPU RET + Core RET */
{2500 + 7500, 12000, 1},
- /* C6 */
+ /* C6 . MPU OFF + Core RET */
{3000 + 8500, 15000, 1},
- /* C7 */
+ /* C7 . MPU OFF + Core OFF */
{1 + 3, 30, 1},
Latency numbers still seems to include CORE PD latency as
well. Am I missing something Jean?
Regards
Santosh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
Hi, On Friday, June 24, 2011, Paul Walmsley wrote: (Arve cc'ed, also adding Magnus and Kevin back to cc) Thanks, my mailer is playing tricks on me. :-) Hi Rafael, On Thu, 23 Jun 2011, Rafael J. Wysocki wrote: On Thursday, June 23, 2011, Alan Stern wrote: On Thu, 23 Jun 2011, Paul Walmsley wrote: On Wed, 15 Jun 2011, Rafael J. Wysocki wrote: Well, the freezing of user space by itself doesn't buy you anything power management-wise, you pretty much need to do the other things too to really save energy this way. Freezing user space stops CPU-hogging processes from running. When the runqueue is empty, the scheduler can go idle. This in turn allows the CPU(s) to enter low power sleep states via CPUIdle. But you don't have to freeze user space for this purpose, do you? You may simply send a SIGSTOP to those processes. Probably that would be useful for some use-cases. there are two issues with SIGSTOP/SIGCONT that I'm aware of, compared to freezing: 1. if sent from a userspace process, SIGSTOP/SIGCONT are potentially racy with respect to system calls like setsid(), such that the sender may miss some processes; I must admit I don't know the details here, but that sounds quite plausible. 2. SIGSTOP/SIGCONT are observable, so could cause side-effects: see for example http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cgroups/freezer-subsystem.txt;h=c21d77742a0799424b09466857681ddcc7100f8b;hb=HEAD#l19 That's correct, but on the other hand some user space processes want to be notified that they're going to be frozen (like NetworkManager, although it probably wants that because of the suspend that's going to happen next). My point here is that being observable need not be a bad thing, depending on the viewpoint. As I understand it, this is really the basis for the modern Android use-case for wakelocks and opportunistic suspend. They prevent non-power-privileged userspace applications from keeping the system from entering a low-power state. (Secondarily, suspend also prevents kernel code from running, e.g., timers set by filesystems, the networking stack, etc.; but problems here should be fixed in the offending kernel code, rather than hacked around, since some of the users of those timers could be important) I think you have oversimplified things a little, but never mind... Well, saying a little is an overstatement. :-) What parts do you feel were oversimplified? In fact, there are several things that wakelocks are being used for, including the one you have mentioned, but also: * Idleness detection (meaning whole system idleness). * Detection of races between system suspend and wakeup events. * Collecting wakeup events statistics (useful for detection of misbehaving applications). The system idleness detection mechanism probably makes the most of the difference between Android and other Linux-based systems PM-wise. This was given as one of the arguments why using the wakelocks mechanism along with the opportunistic suspend might be regarded as a good idea, but I think the _real_ reason why it is used by Android is that the system suspend framework was usable already when Android was being developed and if they wanted to get acceptable battery lives at that time, they simply had no choice but to use it. This is why modern was written in the original text: to contrast with the historical rationale for suspend blockers. As I understand it, in the original Android implementation, the hardware that they were using didn't have fine-grained power management. So system-wide suspend made more sense in that context. But that shouldn't be confused with the modern rationale for wakelocks: https://lists.linux-foundation.org/pipermail/linux-pm/2010-May/025668.html On the hardware that shipped we enter the same power state from idle and suspend, so the only power savings we get from suspend that we don't get in idle is from not respecting the scheduler and timers. There is a point in that, because timers wake up the CPU from low-power states entered through CPUuidle. Anyway, I don't quite get your point overall in the ongoing discussion. I'd like to understand it, so we know we're talking about the same things. :-) You seem to be making a point for not supporting system suspend. That may mean two different things, though. First, you may be trying to say that system suspend is a bad idea in general and it shouldn't be supported at all. That I strongly disagree with, because there are platforms where it is the only effective way of saving energy on systems that are not in use, but should become available quickly if necessary. Moreover, there are systems where system suspend makes it possible to save more energy than CPUidle and runtime PM combined. Second, your point may be that for
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Hilman, Kevin Sent: Saturday, June 25, 2011 1:44 AM To: Russell King - ARM Linux Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Russell King - ARM Linux li...@arm.linux.org.uk writes: On Fri, Jun 24, 2011 at 11:20:44PM +0530, Premi, Sanjeev wrote: I was able to test BogoMIPS calculations via /proc/cpuinfo for both with without CONFIG_SMP selected. For most part things work fine - but I do notice occassional Oops and segmentation faults while doing cat /proc/cpuinfo With CONFIG_SMP enabled, system doesn't recover from the Oops; but without SMP - I noticed segmentation faults/ BUG but system does recover. They could be unrelated - but i didn't see any of these earlier today. I will continue debug on MON. I don't think these are related to the patch - I think there's something up with your hardware. Let's take the first. [root@OMAP3EVM cpufreq]# cat /proc/cpuinfo [ 73.832366] Internal error: Oops - undefined instruction: 0 [#1] SMP Ok an undefined instruction. So... [ 73.839019] Modules linked in: [ 73.842193] CPU: 0Not tainted (3.0.0-rc3-14002-g40b6752-dirty #21) [ 73.849121] PC is at __do_fault+0x1c0/0x450 [ 73.853485] LR is at __do_fault+0x2b0/0x450 [ 73.857879] pc : [c010fa18]lr : [c010fb08] psr: 0113 [ 73.857879] sp : c7907d48 ip : fp : c5d518c0 [ 73.869873] r10: 0200 r9 : 40214000 r8 : [ 73.875335] r7 : c2692f98 r6 : c0ad7600 r5 : 87fb018f r4 : [ 73.882141] r3 : 87fb0a3e r2 : 0800 r1 : 87fb01cf r0 : c5d518c0 [ 73.888977] Flags: nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 73.896423] Control: 10c5387d Table: 8795c019 DAC: 0015 [ 73.902435] Process cat (pid: 449, stack limit = 0xc79062f8) ... lets look at the code line: [ 74.176879] Code: e1a01005 e3a02000 ebfd1694 e59d0014 (eb07fcba) and disassemble it: 0: e1a01005mov r1, r5 4: e3a02000mov r2, #0 ; 0x0 8: ebfd1694bl 0xfff45a60 c: e59d0014ldr r0, [sp, #20] 10: eb07fcbabl 0x1ff300 There is no way that 0xeb07fcba should ever cause an undefined ARM instruction on a properly functioning system. It points at a hardware problem - are you using a socketed SoC? Is it properly socketed? Is the socket dirty? And all other questions related to hardware integrity... And in particular, since we're talking CPUfreq, are you running at a frequency that the SoC and especially the memory support? Yes. the frequencies are 300 - 800MHz range. The same board is also quite stable for 1GHz operations (tested ARM only) - with sources hosted at: http://arago-project.org/git/projects/?p=linux-omap3.git;a=summary For testing, I was changing frequencies in a tight 'forever' loop. But, as I mentioned earlier that issues could be unrelated. And the loop could be exposing something else. ~sanjeev Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Saturday, June 25, 2011 1:47 PM To: linux-omap@vger.kernel.org List Cc: linux-arm-kernel; Paul Walmsley Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. After few days of debug GPTIMER12 came to be only difference. Tracing GPTIMER12 in the spec proved quite a challenge; the as timer is not included in the TRM and corresponding interrupt is marked reserved. Paul (in cc:) obviously had access to documents that we don't. This patch is merely trying to bring parity in use of GPTIMER across OMAP3 boards (AND use documented IP) - taking note of many Beagleboards where current code is necessary. ~sanjeev -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation
-Original Message- From: Shilimkar, Santosh Sent: Saturday, June 25, 2011 12:18 AM To: Russell King - ARM Linux Cc: Premi, Sanjeev; linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Hilman, Kevin Subject: Re: [PATCHv2] omap2+: pm: cpufreq: Fix loops_per_jiffy calculation Russell, On 6/24/2011 8:12 AM, Russell King - ARM Linux wrote: Right, thanks for the file. Here's the patch. [.] Notice how we adjust _both_ the per-cpu loops_per_jiffy, and that we adjust them with reference to the initial values. If you adjust lpj with reference to the last, then you _will_ build up a progressively bigger and bigger error in the value over time. Thanks Russell for the change. This change should fix the global lpj for UP machine as well when build with SMP_ON_UP. Can you have a look at below complete change which should make the BOGOMIPS happy on all OMAP2PLUS machines. Generated against Kevin's cpufreq branch. url = git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-om ap-pm.git pm-wip/cpufreq. Just compile tested with UP and SMP OMAP builds. After your review, I can give a test. Regards Santosh From 9a6154c0f68e39c4d1fbc4ef3fef5ce577ba87d4 Mon Sep 17 00:00:00 2001 From: Russell King rmk+ker...@arm.linux.org.uk Date: Fri, 24 Jun 2011 10:51:17 -0700 Subject: [PATCH] OMAP2+: CPUfreq: update lpj with refernce value to avoid progressive error. Adjust _both_ the per-cpu loops_per_jiffy and global lpj. Calibrate them with with reference to the initial values to avoid a progressively bigger and bigger error in the value over time. While at this also re-use the notifiers for UP/SMP since on UP machine or UP_ON_SMP policy-cpus mask would contain only the one CPU. Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com [santosh.shilim...@ti.com: rebased against omap cpufreq upstream branch] Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Kevin Hilman khil...@ti.com [sp] I thought we were solving a problem - but this makes it look like race for addding sign-offs - which I am not interested in. [snip]...[snip] -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-pm] Runtime PM discussion notes
On Fri, 24 Jun 2011, Paul Walmsley wrote: But suspend users don't know this either, since they can't predict when the next external wakeup can happen. But they do know (or should know) that they don't intend to use the system in the near future. It might be good to have a separate way to express that idea to the kernel. Are you thinking of the current userspace interfaces to suspend, or something else? I'm not thinking of anything in particular. Just brainstorming... If somebody decides to freeze userspace without putting the entire system to sleep, how will they know when to unfreeze? A certain amount of specialized kernel/userspace interaction would be needed. 1. preventing userspace processes from keeping the system from entering idle 2. preventing userspace processes from waking the system back up It's not clear what this means. How can a user process wake the system up? Are you referring to user timers? Yes. Then those two are almost the same thing. It doesn't seem to make much sense to say I want to stop these processes from running now, but allow them to run if one of them gets a timer or I/O signal. 3. preventing kernel code from keeping the system from entering idle Relatively few kernel threads are freezable. The ones that are tend to be involved in device management. Did you have something specific in mind? No, nothing specific. 4. preventing kernel code from waking the system back up Once userspace is inactive, the kernel probably doesn't have very much to do. Responding to some network packets, maybe, if the network interfaces are left running (like a router but without support for dynamic routing protocols). In general, I don't think a system could do a whole lot of useful work in such a state. 5. requesting that drivers abort what they are currently doing Not exactly abort. More like stop processing their I/O queues. Yes, that's a better way of putting it; hopefully most drivers are doing that. This is more of a transition issue than a steady-state concern. When userspace is frozen, it can't generate new I/O requests. If the old ones were left to terminate normally, pretty soon the I/O queues would drain by themselves. In short, I'm not sure how these ideas would yield anything new and worthwhile. Maybe I'm just slow today... Alan Stern -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Saturday, June 25, 2011 1:47 PM To: linux-omap@vger.kernel.org List Cc: linux-arm-kernel; Paul Walmsley Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. After few days of debug GPTIMER12 came to be only difference. Tracing GPTIMER12 in the spec proved quite a challenge; the as timer is not included in the TRM and corresponding interrupt is marked reserved. Paul (in cc:) obviously had access to documents that we don't. This patch is merely trying to bring parity in use of GPTIMER across OMAP3 boards (AND use documented IP) - taking note of many Beagleboards where current code is necessary. I get a value of 1010 ±10 bogoMIPS consistently with .39 + dvfs patches. Having said that, this patch does seem to be an improvement, but has it actually been tested on real beagleboard hardware with a recent kernel? Especially on the boards affected by the capacitor issue on the external clock.-- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
On Sun, 26 Jun 2011, Premi, Sanjeev wrote: [sp] I didn't include a reason - because the problem may not be reproducible on the public trees. During tests performed in internal development trees, the BogoMIPS calculations @ 1GHz wouldn't go beyond 830-850 range. While there was no such inconsistency on OMAP3EVM. There are some other reasons to avoid GPTIMER12 when possible, which you should probably put in the patch description. The most important, in my view, is that the clock source for GPTIMER12 is much less frequency-stable than the clock sources for GPTIMER1. So using GPTIMER12 can result in major time skew over a fairly short interval. I've been meaning to send a patch like this for some time, so I'm happy to see this fixed. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
On Fri, 24 Jun 2011, Sanjeev Premi wrote: The current selection of the GPTIMER on was result of a hardware issue in early versions of the Beagleboards (Ax and B1 thru B4). [1] [2] Its been long since the hardware issue has been fixed. This patch uses GPTIMER 1 for all newer board revisions incl. Beagleboard XM. [1] http://thread.gmane.org/gmane.comp.hardware.beagleboard.general/91 [2] Errata #7 at http://elinux.org/BeagleBoard#Errata Signed-off-by: Sanjeev Premi pr...@ti.com Cc: Paul Walmsley p...@pwsan.com Reviewed-by: Paul Walmsley p...@pwsan.com * Browsing through the code, it appears that similar change could be applied for these boards: - devkit8000 - omap3stalker - omap3touchbook However, I don't have access to any of these; or information on their revisions. I can update this patch based on confirmations. You might want to send an E-mail to the people who are listed as authors in git for these boards. Otherwise they will probably miss it in the onslaught of mailing list traffic. Unless the PCB designs are based on A or B revisions of the BeagleBoard, it should be safe for them to switch to GPTIMER1. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/8] Introducing a generic AMP/IPC framework
Hi Stephen, On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote: This sounds a lot like SMD (shared memory driver) on MSM. The main difference I see is that SMD uses the platform bus instead of the virtio bus and it has its own protocol for channel allocation. Yeah, virtio is a key factor in this work; it was suggested to us by Arnd at the AMP plumbers discussions last year, where it was apparent that many vendors have their own IPC drivers/buses/channels over shared memory with some vendor-ish binary protocol. I must say we really liked virtio: it considerably simplified the code (we're not adding any new binary protocol), it's very nicely optimized and flexible, and it comes with a set of virtio drivers (e.g. network, console, block) so we don't have to write our own. We also cared about adding this functionality as an IPC bus, so the driver core will help matching drivers to channels - it simplified the code (in both setup and tear down of channels) and kept it flexible. It will also facilitate error recovery (on remote crash, we just remove the virtio device, and then the driver core will in turn start -remove()ing the rpmsg drivers) and power management (via runtime PM). About SMD: I'm not familiar with it too much, but Brian naturally is (just for the sake of everyone who are not reading headers - Brian Swetland wrote the Linux SMD driver, and is also an author of this Google+TI joint work). Btw, I'm sure SMD is conceptually not MSM-specific, and have wondered whether you guys would like to use rpmsg/virtio (I know you have several drivers like network/tty/etc over SMD, somewhat similarly to virtio). Probably the biggest reason why not to is the pain in changing the binary protocol with the modem/dsp side. If you ever do think about it, I'd be happy to work with you to make it happen. This remote proc code is eerily similar to PIL (peripheral image loader, yes we love our acronyms) which I posted a few months back[1]. Was it inspiration for this patch series? No, we weren't (or at least I wasn't) aware of PIL. In terms of API, s/pil/rproc/ and it would be 95% identical. There are some low-level differences though (see below). Indeed, eerily similar :O I just guess the API is so simple that probably most kernel hackers would use refcounting get/put semantics here. This is an important difference between remote proc and PIL. In PIL, we do image authentication in addition to processor boot. Yes, we have this too (secure code will need to authenticate the image in some use cases) - but that's not ready yet for submission and we decided to start off with the basics first and then evolve. Instead of devising a new firmware format, we decided to just stick with elf and parse the headers in the kernel because we needed them for authentication anyway. Is this reason enough to move to an ELF format instead? I think that consolidation of code is enough reason to make an effort. I know that our firmware format was chosen for simplicity, but I'm not sure if we have the tools yet to build standard ELF files for the remote processors (IIRC it's in the works though). I'll let Mark comment this one. Another difference is inter-processor dependencies. For example, on msm8660 the modem can't boot until the dsp has been booted. I suppose we could hide this detail in the platform specific get() implementation by calling rproc_get() on the dependent processor (hopefully no locking issues arise). I'd rather have it built into the core though as it isn't really specific to the hardware. No problems, I'm sure we can solve this one easily. If we can resolve these differences I think we can easily support remote processor boot on MSM via remoteproc. That'd be very cool, I sure do hope we can work together. Thanks for your comments ! Ohad. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/8] Introducing a generic AMP/IPC framework
On Sat, Jun 25, 2011 at 6:11 PM, Ohad Ben-Cohen o...@wizery.com wrote: Hi Stephen, On Fri, Jun 24, 2011 at 11:16 PM, Stephen Boyd sb...@codeaurora.org wrote: This sounds a lot like SMD (shared memory driver) on MSM. The main difference I see is that SMD uses the platform bus instead of the virtio bus and it has its own protocol for channel allocation. Yeah, virtio is a key factor in this work; it was suggested to us by Arnd at the AMP plumbers discussions last year, where it was apparent that many vendors have their own IPC drivers/buses/channels over shared memory with some vendor-ish binary protocol. I must say we really liked virtio: it considerably simplified the code (we're not adding any new binary protocol), it's very nicely optimized and flexible, and it comes with a set of virtio drivers (e.g. network, console, block) so we don't have to write our own. We also cared about adding this functionality as an IPC bus, so the driver core will help matching drivers to channels - it simplified the code (in both setup and tear down of channels) and kept it flexible. It will also facilitate error recovery (on remote crash, we just remove the virtio device, and then the driver core will in turn start -remove()ing the rpmsg drivers) and power management (via runtime PM). About SMD: I'm not familiar with it too much, but Brian naturally is (just for the sake of everyone who are not reading headers - Brian Swetland wrote the Linux SMD driver, and is also an author of this Google+TI joint work). rpmsg definitely shares some design features with SMD (given that I wrote the linux SMD driver and was involved in the design of rpmsg, this is maybe unsurprising), but whereas in SMD we had to be compatible with existing AMSS modems (to a degree), we had more flexibility in the wire protocol on rpmsg and virtio looked like a really nice fit that already was in the kernel. Ohad had a number of great ideas for making the dynamic discovery, publishing, and binding of remote services very clean and straightforward -- I wish I had a chance to pick his brain about this stuff back when building the SMD interfaces, which started out fairly static, but then evolved into publishing platform devices, etc. Of course some of this is the benefit of hindsight. It's easier to get it right (er?) the second or third time around. The TI SYS/BIOS folks were quite helpful and patient as we redesigned the wire protocol and publishing/resource model several times along the way here. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
