Revert "drm: Add EDID_QUIRK_FORCE_REDUCED_BLANKING for ASUS VW222S"

This reverts commit 6f33814bd4d9cfe76033a31b1c0c76c960cd8e4b.

The quirk cause a regression, and it looks like the original bug was
simply a lack of FIFO bandwidth on the i915G of the reporter. Which
should eventually be fixed as soon as we get around to implemented
DSPARB FIFO reassignment on gen 3.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: review locking for drm_fb_helper_restore_fbdev_mode

... it's required. Fix up exynos and the cma helper, and add a
corresponding WARN_ON to drm_fb_helper_restore_fbdev_mode.

Note that tegra calls the fbdev cma helper restore function also from
it's driver-load callback. Which is a bit against current practice,
since usually the call is only from ->lastclose, and initial setup is
done by drm_fb_helper_initial_config.

Also add the relevant drm DocBook entry.

v2: Add promised WARN to restore_fbdev_mode.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: kill drm_fb_helper_restore

It's only used internally for the sysrq and panic handlers provided by
the drm fb helper implementation. Hence just inline it, kill the
export and remove the confusing kerneldoc. Driver's are supposed to
call drm_fb_helper_restore_fbdev_mode on lastclose.

Note that locking is totally fubar - the sysrq case doesn't take any
locks at all. The panic handler probably shouldn't take any locks
since it'll only make things worse. Otoh it's probably better to
switch things over to the atomic modeset callbacks (and disable the
panic handler for those drivers which don't implement it).

But that's both better done in separate patches.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: unexport drm_fb_helper_panic

It doesn't even show up in any header files and only used iternally.
Originally it was (ab)used to restore the fbcon on lastclose, but that
died with

commit e8e7a2b8ccfdae0d4cb6bd25824bbedcd42da316
Author: Dave Airlie <airlied@redhat.com>
Date:   Thu Apr 21 22:18:32 2011 +0100

    drm/i915: restore only the mode of this driver on lastclose (v2)

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: unexport drm_fb_helper_single_fb_probe

Not called by anyone, and really, shouldn't be. Drivers are supposed
either drm_fb_helper_initial_config or drm_fb_helper_hotplug_event.
Originally this was done differently, but is now consolidated in the
helper functions and no longer done by drivers directly.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/tegra: don't set up initial fbcon config twice

drm_fbdev_cma_init does the inital fbcon setup by calling down into
drm_fb_helper_initial_config, so no need at all to restore the just
set up configuration right away ...

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: don't disable everything in initial_config

This should be done in the drivers for two reasons:
- it gets in the way of fastboot efforts
- it links the fb helpers with the crtc helpers instead of going
  through the real interface vfuncs, forcing i915 to fake all the
  ->disable callbacks used by the crtc helper to avoid ugly Oopsen

v2: Resolve conflicts since drivers still call
drm_fb_helper_single_add_all_connectors.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/i915: rip out helper->disable noop functions

Now that the driver is in control of whether it needs to disable
everything at take-over or not, we can rip this all out.

Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: fixup set_config semantics

While doing the modeset rework for drm/i915 I've noticed that the fb
helper is very liberal with the semantics of the ->set_config
interface:
- It doesn't bother clearing stale modes (e.g. when unplugging a
  screen).
- It unconditionally sets the fb, even if no mode will be set on a
  given crtc.
- The initial setup is a bit fun since we need to pick crtcs to decide
  the desired fb size, but also should set the modeset->fb pointer.
  Explain what's going on in the fixup code after the fb is allocated.

The crtc helper didn't really care, but the new i915 modeset
infrastructure did, so I've had to add a bunch of special-cases to
catch this.

Fix this all up and enforce the interface by converting the checks in
drm/i915/intel_display.c to BUG_ONs.

v2: Fix commit message spell fail spotted by Rob Clark.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: directly call set_par from the hotplug handler

The idea behind calling down into the driver's ->fb_probe function on each
hotplug seems to be able to reallocate the backing storage (if e.g. a screen
with higher resolution gets added). But that requires quite a bit of work in the
fb helper itself, since currently we limit new screens to the currently
allocated fb. An no kms driver supports fbdev fb resizing.

So don't bother and start to simplify the code by calling drm_fb_helper_set_par
directly from the fbdev hotplug function, since that's the only thing left in
drm_fb_helper_single_fb_probe which does not concern itself with fb allocation
and initial setup. Follow-on patches will streamline the initial setup
code.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: streamline drm_fb_helper_single_fb_probe

No need to check whether we've allocated a new fb since we're not
always doing that. Also, we always need to register the fbdev and add
it to the panic notifier.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/<drivers>: simplify ->fb_probe callback

The fb helper lost its support for reallocating an fb completely, so
no need to return special success values any more.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: improve kerneldoc

Now that the fbdev helper interface for drivers is trimmed down,
update the kerneldoc for all the remaining exported functions.

I've tried to beat the DocBook a bit by reordering the function
references a bit into a more sensible ordering. But that didn't work
out at all. Hence just extend the in-code DOC: section a bit.

Also remove the LOCKING: sections - especially for the setup functions
they're totally bogus. But that's not a documentation problem, but
simply an artifact of the current rather hazardous locking around drm
init and even more so around fbdev setup ...

v2: Some further improvements:
- Also add documentation for drm_fb_helper_single_add_all_connectors,
  Dave Airlie didn't want me to kill this one from the fb helper
  interface.
- Update docs for drm_fb_helper_fill_var/fix - they should be used
  from the driver's ->fb_probe callback to setup the fbdev info
  structure.
- Clarify what the ->fb_probe callback should all do - it needs to
  setup both the fbdev info and allocate the drm framebuffer used as
  backing storage.
- Add basic documentaation for the drm_fb_helper_funcs driver callback
  vfunc.

v3: Implement clarifications Laurent Pinchart suggested in his review.

v4: Fix another mispelling Laurent spotted.

Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: don't sleep for screen unblank when an oopps is in progress

Otherwise the system will burn even brighter and worse, leave the user
wondering what's going on exactly.

Since we already have a panic handler which will (try) to restore the
entire fbdev console mode, we can just bail out. Inspired by a patch
from Konstantin Khlebnikov. The callchain leading to this, cut&pasted
from Konstantin's original patch:

callstack:
panic()
bust_spinlocks(1)
unblank_screen()
vc->vc_sw->con_blank()
fbcon_blank()
fb_blank()
info->fbops->fb_blank()
drm_fb_helper_blank()
drm_fb_helper_dpms()
drm_modeset_lock_all()
mutex_lock(&dev->mode_config.mutex)

Note that the entire locking in the fb helper around panic/sysrq and
kdbg is ... non-existant. So we have a decent change of blowing up
everything. But since reworking this ties in with funny concepts like
the fbdev notifier chain or the impressive things which happen around
console_lock while oopsing, I'll leave that as an exercise for braver
souls than me.

v2: Drop the -EBUSY return value I've copied, we don't need it since
the we'll take care of things ourselves anyway.

Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
References: https://patchwork.kernel.org/patch/1878181/
Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/fb-helper: remove unused members of struct drm_fb_helper

Spotted by Rob Clark.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drm/pci: define drm_pcie_get_speed_cap_mask() only when CONFIG_PCI=y

Move drm_pcie_get_speed_cap_mask() under #ifdef CONFIG_PCI because it
it used only for PCI devices (evergreen, r600, r770), and it uses
PCI interfaces that only exist when CONFIG_PCI=y.

Previously, we tried to compile drm_pcie_get_speed_cap_mask() even when
CONFIG_PCI=n, which fails.

Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: fix compile failure by including <linux/swiotlb.h>

On tile architecture (with "make allyesconfig") including
<linux/swiotlb.h> is required to call swiotlb_nr_tbl().

Signed-off-by: Chris Metcalf <cmetcalf@tilera.com>
Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm: shut up invalid edid messages

My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds.

I get it the first time that the entire block is all 0xff..

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Cc: stable@vger.kernel.org [v3.7]
Signed-off-by: Dave Airlie <airlied@redhat.com>
Merge branch 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm into drm-next

This is the drm fb helper cleanup, mostly motivated by strange things I've
seen in my locking rework and the i915 modeset revamp. Compared to the
original submission I've reinstated the setup flexibility you'd like to
retain, kerneldoc has been reviewed by Laurent Pinchart and Rob Clark
reviewed the code changes.

Quick overview of the changes:
- Cleaned-up library interface for drivers using the fb helper, also
  simplified the fb allocation callback since no driver supported
  reallocating the fb on-the-fly. And the fbdev/fbcon code keeps pointers
  to the old mapping around anyway, so reallocating backing storage will
  be much more work.
- No longer call the crtc helper "disable everything" function at init
  time, but allow drivers to do so. Motivated by i915's fastboot effort
  and allows us to drop a bunch of noop dummy functions just to avoid
  calling NULL function pointers from i915.ko.
- Properly clear old state when doing modeset calls, the fb helper left
  some old modes in there and unconditionally set an fb (even when
  disabling a crtc). The crtc helpers didn't care, but i915 modeset code
  can now drop a few special cases.
- Full kerneldoc for the fb helper. Yay!
- My version of the "don't sleep in panic ->unblank calls". The patch is
  already in -mm, I guess Andrew can drop it as soon as this pull lands in
  drm-next.

* 'drm-fb-helper' of git://people.freedesktop.org/~danvet/drm:
  drm/fb-helper: remove unused members of struct drm_fb_helper
  drm/fb-helper: don't sleep for screen unblank when an oopps is in progress
  drm/fb-helper: improve kerneldoc
  drm/<drivers>: simplify ->fb_probe callback
  drm/fb-helper: streamline drm_fb_helper_single_fb_probe
  drm/fb-helper: directly call set_par from the hotplug handler
  drm/fb-helper: fixup set_config semantics
  drm/i915: rip out helper->disable noop functions
  drm/fb-helper: don't disable everything in initial_config
  drm/tegra: don't set up initial fbcon config twice
  drm/fb-helper: unexport drm_fb_helper_single_fb_probe
  drm/fb-helper: unexport drm_fb_helper_panic
  drm/fb-helper: kill drm_fb_helper_restore
  drm: review locking for drm_fb_helper_restore_fbdev_mode
drm/omap: Add PM capabilities

Added power management capabilities into the omapdrm and DMM drivers.
During suspend, we don't need to do anything to maintain the state of
the LUT.  We have all the necessary information to recreate the mappings
of the GEM object list maintained by the omapdrm driver.

On resume, the DMM resume handler will first reprogram the LUT to point
to the dummy page.  The subsequent resume handler in the omapdrm will call
into the DMM and reprogram each of the buffer objects.  This will ensure
that all of the necessary objects will be pinned into the DMM properly.

Order of suspend/resume handlers is done by device creation.  We create
the DMM device before the omapdrm, so the correct order is maintained.

Signed-off-by: Andy Gross <andy.gross@ti.com>
Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>