On Wed, Jun 21, 2000, David S. Miller <davem@redhat.com> wrote:
>ces.
>
>So what I am saying is that I would rather the kernel provide and
>interface which allows the application to say "Please assign the
>base address registers of pci device bus/dev/fn" than to provide
>a "Hey I just messed with the base address registers of this pci
>device, go have a look at what I did and update your state, and hope
>I didn't do anything wrong".
So what about a /dev/pci that would handle the entire kernel<->userland
PCI interface ?
Basically, each open instance would be tied to a given PCI device via an
ioctl, and then would have ioctls to turn on/off VGA decoding (since
that's what XFree really needs to do multihead with VGA cards) and would
provide the mmap we talked about. I'm not sure we need one instance per
BAR however. I beleive we could have a different ioctl for a given
instance to "select" the card and to "select" the current BAR which will
be the object of a subsequent mmap.
There is still need for a way to probe the bus and eventually do some
non-mapping related config space accesses (I imagine there may be rare
cases where some config space registers may need to be accessed) but all
this can be handled via additional ioctls.
>Let me give an example. What is to say that the XFree code knows what
>restrictions exist to where PCI MEM space allocations can actually
>take place? For example, on sparc64 PCI controllers, there is a
>reserved range of the 32-bit MEM space which is interpreted as bus
>mastering to main memory, so XFree would have to know to avoid this
>area to operate properly on sparc64. The extents of this restricted
>area are different depending upon which PCI controller is used, and on
>some the range is even programmable so could be different on two
>machines using the same controller chipset. The point here is that I
>hope it is evident to someone reading this that this sort of
>information has no place in an application, even one which is as low
>level as the X server can be. The kernel already knows these details,
>and this is my justification for not allowing applications to
>themselves assign PCI resources.
Yes, and that's the reason whe don't yet fully support XFree PCI on all
PPC cases: XFree would have to know about every single bus bridge, it's
specifics, it's implementation details, etc... and all this is kernel
job. Don't worry, I'm already convinced ;)
>I feel very strongly that Linus would agree with me on this point,
>and that if he knew what XFree was doing wrt. PCI device resource
>allocation, he would most likely scream :-)
Like I did when I first discovered it :) (Well, they have perfectly good
reasons to do that on other OSes, but let's make sure it's not the case
on Linux).
>Which syscalls are these? As a temporary solution I may wish to
>do the same for sparc64 to get some of the PCI drivers to work
>quickly.
Look at arch/alpha/kernel/bios32.c, for those, at least in a 2.2.x.
(Sorry, I don't have the details at hand right now, I can send you more
tonight). I didn't yet look at 2.4, I'll do so when I'm back.
I simplified them slightly for PPC (no need for sparse stuffs).
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Jun 23 2000 - 21:00:22 EST