None of these files are actually using any __init type directives
and hence don't need to include <linux/init.h>.  Most are just a
left over from __devinit and __cpuinit removal, or simply due to
code getting copied from one driver to the next.

Cc: David Airlie <airlied@linux.ie>
Cc: Matt Mackall <mpm@selenic.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Corey Minyard <minyard@acm.org>
Cc: Chris Metcalf <cmetcalf@tilera.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Peter Huewe <peterhuewe@gmx.de>
Cc: Ashley Lai <ashley@ashleylai.com>
Cc: Marcel Selhorst <tpmdd@selhorst.net>
Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>

In i810_setup(), i830_setup(), and i9xx_setup(), we use the result of
pci_bus_address() as an argument to ioremap() and to compute gtt_phys_addr.
These should use pci_resource_start() instead because we want the CPU
physical address, not the bus address.

If there were an AGP device behind a host bridge that translated addresses,
e.g., a PNP0A08 device with _TRA != 0, this would fix a bug.  I'm not aware
of any of those, but they are possible.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
GTTADR is a standard PCI BAR.

The PCI core reads GTTADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit GTTADR, but we
should still use the standard interface.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
MMADR is a standard PCI BAR.

The PCI core reads MMADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit MMADR, but we
should still use the standard interface.

Also, stop clearing the low 19 bits of the bus address because it's invalid
to use addresses outside the region defined by the BAR.  The spec claims
MMADR is 512KB; if that's the case, those bits will be zero anyway.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Per the Intel 915G/915GV/... Chipset spec (document number 301467-005),
GMADR is a standard PCI BAR.

The PCI core reads GMADR at enumeration-time.  Use pci_bus_address()
instead of reading it again in the driver.  This works correctly for both
32-bit and 64-bit BARs.  The spec above only mentions 32-bit GMADR, but
Yinghai's patch (link below) indicates some devices have a 64-bit GMADR.

[bhelgaas: reworked starting from http://lkml.kernel.org/r/1385851238-21085-13-git-send-email-yinghai@kernel.org]
Signed-off-by: NYinghai Lu <yinghai@kernel.org>
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The only use of gtt_bus_addr is as an argument to ioremap(), so it is a CPU
physical address, not a bus address.  Rename it to gtt_phys_addr to reflect
this.

No functional change.
Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only depend on the intel-gtt module for GTT frobbign on older gens.
The intel_agp module is optional, except for UMS and some old XvMC
userland on gen3. So make AGP support optional. As before, we will
fail the i915 init for UMS and gen3 KMS the same as before if
intel_agp isn't around.

intel-gtt.c is left with a somewhat ugly ifdef mess, but I'm going
to save that for a later cleaning.

At least my gen2 still works with the patch and CONFIG_AGP=n.

v2: Make i915 depend on X86 and PCI, and intel-gtt depend on PCI
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Whilst IOMMU is enabled for the Intel GPU on Ironlake, it appears that
using WC writes to update the PTE on the GPU fails miserably. The
result looks like the majority of the writes do not land leading to
lots of screen corruption and a hard system hang.

v2: s/</<=/ to preserve the current exclusion of Sandybridge
Reported-by: NNathan Myers <ncm@cantrip.org>
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NNathan Myers <ncm@cantrip.org>
[danvet: Remove cc: stable and add tested-by.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When I refactored the code initially, I forgot that gen2 uses a
different bar for the CPU mappable aperture. The agp-less code knows
nothing of generations less than 5, so we have to expand the gtt_probe
function to include the mappable base and end.

It was originally broken by me:
commit baa09f5f
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jan 24 13:49:57 2013 -0800

    drm/i915: Add probe and remove to the gtt ops
Reported-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the probe call in our dispatch table, we can now cut away the
last three remaining members in the intel_gtt shared struct and so
remove it completely.

v2: Rebased on top of Daniel's series
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
[danvet: bikeshed commit message a bit.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It is no longer used in the i915 code, so isolate it from the shared
struct.

This was originally part of:
commit 0e275518f325418d559c05327775bff894b237f7
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Mon Jan 14 13:35:33 2013 -0800

    agp/intel: decouple more of the agp-i915 sharing
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>

That commit had some other hunks which can't be used due to issues
Daniel found in previous commits.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: drop squash notice from the commit since it's imo ok to keep
this one separate.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The reasoning behind our code taking two paths depending upon whether or
not we may have been configured for IOMMU isn't clear to me. It should
always be safe to use the pci mapping functions as they are designed to
abstract the decision we were handling in i915.

Aside from simpler code, removing another member for the intel_gtt
struct is a nice motivation.

I ran this by Chris, and he wasn't concerned about the extra kzalloc,
and memory references vs. page_to_phys calculation in the case without
IOMMU.

v2: Update commit message

v3: Remove needs_dmar addition from Zhenyu upstream

This reverts (and then other stuff)
commit 20652097
Author: Zhenyu Wang <zhenyuw@linux.intel.com>
Date:   Thu Dec 13 23:47:47 2012 +0800

    drm/i915: Fix missed needs_dmar setting

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Squash in follow-up fix to remove the bogus hunk which
deleted the dma_mask configuration for gen6+.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already had a mapping in both (minus the phys_addr in AGP).
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

And, move it to where the rest of the logic is.

There is some slight functionality changes. There was extra paranoid
checks in AGP code making sure we never do idle maps on gen2 parts. That
was not duplicated as the simple PCI id check should do the right thing.

v2: use IS_GEN5 && IS_MOBILE check instead. For now, this is the same as
IS_IRONLAKE_M but is more future proof. The workaround docs hint that
more than one platform may be effected, but we've never seen such a
platform in the wild. (Rodrigo, Daniel)

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This removes an unused field from the AGP structure and moves it into
the dev_priv structure (with a slightly better name). This builds upon
the kill-agp series already merged.

GSM is a well defined term in the bspec:
GSM: Graphics Stolen Memory

GTT stolen space is defined for storage of the GFX GTT entries in
physical memory. IA can not access GSM directly , it can only access via
GTTMMADR. GT can access GSM directly or through GTTMMADR.

This is not the entire stolen space.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Accidently removed an ILK case in i9xx_setup (Nicely found by Chris)

CC: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by [v1] : Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As a quick hack we make the old intel_gtt structure mutable so we can
fool a bunch of the existing code which depends on elements in that data
structure. We can/should try to remove this in a subsequent patch.

This should preserve the old gtt init behavior which upon writing these
patches seems incorrect. The next patch will fix these things.

The one exception is VLV which doesn't have the preserved flush control
write behavior. Since we want to do that for all GEN6+ stuff, we'll
handle that in a later patch. Mainstream VLV support doesn't actually
exist yet anyway.

v2: Update the comment to remove the "voodoo"
Check that the last pte written matches what we readback

v3: actually kill cache_level_to_agp_type since most of the flags will
disappear in an upcoming patch

v4: v3 was actually not what we wanted (Daniel)
Make the ggtt bind assertions better and stricter (Chris)
Fix some uncaught errors at gtt init (Chris)
Some other random stuff that Chris wanted

v5: check for i==0 in gen6_ggtt_bind_object to shut up gcc (Ben)
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by [v4]: Chris Wilson <chris@chris-wilson.co.uk>
[danvet: Make the cache_level -> agp_flags conversion for pre-gen6 a
tad more robust by mapping everything != CACHE_NONE to the cached agp
flag - we have a 1:1 uncached mapping, but different modes of
cacheable (at least on later generations). Suggested by Chris Wilson.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It doesn't work since the gtt pte range sits in the middle of the mmio
bar. We didn't notice that since both my and Chris' gen2 machines
don't support PAT and hence all wc io mapping request will
automatically be demoted to uc.

This regression has been introduce in

commit edef7e68
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Sep 14 11:57:47 2012 +0100

    agp/intel: Use a write-combining map for updating PTEs
Reported-by: NEgbert Eich <eich@pdx.freedesktop.org>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55834Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rewriting the PTE entries using an WC mapping is roughly an order of
magnitude faster than through the uncached mapping. This makes an
observable difference on workloads that cycle through large numbers of
buffers, for example Chromium using ShmPixmaps where virtually all the
CPU time is currently spent rebinding the userptr.

v2: Limit the WC mapping to older generations as we have observed that
the TLB invalidation on SandyBridge+ is unreliable with WC updates.
See i-g-t/tests/gem_gtt_cpu_tlb
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.

One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.

The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.

v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

They've changed it ... for no apparent reason. Meh.

V2: remove unused 'is_hsw' field.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also properly indent the HB IDs.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV is a gen7 device, but we don't currently handle that in the switch.
So add it and write the PTEs correctly.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The PTE format is similar to SNB, but we don't support an MLC and don't
need chipset flushing.

Note: I have my questions whether this is right, given that MLC died
for snb & ivb, that ivb has grown a L3$ cache instead (which vlv seems
to have, too) and that the LLC bit here isn't actually LLC, but just
means 'snoop cpu caches'.

But I plan to burn this all with the heat of a thousands suns in my
gtt rework, so who cares ;-)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Added note.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this thing much earlier, and it doesn't make sense
in the hw enabling function intel_enable_gtt - this does not
change over a suspend/resume cycle ...
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To be able to directly set up the intel-gtt code from drm/i915 and
avoid setting up the fake-agp driver we need to prepare a few things:
- pass both the bridge and gpu pci_dev to the probe function and add
  code to handle the gpu pdev both being present (for drm/i915) and
  not present (fake agp).
- add refcounting to the remove function so that unloading drm/i915
  doesn't kill the fake agp driver

v2: Fix up the cleanup and refcount, noticed by Jani Nikula.
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We only need it to fake the agp interface and don't actually
use it in the driver anywhere. Hence conditionalize that.

This is just a prep patch to eventually disable the fake agp
driver on gen6+.
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For that to work we need to export the base address of the gtt
mmio window from intel-gtt. Also replace all other uses of
dev->agp by values we already have at hand.
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a leftover from the conversion of the i81x fake agp driver
over to the new intel-gtt code layoute.
Reviewed-by: NJani Nikula <jani.nikula@linux.intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds product definitions for desktop, mobile and server boards.

v2: split into a separate patch, add .has_pch_split feature.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Totally unexpected that this regressed. Luckily it sounds like we just
need to have dmar disable on the igfx, not the entire system. At least
that's what a few days of testing between Tony Vroon and me indicates.
Reported-by: NTony Vroon <tony@linx.net>
Cc: Tony Vroon <tony@linx.net>
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43024Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This adds PCI ID for IVB GT2 server variant which we were missing.
Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
[danvet: fix up conflict because the patch has been diffed against next. tsk.]
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

... and bind it right to the PCI id.

Note that there are still a few things to fix here:
- we need to move the tlb flush to a better place in drm/i915.
- we need to check snoop support on vlv and implement it.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
[danvet: squash follow-on patch and add todo items to commit msg.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to flush the Gunit TLB when we update GTT PTEs on VLV, but the
register for doing so is above the range we normally map.  Map the whole
register space to make sure we can get it.

v2: only map the larger space on gen7+ (Daniel)
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need this because ppgtt page directory entries need to be in the
global gtt pagetable.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

To implement a PPGTT for drm/i915 that fully aliases the GTT, we also
need to properly alias the scratch page.
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>

The semi-colon is a typo here and it makes the if statement
unconditional.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: NKeith Packard <keithp@keithp.com>

Kernels with no iommu support cannot ever need the Ironlake
work-around, so never enable it in that case.

Might be better to completely remove the work-around from the kernel
in this case?
Signed-off-by: NKeith Packard <keithp@keithp.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>