From mboxrd@z Thu Jan 1 00:00:00 1970 From: Grant Likely Subject: Re: Representing Embedded Architectures at the Kernel Summit Date: Thu, 4 Jun 2009 14:15:21 -0600 Message-ID: References: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com> <20090602211057.GA10800@flint.arm.linux.org.uk> <4A2596B4.3020309@billgatliff.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <4A2596B4.3020309@billgatliff.com> Sender: linux-embedded-owner@vger.kernel.org To: Bill Gatliff Cc: James Bottomley , ksummit-2009-discuss@lists.linux-foundation.org, linux-arch@vger.kernel.org, linux-embedded@vger.kernel.org, Josh Boyer , Tim Bird List-Id: linux-arch.vger.kernel.org On Tue, Jun 2, 2009 at 3:16 PM, Bill Gatliff wro= te: > Russell King wrote: >> >> The big problem we have is that the only commonality between differe= nt >> SoCs is that the CPU executes ARM instructions. =A0Everything else i= s >> entirely up to the SoC designer - eg location of memory, spacing of >> memory banks, type of interrupt controller, etc is all highly SoC >> specific. =A0Nothing 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 act= ivity, > which suggests that we shouldn't bother the effort to come up with a > comprehensive solution because none will exist. =A0Rather, we should = maintain > and improve the ability to rapidly prototype and adapt. =A0Things lik= e > furthering the deployment of platform_device, clocksource/clockdevice= , and > so on. No, not comprehensive; just common. It makes sense to spend the effort on the patterns and devices which are common. It may not cover everything, but it doesn't have to to be valuable. g. --=20 Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qy0-f176.google.com ([209.85.221.176]:65047 "EHLO mail-qy0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751510AbZFDUPj convert rfc822-to-8bit (ORCPT ); Thu, 4 Jun 2009 16:15:39 -0400 MIME-Version: 1.0 In-Reply-To: <4A2596B4.3020309@billgatliff.com> References: <1243956140.4229.25.camel@mulgrave.int.hansenpartnership.com> <20090602211057.GA10800@flint.arm.linux.org.uk> <4A2596B4.3020309@billgatliff.com> From: Grant Likely Date: Thu, 4 Jun 2009 14:15:21 -0600 Message-ID: Subject: Re: Representing Embedded Architectures at the Kernel Summit Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-arch-owner@vger.kernel.org List-ID: To: Bill Gatliff Cc: James Bottomley , ksummit-2009-discuss@lists.linux-foundation.org, linux-arch@vger.kernel.org, linux-embedded@vger.kernel.org, Josh Boyer , Tim Bird Message-ID: <20090604201521.Rw1OcqTTttcZSDlBlYNuHboAfzDv2xvAM87dFLgPehY@z> On Tue, Jun 2, 2009 at 3:16 PM, Bill Gatliff 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, 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. No, not comprehensive; just common. It makes sense to spend the effort on the patterns and devices which are common. It may not cover everything, but it doesn't have to to be valuable. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd.