Hi,
We've uncovered a need when using the new memory manager to flush the
chipset global write buffers on certain intel chipset due to a lack of
coherency..
The attached patches add a new AGP interface for this purpose and
implements this in the Intel AGP driver. This stuff is based of some
guesswork in the 915 case from comments in the documentation :).
Unfortuantely the 965 BIOS doesn't set this stuff up properly and it
doesn't use a standard BAR address, so I have to do it by hand, I'd
appreciate any commentary particularly in the setting up of the resource
stuff.
Regards,
Dave.
On Mon, 2007-10-29 at 08:15 +0000, Dave Airlie wrote:
> The attached patches add a new AGP interface for this purpose and
> implements this in the Intel AGP driver. This stuff is based of some
> guesswork in the 915 case from comments in the documentation :).
The relevant register lives in device 0, which is why this is an AGP
interface and not just hidden inside the DRM driver directly.
--
[email protected]
On Monday, October 29, 2007 1:15 am Dave Airlie wrote:
> Hi,
>
> We've uncovered a need when using the new memory manager to flush the
> chipset global write buffers on certain intel chipset due to a lack
> of coherency..
>
> The attached patches add a new AGP interface for this purpose and
> implements this in the Intel AGP driver. This stuff is based of some
> guesswork in the 915 case from comments in the documentation :).
In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
right? Can we be sure that a single flush is sufficient? Is there any
window between when we flush and when we start accessing memory with
the device that we could get into more caching trouble?
> Unfortuantely the 965 BIOS doesn't set this stuff up properly and it
> doesn't use a standard BAR address, so I have to do it by hand, I'd
> appreciate any commentary particularly in the setting up of the
> resource stuff.
Looks reasonable, I'm not sure we can do much better. The only concern
I have is that allocating some more PCI space like that may end up
clobbering some *other* hidden BIOS mapping, but there's not a whole
lot we can do about that.
Jesse
>
> In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
> right? Can we be sure that a single flush is sufficient? Is there any
> window between when we flush and when we start accessing memory with
> the device that we could get into more caching trouble?
Not that I can think off, but I don't work for the company who screwed up
the coherency :-), and I don't have the docs, so please investigate for me
;-)
> Looks reasonable, I'm not sure we can do much better. The only concern
> I have is that allocating some more PCI space like that may end up
> clobbering some *other* hidden BIOS mapping, but there's not a whole
> lot we can do about that.
Again I'm trying to workaround broken BIOS.. nothing I can do.
Dave.
On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
> In this case, we're performing basically a dma_sync*(...DMA_TO_DEVICE)
> right?
But this is just for the GPU; every other DMA device in the system is
cache-coherent.
> Can we be sure that a single flush is sufficient? Is there any
> window between when we flush and when we start accessing memory with
> the device that we could get into more caching trouble?
An uncached write to this page will not complete until the buffers are
completely flushed.
> Looks reasonable, I'm not sure we can do much better. The only concern
> I have is that allocating some more PCI space like that may end up
> clobbering some *other* hidden BIOS mapping, but there's not a whole
> lot we can do about that.
This isn't a hidden mapping; the i965 doesn't allocate space for it in
the BIOS.
--
[email protected]
On Monday, October 29, 2007 12:52 pm Dave Airlie wrote:
> > In this case, we're performing basically a
> > dma_sync*(...DMA_TO_DEVICE) right? Can we be sure that a single
> > flush is sufficient? Is there any window between when we flush and
> > when we start accessing memory with the device that we could get
> > into more caching trouble?
>
> Not that I can think off, but I don't work for the company who
> screwed up the coherency :-), and I don't have the docs, so please
> investigate for me ;-)
It *looks* like it'll be enough. I assume Keith has talked to the
chipset guys to confirm this.
> > Looks reasonable, I'm not sure we can do much better. The only
> > concern I have is that allocating some more PCI space like that may
> > end up clobbering some *other* hidden BIOS mapping, but there's not
> > a whole lot we can do about that.
>
> Again I'm trying to workaround broken BIOS.. nothing I can do.
Right, BIOSes are so much fun to deal with. One other thing: it looks
like the flush mmio space has to be allocated above the top of DRAM but
below 4G. I wonder if there's an easy way to guarantee this with the
pci_bus* routines...
Jesse
On Monday, October 29, 2007 1:12 pm Keith Packard wrote:
> On Mon, 2007-10-29 at 12:47 -0700, Jesse Barnes wrote:
> > In this case, we're performing basically a
> > dma_sync*(...DMA_TO_DEVICE) right?
>
> But this is just for the GPU; every other DMA device in the system is
> cache-coherent.
Right.
> > Can we be sure that a single flush is sufficient? Is there any
> > window between when we flush and when we start accessing memory
> > with the device that we could get into more caching trouble?
>
> An uncached write to this page will not complete until the buffers
> are completely flushed.
Yeah, so we should be safe.
> > Looks reasonable, I'm not sure we can do much better. The only
> > concern I have is that allocating some more PCI space like that may
> > end up clobbering some *other* hidden BIOS mapping, but there's not
> > a whole lot we can do about that.
>
> This isn't a hidden mapping; the i965 doesn't allocate space for it
> in the BIOS.
I know, that's what I'm worried about. If the BIOS is broken enough to
not allocate MMIO space for the flush page, it may also be broken
enough that our hand crafted MMIO space allocation will end up
conflicting with some unreported BIOS area, which would be bad.
Jesse