On Thu, Jul 25, 2013 at 09:37:49AM -0700, Jesse Barnes wrote:
> Systems with Intel graphics controllers set aside memory exclusively for
> gfx driver use. This memory is not marked in the E820 as reserved or as
> RAM, and so is subject to overlap from E820 manipulation later in the
> boot process. On some systems, MMIO space is allocated on top, despite
> the efforts of the "RAM buffer" approach, which simply rounds memory
> boundaries up to 64M to try to catch space that may decode as RAM and so
> is not suitable for MMIO.
>
> v2: use read_pci_config for 32 bit reads instead of adding a new one
> (Chris)
> add gen6 stolen size function (Chris)
> use a function pointer (Chris)
> drop gen2 bits (Daniel)
As a reminder, can you please reorder the entries in the macro to ease
compilation by userspace - c++ doesn't like having .class and so I have
to massage the file with
intel_pciids.h: i915_pciids.h
sed 's/_I915_PCIIDS/INTEL_PCIIDS/; s/\..*= //' < $^ > $@
to strip out the C99-style struct declarations (as my cpp skills were
obviously not strong enough) but then that requires the member ordering
is correct. Alternatively, if we discard the clean C99 code, both the
kernel struct pci_device_id and libpciaccess's struct pci_match_data are
the same - and I can just use i915_pciids.h directly. My perference is
to keep using C99 in the kernel as it makes the header much more
readable.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
