pci rework not quite ready yet?
josh at freedesktop.org
Sat Sep 29 21:13:08 PDT 2007
Jesse Barnes wrote:
> On Wednesday, August 29, 2007 9:10 am Keith Packard wrote:
>> On Wed, 2007-08-29 at 08:11 -0700, Jesse Barnes wrote:
>>> I'd be much happier if we just got away from using bus
>>> addresses entirely. There's really no way we can use them reliably
>>> short of growing sophisticated bus drivers in the X server...
>> I disagree -- all bus addresses for a single card live in a single
>> address space, and the driver must use many of them while programming
>> various operations. In particular, if you want to split a single BAR
>> into multiple 'regions' (as we do on Intel cards when mapping the
>> GTT), then you must talk about bus addresses instead of trying to
>> hide entirely behind a BAR abstraction.
>> It's also far easier to store just the bus address in the driver than
>> to track both BAR index and offset. Given that you must often program
>> the card with bus addresses, it doesn't make sense to make the driver
>> constantly refer back to the pci BAR tables unless you think those
>> are going to change.
> Yeah, I guess my main concern is how buggy some of the core X usage of
> bus addresses has been. As long as we can avoid that by making clear
> the difference between bus, CPU physical, GTT virtual, and process
> virtual I'll be happy.
To help keep address spaces straight, you might consider using the
address_space attribute of Sparse, like the Linux kernel does:
#define __physical __attribute__((address_space(1)))
#define __gtt_virtual __attribute__((address_space(2)))
extern void needs_a_gtt_virtual(void __gtt_virtual *);
void has_a_physical(void __physical *foo)
needs_a_gtt_virtual(foo); /* Will warn */
You can also throw in the attribute "noderef" as well, to prevent
- Josh Triplett
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 252 bytes
Desc: OpenPGP digital signature
More information about the xorg