sparse and DRM on non-x86

[Keith Whitwell]

Jon Smirl wrote:
> On Fri, 01 Oct 2004 18:05:29 +0100, Keith Whitwell
> <keith at tungstengraphics.com> wrote:
> 
>>>Second the DRM code always treats the framebuffer as if it is in
>>>IOMEM. But what about IGP type devices where the framebuffer is in
>>>main memory? These only exist on the x86 so treating their framebuffer
>>>as IOMEM works since there is no difference between IOMEM and normal
>>>memory access on an x86.
>>
>>The framebuffer lives in agp memory on those devices, presumably this is iomem
>>as it appears to be memory of the agp device.
> 
> 
> On normal AGP/PCI cards the memory is on the card. It is accessed over
> the AGP/PCI bus which requires special IO instructions on non-x86
> hardware. IGP cards use the normal system memory for their buffers.
> You don't use the special IO instructions to access this memory. The
> key is where the memory lives, on the graphics card or on the
> motherboard.
> 
> On x86 both types of memory use the same access instructions since the
> x86 makes AGP/PCI memory look like normal system memory. So we don't
> have a problem.

I understand this.  I'm pointing out that agp memory, ie. system memory mapped 
into the GART table, though it is backed by system memory, is typically 
accessed through an io range of the gart device.  So what sort of memory is that?

For the Intel chipsets, again, although the framebuffer is backed by system 
memory, all accesses to that memory are through a device io memory range, not 
by reading/writing to the backing memory directly.

> On other platforms introduction of an IGP type device will break
> X/mesa since they don't know to switch from IO instruction access to
> normal memory access. IA64 may have already run into this on
> unreleased products since they have been asking questions along these
> lines.

I've seen stuff on the web that suggests Intel wants to unify its chipsets to 
support both x86 and IA64, so that's not a huge suprise.  It'd still be good 
to base any design on actual known examples rather than guesses as to what 
might be coming.

Keith