Messages in this thread |  | | | Date | Wed, 1 Jul 2009 10:25:00 -0700 | | From | Jesse Barnes <> | | Subject | Re: [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
|  |