On Jun 18, 2009, at 10:00 PM, Paul Mundt wrote:
On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote:
On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote:
On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote:
One topic that was partially touched on was dealing with various
memories
On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote:
On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote:
One topic that was partially touched on was dealing with various
memories on embedded systems. We have several sram based allocators
in the kernel for various different arch's:
-
On Thu, Jun 18, 2009 at 09:59:20PM -0500, Kumar Gala wrote:
On Jun 17, 2009, at 9:51 PM, Paul Mundt wrote:
On Wed, Jun 17, 2009 at 09:31:48AM -0500, Kumar Gala wrote:
One topic that was partially touched on was dealing with various
memories on embedded systems. We have several sram based
On Tue, Jun 16, 2009 at 09:26:02PM -0700, H. Peter Anvin wrote:
I2C or similar busses can be a particularly annoying if they contain
essential configuration information such as memory size which is needed
long before anything else. So for far a common solution is that platforms
are
One topic that was partially touched on was dealing with various
memories on embedded systems. We have several sram based allocators
in the kernel for various different arch's:
- Blackfin sram allocator arch/blackfin/mm/sram-alloc.c
- Lite5200(b) sram allocator
Ralf Baechle wrote:
However, on most systems, even embedded, bringing up memory falls on
firmware (sometimes in the form of a boot loader) so Linux rarely sees it.
There are embedded systems were the firmware does not provide a usuable
memory map or where that is plain broken. Or Linux
On Tue, Jun 16, 2009 at 09:42:46AM +0300, Mike Rapoport wrote:
James Bottomley wrote:
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
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
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
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.
On Tue, Jun 16, 2009 at 04:06:48AM -0400, Mike Frysinger wrote:
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
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,
On Tue, Jun 16, 2009 at 2:06 AM, Mike Frysingervapier@gmail.com wrote:
On Tue, Jun 16, 2009 at 02:42, Mike Rapoport wrote:
James Bottomley wrote:
Another issue that affects embedded architectures is drivers initialization
order. There are a lot of cases when you need the drivers to be
Grant Likely wrote:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With this approach, a driver can use a
bus_register_notifier() variant
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Grant Likely wrote:
http://patchwork.ozlabs.org/patch/24152/
I never actually pushed through and finished it because it turned out
to be a non-issue for Ethernet devices in the end. However, I can see
the value. With
Grant Likely wrote:
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
That would work for some cases, but a lot of cases the problem is not
module init
On Tue, Jun 16, 2009 at 2:07 PM, Jamie Lokierja...@shareable.org wrote:
Grant Likely wrote:
On Tue, Jun 16, 2009 at 12:18 PM, Jamie Lokierja...@shareable.org wrote:
Something which lets you specify a dependency in a one-line
MODULE_INIT_PREREQS() macro would be much nicer.
That would work
Ralf Baechle wrote:
I2C or similar busses can be a particularly annoying if they contain
essential configuration information such as memory size which is needed
long before anything else. So for far a common solution is that platforms
are carrying a private (aka redundant, ugly) early-i2c
On Wed, Jun 10, 2009 at 5:13 PM, Kumar Galaga...@kernel.crashing.org wrote:
On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
I'd like to propose AMP and kernel relocate
as more and SoC will came with multiple core with or without the same arch
I think AMP or at least the
Le Wed, 03 Jun 2009 12:19:57 -0400,
James Bottomley james.bottom...@hansenpartnership.com a écrit :
So ZONE_DMA and coherent memory allocation as represented by the
coherent mask are really totally separate things. The idea of
ZONE_DMA was really that if you had an ISA device, allocations
On Jun 2, 2009, at 5:21 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
I'd like to propose AMP and kernel relocate
as more and SoC will came with multiple core with or without the
same arch
I think AMP or at least the idea of the kernel communicating with
other OSes on the same SoC in
: james.bottom...@hansenpartnership.com;
linux-a...@vger.kernel.org; linux-embedded@vger.kernel.org;
ksummit-2009-disc...@lists.linux-foundation.org
Subject: Re: [Ksummit-2009-discuss] Representing Embedded
Architectures at the Kernel Summit
On Wed, 3 Jun 2009 18:09:25 +0100
Russell King r
On Tue, Jun 2, 2009 at 11:48 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
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
On Tue, Jun 2, 2009 at 3:16 PM, Bill Gatliff b...@billgatliff.com wrote:
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,
On Wed, Jun 3, 2009 at 3:08 AM, Steve Langstaff
steve.langst...@pebblebay.com wrote:
From: linux-embedded-ow...@vger.kernel.org [mailto:linux-embedded-
ow...@vger.kernel.org] On Behalf Of Russell King
The big problem we have is that the only commonality between different
SoCs is that the CPU
On Tue, Jun 02, 2009 at 05:48:37PM +, James Bottomley wrote:
On Tue, 2009-06-02 at 11:29 -0600, Grant Likely wrote:
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
On Wed, Jun 03, 2009 at 02:04:46PM +0100, Catalin Marinas wrote:
* Mixed endianness devices in the same system - this may only need
dedicated readl_be/writel_be etc. macros but it could also be
done by having bus-aware readl/writel-like macros
ioread/iowrite{8,16,32} and
On Wed, 2009-06-03 at 09:18 -0400, Josh Boyer wrote:
On Wed, Jun 03, 2009 at 02:04:46PM +0100, Catalin Marinas wrote:
* Mixed endianness devices in the same system - this may only need
dedicated readl_be/writel_be etc. macros but it could also be
done by having bus-aware
On Wed, Jun 03, 2009 at 02:45:37PM +0100, Catalin Marinas wrote:
On Wed, 2009-06-03 at 09:18 -0400, Josh Boyer wrote:
On Wed, Jun 03, 2009 at 02:04:46PM +0100, Catalin Marinas wrote:
* Mixed endianness devices in the same system - this may only need
dedicated readl_be/writel_be
* Asymmetric MP:
* Different CPU frequencies
* Different CPU features (e.g. floating point only one
some CPUs): scheduler awareness, per-CPU hwcap bits (in
case user space wants to set the affinity)
*
On Wed, 2009-06-03 at 14:04 +0100, Catalin Marinas wrote:
Hi,
On Tue, 2009-06-02 at 15:22 +, James Bottomley wrote:
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
On Wed, Jun 03, 2009 at 12:19:57PM -0400, James Bottomley wrote:
On Wed, 2009-06-03 at 14:04 +0100, Catalin Marinas wrote:
* Better support for coherent DMA mask - currently ZONE_DMA is
assumed to be in the bottom part of the memory which isn't
always the case.
On Wed, 3 Jun 2009 18:09:25 +0100
Russell King r...@arm.linux.org.uk wrote:
In
fact, on ARM the DMA mask is exactly that - it's a 100% proper mask. It's
not a bunch of zeros in the MSB followed by a bunch of ones down to the
LSB. It can be a bunch of ones, a bunch of zeros, followed by a
On Wed, 2009-06-03 at 11:43 -0700, Andrew Morton wrote:
On Wed, 3 Jun 2009 18:09:25 +0100
Russell King r...@arm.linux.org.uk wrote:
In
fact, on ARM the DMA mask is exactly that - it's a 100% proper mask. It's
not a bunch of zeros in the MSB followed by a bunch of ones down to the
LSB.
On Wed, 2009-06-03 at 12:19 -0400, James Bottomley wrote:
On Wed, 2009-06-03 at 14:04 +0100, Catalin Marinas wrote:
On Tue, 2009-06-02 at 15:22 +, James Bottomley wrote:
So what we're looking for is a proposal to discuss the issues
most affecting embedded architectures, or preview any
;
ksummit-2009-disc...@lists.linux-foundation.org
Subject: Re: [Ksummit-2009-discuss] Representing Embedded
Architectures at the Kernel Summit
On Wed, 3 Jun 2009 18:09:25 +0100
Russell King r...@arm.linux.org.uk wrote:
In
fact, on ARM the DMA mask is exactly that - it's a 100%
proper
On Wed, Jun 3, 2009 at 23:11, David VomLehn (dvomlehn) wrote:
David Delaney has a proof-of-concept of an idea of his which was
presented at the last CELF, which is basically to put the kernel and
loadable kernel modules closely enough together that you can avoid the
use of long jumps. He sees
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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.
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
55 matches
Mail list logo
