gen2 hardware has some significant differences from the other interrupt
routines that were glossed over and then forgotten about in the
transition to KMS. Such as

- 16bit IIR
- PendingFlip status bit

This patch reintroduces a handler specifically for gen2 for the purpose
of handling pageflips correctly, simplifying code in the process.

v2: Also fixup ring get/put irq to only access 16bit registers (Daniel)

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=24202
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41793Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: use posting_read16 in intel_ringbuffer.c and kill _driver
from the function names.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we fail to unbind and so abort the change in tiling, we will have
removed the VMA for the object for no reason. The likelihood of unbind
failing is slim (other than ERESTARTSYS which will cause userspace to
try again), so the change is mostly for the principle.

Also improve the slightly stale comment.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rename obj->tiling_changed to obj->fence_dirty so that it is clear that
it flags when the parameters for an active fence (including the
no-fence) register are changed.

Also, do not set this flag when the object does not have a fence
register allocated currently and the gpu does not depend upon the
unfence. This case works exactly like when a tiled object lost its
fence and hence does not need additional handling for the tiling
change in the code.

v2: Use fence_dirty to better express what the flag tracks and add a few
more details to the comments to serve as a reminder of how the GPU also
uses the unfenced register slot.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: Add some bikeshed to the commit message about the stricter
use of fence_dirty.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When fixing up the crt load detect code I've failed to notice the same
problem in the tv load detect code. Again, unconditionally use the
load detect pipe infrastructure, it gets things right.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This got lost in the intel_pm.c move.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As with one of the earlier patches in the series, we're forced to cast
for copy_[to|from]_user. Again because of the nature of the GEN x86
exclusivity, this should be safe.
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
[danvet: Added some bikeshed.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These were mostly straight forward. No forced casting needed.
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
[danvet: fix conflict with ringbuffer_data removal and drop the hunk
about the status page - that needs more care to fix up.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the exception of a forced cast for phys_obj stuff (a problem in
other patches as well) all of these are fairly simple __iomem compliance
fixes.

As with other patches, yank/paste errors may exist.
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
[danvet: Added comment to explain the __iomem cast.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Almost all of the errors related __iomem problems.

Most of the changes here are trivial, however there is plenty of chance
for yank/paste errors.
Signed-off-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This was originally used as an attempt to diagnose GPU hangs, but was
never very reliable and superseded by the i915_error_state capture on
hangcheck. It now lies languishing unused and unwanted.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

IvyBridge requires an extra frame between disabling the low power
watermarks and enabling scaling on the sprite plane. If the scaling
is already enabled, then we have already disabled the low power
watermarks and need not incur an extra wait.

Similarly, as we disable the scaling when turning off the sprite plane,
we can update the scaling enabled flag and restore the low power
watermarks.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Pretty useful to debug our DP bandwidth woes.

v2: Also print out the required and available link bandwidth,
suggested by Chris Wilson.

v3: Also print out the input parameters so that diagnosing failures to
find a valid dp link configuration is possible.

v4: s/Display port/DP/ to shorten the output.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Merge tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel into drm-core-next

Daniel Vetter writes:

A new drm-intel-next pull. Highlights:
- More gmbus patches from Daniel Kurtz, I think gmbus is now ready, all
 known issues fixed.
- Fencing cleanup and pipelined fencing removal from Chris.
- rc6 residency interface from Ben, useful for powertop.
- Cleanups and code reorg around the ringbuffer code (Ben&me).
- Use hw semaphores in the pageflip code from Ben.
- More vlv stuff from Jesse, unfortunately his vlv cpu is doa, so less
 merged than I've hoped for - we still have the unused function warning :(
- More hsw patches from Eugeni, again, not yet enabled fully.
- intel_pm.c refactoring from Eugeni.
- Ironlake sprite support from Chris.
- And various smaller improvements/fixes all over the place.

Note that this pull request also contains a backmerge of -rc3 to sort out
a few things in -next. I've also had to frob the shortlog a bit to exclude
anything that -rc3 brings in with this pull.

Regression wise we have a few strange bugs going on, but for all of them
closer inspection revealed that they've been pre-existing, just now
slightly more likely to be hit. And for most of them we have a patch
already. Otherwise QA has not reported any regressions, and I'm also not
aware of anything bad happening in 3.4.

* tag 'drm-intel-next-2012-04-23' of git://people.freedesktop.org/~danvet/drm-intel: (420 commits)
  drm/i915: rc6 residency (fix the fix)
  drm/i915/tv: fix open-coded ARRAY_SIZE.
  drm/i915: invalidate render cache on gen2
  drm/i915: Silence the change of LVDS sync polarity
  drm/i915: add generic power management initialization
  drm/i915: move clock gating functionality into intel_pm module
  drm/i915: move emon functionality into intel_pm module
  drm/i915: move drps, rps and rc6-related functions to intel_pm
  drm/i915: fix line breaks in intel_pm
  drm/i915: move watermarks settings into intel_pm module
  drm/i915: move fbc-related functionality into intel_pm module
  drm/i915: Refactor get_fence() to use the common fence writing routine
  drm/i915: Refactor fence clearing to use the common fence writing routine
  drm/i915: Refactor put_fence() to use the common fence writing routine
  drm/i915: Prepare to consolidate fence writing
  drm/i915: Remove the unsightly "optimisation" from flush_fence()
  drm/i915: Simplify fence finding
  drm/i915: Discard the unused obj->last_fenced_ring
  drm/i915: Remove unused ring->setup_seqno
  drm/i915: Remove fence pipelining
  ...

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Tested-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we want hdmi_offset to be relative to the first block, zero value can
be used also for enabled block.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Tested-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

R6xx has routable blocks, but there's nothing wrong in assignment based
on dig_encoder. We didn't really need that algorithm.
Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Tested-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Tested-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NRafał Miłecki <zajec5@gmail.com>
Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
Tested-by: NChristian König <deathsimple@vodafone.de>
Reviewed-by: NChristian König <deathsimple@vodafone.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this fixes a report that the new load code needed to be updated for
ajax's validity changes.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This helper macro retrieves the fractional part of a fixed20_12 20.12
fixed-point number.
Signed-off-by: NRobert Morell <rmorell@nvidia.com>
Signed-off-by: NOlof Johansson <olofj@chromium.org>
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Some boards such as the Intel D2700MUD allow you to have over 4GB of RAM.
The GTT on the PVR based devices is 32bit however. Hugh Dickins points out
that we should therefore be setting the mapping gfp mask.

This is not the whole fix for the problem. Some further shmem patches will
be needed to deal with the corner cases.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This provides the needed callback hooks to add hotplug display support to
the GMA36x0 devices.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In particular clean up the errata handling and correct the crtc masks. We do
this a bit differently using our device abstraction for neatness.

This doesn't address the ACPI opregion and hotplug plumbing, nor the IRQ related
changes that will need. It touches on backlight init but the full backlight
support is not in this change set.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The problem in console mode is lack of linear memory. We can solve that by
dropping to 16bpp. The mode setting X server will allocate its own GEM
framebuffer in 32bpp and all will be well.

We could just do 16bpp anyway but that would be a regression on the lower
modes as many distributions don't yet ship the generic mode setting KMS
drivers.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Introduce a panel presence check for Cedartrail. Non netbook devices don't
necessarily have a panel attached.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Pull in various i915 bits that we will need to begin tackling the LVDS detect
and ACPI events. We try and drift towards the i915 version of the code with
the long term goal that at least some of it can one day be unified.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We don't want them uncached, combining will do nicely and fixes the performance
problem with the generic modesetting X server.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

We need to pull more stuff from the VBT in order to configure the clocking
correctly in all cases. Add the relevant bits from the other CDV driver work.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This was reported a long time ago (and I apologize to whoever it was that
reported it as I've lost the original report).
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

EDID vendor IDs are always 3 characters long (4 with the terminating
0).  It doesn't make any sense to have a (possibly 8-byte) pointer
to the ID string in the quirk structure.
Signed-off-by: NIan Pilcher <arequipeno@gmail.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Requiring the first byte of the EDID base block header to be 0 means we
don't fix up as many transfer errors as we could.  Instead have the
callers specify whether it's meant to be block 0 or not, and
conditionally run header fixup based on that.

Bugzilla: https://bugzilla.redhat.com/812890Signed-off-by: NAdam Jackson <ajax@redhat.com>
Reviewed-by: NAlex Deucher <alexdeucher@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This fixes the build breakage reported by Stephen in -next
when merging the drm-next tree.
Signed-off-by: NDave Airlie <airlied@redhat.com>

The error handling code w.r.t. idr usage looks inconsistent.

In the case of drm_mode_object_get() and drm_ctxbitmap_next() the error
handling is also incomplete.

Unify the code to follow the same pattern always.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since Matthew's changes we have to select arbitration.

Reported-by: devh on #radeon
Signed-off-by: NDave Airlie <airlied@redhat.com>

EFI doesn't typically make use of the legacy VGA ROM, but it may still be
configured to pass that through to a given video device. This may lead to
an inaccurate choice of default video device. Add support to efifb to pick
out the correct active video device.

v2: fix if->ifdef
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Acked-by: hpa@zytor.com
Cc: matt.fleming@intel.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

IORESOURCE_ROM_SHADOW is not necessarily an indication that the hardware
is the primary device. Add support for using the vgaarb functions and
fall back if nothing's set them.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Cc: mingo@redhat.com
Acked-by: hpa@zytor.com
Signed-off-by: NDave Airlie <airlied@redhat.com>

vga-switcheroo currently changes the default VGA device by fiddling with
the IORESOURCE_ROM_SHADOW flag on the device. This isn't strictly accurate,
since there's no guarantee that switching also changes the ROM decoding.
Switch over to using the vgaarb functions for this.
Signed-off-by: NMatthew Garrett <mjg@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>