[PATCH 0/2] MMC Agressive clocking framework v2
ChangeLog v1-v2: * Switch the gating mechanism from using an additional callback to setting the clock field in the ios structure to 0 and storing away the current value to ungate the clock later on. * Remove the mmc_clk_enable/disable around the ios() operations as a result, if you use clock gating you have to take the gating into account in your set_ios() code. * Keep the nesting code (use count) this is used so that quick bursts of requests can be handled properly while the disable work is idling in the background and appears quite solid. Tried my best to clarify why this code look as it does. * Removed unnecessary depend on MMC!=n in the Kconfig, explicit (EXPERIMENTAL) in option description. * Updates MMCI reference implementation to reflect the new use of the clock field. * Remove unnecessary #include clk.h * Added a debugfs file appearing in /mmcN/clk_delay that can be used to trim the delay cycle count to test what happens with different values. * Works fine on my system. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] MMC Agressive clocking framework v2
This patch modified the MMC core code to optionally call the
set_ios() operation on the driver with the clock frequency set
to 0 to gate the hardware block clock (and thus the MCI clock)
for an MMC host controller after a grace period of at least 8
MCLK cycles. It is inspired by existing clock gating code found
in the OMAP and Atmel drivers and brings this up to the host
abstraction. Gating is performed before and after any MMC request
or IOS operation, the other optional host operations will not
ungate/gate the clock since they do not necessary touch the
actual host controller hardware.
It exemplifies by implementing this for the MMCI/PL180 MMC/SD
host controller, but it should be simple to switch OMAP and
Atmel over to using this instead.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/core/Kconfig | 11 +++
drivers/mmc/core/core.c| 38 +++
drivers/mmc/core/core.h|2 +
drivers/mmc/core/debugfs.c | 10 ++-
drivers/mmc/core/host.c| 160 +++-
drivers/mmc/core/host.h|3 +
include/linux/mmc/host.h |9 +++
7 files changed, 230 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index ab37a6d..6ae2156 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -14,3 +14,14 @@ config MMC_UNSAFE_RESUME
This option is usually just for embedded systems which use
a MMC/SD card for rootfs. Most people should say N here.
+config MMC_CLKGATE
+ bool MMC host clock gaing (EXPERIMENTAL)
+ depends on EXPERIMENTAL
+ help
+ This will attempt to agressively gate the clock to the MMC host,
+ which typically also will gate the MCI clock to the card. This
+ is done to save power due to gating off the logic and bus noise
+ when MMC is not in use. Your host driver has to support this in
+ order for it to be of any use.
+
+ Of unsure, say N.
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 2649117..c64dfe2 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -113,6 +113,8 @@ void mmc_request_done(struct mmc_host *host,
struct mmc_request *mrq)
if (mrq-done)
mrq-done(mrq);
+
+ mmc_clk_disable(host);
}
}
@@ -173,6 +175,7 @@ mmc_start_request(struct mmc_host *host, struct
mmc_request *mrq)
mrq-stop-mrq = mrq;
}
}
+ mmc_clk_enable(host);
host-ops-request(host, mrq);
}
@@ -447,6 +450,39 @@ void mmc_set_clock(struct mmc_host *host, unsigned int hz)
mmc_set_ios(host);
}
+#ifdef CONFIG_MMC_CLKGATE
+/*
+ * This gates the clock by setting it to 0 Hz.
+ */
+void mmc_gate_clock(struct mmc_host *host)
+{
+ host-clk_old = host-ios.clock;
+ host-ios.clock = 0;
+ mmc_set_ios(host);
+}
+
+/*
+ * This restores the clock from gating by using the cached
+ * clock value.
+ */
+void mmc_ungate_clock(struct mmc_host *host)
+{
+ /*
+* We have gated previously so the clock
+* shall be 0 here!
+*/
+ BUG_ON(host-ios.clock);
+ /*
+* The clock may however be 0 during intialization,
+* when some request operations are performed before setting
+* the frequency. When ungate is requested in that situation
+* we just ignore the call.
+*/
+ if (host-clk_old)
+ mmc_set_clock(host, host-clk_old);
+}
+#endif
+
/*
* Change the bus mode (open drain/push-pull) of a host.
*/
@@ -861,6 +897,7 @@ void mmc_rescan(struct work_struct *work)
* release the lock here.
*/
mmc_bus_put(host);
+ mmc_clk_enable(host);
if (host-ops-get_cd host-ops-get_cd(host) == 0)
goto out;
@@ -911,6 +948,7 @@ void mmc_rescan(struct work_struct *work)
mmc_bus_put(host);
}
out:
+ mmc_clk_disable(host);
if (host-caps MMC_CAP_NEEDS_POLL)
mmc_schedule_delayed_work(host-detect, HZ);
}
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index c819eff..ee27f81 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -27,6 +27,8 @@ void mmc_detach_bus(struct mmc_host *host);
void mmc_set_chip_select(struct mmc_host *host, int mode);
void mmc_set_clock(struct mmc_host *host, unsigned int hz);
+void mmc_gate_clock(struct mmc_host *host);
+void mmc_ungate_clock(struct mmc_host *host);
void mmc_set_bus_mode(struct mmc_host *host, unsigned int mode);
void mmc_set_bus_width(struct mmc_host *host, unsigned int width);
u32 mmc_select_voltage(struct mmc_host *host, u32 ocr);
diff --git a/drivers/mmc/core/debugfs.c b/drivers/mmc/core/debugfs.c
index 610dbd1..1a969bd 100644
--- a/drivers/mmc/core/debugfs.c
+++ b/drivers/mmc/core/debugfs.c
@@ -149,11 +149,17 @@ void
[PATCH 2/2] Modify MMCI/PL180 to handle agressive clocking v2
This adds a few clk_enable()/clk_disable() calls to the MMCI
driver so as to handle an set_ios() request with clock
frequency set to 0 as an instruction to gate the block clock.
This also breaks out the clock setting code into its own
function to simplify the set_ios() function a bit.
Signed-off-by: Linus Walleij linus.wall...@stericsson.com
---
drivers/mmc/host/mmci.c | 78 ++
1 files changed, 57 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 36875dc..d9f5c9a 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -37,8 +37,34 @@
static unsigned int fmax = 515633;
+/*
+ * This must be called with host-lock held
+ */
+static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
+{
+ u32 clk = 0;
+
+ if (desired) {
+ if (desired = host-mclk) {
+ clk = MCI_CLK_BYPASS;
+ host-cclk = host-mclk;
+ DBG(host, MMCI: bypass clock divider, cclk = %u Hz\n,
host-cclk);
+ } else {
+ clk = host-mclk / (2 * desired) - 1;
+ if (clk = 256)
+ clk = 255;
+ host-cclk = host-mclk / (2 * (clk + 1));
+ DBG(host, MMCI: divide cclk to %u Hz (divide %u by
%u)\n,
host-cclk, host-mclk, clk);
+ }
+ if (host-hw_designer == 0x80)
+ clk |= MCI_FCEN; /* Bug fix in ST IP block */
+ clk |= MCI_CLK_ENABLE;
+ }
+ writel(clk, host-base + MMCICLOCK);
+}
+
static void
-mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
+ mmci_request_end(struct mmci_host *host, struct mmc_request *mrq)
{
writel(0, host-base + MMCICOMMAND);
@@ -418,22 +444,7 @@ static void mmci_request(struct mmc_host *mmc,
struct mmc_request *mrq)
static void mmci_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
{
struct mmci_host *host = mmc_priv(mmc);
- u32 clk = 0, pwr = 0;
-
- if (ios-clock) {
- if (ios-clock = host-mclk) {
- clk = MCI_CLK_BYPASS;
- host-cclk = host-mclk;
- } else {
- clk = host-mclk / (2 * ios-clock) - 1;
- if (clk = 256)
- clk = 255;
- host-cclk = host-mclk / (2 * (clk + 1));
- }
- if (host-hw_designer == 0x80)
- clk |= MCI_FCEN; /* Bug fix in ST IP block */
- clk |= MCI_CLK_ENABLE;
- }
+ u32 pwr = 0;
if (host-plat-translate_vdd)
pwr |= host-plat-translate_vdd(mmc_dev(mmc), ios-vdd);
@@ -464,12 +475,23 @@ static void mmci_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
}
}
- writel(clk, host-base + MMCICLOCK);
+ spin_lock(host-lock);
+
+ if (ios-clock == 0) {
+ clk_disable(host-clk);
+ } else {
+ clk_enable(host-clk);
+ mmci_set_clkreg(host, ios-clock);
+ }
if (host-pwr != pwr) {
host-pwr = pwr;
+ clk_enable(host-clk);
writel(pwr, host-base + MMCIPOWER);
+ clk_disable(host-clk);
}
+
+ spin_unlock(host-lock);
}
static const struct mmc_host_ops mmci_ops = {
@@ -615,6 +637,8 @@ static int __devinit mmci_probe(struct amba_device
*dev, void *id)
host-timer.expires = jiffies + HZ;
add_timer(host-timer);
+ /* The first IOS will turn the clock on again */
+ clk_disable(host-clk);
return 0;
irq0_free:
@@ -646,17 +670,22 @@ static int __devexit mmci_remove(struct amba_device *dev)
mmc_remove_host(mmc);
+ /* framework may have gated the block clock */
+ clk_enable(host-clk);
+
writel(0, host-base + MMCIMASK0);
writel(0, host-base + MMCIMASK1);
writel(0, host-base + MMCICOMMAND);
writel(0, host-base + MMCIDATACTRL);
+ clk_disable(host-clk);
+
free_irq(dev-irq[0], host);
free_irq(dev-irq[1], host);
iounmap(host-base);
- clk_disable(host-clk);
+
clk_put(host-clk);
mmc_free_host(mmc);
@@ -677,8 +706,11 @@ static int mmci_suspend(struct amba_device *dev,
pm_message_t state)
struct mmci_host *host = mmc_priv(mmc);
ret = mmc_suspend_host(mmc, state);
- if (ret == 0)
+ if (ret == 0) {
+ clk_enable(host-clk);
writel(0, host-base + MMCIMASK0);
+ clk_disable(host-clk);
+ }
}
return ret;
@@ -692,7 +724,11 @@ static int mmci_resume(struct
[PATCH] Cgroup: add cgroup members's exit data statistics
From: Marco Stornelli marco.storne...@gmail.com
This patch adds the possibility for an application to receive statistics
information only
for processes belonging to a cgroup. The mechanism is the same of the cpu's
exit data statistics.
With this patch, instead of waiting on a specific cpumask, an application can
wait for
exit data on a specific container. Through this patch it's possible to have a
simple death
notifier mechanism. We can select the processes to watch and wait for their
death.
A death notify mechanism is especially useful for embedded systems.
Signed-off-by: Marco Stornelli marco.storne...@gmail.com
---
diff -uprN linux-2.6.29-orig/Documentation/accounting/getdelays.c
linux-2.6.29/Documentation/accounting/getdelays.c
--- linux-2.6.29-orig/Documentation/accounting/getdelays.c 2009-03-24
00:12:14.0 +0100
+++ linux-2.6.29/Documentation/accounting/getdelays.c 2009-06-02
15:47:01.0 +0200
@@ -77,9 +77,11 @@ static void usage(void)
[-m cpumask] [-t tgid] [-p pid]\n);
fprintf(stderr, -d: print delayacct stats\n);
fprintf(stderr, -i: print IO accounting (works only with -p)\n);
+ fprintf(stderr, -q: print context switch accounting\n);
fprintf(stderr, -l: listen forever\n);
fprintf(stderr, -v: debug on\n);
- fprintf(stderr, -C: container path\n);
+ fprintf(stderr, -C: container path (container statistics)\n);
+ fprintf(stderr, -N: container path (death notify)\n);
}
/*
@@ -263,13 +265,14 @@ int main(int argc, char *argv[])
char *logfile = NULL;
int loop = 0;
int containerset = 0;
+ int containernotify = 0;
char containerpath[1024];
int cfd = 0;
struct msgtemplate msg;
while (1) {
- c = getopt(argc, argv, qdiw:r:m:t:p:vlC:);
+ c = getopt(argc, argv, qdiw:r:m:t:p:vlC:N:);
if (c 0)
break;
@@ -290,6 +293,10 @@ int main(int argc, char *argv[])
containerset = 1;
strncpy(containerpath, optarg, strlen(optarg) + 1);
break;
+ case 'N':
+ containernotify = 1;
+ strncpy(containerpath, optarg, strlen(optarg) + 1);
+ break;
case 'w':
logfile = strdup(optarg);
printf(write to file %s\n, logfile);
@@ -364,8 +371,13 @@ int main(int argc, char *argv[])
}
}
- if (tid containerset) {
- fprintf(stderr, Select either -t or -C, not both\n);
+ if (tid (containerset || containernotify)) {
+ fprintf(stderr, Select either -t or -C or -N\n);
+ goto err;
+ }
+
+ if (containerset containernotify) {
+ fprintf(stderr, Select either -C or -N, not both\n);
goto err;
}
@@ -392,7 +404,23 @@ int main(int argc, char *argv[])
goto err;
}
}
- if (!maskset !tid !containerset) {
+
+ if (containernotify) {
+ cfd = open(containerpath, O_RDONLY);
+ if (cfd 0) {
+ perror(error opening container file);
+ goto err;
+ }
+ rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET,
+ CGROUPSTATS_CMD_ATTR_REGISTER_FD,
+ cfd, sizeof(__u32));
+ if (rc 0) {
+ perror(error sending cgroupstats command);
+ goto err;
+ }
+ }
+
+ if (!maskset !tid !containerset !containernotify) {
usage();
goto err;
}
@@ -400,6 +428,7 @@ int main(int argc, char *argv[])
do {
int i;
+ PRINTF(Recv...\n);
rep_len = recv(nl_sd, msg, sizeof(msg), 0);
PRINTF(received %d bytes\n, rep_len);
@@ -495,6 +524,14 @@ done:
if (rc 0)
err(rc, error sending deregister cpumask\n);
}
+ if (containernotify) {
+ rc = send_cmd(nl_sd, id, mypid, CGROUPSTATS_CMD_GET,
+ CGROUPSTATS_CMD_ATTR_DEREGISTER_FD,
+ cfd, sizeof(__u32));
+ printf(Sent deregister container, retval %d\n, rc);
+ if (rc 0)
+ err(rc, error sending deregister container\n);
+ }
err:
close(nl_sd);
if (fd)
--- linux-2.6.29-orig/kernel/taskstats.c2009-03-24 00:12:14.0
+0100
+++ linux-2.6.29/kernel/taskstats.c 2009-06-02 15:54:37.0 +0200
@@ -56,6 +56,8 @@ __read_mostly = {
static struct nla_policy
cgroupstats_cmd_get_policy[CGROUPSTATS_CMD_ATTR_MAX+1] __read_mostly = {
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org Hi James, One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ie. On x86, PowerPC and Sparc a kernel image will boot on any machine (assuming the needed drivers are enabled), but this is rarely the case in embedded. Most embedded kernels require explicit board support selected at compile time with no way to produce a generic kernel which will boot on a whole family of devices, let alone the whole architecture. Part of this is a firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. Cheers, g. On Thu, May 28, 2009 at 5:41 PM, Josh Boyer jwbo...@linux.vnet.ibm.com wrote: Not to hijack this entirely, but I'm wondering if we could tie in some of the cross-arch device tree discussions that have been taking place among the ppc, sparc, and arm developers. I know the existing OF code for ppc, sparc, and microblaze could probably use some consolidation and getting some of the arch maintainers together in a room might prove fruitful. Particularly if we are going to discuss how to make drivers work for device tree and standard platforms alike. josh -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 03:22:20PM +, James Bottomley wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org For those not following the ksummit list, below is the current list of suggested topics: PROPOSERTOPIC Jon Corbet How much do we owe sloppy application writers Jon Corbet The containers end game and how we get there Balbir SinghThe Hacking Hour Rafael Wysocki Regression tracking and kernel quality Jon Corbet Criteria for acceptance of kernel tracepoints Jesse BarnesProfiling and performance counters Eric Biederman Procedures for dealing with patent problems John Linville Patch review checklist Matthew Wilcox How to handle style-only patches Dan WilliamsRAID unification / stacked block devices Jiri Kosina User-space drivers - worth encouraging? Sam RavnborgShipping user-space components in the kernel Kay Sievers Establishment/maintenance of per-subsystem todo lists Steve Rostedt Improving changelogs Jon Corbet I/O bandwidth controllers (maybe minisummit report) Ted Ts'oPulseAudio and kernel interface issues Greg KH Generic architecture support and arch layer cleanup (Josh Boyer: add device tree discussion?) Dave Jones cpumasks, churn, and unending API changes Dirk HohndelIssues related to wireless technologies Jon Corbet Tracing: Merging utrace Ftrace mainline v. private debugging tools Non-ftrace visibility infrastructure Systemtap for kernel developers Marcel Holtmann Tracing and protocol dumping Some of these certainly impact embedded architectures and workloads. Examples would be Generic architecture support, arch layer cleanup, tracing, profiling and performance counters, userspace drivers, etc. Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. josh -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote: One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ie. On x86, PowerPC and Sparc a kernel image will boot on any machine (assuming the needed drivers are enabled), but this is rarely the case in embedded. Most embedded kernels require explicit board support selected at compile time with no way to produce a generic kernel which will boot on a whole family of devices, let alone the whole architecture. Part of this is a firmware issue, where existing firmware passes very little in the way of hardware description to the kernel, but part is also not making available any form of common language for describing the machine. OK, so my minimal understanding in this area lead me to believe this was because most embedded systems didn't have properly discoverable busses and therefore you had to tailor the kernel configuration exactly to the devices the system had. Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. It sounds interesting ... however, it also sounds like an area which might not impact the core kernel much ... or am I wrong about that? The topics we're really looking for the Kernel Summit are ones that require cross system input and which can't simply be sorted out by organising an Embedded mini-summit. Now if flattened device tree could help us out with BIOS, ACPI, EFI and the other myriad boot and identification standards that seem designed to hide system information rather than reveal it, then we might be all ears ... James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote: On Tue, Jun 2, 2009 at 9:22 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org Hi James, One topic that seems to garner debate is the issue of decoupling the kernel image from the target platform. ... Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Josh Boyer has already touched on discussing flattened device tree support at kernel summit in an email to the ksummit list last week (quoted below), and I'm wondering if a broader discussing would be warranted. I absolutely agree with this. We have been using the flattened device tree on our MIPS platform to support multiple systems, and are close to posting a patch to the MIPS Linux mailing list. At least one other MIPS platform has indicated that they want to use the device tree. I think that in the absence of any established standard like the PC BIOS/EFI or a real Open Firmware interface, then the kernel should at least offer a recommended interface so that multiplatform kernels are possible without explicitly having the machine layout described to it at compile time. I know that some of the embedded distros are interested in such a thing since it gets them away from shipping separate images for each supported board. ie. It's really hard to do a generic live-cd without some form of multiplatform. FDT is a great approach, but it probably isn't the only option. It would be worth debating. Is there another possibility besides the device tree that people are using on 4 different architectures? We can't mandate support of the device tree for any particular architecture or platform, but we can make sure the device tree infrastructure is supported well enough that any architecture can pick it up easily. Doing so will also encourage support in bootloaders which may not currently do so. Should we decide to go this way, there probably a next step wherein we standardize the device tree entries for those devices that are shared across multiple architectures and platorms. This will likely be a never-ending and mostly thankless task, but will again make things easier in the long run. Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote: On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 2, 2009 at 11:45 AM, David VomLehn dvoml...@cisco.com wrote: Should we decide to go this way, there probably a next step wherein we standardize the device tree entries for those devices that are shared across multiple architectures and platorms. This will likely be a never-ending and mostly thankless task, but will again make things easier in the long run. devicetree-disc...@ozlabs.org mailing list is your friend here. In PowerPC land we've mostly settled on the policy of not merging a driver before the device tree binding is documented, posted and reviewed. This weeds out a lot of common mistakes. I also think the stuff in Documentation/powerpc/dts-bindings needs to be moved out to a common location. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 01:25:32PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 10:52 -0700, David VomLehn wrote: On Tue, Jun 02, 2009 at 12:42:57PM -0500, James Bottomley wrote: On Tue, 2009-06-02 at 13:29 -0400, Josh Boyer wrote: Which leads me to suggest that it is at least worth having someone with an embedded focus at KS to simply keep an eye out for impacts of generic changes. Feature parity is something I often deal with in trying to keep ppc4xx up to speed with the rest of the archs in the kernel. We're fine with this, if that's how the embedded guys would like to do it ... how do you want to nominate the someone with an embedded focus? We chose the topic driven approach because that's the one it's easiest for the Kernel Summit Programme Committee to look at and make attendance decisions based upon. However, if all the embedded people want to choose their own representatives, that's fine by us too ... as long as you can devise a fair process. Now, James, I think you haven't been paying attention to the embedded Linux world...asking us to devise *any* process is much more chaotic than herding cats. Expecting something everyone agrees is fair would probably take until at least KS 2010. That being said, we have three people who are listed in MAINTAINERS under embedded Linux. We might start by seeing which of them might take up the mantle and vote on the linux-embedded mailing list. Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. Most of these are probably tired and old, but some possible topic suggestions: 1) Kernel binary bloat (again) 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc 3) Netbooks - the bridge between embedded and desktop? Is the flourish of low cost netbooks, some pre-installed with Linux, having any impact on how we review and develop general kernel code? One of the problems I struggle with is coming up with embedded topics general enough to be of interest to a broader set of both upstream kernel developers and the embedded community. Those that are general enough have either been discussed quite a bit already, or are already on the list of topics. Maybe I'm just not trying hard enough. josh -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
Josh Boyer wrote: 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc CELF tries, but the progress is exceedingly slow. Recently we've been more focused on contracting specific feature work. (E.g. Squashfs mainlining). James Bottomley wrote: Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. With regard to a process to determine representatives, I'm not sure we need one. Based on participation and inclusion in MAINTAINERS, either Matt Mackall or David Woodhouse can represent most embedded issues just fine. And I can say that officially on behalf of CELF and it's members, which would account for a large fraction of the overall embedded community. With regard to topics, do topics drive attendee invitations, or vice-versa? Here's my own issue list: tracing - already well (over?) represented bloat - tracing will help identify performance bloat. As for size bloat, a smaller kernel is always desirable, but we are seeing signs that Moore's law is catching up and making this less an issue (for the kernel - apps still have big problems here.) power management - Use cases for products that spend most of their time off (even while appearing to be running) are of interest. I don't know what the status 'wakelock-like' solutions is. fast boot - kernel is almost done? (!!!) The new target for kernel boot time is 300 milliseconds. Once there, almost all problems are then user space issues. It is interesting how much of a differentiator fast boot became for Linux in netbooks and dual-boot configurations, in just the last 2 years - which just shows that sometimes it pays off to optimize something. ;-) participation - talking about this is like beating a dead horse (for me at least). I've been working on this for 5 years now, making baby steps forward. The issues are, by now, well understood (I hope). I'm not sure what a KS discussion is going to do to drive issues here. = Tim Bird Architecture Group Chair, CE Linux Forum Senior Staff Engineer, Sony Corporation of America = -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, 2009-06-02 at 12:30 -0700, Tim Bird wrote: Josh Boyer wrote: 2) Encouraging upstream participation of Embedded distros Things like Moblin and Android are getting a lot of press these days, but embedded distros have been around for a while. Are we getting good participation from these vendors? Is there something we could be doing to encourage such participation? Has CELF helped with this at all? etc CELF tries, but the progress is exceedingly slow. Recently we've been more focused on contracting specific feature work. (E.g. Squashfs mainlining). James Bottomley wrote: Even for someone as inattentive as me, the general problems of getting embedded people to agree the sky is blue did impinge on the peripheral consciousness. Thus: If you can come up with such a process in a timely fashion then fine ... if not, we'll do the topic based one suggested by the PC. With regard to a process to determine representatives, I'm not sure we need one. Based on participation and inclusion in MAINTAINERS, either Matt Mackall or David Woodhouse can represent most embedded issues just fine. And I can say that officially on behalf of CELF and it's members, which would account for a large fraction of the overall embedded community. With regard to topics, do topics drive attendee invitations, or vice-versa? Here's my own issue list: tracing - already well (over?) represented bloat - tracing will help identify performance bloat. As for size bloat, a smaller kernel is always desirable, but we are seeing signs that Moore's law is catching up and making this less an issue (for the kernel - apps still have big problems here.) power management - Use cases for products that spend most of their time off (even while appearing to be running) are of interest. I don't know what the status 'wakelock-like' solutions is. fast boot - kernel is almost done? (!!!) The new target for kernel boot time is 300 milliseconds. Once there, almost all problems are then user space issues. It is interesting how much of a differentiator fast boot became for Linux in netbooks and dual-boot configurations, in just the last 2 years - which just shows that sometimes it pays off to optimize something. ;-) OK, if that's what you all want, that's what we can do ... however, it would likely be the same people discussing the same issues. participation - talking about this is like beating a dead horse (for me at least). I've been working on this for 5 years now, making baby steps forward. The issues are, by now, well understood (I hope). I'm not sure what a KS discussion is going to do to drive issues here. This is what made us suggest the presentation driven approach. We can send people who understand how the kernel development process out anointed as embedded maintainers. However, looking at the arch directory, you have a ton of new kids on the block. We wondered if, perhaps, rather than having seasoned kernel developers reach out to the embedded community, we might try giving the embedded community the opportunity to reach out to us. The topic of flattened device tree look interesting to me (perhaps because I'm a hardened device driver person and things like that always look interesting to me) ... if we can get a few more like that out of the woodwork, this approach might end up being successful. James -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
James Bottomley wrote: On Tue, 2009-06-02 at 12:30 -0700, Tim Bird wrote: With regard to a process to determine representatives, I'm not sure we need one. Based on participation and inclusion in MAINTAINERS, either Matt Mackall or David Woodhouse can represent most embedded issues just fine. And I can say that officially on behalf of CELF and it's members, which would account for a large fraction of the overall embedded community. What about others like myself who would like to get more involved, but don't show up in the MAINTAINERS list? I might be interested in lending a hand in helping to represent the embedded issues... b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 11:29:46AM -0600, Grant Likely wrote: Embedded PowerPC and Microblaze has tackled this problem with the Flattened Device Tree data format which is derived from the OpenFirmware specifications, and there is some interest and debate (as discussed recently on the ARM mailing list) about making flattened device tree usable by ARM also (which I'm currently proof-of-concepting). Note that I have to point out that ARM will probably never be in a situation where you can have a one kernel image boots on everything. That _is_ practical today (and does happen with all PXA now) with what we have within a very big restriction - which is that the kernel must be built to support PXA and not Atmel SoCs. I really don't think combining SoC support is going to be realistic, device tree or not. When we had just four machine types (RiscPC, EBSA110, EBSA285, Netwinder) I did look into this and came to the conclusion that it would be far too inefficient for there to be any win. The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
Russell King wrote: The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. And that diversity is precisely because of the diversity in ARM-based embedded platforms. Such diversity means that kernel/driver development is a constant activity, which suggests that we shouldn't bother the effort to come up with a comprehensive solution because none will exist. Rather, we should maintain and improve the ability to rapidly prototype and adapt. Things like furthering the deployment of platform_device, clocksource/clockdevice, and so on. ARM diversity is already a LOT easier to deal with than it was under 2.4, so we're making progress. b.g. -- Bill Gatliff b...@billgatliff.com -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote: The topic of flattened device tree look interesting to me (perhaps because I'm a hardened device driver person and things like that always look interesting to me) ... The recent oftree activities look indeed very promising; the different boot-information-passing methods, mainly in powerpc and arm land, is IMHO and important field where a generic kernel infrastructure would make sense for the embedded people. Taken that oftree has created robustness and compatiblity problems in the past but seems to move into a good direction recently, feedback from core kernel developers would certainly be a good thing. if we can get a few more like that out of the woodwork, this approach might end up being successful. Could flickerfree-bootsplash be a topic? Or is that completely pushed into the userspace these fastboot days? rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 10:10:58PM +0100, Russell King wrote: I really don't think combining SoC support is going to be realistic, device tree or not. When we had just four machine types (RiscPC, EBSA110, EBSA285, Netwinder) I did look into this and came to the conclusion that it would be far too inefficient for there to be any win. The big problem we have is that the only commonality between different SoCs is that the CPU executes ARM instructions. Everything else is entirely up to the SoC designer - eg location of memory, spacing of memory banks, type of interrupt controller, etc is all highly SoC specific. Nothing outside of the ARM CPU itself is standardized. And even with the cpu core, we usually build kernels with optimized toolchains for their cpu family. But nevertheless - describing hardware inside a mach* makes sense. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Representing Embedded Architectures at the Kernel Summit
On 13:29 Tue 02 Jun , Josh Boyer wrote: On Tue, Jun 02, 2009 at 03:22:20PM +, James Bottomley wrote: Hi All, We've got to the point where there are simply too many embedded architectures to invite all the arch maintainers to the kernel summit. So, this year, we thought we'd do embedded via topic driven invitations instead. So what we're looking for is a proposal to discuss the issues most affecting embedded architectures, or preview any features affecting the main kernel which embedded architectures might need ... or any other topics from embedded architectures which might need discussion or debate. If you'd like to do this, could you either reply to this email, or send proposals to: ksummit-2009-disc...@lists.linux-foundation.org For those not following the ksummit list, below is the current list of suggested topics: PROPOSERTOPIC Jon Corbet How much do we owe sloppy application writers Jon Corbet The containers end game and how we get there Balbir SinghThe Hacking Hour Rafael Wysocki Regression tracking and kernel quality Jon Corbet Criteria for acceptance of kernel tracepoints Jesse BarnesProfiling and performance counters Eric Biederman Procedures for dealing with patent problems John Linville Patch review checklist Matthew Wilcox How to handle style-only patches Dan WilliamsRAID unification / stacked block devices Jiri Kosina User-space drivers - worth encouraging? Sam RavnborgShipping user-space components in the kernel Kay Sievers Establishment/maintenance of per-subsystem todo lists Steve Rostedt Improving changelogs Jon Corbet I/O bandwidth controllers (maybe minisummit report) Ted Ts'oPulseAudio and kernel interface issues Greg KH Generic architecture support and arch layer cleanup (Josh Boyer: add device tree discussion?) Dave Jones cpumasks, churn, and unending API changes Dirk HohndelIssues related to wireless technologies Jon Corbet Tracing: Merging utrace Ftrace mainline v. private debugging tools Non-ftrace visibility infrastructure Systemtap for kernel developers Marcel Holtmann Tracing and protocol dumping I'd like to propose AMP and kernel relocate as more and SoC will came with multiple core with or without the same arch Best Regards, J. -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
David VomLehn dvoml...@cisco.com writes: On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote: ... This is what made us suggest the presentation driven approach. We can send people who understand how the kernel development process out anointed as embedded maintainers. However, looking at the arch directory, you have a ton of new kids on the block. We wondered if, perhaps, rather than having seasoned kernel developers reach out to the embedded community, we might try giving the embedded community the opportunity to reach out to us. The topic of flattened device tree look interesting to me (perhaps because I'm a hardened device driver person and things like that always look interesting to me) ... if we can get a few more like that out of the woodwork, this approach might end up being successful. Failure reporting is the one area where embedded applications have little overlap with other Linux application domains. The cable settop box environment has: o Limited peristent storage o Low or no upstream bandwidth o Little access to hundreds of thousands of devices in the field When a kernel panics in the field, we have no place to put a core dump and, if we had a place to put it, it would take way too long to upload it when the box comes back up. And most people just don't understand when you knock at their door at midnight, JTAG probe in hand. We hook in a panic notifier and have it generate a really rich report. At present, this report stays in memory until we reboot and send it upstream (or write it to flash), but we could really write it to any device with which we can use polled I/O (interrupts being questionable at this point). Generic interfaces to support this would be useful. Many embedded devices have highly integrated stacks, so failures in user space lead to device reboots, and you want to leverage much of the same ability to store and send failure reports. Our failure report includes things you'd expect as well as various pieces of history, such as: o IRQs o softirq dispatches (including max times) o selected /proc info, e.g. /proc/meminfo We also report info on the current thread, like backtracing and /proc/pid/maps, though I'm not sure it's as useful as it might be. Though I'm working on pushing this stuff out, other things that might be helpful are: o If you get to panic() by way of die(), you've lost the registers passed to die(). We save a pointer off, but it's really a kludge. o The implementation of die() varies from platform to platform and isn't even called die() everywhere. o It is truly nasty trying to get /proc information when you are in a panic situation--any semaphores being held are not going to be released, so you have to duplicate a lot of the code, minus the semaphores. Pretty gross and there is no way our implementation will be acceptable. o Increased reporting on what's happening in user/kernel space interaction. For example, a signal sent in good faith might kill a buggy process. It would be helpful to log signals that result in a process' death. o Then there is more speculative stuff. For example, your caches would have a copy of the most recently accessed code and data. If your processor supports dumping cache, it might help determing what went wrong. Have you looked at doing this with the kexec on panic infrastructure? Things like mkdumpfile can now have enough information to dump this. If you are space constrained a stand alone executable could be used instead of a linux kernel to marshal the information into your buffer. Eric -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, 2 Jun 2009, David VomLehn wrote: On Tue, Jun 02, 2009 at 03:37:44PM -0500, James Bottomley wrote: Our failure report includes things you'd expect as well as various pieces of history, such as: o IRQs o softirq dispatches (including max times) o selected /proc info, e.g. /proc/meminfo We also report info on the current thread, like backtracing and /proc/pid/maps, though I'm not sure it's as useful as it might be. Though I'm working on pushing this stuff out, other things that might be helpful are: o If you get to panic() by way of die(), you've lost the registers passed to die(). We save a pointer off, but it's really a kludge. o The implementation of die() varies from platform to platform and isn't even called die() everywhere. o It is truly nasty trying to get /proc information when you are in a panic situation--any semaphores being held are not going to be released, so you have to duplicate a lot of the code, minus the semaphores. Pretty gross and there is no way our implementation will be acceptable. o Increased reporting on what's happening in user/kernel space interaction. For example, a signal sent in good faith might kill a buggy process. It would be helpful to log signals that result in a process' death. o Then there is more speculative stuff. For example, your caches would have a copy of the most recently accessed code and data. If your processor supports dumping cache, it might help determing what went wrong. If your system is hooked up to a serial console, another helpful thing to do is to pass in ftrace_dump_on_oops in the command line and also keep the event tracer running, where you enable just the events you are interested in. Then if the system crashes, it will dump out the ftrace buffer to the console, which could be logged by a serial console and then you at least have a trace of the events that lead up to the crash. The event tracer while active is not that much overhead and could be enabled in a production system. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Ksummit-2009-discuss] Representing Embedded Architectures at the Kernel Summit
On Tue, Jun 02, 2009 at 11:34:52PM +0200, Robert Schwebel wrote: Could flickerfree-bootsplash be a topic? Or is that completely pushed into the userspace these fastboot days? We have that working today, no in-kernel work needed other than the already-present KMS stuff. See the recent Moblin images for proof of this. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-embedded in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
