mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: airlied@gmail.com
Cc: mikpe@it.uu.se, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [BUG] 2.6.26-rc1 broke X on SPARC Ultra5
Date: Tue, 03 Jun 2008 13:54:49 -0700 (PDT)	[thread overview]
Message-ID: <20080603.135449.193702216.davem@davemloft.net> (raw)
In-Reply-To: <21d7e9970806031345u4e7838fdp60bbedadd65b5f2a@mail.gmail.com>

From: "Dave Airlie" <airlied@gmail.com>
Date: Wed, 4 Jun 2008 06:45:57 +1000

> Wow thats a major userspace regression to ship, we'd never get away
> with doing that on x86 platforms.

x86 has how many maintainers and contributors last time you checked?

Meanwhile X itself shipped mostly-non-working for PCI devices on sparc
for years.  And would you also not argue that it's broken to begin
with that the older X servers cannot work properly without a root PCI
controller being there?

The only way I can work around this issue is to provide a virtual host
bridge driver in the kernel, and I tried to do that, but it doesn't
work which is why the change got installed that did.

We'd need this because on many sparc64 machines the PCI host bridge
(and some sub-bridges) aren't even accessible via PCI config space.

If you provide a virtual host bridge, you have to emulate all of
the PCI config space accesses, you have to provide the expected
linkage and hierarchy with the rest of the PCI devices, and you
also have to do all of the I/O and MEM space range bits correctly
too.

For PCI-E and sub-bridges this becomes even more complicated, and
frankly a waste of time.

In short you have to implement an entire non-trivial emulation layer
for this stuff.

I'm the only sparc64 platform developer, so my time is better spent
moving forward and making sure that libpciaccess based X servers
aren't so broken and do the right thing in a way which works in a
maintainable long term manner.

  reply	other threads:[~2008-06-03 20:55 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-03  7:35 Mikael Pettersson
2008-06-03 13:22 ` David Miller
2008-06-03 19:26   ` Mikael Pettersson
2008-06-03 19:51     ` David Miller
     [not found]     ` <a5f334790806031259nc872dcekd00315d3e5bea048@mail.gmail.com>
2008-06-03 20:13       ` David Miller
2008-06-03 20:45     ` Dave Airlie
2008-06-03 20:54       ` David Miller [this message]
2008-06-04  0:04         ` Frans Pop
2008-06-04  0:05           ` David Miller
2008-06-04  8:06         ` Mikael Pettersson
2008-06-03 21:30 Dennis Gilmore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080603.135449.193702216.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=airlied@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mikpe@it.uu.se \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®