On Tue, 2003-08-26 at 10:22, Marc Aurele La France wrote: > Frankly, I don't see how this EFI MDT can be accurate given that, in > general, whether or not a particular PCI memory assignment will tolerate > caching and/or write-combining is highly device-specific. That would be a > horrific PCI device database for EFI to maintain.
My understanding (albeit limited) from correspondence with HP is that it is the "chipset" that determines this. On current HP ia64 they use the ZX1 chipset which only does non-cached access on PCI. Thus if firmware knows there is a ZX1 chipset it knows how the memory region will be handled. Apparently EFI also seems to know about GARTs. Intel boxes used a different chipset but share EFI and the kernel code so it should be behave the same. I'm leery of misinterpreting some of the correspondence so is the actual text from some of it, if you draw different conclusions let me know. John> What had been confusing at this end is the notion that ROM by John> definition can never be incoherent, therefore cached John> vs. non-cached should be irrelevant. HP> Ah, I see that point. The problem in this case is that the HP> chipset may support different types of access to different HP> regions. (That's part of what the EFI MDT tells you.) The ZX1 HP> chipset doesn't support cacheable access to any MMIO space, HP> regardless of whether that space happens to contain RAM, ROM, HP> device CSRs, etc. John> The problem if I understand correctly is that the access was not John> consistent with the EFI table defining what the memory attribute John> needed to be. Bottom line, its EFI that determines cachability, John> not a prori knowledge of the memory characteristics being John> mapped. HP> Right. And the underlying chipset determines what goes in the EFI HP> table. ------------------------------------- John> This made me think about the MAP_WRITECOMBINED flag passed to John> mmap. The current scheme has EFI responsible for determining the John> cached vs. non-cached memory attribute, the user should not be John> specifying such a memory attribute. Write combining or write John> coalescing is one variant of a non-cached memory attribute on John> ia64 that is used for frame buffers. My understanding is that John> EFI will be ignorant of this memory attribute and the John> MAP_WRITECOMBINED remains a valid flag to pass. I also assume John> that passing this flag replaces an ma value of 4 (uncached) with John> 6 (uncached write coalescing) and that such a replacement, John> outside the scope of the EFI MDT is valid because both share the John> uncached attribute. Correct? HP> The EFI MDT does have a bit for WC, but I don't know of any ia64 HP> platform that sets it. I removed support for MAP_WRITECOMBINED in HP> the 2.4.19 patch because we don't have a good way of using it HP> safely. (Even if there were an ia64 platform that claimed to HP> support it, we'd have to be very careful to avoid the attribute HP> aliasing problem. The fact that kernel identity mappings don't HP> have page tables and are inserted in 64Mb (or maybe 16Mb) chunks HP> means that we'd have to somehow ensure that a 64Mb chunk that HP> contained a WC mapping could never also be mapped WB.) HP> From the user side, MAP_WRITECOMBINED can still be specified; we HP> just ignore it in the kernel. This used to be used for AGP, but HP> all ia64 GARTs are now run in coherent mode, so there's no need HP> for WC. HP> It is possible for multiple attributes to be supported, so it's HP> conceivable that we could look at user requests for special HP> mappings. For example, the i2000 supports both UC and WB mappings HP> of main memory. But at the moment, I don't think there's an HP> actual need for such a feature, and the fact that we don't have HP> kernel page tables would complicate adding it. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
