Re: pci-sysfs resource mmap broken (and PATCH)

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Wed, 2005-04-27 at 22:37 -0700, David S. Miller wrote:
> On Wed, 27 Apr 2005 23:33:11 -0600

> The 'offset' argument is defined to be page aligned
> when passed to mmap().

mmap API in general is defined to only ever deal with page aligned
parameters & return values no ?

> > If it's a token, the arch specific mmap() will know how to deal with it.
> > parisc does that with IO Port space(s) in the kernel.
> 
> Yes, if the token goes in as the offset parameter to mmap() then
> whatever ->mmap() code we write can call arch specific code to
> transform it as necessary.

Except from that page alignment thing ... which is the root of the
problem.

> It's been around for ages, and it used in the X server on PPC
> and Sparc.  It mostly allows handling of multi-domain stuff.
> Unfortunately, the $DOMAIN:xxx directory naming change we made
> in 2.6.x for /proc/pci stuff broke the X server at least on
> sparc64 :-/

In fact, I'm fairly sure X still uses /dev/mem on ppc :( Oh well...

> I hate to say this, but the largest consumer of this stuff is the
> X server, so we really need to force ourselves to work in parallel
> on clean X server support.

Cleaning X.org is my goal, this is why I'm trying to clean the kernel
side first :) I'm also working separately on the problem of VGA access
arbitration (We'll probably do a joint session with the desktop summit
an the kernel summit about those issue).

> Whether that's via some libpci.a
> abstraction or whatever, I personally don't care, but without the
> X support in some form all of this is API masterbation :-)

It is :) Userland driver stuff is a consumer too though.

> > If it's prefetchable, won't the reads/writes automatically be combined?
> > Since I equate "prefetchable" == "cacheable", I'd think anything
> > is fair game.
> 
> On many platforms some kind of "side effect" bit in the PTE
> determine if store buffer compression can happen in the processor.
> We'd want to not set such a bit for things like frame-buffers and
> the like.

Yes, and I think that pretty much match with PCI devices exposing a
"prefetchable" BAR, don't you agree ?

Ben.