Comment 274 for bug 541511

> --- Comment #160 from Indan Zupancic <email address hidden> 2010-05-11 15:33:24 PDT ---
> There's also a small copy&paste bug in your patch:
>
> for (i = 0; i < I830_CC_CANARY_FLOCK_PAGES; i++) {
> intel_private.i8xx_cpu_canary_pages[i]
> = kmap(intel_private.i8xx_pages[i+2]);
> if (!intel_private.i8xx_cpu_flush_page) {
> WARN_ON(1);
> intel_i830_fini_flush();
> return;
> }
> }
> That should be if (!intel_private.i8xx_cpu_canary_pages[i]).

Thanks for spotting this. Fixed in my local version.

> I don't understand this bit:
>
> /* Don't map the first page, we only write via its physical address
> * into it. */
> for (i = 0; i < I830_CC_DANCE_PAGES; i++) {
> writel(agp_bridge->driver->mask_memory(agp_bridge,
> page_to_phys(intel_private.i8xx_pages[i+1]), 0),
> intel_private.registers+I810_PTE_BASE+((num_entries+i)*4));
> }
>
> The first page is i8xx_cpu_flush_page, but if it isn't mapped, the gmch doesn't
> know about it, and intel_flush_mch_write_buffer() has no effect, has it? Or is
> any write at any address sufficient to fill the write buffer?

This just implements the gtt mapping. The direct mapping using physical
address is done a few lines before. And because
intel_flush_mch_write_buffer only needs a direct mapping, I've decided to
save on gtt page.

> We seem to have mysterious behaviour here, all the canary pages ended up
> coherent, but that one write somehow didn't?!
>
> I guess the gmch has a local cache that hides writes. If you know that cache's
> design (associativity etc.) then you can probably flush it out by doing a read
> or write to the right address. The canary stuff seems to work most of the time,
> so the cache can't be too big.

Well, that's exactly the problem. No one knows how it works exactly ...

> Or maybe you can flush it out by putting the chip in D1-3 and back to D0
> quickly, or something crazy like that.

That one probably takes even longer than what I'm doing here ...