Re: 2.6.10-rc2-mm4

[Terence Ripperda]

(sorry for breaking the email thread, I tried to grab the mbox archive
for responding, but ftp.uwsg.iu.edu seems to be having problems with
the mail archive).

in response to Alan Cox' voiced concerns from Tue Nov 30:

> That would also be a proprietary hook wouldn't it 8)

nvidia really isn't interested in proprietary hooks; such a hook
really wouldn't be good for nvidia or the linux kernel. but we don't
feel that a 32-bit zone is such a hook.

> beyond the supported open source hardware PCI-Express is the
> non-AGPGART user and that is 64bit.

I assume you mean traditional pci in this case, but I remain confused.
the pci spec calls for 32-bits of addressing, although there is an
optional extension for 64-bit bus extension pins. I can't speak for other
pci devices, but all of our pci devices are 32-bit.

additionally, the pci-express spec defines legacy and non-legacy
devices.  legacy devices are only required to address 32-bits, whereas
non-legacy devices are required to handle 64-bit addresses.

> In the video space it's even stranger because DRI doesn't need it

I'm unclear how traditional pci video cards function without being
able to allocate < 32-bit addresses for dma purposes. are the video cards
you've tested 64-bit capable or is dma disabled? what about 32-bit cards? I'm
afraid I don't understand how this isn't an issue.

> it seems a risky path because of the past problems trying to get
> zone balancing working.

I certainly understand the concerns with this, although I was led to
believe that recent 2.6 work made the zone balancing much less
expensive.  is that not the case?

> I can find users for a 512Mb or 1Gb DMA region

there was some brief discussion of this when we originally discussed
32-bit addressing issues, but I don't know if a satisfactory solution was
reached.  If a 1Gb region was prefered for this reason, that should satisfy
nvidia's needs for 32-bit addressing, but I couldn't speak for any other device
drivers.

for reference, the previous discussion was here:

http://www.uwsg.indiana.edu/hypermail/linux/kernel/0406.2/2093.html

Thanks,
Terence


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/