Jesse's initial patch commit said:

"At panic time (i.e.  when oops_in_progress is set) we should try a bit
harder to update the screen and make sure output gets to the VT, since
some drivers are capable of flipping back to it.

So make sure we try to unblank and update the display if called from a
panic context."

I've enhanced this to add a flag to the vc that console layer can set to
indicate they want this behaviour to occur.  This also adds support to
fbcon for that flag and adds an fb flag for drivers to indicate they want
to use the support.  It enables this for KMS drivers.
Signed-off-by: NDave Airlie <airlied@redhat.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NJames Simmons <jsimmons@infradead.org>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work().  The former returns 0 on success and -errno on
failures while the latter never fails and only uses the return value
to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages.  Remove the now
unnecessary return value check and error message.

Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()
Signed-off-by: NTejun Heo <tj@kernel.org>
Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Tested-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org

Commit 5349ef31 (drm/fb: fix
FBIOGET/PUT_VSCREENINFO pixel clock handling) changed the logic of
when a pixclock was valid vs invalid.

The atomic kernel mode setting used by the kernel debugger relies upon
the drm_fb_helper_check_var() to always return -EINVAL.  Until a
better solution exists, this behavior will be restored.

CC: David Airlie <airlied@linux.ie>
CC: Jesse Barnes <jbarnes@virtuousgeek.org>
CC: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

If the HW compression is left on, the call backs from the HW will
crash the kernel.  The only time this code is called is when kernel
mode setting is in use with kgdb and the kdb shell.

The atomic display pipe handler callback will reset everything when
kgdb restores kernel to the run state.
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
CC: David Airlie <airlied@linux.ie>

Implement atomic kernel mode settings using the fb layer's debug hook
system for supporting debugger interaction.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

Implement the callbacks for KDB entry/exit via the drm helpers.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NJason Wessel <jason.wessel@windriver.com>

This restricts the use of the big kernel lock to the i830 and i810
device drivers. The three remaining users in common code (open, ioctl
and release) get converted to a new mutex, the drm_global_mutex,
making the locking stricter than the big kernel lock.

This may have a performance impact, but only in those cases that
currently don't use DRM_UNLOCKED flag in the ioctl list and would
benefit from that anyway.

The reason why i810 and i830 cannot use drm_global_mutex in their
mmap functions is a lock-order inversion problem between the current
use of the BKL and mmap_sem in these drivers. Since the BKL has
release-on-sleep semantics, it's harmless but it would cause trouble
if we replace the BKL with a mutex.

Instead, these drivers get their own ioctl wrappers that take the
BKL around every ioctl call and then set their own handlers as
DRM_UNLOCKED.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

In most use cases the driver will be using the same static config all
the time: interpreting i2c_board_info::platform_data as the default
config we can can save the GPU driver a redundant set_config() call.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is required should we ever attempt to use an io-mapping where
KM_USER0 is verboten, such as inside an IRQ context.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: NDave Airlie <airlied@redhat.com>

R4xx also uses the atom add connector function, but underscan is only
supported on avivo chips.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

v2: Userspace (notably xf86-video-{intel,ati}) became confused when
drmSetInterfaceVersion() started returning -EBUSY as they used a second
call (the first done in drmOpen()) to check their master credentials.
Since userspace wants to be able to repeatedly call
drmSetInterfaceVersion() allow them to do so.

v3: Rebase to drm-core-next.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

On non laptop systems we'll see these the whole time, so make them
less important.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This connector attribute allows you to enable or disable underscan
on a digital output to compensate for panels that automatically
overscan (e.g., many HDMI TVs).  Valid values for the attribute are:

off - forces underscan off
on - forces underscan on
auto - enables underscan if an HDMI TV is connected, off otherwise

default value is auto.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Prior to this patch the code was dividing the src_v by the dst_h
and vice versa, rather than src_v/dst_v and src_h/dst_h.

This could lead to problems in the calculation of the display
watermarks.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Intel variants don't support it.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Logic was:
if (mode0 && mode1)
else if (mode0)
else

Should be:
if (mode0 && mode1)
else if (mode0)
else if (mode1)

Otherwise we may end up calculating the priority regs with
unitialized values.

Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=16492Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

I wrote this for the prime sharing work, but I also noticed other external
non-upstream drivers from a large company carrying a similiar patch, so I
may as well ship it in master.
Signed-off-by: NDave Airlie <airlied@redhat.com>

My fine DisplayPort output was getting ST dithering forever after
having had the LVDS enabled at one point.
Signed-off-by: NEric Anholt <eric@anholt.net>

HPD is digital only.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we were not able to map the io bar in device init, don't attempt
to unmap it in device fini.  All radeons should have a io bar, so
I doubt this would ever trigger, but just to be on the safe side...

Pointed out by: Alberto Milone <alberto.milone@canonical.com>
Signed-off-by: NAlex Deucher <alexdeucher@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>

The docs warn that to position the cursor such that no part of it is
visible on the pipe is an undefined operation. Avoid such circumstances
upon changing the mode, or at any other time, by unsetting the cursor if
it moves out of bounds.

"For normal high resolution display modes, the cursor must have at least a
single pixel positioned over the active screen.” (p143, p148 of the hardware
registers docs).

Fixes:

  Bug 24748 - [965G] Graphics crashes when resolution is changed with KMS
              enabled
  https://bugs.freedesktop.org/show_bug.cgi?id=24748

v2: Only update the cursor registers if they change.
v3: Fix the unsigned comparision of x,y against width,height.
v4: Always set CUR.BASE or else the cursor may become corrupt.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reported-by: NChristian Eggers <ceggers@gmx.de>
Cc: Christopher James Halse Rogers  <chalserogers@gmail.com>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

When creating an object, we create the handle by which it is known to
the process and which own the reference to the object. That reference to
the new handle is what we want to transfer to the process, not the lost
reference to the object; so free the local object reference *not* the
process's handle reference.

This brings i915_gem_object_create_ioctl() into line with
drm_gem_open_ioctl()
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

If we fail to flush outstanding GPU writes but return the memory to the
system, we risk corrupting memory should the GPU recovery and complete
those writes. On the other hand, if we bail early and free the object
then we have a definite use-after-free and real memory corruption.
Choose the lesser of two evils, since in order to recover from the hung
GPU we need to completely reset it, those pending writes should
never happen.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

If during the freeing of an object the unbind is interrupted by a system
call, which is quite possible if we have outstanding GPU writes that
must be flushed, the unbind is silently aborted. This still leaves the
AGP region and backing pages allocated, and perhaps more importantly,
the object remains upon the various lists exposing us to memory
corruption.

I think this is the cause behind the use-after-free, such as

  Bug 15664 - Graphics hang and kernel backtrace when starting Azureus
              with Compiz enabled
  https://bugzilla.kernel.org/show_bug.cgi?id=15664

v2: Daniel Vetter reminded me that kernel space programming is never easy.
We cannot simply spin to clear the pending signal and so must deferred
the freeing of the object until later.
v3: Run from the top level retire requests.
v4: Tested with P(return -ERESTARTSYS)=.5 from i915_gem_do_wait_request()
v5: Rebase against Eric's for-linus tree.
v6: Refactor, split and add a comment about avoiding unbounded recursion.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NEric Anholt <eric@anholt.net>

Combine the iteration over active render rings into a common function.
This is in preparation for reusing the idle function to also retire
deferred free requests.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Even though "we have enough padding that it should be ok", round up the
watermark entries to the next unit to be on the safe side...

v2: Use the DIV_ROUND_UP macro
v3: Spotted a few more missing round-ups.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NEric Anholt <eric@anholt.net>

Apparently i830 and i845 cannot handle any stride that is not a multiple
of 256, unlike their brethren which do support 64 byte aligned strides.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

When trying to set other display mode besides the fixed panel mode, the
panel fitting should be enabled. This is similar to LVDS.
Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NZhao Yakui <yakui.zhao@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: stable@kernel.org
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

This makes them sort to the front in X, which makes them likely to be
the primary outputs if you haven't specified a preference in your DE,
which is likely to be what you want.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Do this for both real eDP and for PCH_DP_D when used as the eDP
connection.
Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

Signed-off-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NEric Anholt <eric@anholt.net>