With the previous patch to clean up where exactly these two functions
are getting called, this patch can tackle the enable/disable code
itself:

- WARN if the port enable bit is in the wrong state or if the edp pll
  bit is in the wrong state, just for paranoia's sake.
- Don't disable the edp pll harder in the modeset functions just for
  fun.
- Don't set the edp pll enable flag in intel_dp->DP in modeset, do
  that while changing the actual hw state. We do the same with the
  actual port enable bit, so this is a bit more consistent.
- Track the current DP register value when setting things up and add
  some comments how intel_dp->DP is used in the disable code.

v2: Be more careful with resetting intel_dp->DP - otherwise dpms
off->on will fail spectacularly, becuase we enable the eDP port when
we should only enable the eDP pll.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By using the new pre_enable/post_disable functions.

To ensure that we only frob the cpu edp pll while the pipe is off add
the relevant asserts. Thanks to the new output state staging, this is
now really easy.

With this fixed we can now finally rip out the special-case handling
in the dp dpms code and replace it by the common intel_connector_dpms.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The cpu eDP encoder has some horrible hacks to set up the DP pll at
the right time. To be able to move them to the right place, add some
more encoder callbacks so that this can happen at the right time.

LVDS has some similar funky hacks, but that would require more work
(we need to move around the pll setup a bit). Hence for now only
wire these new callbacks up for ilk+ - we only have cpu eDP on these
platforms.

v2: Bikeshed the vtable ordering, requested by Chris Wilson.
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's bogus.

If I've followed the history of this piece of code correctly, i.e. the
initial register write with the following vblank wait, this goes all
the way back to the original enabling of DP support in

commit a4fc5ed6
Author: Keith Packard <keithp@keithp.com>
Date:   Tue Apr 7 16:16:42 2009 -0700

    drm/i915: Add Display Port support

Unfortunately it seems to be nothing more than glorified duct-tape and
sometimes actively harmful. Adam Jackson noticed this for CPT
platforms with

commit e8519464
Author: Adam Jackson <ajax@redhat.com>
Date:   Thu Jul 21 17:48:38 2011 -0400

    drm/i915/dp: Don't turn CPT DP ports on too early

Unfortunately this kept the code around for ilk and gm45.

The specific failure case I'm seeing here is that after a dpms off/on
cycle we have the bits from the last link training (hopefully
successful link training) set in intel_dp->DP. This is requiered so
that complete_link_train can enable the port with the right tuning
values.

Unfortunately writing these again to the disabled port at dpms on time
kills the port somehow until it's disabled - dp link training fails in
an endless loop without this patch on my mobile ilk and gm45.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: NChris Wilson <chris@chris-wilson.co.uk>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51493Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

With the new "standardized" sysfs interfaces we need to be a bit more
careful about setting the RPS values.

Because the sysfs code and the rps workqueue can run at the same time,
if the sysfs setter wins the race to the mutex, the workqueue can come
in and set a value which is out of range (ie. we're no longer protecting
by RPINTLIM).

I was not able to actually make this error occur in testing.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to keep our cached values in sync with the hardware, we need a
posting read here.

CC: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Userspace applications such as PowerTOP are interesting in being able to
read the current GPU frequency. The patch itself sets up a generic array
for gen6 attributes so we can easily add other items in the future (and
it also happens to be just about the cleanest way to do this).

The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Thu Aug 30 13:26:48 2012 +0200

    drm/i915: add a tracepoint for gpu frequency changes

Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Magic numbers are bad mmmkay. In this case in particular the value is
especially weird because the docs say multiple things. We'll need this
value for sysfs, so extracting it is useful for that as well.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Name variables a bit better for copy-pasters. This got turned up as part
of review for upcoming sysfs patches.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: resolved conflicts due to missing some earlier patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because declaring a variable in the beginning of the function, then
initializing it 100 lines later, then using it 100 lines later does
not make our code look good IMHO.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because ironlake_crtc_mode_set is a giant function that used to have
404 lines. Let's try to make it less complex/confusing.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rather than have multiple data structures for describing our page layout
in conjunction with the array of pages, we can migrate all users over to
a scatterlist.

One major advantage, other than unifying the page tracking structures,
this offers is that we replace the vmalloc'ed array (which can be up to
a megabyte in size) with a chain of individual pages which helps reduce
memory pressure.

The disadvantage is that we then do not have a simple array to iterate,
or to access randomly. The common case for this is in the relocation
processing, which will typically fit within a single scatterlist page
and so be almost the same cost as the simple array. For iterating over
the array, the extra function call could be optimised away, but in
reality is an insignificant cost of either binding the pages, or
performing the pwrite/pread.

v2: Fix drm_clflush_sg() to not invoke wbinvd as well! And fix the
trivial compile error from rebasing.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
beneath us, and so we can simplify the code for iterating over the pages.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By using the recently introduced pinning of pages, we can safely drop
the mutex in the knowledge that the pages are not going to disappear
jeneath us, and so we can simplify the code for iterating over the pages.

Note: The old code had such complicated page refcounting since it used
obj->pages as a micro-optimization if it's there, but that could
(before this patch) disappear when we drop the dev->struct_mutex.
Hence some manual page refcounting was required for the slow path,
complicated by the fact that pages returned by shmem_read_mapping_page
already have a pageref, which needs to be dropped again.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Added note to explain the question Ben raised in review.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to refcount our pages in order to prevent reaping them at
inopportune times, such as when they currently vmapped or exported to
another driver. However, we also wish to keep the lazy deallocation of
our pages so we need to take a pin/unpinned approach rather than a
simple refcount.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to specialise functions depending upon the type of object, we
can attach vfuncs to each object via a new ->ops pointer.

For instance, this will be used in future patches to only bind pages from
a dma-buf for the duration that the object is used by the GPU - and so
prevent them from pinning those pages for the entire of the object.

v2: Bonus comments.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are internal patches for a feature which require a parameter to
query whether support exists . These patches cannot be made external
yet. In order to keep existing tests and userspace happy and free from
conflicts, reserve a number for it.
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Daniel writes:
"The big ticket item here is the new i915 modeset infrastructure.
Shockingly it didn't not blow up all over the place (i.e. I've managed to
fix the ugly issues before merging). 1-2 smaller corner cases broke, but
we have patches. Also, there's tons of patches on top of this that clean
out cruft and fix a few bugs that couldn't be fixed with the crtc helper
based stuff. So more stuff to come ;-)

Also a few other things:
- Tiny fix in the fb helper to go through the official dpms interface
  instead of calling the crtc helper code.
- forcewake code frobbery from Ben, code should be more in-line with
  what Windows does now.
- fixes for the render ring flush on hsw (Paulo)
- gpu frequency tracepoint
- vlv forcewake changes to better align it with our understanding of the
  forcewake magic.
- a few smaller cleanups"

+ 2 fixes.

* 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (78 commits)
  drm/i915: fix OOPS in lid_notify
  drm/i915: correctly update crtc->x/y in set_base
  drm/fb helper: don't call drm_helper_connector_dpms directly
  drm/i915: improve modeset state checking after dpms calls
  drm/i915: add tons of modeset state checks
  drm/i915: no longer call drm_helper_resume_force_mode
  drm/i915: disable all crtcs at suspend time
  drm/i915: push commit_output_state past the crtc/encoder preparing
  drm/i915: switch the load detect code to the staged modeset config
  drm/i915: WARN if the pipe won't turn off
  drm/i915: s/intel_encoder_disable/intel_encoder_noop
  drm/i915: push commit_output_state past crtc disabling
  drm/i915: implement new set_mode code flow
  drm/i915: compute masks of crtcs affected in set_mode
  drm/i915: use staged outuput config in lvds->mode_fixup
  drm/i915: use staged outuput config in tv->mode_fixup
  drm/i915: extract adjusted mode computation
  drm/i915: move output commit and crtc disabling into set_mode
  drm/i915: remove crtc disabling special case
  drm/i915: push crtc->fb update into pipe_set_base
  ...

We hit this a lot with i915 and although we'd like to engineer things to hit
it a lot less, this commit at least makes it consume a few less cycles.

from something containing
movzwl 0x0(%rip),%r10d
to
add    %r8,%rdx

I only noticed it while using perf to profile something else.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Laurent writes:

The SH Mobile DRM driver is now (in my opinion) ready for mainline. It
requires GEM and KMS/FB helpers that have been reviewed on the list and
tested. Sascha is waiting for them to reach your tree to send a pull request
for another new driver.

* 'drm-lcdc' of git://linuxtv.org/pinchartl/fbdev:
  drm: Renesas SH Mobile DRM driver
  drm: Add NV24 and NV42 pixel formats
  DRM: Add DRM KMS/FB CMA helper
  DRM: Add DRM GEM CMA helper
  drm/edid: limit printk when facing bad edid

The SH Mobile LCD controller (LCDC) DRM driver supports the main
graphics plane in RGB and YUV formats, as well as the overlay planes (in
alpha-blending mode only).

Only flat panel outputs using the parallel interface are supported.
Support for SYS panels, HDMI and DSI is currently not implemented.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the DRM GEM CMA helper function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
[Make DRM_KMS_CMA_HELPER a boolean Kconfig option]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Many embedded drm devices do not have a IOMMU and no dedicated
memory for graphics. These devices use CMA (Contiguous Memory
Allocator) backed graphics memory. This patch provides helper
functions to be able to share the code. The code technically does
not depend on CMA as the backend allocator, the name has been chosen
because CMA makes for a nice, short but still descriptive function
prefix.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
[Make DRM_GEM_CMA_HELPER a boolean Kconfig option]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

This goes back to

commit c1c7af60
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date:   Thu Sep 10 15:28:03 2009 -0700

    drm/i915: force mode set at lid open time

It was used to fix an issue on a i915GM based Thinkpad X41, which
somehow clobbered the modeset state at lid close time. Since then
massive amounts of things changed: Tons of fixes to the modeset
sequence, OpRegion support, better integration with the acpi code.
Especially OpRegion /should/ allow us to control the display hw
cooperatively with the firmware, without the firmware clobbering the
hw state behind our backs.

So it's dubious whether we still need this.

The second issue is that it's unclear who's responsibility it actually
is to restore the mode - Chris Wilson suggests to just emit a hotplug
event and let userspace figure things out.

The real reason I've stumbled over this is that the new modeset code
breaks drm_helper_resume_force_mode - it OOPSes derefing a NULL vfunc
pointer. The reason this wasn't caught in testing earlier is that in

commit c9354c85
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon Nov 2 09:29:55 2009 -0800

    i915: fix intel graphics suspend breakage due to resume/lid event
    confusion

logic was added to _not_ restore the modeset state after a resume. And
since most machines are configured to auto-suspend on lid-close, this
neatly papered over the issue.

Summarizing, this shouldn't be required on any platform supporting
OpRegion. And none of the really old machines I have here seem to
require it either. Hence I'm inclined to just rip it out.

But in case that there are really firmwares out there that clobber the
hw state, replace it with a call to intel_modset_check_state. This
will ensure that we catch any issues as soon as they happen.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

While reworking the modeset sequence, this got lost in

commit 25c5b266
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Sun Jul 8 22:08:04 2012 +0200

    drm/i915: implement new set_mode code flow

I've noticed this because some Xorg versions seem to set up a new mode
with every crtc at (0,0) and then pan to the right multi-monitor
setup. And since some hacks of mine added more calls to mode_set using
the stored crtc->x/y my multi-screen setup blew up.
Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Limit printing bad edid information at one time per connector.
Connector that are connected to a bad monitor/kvm will likely
stay connected to the same bad monitor/kvm and it makes no
sense to keep printing the bad edid message.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This patch removes a unused struct psb_intel_connector

Sparse gives a warning:
drivers/gpu/drm/gma500/cdv_intel_hdmi.c:142:30: warning:
	unused variable ‘psb_intel_connector’ [-Wunused-variable]
Signed-off-by: NEmil Goode <emilgoode@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The memory return by kzalloc() or kmem_cache_zalloc() has already
be set to zero, so remove useless memset(0).
Signed-off-by: NWei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The current logic for probing ddc is limited to
2 blocks (256 bytes), this patch adds support
for the 4 block (512) data.

To do this, a single 8-bit segment index is
passed to the display via the I2C address 30h.
Data from the selected segment is then immediately
read via the regular DDC2 address using a repeated
I2C 'START' signal.
Signed-off-by: NShirish S <s.shirish@samsung.com>
Reviewed-by: NJean Delvare <jdelvare@suse.de>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NVille Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Since arch/arm/include/asm/pgtable.h contains:

#define io_remap_pfn_range(vma,from,pfn,size,prot) \
                remap_pfn_range(vma, from, pfn, size, prot)

there is no point treating ARM as a special case in distinguishing
between remap_pfn_range() and io_remap_pfn_range().
Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

There are two slightly different pieces of code for HDMI VSDB
detection. Unify the code into a single helper function.

Also fix a bug where drm_detect_hdmi_monitor() would stop looking
for the HDMI VSDB after the first vendor specific block is found,
whether or not that block happened to be the HDMI VSDB. The
standard allows for any number of vendor specific blocks to be
present.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The length of HDMI VSDB must be at least 5 bytes. Other than the minimum,
nothing else about the length is specified. Check the length before
accessing any additional field beyond the minimum length.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Make sure drm_detect_hdmi_monitor() and drm_detect_monitor_audio() don't
access beyond the extension block.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

At the moment, there is an inconsistency in the way modes are named.
Modes with timings parsed from the EDID information will call
drm_mode_set_name(), which will name the mode using this form:

	<horizontal-res>x<vertical-res><interlace-char>

eg, 1920x1080i for an interlaced mode, or 1920x1080 for a progressive
mode.

However, timings parsed using the tables in drm_edid_modes.h do not
have the 'i' suffix.  You are left to deduce that they're interlaced
from xrandr's output by the lower vertical refresh frequencies.

This patch changes the interlaced mode names in drm_edid_modes.h to
follow the style set by drm_mode_set_name(), which makes it clear
in xrandr which modes are interlaced and which are not (as xrandr
groups the refresh rates on a line according to the name field.)
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

DRM users should be able to create/destroy/manage dumb- and frame-buffers
without DRM_MASTER. These ioctls do not affect modesetting so there is no
reason to protect them by drm-master. Particularly, destroying buffers
should always be possible as a client has only access to buffers that they
created. Hence, there is no reason to prevent a client from destroying the
buffers, considering a simple close() would destroy them, anyway.

Furthermore, a display-server currently cannot shutdown correctly if it
does not have DRM_MASTER. If some other display-server becomes active (or
the kernel console), then the background display-server is unable to
destroy its buffers.
Under special curcumstances (like monitor reconfiguration) this might even
happen during runtime.
Signed-off-by: NDavid Herrmann <dh.herrmann@googlemail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Yet again a case where the fb helper is too intimate with the crtc
helper and calls a crtc helepr function directly instead of going
through the interface vtable.

This fixes console blanking in drm/i915 with the new i915-specific
modeset code.
Reported-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

As a quick reference I'll detail the motivation and design of the new code a
bit here (mostly stitched together from patchbomb announcements and commits
introducing the new concepts).

The crtc helper code has the fundamental assumption that encoders and crtcs can
be enabled/disabled in any order, as long as we take care of depencies (which
means that enabled encoders need an enabled crtc to feed them data,
essentially).

Our hw works differently. We already have tons of ugly cases where crtc code
enables encoder hw (or encoder->mode_set enables stuff that should only be
enabled in enocder->commit) to work around these issues. But on the disable
side we can't pull off similar tricks - there we actually need to rework the
modeset sequence that controls all this. And this is also the real motivation
why I've finally undertaken this rewrite: eDP on my shiny new Ivybridge
Ultrabook is broken, and it's broken due to the wrong disable sequence ...

The new code introduces a few interfaces and concepts:

- Add new encoder->enable/disable functions which are directly called from the
crtc->enable/disable function. This ensures that the encoder's can be
enabled/disabled at a very specific in the modeset sequence, controlled by our
platform specific code (instead of the crtc helper code calling them at a time
it deems convenient).

- Rework the dpms code - our code has mostly 1:1 connector:encoder mappings and
does support cloning on only a few encoders, so we can simplify things quite a
bit.

- Also only ever disable/enable the entire output pipeline. This ensures that
we obey the right sequence of enabling/disabling things, trying to be clever
here mostly just complicates the code and results in bugs. For cloneable
encoders this requires a bit of special handling to ensure that outputs can
still be disabled individually, but it simplifies the common case.

- Add infrastructure to read out the current hw state. No amount of careful
ordering will help us if we brick the hw on the initial modeset setup. Which
could happen if we just randomly disable things, oblivious to the state set up
by the bios. Hence we need to be able to read that out. As a benefit, we grow a
few generic functions useful to cross-check our modeset code with actual hw
state.

With all this in place, we can copy&paste the crtc helper code into the
drm/i915 driver and start to rework it:

- As detailed above, the new code only disables/enables an entire output pipe.
As a preparation for global mode-changes (e.g. reassigning shared resources) it
keeps track of which pipes need to be touched by a set of bitmasks.

- To ensure that we correctly disable the current display pipes, we need to
know the currently active connector/encoder/crtc linking. The old crtc helper
simply overwrote these links with the new setup, the new code stages the new
links in ->new_* pointers. Those get commited to the real linking pointers once
the old output configuration has been torn down, before the ->mode_set
callbacks are called.

- Finally the code adds tons of self-consistency checks by employing the new hw
state readout functions to cross-check the actual hw state with what the
datastructure think it should be. These checks are done both after every
modeset and after the hw state has been read out and sanitized at boot/resume
time. All these checks greatly helped in tracking down regressions and bugs in
the new code.

With this new basis, a lot of cleanups and improvements to the code are now
possible (besides the DP fixes that ultimately made me write this), but not yet
done:

- I think we should create struct intel_mode and use it as the adjusted mode
everywhere to store little pieces like needs_tvclock, pipe dithering values or
dp link parameters. That would still be a layering violation, but at least we
wouldn't need to recompute these kinds of things in intel_display.c. Especially
the port bpc computation needed for selecting the pipe bpc and dithering
settings in intel_display.c is rather gross.

- In a related rework we could implement ->mode_valid in terms of ->mode_fixup
in a generic way - I've hunted down too many bugs where ->mode_valid did the
right thing, but ->mode_fixup didn't. Or vice versa, resulting in funny bugs
for user-supplied modes.

- Ditch the idea to rework the hdp handling in the common crtc helper code and
just move things to i915.ko. Which would rid us of the ->detect crtc helper
dependencies.

- LVDS wire pair and pll enabling is all done in the crtc->mode_set function
currently. We should be able to move this to the crtc_enable callbacks (or in
the case of the LVDS wire pair enabling, into some encoder callback).

Last, but not least, this new code should also help in enabling a few neat
features: The hw state readout code prepares (but there are still big pieces
missing) for fastboot, i.e. avoiding the inital modeset at boot-up and just
taking over the configuration left behind by the bios. We also should be able
to extend the configuration checks in the beginning of the modeset sequence and
make better decisions about shared resources (which is the entire point behind
the atomic/global modeset ioctl).
Tested-by: NJani Nikula <jani.nikula@intel.com>
Tested-by: NBen Widawsky <ben@bwidawsk.net>
Tested-by: NDamien Lespiau <damien.lespiau@intel.com>
Tested-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Tested-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Acked-by: NVijay Purushothaman <vijay.a.purushothaman@intel.com>
Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Tested-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>