lkml.org 
[lkml]   [2009]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateWed, 1 Jul 2009 10:25:00 -0700
FromJesse Barnes <>
SubjectRe: [PATCH 3/9] x86/moorestown: add moorestown platform flags
On Tue, 30 Jun 2009 08:35:13 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> On Fri 2009-06-26 09:54:54, Jesse Barnes wrote:
> > On Fri, 26 Jun 2009 18:32:42 +0200 (CEST)
> > Thomas Gleixner <tglx@linutronix.de> wrote:
> >
> > > On Fri, 26 Jun 2009, Ingo Molnar wrote:
> > > > [ Although it is beyond me why ABP was done - why wasnt HPET
> > > > good enough? HPET can do per CPU clockevents too and it's just
> > > > as off-chip (and hence fundamentally slow) as ABP. ]
> > >
> > > Welcome to the wonderful world of embedded systems. Just have a
> > > peek into arch/[arm/powerpc/mips] to see what's coming up to us
> > > with full force. I would not be surprised when we see an x86
> > > system sharing the device driver for i2c or whatever with an ARM
> > > SoC in the foreseable future.
> >
> > Ha, yeah I was just going to say "think embedded". ABP is a much
> > simpler spec and programming interface than HPET, and since we were
> > designing new custom silicon, it made sense to just do the simple
> > thing, rather than butchering an existing spec, then making a
> > partial HPET that looks like ABP anyway and forcing any future HPET
> > updates to conform to the new standard (very similar reasoning to
> > the ACPI vs SFI discussion btw). Hopefully the technologies we've
> > come up with for
>
> Very similary wrong, I'd say :-(. While you could have created
> hpet-lite, where hpet-lite driver would work on hpet system, you went
> and created something new.
>
> And yes, SFI is similar disaster, you should just define subset of
> acpi ('acpi-lite').
>
> In the end, you are willing to use silicon for compatibility (arm
> instruction set needs less transistors, right?) and wasting millions
> of transistors, then try to save thousands with non-compatible
> devices :-(.

You didn't address the essence of either argument; butchering an
existing spec and placing an extra burden on all future implementations
is a high price to pay, both in terms of complexity and cost.

But really these are moot points; this is how the platform works. I'd
like to see Linux run on it "out of the box" which means integrating
support for these features in a maintainable way. Hopefully no one
disagrees with that; after all Linux runs on much uglier platforms than
this.

--
Jesse Barnes, Intel Open Source Technology Center


\
 
 \ /
  Last update: 2009-07-01 19:27    [from the cache]
©2003-2010