This just splits the device list into two and moves the gtt related stuff
to intel-gtt.c. The two new devices lists also lose the not longer needed
fields. There where only about 5 cases anyway with both a gmch and a
possible agp port, so the duplication of entries is rather small.
Additionally kill 2 out of the three Ironlake mobile entries that
only differed in host bridge pci id.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

New pci ids for GT2 and GT2+ on desktop and mobile sandybridge,
and graphics device ids for server sandybridge. Also rename original
ids string to reflect GT1 version.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Sandybridge GTT has new cache control bits in PTE, which controls
graphics page cache in LLC or LLC/MLC, so we need to extend the mask
function to respect the new bits.

And set cache control to always LLC only by default on Gen6.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

It should shift bit 39-32 into pte's bit 11-4.
Reported-by: NTakashi Iwai <tiwai@suse.de>
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Cc: stable@kernel.org
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>

Make sure we always detect when we fail to correctly allocate the Isoch
Flush Page and print an error to warn the user about the likely memory
corruption that will result in invalid rendering or worse.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.

The semantic match that finds this problem is as follows:

// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@

(
* x->irq
|
* x->resource
|
* request(x, ...)
)
 ...
*pci_enable_device(x)
// </smpl>
Signed-off-by: NKulikov Vasiliy <segooon@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some BIOSes will claim a large chunk of stolen space.  Unless we
reclaim it, our aperture for remapping buffer objects will be
constrained.  So clamp the stolen space to 32M and ignore the rest.

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15469 among others.

Adding the ignored stolen memory back into the general pool using the
memory hotplug code is left as an exercise for the reader.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NSimon Farnsworth <simon.farnsworth@onelan.com>
Tested-by: NArtem S. Tashkinov <t.artem@mailcity.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

A side-effect of being able to use custom page allocations with the
sg_table is that it cannot reap the partially constructed scatterlist if
fails to allocate a page. So we need to call sg_free_table() ourselves
if sg_alloc_table() fails.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc Dave Airlie <airlied@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
[anholt: Split this patch out of a larger patch for Sandybridge fixes]
Signed-off-by: NEric Anholt <eric@anholt.net>

When "onboard video memory" is set do "disabled" in BIOS on Asus P4P800-VM
board (i865G), kernel oopses with memory corruption:
https://bugs.freedesktop.org/show_bug.cgi?id=28430

Fix that by cleanly aborting the initialization.
Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

BugLink: https://bugs.launchpad.net/bugs/597075

commit f1befe71 introduced a
regression when detecting aperture size of some i915 adapters, e.g.,
those on the Intel Q35 chipset.

The original report: https://bugzilla.kernel.org/show_bug.cgi?id=15733
The regression report: https://bugzilla.kernel.org/show_bug.cgi?id=16294

According to the specification found at
http://intellinuxgraphics.org/VOL_1_graphics_core.pdf, the PCI config
space register I830_GMCH_CTRL is a mirror of GMCH Graphics
Control. The correct macro for isolating the aperture size bits is
therefore I830_GMCH_GMS_MASK along with the attendant changes to the
case statement.
Signed-off-by: NTim Gardner <tim.gardner@canonical.com>
Tested-by: NKees Cook <kees.cook@canonical.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

also drop the NORETRY we can probably nearly always satisfy order 1 allocs now,
and again the vmalloc path is there.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since the code that was too ugly to live is upstream, we can use it now,
instead of rolling our own.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes a sporadic oops at boot on G5 Power Macs.  The table_end
variable has the address of the last byte of the table.  Adding on
PAGE_SIZE means we flush too much, and if the page after the table
is not mapped for any reason, the kernel will oops.  Instead we add
on 1 because flush_dcache_range() interprets its second argument as
the first byte past the range to be flushed.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>

References:

  Bug 15733 - Crash when accessing nonexistent GTT entries in i915
  https://bugzilla.kernel.org/show_bug.cgi?id=15733

On G33 and above, the size of the GTT space is determined by the GMCH
control register. Prior to this revision, the size is determined by the
size of the aperture. So we must careful to map and fill the appropriate
range depending on chipset.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Stanse found pci reference leaks in uli_agp_init and nforce3_agp_init
initialization functions.

The PCI devices are bridges, so it's not critical, but still worth fixing.
Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The current initialisation code probes 'unsupported' AGP devices
simply by calling its own probe function.  It does not lock these
devices or even check whether another driver is already bound to
them.

We must use the device core to manage this.  So if the specific
device id table didn't match anything and agp_try_unsupported=1,
switch the device id table and call driver_attach() again.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

SIS 760 is listed in the device tables for both amd64-agp and sis-agp.
amd64-agp is apparently preferable since it has workarounds for some
BIOS misconfigurations that sis-agp doesn't handle.
Signed-off-by: NBen Hutchings <ben@decadent.org.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes sparse warning:

drivers/char/agp/generic.c:1217:33: warning: Using plain integer as
NULL pointer
Signed-off-by: NBill Pemberton <wfp5p@virginia.edu>
CC: linux-kernel@vger.kernel.org
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Convert most AGP chipset to use scratch page as default entries.
This help avoiding GPU querying 0 address and trigger computer
fault. With KMS and memory manager we bind/unbind AGP memory
constantly and it seems that some GPU are still doing AGP
traffic even after GPU report being idle with the memory segment.

Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on :
- SIS 1039:0001 & 1039:0003
- Intel 865 8086:2571

Compile tested for other bridges

V2 enable scratch page on uninorth
V3 fix unbound check in uninorth insert memory (Michel Dänzer)
V4 rebase on top of drm-next branch with the lastest intel AGP
   changeset (stable should use version V3 of the patch)
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NMichel Dänzer <michel@daenzer.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On my 945 laptop + radeon GPU, I was getting an oops on boot without this
check which seems to have gotten dropped in the rework.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Not needed for the GTT and inconsistent: Sometimes the _new_ size
was stored there ...
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

We don't use the generic insert/remove_memory functions that
require this. So kill this useless code.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

This is essentially the last piece of code that's tying intel-gtt.c
to intel-agp.c. Extract the probe code into it's own function so that
it can be moved to intel-gtt.c.

This requires some slight changes in the ordering of device probe function.
This patch just implements that for better bisectability in case this
introduces bugs.

The biggest change is that the gmch/gtt code doesn't execute a pci
resource fixup anymore. I've dug around in historical git trees, and
this change is to support the agp port on an old HP server with the
i440 intel chipset. So only needed for the agp driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Always zero, i.e. unused.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Only two drivers were not in this table (7505 and g33), both non-mobile
chipsets. So they were most likely just missing. This is another step
to untangle the gtt from the agp driver.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

intel-agp.c contains actually two different drivers: An agp driver
for _physical_ agp slots an the gtt driver that is used by the intel
drm modules. Split them to prevent any further confusion.

This patch just moves the code and includes intel-gtt.c in intel-agp.c
Later patches will untangle these two drivers further.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Intel definitions have spilled into agp.h. Create a header file for
them and also include it in efficion-agp.c 'cause it needs a few of
them.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h

percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files.  percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.

percpu.h -> slab.h dependency is about to be removed.  Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability.  As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.

  http://userweb.kernel.org/~tj/misc/slabh-sweep.py

The script does the followings.

* Scan files for gfp and slab usages and update includes such that
  only the necessary includes are there.  ie. if only gfp is used,
  gfp.h, if slab is used, slab.h.

* When the script inserts a new include, it looks at the include
  blocks and try to put the new include such that its order conforms
  to its surrounding.  It's put in the include block which contains
  core kernel includes, in the same order that the rest are ordered -
  alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
  doesn't seem to be any matching order.

* If the script can't find a place to put a new include (mostly
  because the file doesn't have fitting include block), it prints out
  an error message indicating which .h file needs to be added to the
  file.

The conversion was done in the following steps.

1. The initial automatic conversion of all .c files updated slightly
   over 4000 files, deleting around 700 includes and adding ~480 gfp.h
   and ~3000 slab.h inclusions.  The script emitted errors for ~400
   files.

2. Each error was manually checked.  Some didn't need the inclusion,
   some needed manual addition while adding it to implementation .h or
   embedding .c file was more appropriate for others.  This step added
   inclusions to around 150 files.

3. The script was run again and the output was compared to the edits
   from #2 to make sure no file was left behind.

4. Several build tests were done and a couple of problems were fixed.
   e.g. lib/decompress_*.c used malloc/free() wrappers around slab
   APIs requiring slab.h to be added manually.

5. The script was run on all .h files but without automatically
   editing them as sprinkling gfp.h and slab.h inclusions around .h
   files could easily lead to inclusion dependency hell.  Most gfp.h
   inclusion directives were ignored as stuff from gfp.h was usually
   wildly available and often used in preprocessor macros.  Each
   slab.h inclusion directive was examined and added manually as
   necessary.

6. percpu.h was updated not to include slab.h.

7. Build test were done on the following configurations and failures
   were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
   distributed build env didn't work with gcov compiles) and a few
   more options had to be turned off depending on archs to make things
   build (like ipr on powerpc/64 which failed due to missing writeq).

   * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
   * powerpc and powerpc64 SMP allmodconfig
   * sparc and sparc64 SMP allmodconfig
   * ia64 SMP allmodconfig
   * s390 SMP allmodconfig
   * alpha SMP allmodconfig
   * um on x86_64 SMP allmodconfig

8. percpu.h modifications were reverted so that it could be applied as
   a separate patch and serve as bisection point.

Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: NTejun Heo <tj@kernel.org>
Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

... not a GTT driver. So the additional chipset flush introduced in

commit 2162e6a2
Author: Dave Airlie <airlied@redhat.com>
Date:   Wed Nov 21 16:36:31 2007 +1000

    agp/intel: Add chipset flushing support for i8xx chipsets.

to fix a GTT problem makes absolutely no sense. If this would really be needed
for AGP chipsets, too, we should add it to all i8xx agp drivers, not just one.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

This CPU should be coherent with graphics in this direction, though
flushing graphics caches are still required.  Fixes a system reset on
module load on Sandybridge with 4G+ memory.
Signed-off-by: NEric Anholt <eric@anholt.net>

This is similar to 14bc490b which
respected it for how much of the GTT we would actually use.  Now we
won't clear beyond allocated memory when filling the GTT with scratch
page addresses.
Signed-off-by: NEric Anholt <eric@anholt.net>

de957628 changed setting of the
x86_init.iommu.iommu_init function ptr only when GART IOMMU is
found.

One side effect of it is that num_k8_northbridges
is not initialized anymore if not explicitly
called. This resulted in uninitialized pointers in
<arch/x86/kernel/cpu/intel_cacheinfo.c:amd_calc_l3_indices()>,
for example, which uses the num_k8_northbridges thing through
node_to_k8_nb_misc().

Fix that through an initcall that runs right after the PCI
subsystem and does all the scanning. Then, remove initialization
in gart_iommu_init() which is a rootfs_initcall and we're
running before that.

What is more, since num_k8_northbridges is being used in other
places beside GART IOMMU, include it whenever we add AMD CPU
support. The previous dependency chain in kconfig contained

K8_NB depends on AGP_AMD64|GART_IOMMU

which was clearly incorrect. The more natural way in terms of
hardware dependency should be

AGP_AMD64|GART_IOMMU depends on K8_NB depends on CPU_SUP_AMD &&
PCI. Make it so Number One!
Signed-off-by: NBorislav Petkov <borislav.petkov@amd.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
Cc: Joerg Roedel <joerg.roedel@amd.com>
LKML-Reference: <20100312144303.GA29262@aftab>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
Tested-by: NJoerg Roedel <joerg.roedel@amd.com>

See http://bugzilla.kernel.org/show_bug.cgi?id=15021

Make sure that the appropriate AGP module is loaded and probed before
trying to set up the DRM.  The DRM already depends on the AGP core,
but in this case we know the specific AGP driver we need too, and can
help users avoid the trap of loading the AGP driver after the DRM
driver.
Signed-off-by: NZhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NEric Anholt <eric@anholt.net>