linux.git/drivers/char/agp, branch v3.6

drm/i915: fix hsw uncached pte

2012-08-17T07:21:35+00:00

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

V2: remove unused 'is_hsw' field.

Signed-off-by: Daniel Vetter 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter

drm/i915: add more Haswell PCI IDs

2012-08-07T11:17:33+00:00

Also properly indent the HB IDs.

Reviewed-by: Rodrigo Vivi 
Signed-off-by: Paulo Zanoni 
Signed-off-by: Daniel Vetter

agp/intel-agp: remove snb+ host bridge pciids

2012-06-25T19:10:35+00:00

drm/i915 now takes care itself of setting up the gtt for
these chips.

Reviewed-by: Eugeni Dodonov 
Signed-off-by: Daniel Vetter

Merge tag 'v3.5-rc4' into drm-intel-next-queued

2012-06-25T17:10:36+00:00

I want to merge the "no more fake agp on gen6+" patches into
drm-intel-next (well, the last pieces). But a patch in 3.5-rc4 also
adds a new use of dev->agp. Hence the backmarge to sort this out, for
otherwise drm-intel-next merged into Linus' tree would conflict in the
relevant code, things would compile but nicely OOPS at driver load :(

Conflicts in this merge are just simple cases of "both branches
changed/added lines at the same place". The only tricky part is to
keep the order correct wrt the unwind code in case of errors in
intel_ringbuffer.c (and the MI_DISPLAY_FLIP #defines in i915_reg.h
together, obviously).

Conflicts:
	drivers/gpu/drm/i915/i915_reg.h
	drivers/gpu/drm/i915/intel_ringbuffer.c

Signed-Off-by: Daniel Vetter

agp/intel: use correct GTT offset on VLV

2012-06-20T20:49:46+00:00

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: Jesse Barnes 
Signed-off-by: Daniel Vetter

agp/intel: allow cacheable and GDFT PTEs on ValleyView

2012-06-20T20:49:45+00:00

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: Jesse Barnes 
[danvet: Added note.]
Signed-off-by: Daniel Vetter

drm/i915: call intel_enable_gtt

2012-06-12T20:21:07+00:00

When drm/i915 is in control of the gtt, we need to call
the enable function at all the relevant places ourselves.

Reviewed-by: Jani Nikula 
Signed-off-by: Daniel Vetter

agp/intel-gtt: move gart base addres setup

2012-06-12T20:20:28+00:00

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: Jani Nikula 
Signed-off-by: Daniel Vetter

drm/i915 + agp/intel-gtt: prep work for direct setup

2012-06-12T20:19:49+00:00

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: Jani Nikula 
Signed-Off-by: Daniel Vetter

agp/intel-gtt: don't require the agp bridge on setup

2012-06-12T20:18:54+00:00

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: Jani Nikula 
Signed-off-by: Daniel Vetter