<ickle> danvet: in the force wake, both DRM_ERRORs have the same string.
<ickle> useful for .txt shrinkage, horrible for debugging
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For some odd reasons, the vlv forcewake code is rather different from
all other platforms, with no clear justification. Adjust things:

- Don't check whether the gt is awake already (and bail out early), we
  need to grab a forcewake anyway. Otherwise the chip might go to
  sleep too early. And this would also screw up our forcewake
  accounting.
- Like all other platforms, check whether the gt has cleared the
  forcewake bit in the _ACK register before setting it again.
- Use _MASKED_BIT_ENABLE/DISABLE macros
- Only use bit0 of the forcewake reg, not all 16 bits.
- check the gtfifodb reg like on all other platforms in _put.
- Drop the POSTING_READs for consistency.

v2: Failure to git add ... again.

v3: Fixup the spelling fail a bit.
Tested-by: N"Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>
Tested-by: N"Widawsky, Benjamin" <benjamin.widawsky@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We've had and still have too many issues where the gpu turbo doesn't
quite to what it's supposed to do (or what we want it to do).

Adding a tracepoint to track when the desired gpu frequency changes
should help a lot in characterizing and understanding problematic
workloads.

Also, this should be fairly interesting for power tuning (and
especially noticing when the gpu is stuck in high frequencies, as has
happened in the past) and hence for integration into powertop and
similar tools.

Cc: Arjan van de Ven <arjan@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Like with the equivalent change for gen6+ rps state, this helps in
clarifying the code (and in fixing a few places that have fallen through
the cracks in the locking review).
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:

"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."

Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.

There's also a second workaround for the PIPE_CONTROL command itself:

"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"

For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+

Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.

This is a regression that has been introduced in the pipe_control
cleanup:

commit 6c6cf5aa
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Jul 20 18:02:28 2012 +0100

    drm/i915: Only apply the SNB pipe control w/a to gen6

It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since gen 7+ now run the new gen7_render_ring_flush function.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For now, just a copy of gen6_render_ring_flush. Different gens have
different workarounds, so we want different functions.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise it just won't compile ...
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

When I pulled-in today's drm-intel-next into linux-next (next-20120824)
I saw this build-breakage:

drivers/gpu/drm/i915/i915_gem.c: In function 'i915_gem_object_get_pages_gtt':
drivers/gpu/drm/i915/i915_gem.c:1778:40: error: '__GFP_NO_KSWAPD' undeclared (first use in this function)
drivers/gpu/drm/i915/i915_gem.c:1778:40: note: each undeclared identifier is reported only once for each function it appears in

This is caused by commit ba099ef165f8 ("mm: remove __GFP_NO_KSWAPD")
and commit b6beae2c2014 ("mm: remove __GFP_NO_KSWAPD fixes") in
linux-next (next-20120824).

Fix this by removing __GFP_NO_KSWAPD from drm/i915 driver.
Signed-off-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It blows up. And hopefully this is the root-cause of the mysterious
rc6 related hang on ilk. For reference, the commit that enabled rc6 on
ilk again is:

commit 456470eb
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Aug 8 23:35:40 2012 +0200

    drm/i915: enable rc6 on ilk again
Reported-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit d70e551c, Add " 2GB ATA Flash
Disk"/"ADMA428M" to DMA blacklist, should have added a space before 2GB.
Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
Signed-off-by: NJeff Garzik <jgarzik@redhat.com>

If we need to stall in order to complete the pin_and_fence operation
during execbuffer reservation, there is a high likelihood that the
operation will be interrupted by a signal (thanks X!). In order to
simplify the cleanup along that error path, the object was
unconditionally unbound and the error propagated. However, being
interrupted here is far more common than I would like and so we can
strive to avoid the extra work by eliminating the forced unbind.

v2: In discussion over the indecent colour of the new functions and
unwind path, we realised that we can use the new unreserve function to
clean up the code even further.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Using the extracted INSTDONE reading, and our new register definitions,
update our hangcheck detection and error collection to use it. This
primarily means changing == to memcmp, and changing = to memcpy.
Hopefully this will give more info on error dump, and provide more
accurate hangcheck detection (both are actually TBD).

Also, remove the reading of instdone1 from the ring error collection
function, and just crap everything in capture_error_state (that could be
split into a separate patch if it wasn't so trivial).

v2: Now assuming i915_get_extra_instdone does the memset we can clean up the
code a bit (Jani)

v3: use ARRAY_SIZE as requested earlier by Jani (didn't change sizeof)
Updated commit msg

Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

INSTDONE is used in many places, and it varies from generation to
generation. This provides a good reason for us to extract the logic to
read the relevant information.

The patch has no functional change. It's prep for some new stuff.

v2: move the memset inside of i915_get_extra_instdone (Jani)
v3,4: bugs caught by (Jani)
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The principal use for set-to-domain is for userspace to serialise
operations with a particular buffer, for example to maintain coherency
with a CPU map or to ratelimit its rendering by waiting on all previous
operations before continuing. As such we tend to hold the struct_mutex
for long periods during the synchronisation and so cause contention
issues with other users of the graphics device, even for independent
operations as memory management. An example is the contention between
compiz and X which causes jitter in the display and a drop in peak
throughput.

The ultimate solution would be a set of fine grained locks and lockless
operations, but an intermediate step is to first attempt the
synchronisation for set-to-domain without holding the mutex. This
introduces a number of race conditions, so we limit it use to the ioctl
periphery where we have no dependent state and can safely complete with
a locked synchronisation afterwards.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the wait-for-rendering logic around in the file so that we can
group it together with the subsequent variations. The general goal is to
have the lower level routines clustered together and then the higher
level logic building upon those low level routines that came before.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If we have a 266MHz part we set core_freq to 0 in several spots
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

Another reference to raw_edid field of struct drm_display_info was added in
gma500 while the whole field was being removed, causing build
failure. Remove the hopefully last references to raw_edid.
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@gmail.com>

this header was incorrect, caused a build failure.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This prevents the case of unbinding the object in order to process the
relocations through the GTT and then rebinding it only to then proceed
to use cpu relocations as the object is now in the CPU write domain. By
choosing to use cpu relocations up front, we can therefore avoid the
rebind penalty.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As we wish to create specialised object constructions in the near
future that share the same basic GEM object struct, export the default
initializer.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If the object has no backing shmemfs filp, then we obviously cannot
perform a truncation operation upon it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Avoid stalling and waiting for the GPU by checking to see if there is
sufficient inactive space in the aperture for us to bind the buffer
prior to writing through the GTT. If there is inadequate space we will
have to stall waiting for the GPU, and incur overheads moving objects
about. Instead, only incur the clflush overhead on the target object by
writing through shmem.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixes the following sparse warning:
drivers/gpu/drm/drm_fb_helper.c:239:6: warning:
symbol 'drm_fb_helper_force_kernel_mode' was not declared. Should it be static?
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes the following sparse warning:
drivers/gpu/drm/drm_irq.c:1239:6:
warning: symbol 'drm_handle_vblank_events' was not declared. Should it be static?
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The I2C specific suspend and resume functions have been deprecated and
printing a warning on boot for over a year, dev_pm_ops should be used
instead so convert to that.

Also remove the suspend function since all it does is log.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DRM_USB selects USB. However, USB depends on USB_SUPPORT and USB_ARCH_HAS_HCD.
Thus, selecting USB_SUPPORT in Kconfig avoids the following warning
(detected when DisplayLink was selected using exynos4_defconfig):

warning: (MOUSE_APPLETOUCH && MOUSE_BCM5974 && MOUSE_SYNAPTICS_USB && JOYSTICK_XPAD && TABLET_USB_ACECAD && TABLET_USB_AIPTEK && TABLET_USB_HANWANG && TABLET_USB_KBTAB && TABLET_USB_WACOM && TOUCHSCREEN_USB_COMPOSITE && INPUT_ATI_REMOTE2 && INPUT_KEYSPAN_REMOTE && INPUT_POWERMATE && INPUT_YEALINK && INPUT_CM109 && RC_ATI_REMOTE && IR_IMON && IR_MCEUSB && IR_REDRAT3 && IR_STREAMZAP && IR_IGUANA && DRM_USB) selects USB which has unmet direct dependencies (USB_SUPPORT && USB_ARCH_HAS_HCD)
Signed-off-by: NSachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is set when setting DPMS on and off, but it isn't checked anywhere,
so just remove it.
Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NForest Bond <forest.bond@rapidrollout.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NHuacai Chen <chenhc@lemote.com>
Signed-off-by: NHongliang Tao <taohl@lemote.com>
Signed-off-by: NHua Yan <yanh@lemote.com>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Neither the drm core nor any of the drivers really need the raw_edid field
of struct drm_display_info for anything. Instead of being useful, it
creates confusion about who is responsible for freeing the memory it points
to and setting the field to NULL afterwards, leading to memory leaks and
dangling pointers.

Remove the raw_edid field, and fix drivers as necessary.
Reported-by: NRussell King <linux@arm.linux.org.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Acked-by: NInki Dae <inki.dae@samsung.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EDID returned by drm_get_edid() was never freed.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The EDID returned by drm_get_edid() was never freed.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

We should be making this call not praying that the values are right.
In addition as noted by Josiah Standing we should be calling this
for eDP as well.
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NAlan Cox <alan@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>