update_state_fb() at the end of intel_find_plane_obj() is misleading as
it leads us to believe the update is done for all code path.

A successful call to intel_alloc_plane_obj() will return and
update_state_fb() is then only needed when we share a fb from another
CRTC. Put the update() function there then.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The check for previously reserved stolen space size for FBC in
i915_gem_stolen_setup_compression() did not take the compression
threshold into account. Fix this by storing and comparing to
uncompressed size instead.

The bug has been introduced in

commit 5e59f717
Author: Ben Widawsky <benjamin.widawsky@intel.com>
Date:   Mon Jun 30 10:41:24 2014 -0700

    drm/i915: Try harder to get FBC

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88975Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ben Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: leave intel_skylake_info alone (Rodrigo, Daniel)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need to have a separate GT3 struct intel_device_info to declare they
have a second VCS. Let's start by splitting the PCI ids per-GT.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch implements core logic of SKL display power well.

v2: Addressed Imre's comments
	- Added respective DDIs under power well #1 and #2
	- Simplified repetitive code in power well programming

v3: Implemented Imre's comments
	- Further simplified power well programming
	- Made sure that PW 1 is enabled prior to PW 2

v4: Fix minor conflict with the the cherryview support (Damien)

v5: Add the PLL power domain to the always on power well (Damien)

v6: Disable BIOS power well (Imre)
    Use power well data for comparison (Imre)
    Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh,
    Damien)

v7: Addressed Imre's comments
  - Lowered the time out to 1ms
  - Added parantheses in macro
  - Moved debug message and fixed wait_for interval

v8:
  - Add a WARN() when swiching on an unknown power well (Imre, done by Damien)
  - Whitespace fixes (spaces instead of tabs) (Damien)

v9: (Imre, done by Damien)
  - Merge the register definitions with this patch
  - Merge the MISC IO power well in this patch

v10: (Imre, done by Damien)

  - Define the Misc I/O power domains to be the power well 1 ones as Misc I/O
    needs to be enabled with PW1
  - Added Transcoder A and VGA domains to PW 2
  - Remove the MISC_IO power domains as well in the the always on
    domains definition
  - Move Misc I/O power well at the top of the power well list so it's turned
    on right after PW1.
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: Satheeshakrishna M <satheeshakrishna.m@intel.com> (v3,v6,v7)
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

plane->state->fb and plane->fb should always reference the same FB so
that atomic and legacy codepaths have the same view of display state.
In commit

        commit db068420560511de80ac59222644f2bdf278c3d5
        Author: Matt Roper <matthew.d.roper@intel.com>
        Date:   Fri Jan 30 16:22:36 2015 -0800

            drm/i915: Keep plane->state updated on pageflip

we already fixed one case where these two pointers could get out of
sync.  However it turns out there are a few other places (mainly dealing
with initial FB setup at boot) that directly set plane->fb and neglect
to update plane->state->fb.  If we never do a successful update through
the atomic pipeline, the RmFB cleanup code will look at the
plane->state->fb pointer, which has never actually been set to a
legitimate value, and try to clean it up, leading to BUG's.

Add a quick helper function to synchronize plane->state->fb with
plane->fb (and update reference counts accordingly) and call it
everywhere the driver tries to manually set plane->fb outside of the
atomic pipeline.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We already track this in the intel_info struct.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Make the commit message a bit less terse.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This isuue got introduced in -

commit 24ee0e64
Author: Gaurav K Singh <gaurav.k.singh@intel.com>
Date:   Fri Dec 5 14:24:21 2014 +0530

    drm/i915: Update the DSI enable path to support dual
Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Replace the valleyview_set_rps() and gen6_set_rps() calls with
intel_set_rps() which itself does the IS_VALLEYVIEW() check. The
code becomes simpler since the callers don't have to do this check
themselves.

Most of the change was performe with the following semantic patch:
@@
expression E1, E2, E3;
@@
- if (IS_VALLEYVIEW(E1)) {
-  valleyview_set_rps(E2, E3);
- } else {
-  gen6_set_rps(E2, E3);
- }
+ intel_set_rps(E2, E3);

Adding intel_set_rps() and making valleyview_set_rps() and gen6_set_rps()
static was done manually. Also valleyview_set_rps() had to be moved a
bit avoid a forward declaration.

v2: Use a less greedy semantic patch

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Daniel Vetter spotted a bug while reviewing some of my refactoring in this
are of the code. I'll quote:

"""
> @@ -9764,6 +9768,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
>  	work->event = event;
>  	work->crtc = crtc;
>  	work->old_fb_obj = intel_fb_obj(old_fb);
> +	work->old_tiling_mode = to_intel_framebuffer(old_fb)->tiling_mode;

Hm, that's actually an interesting bugfix - currently userspace could be
sneaky and destroy the old fb immediately after the flip completes and the
change the tiling of the underlying object before the unpin work had a
chance to run (needs some fudgin with rt prios to starve workers to make
this work though).

Imo the right fix is to hold a reference onto the fb and not the
underlying gem object. With that tiling is guaranteed not to change.
"""

This patch tries to implement the above proposed change.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There are two sets of helper functions provided by the DRM core that can
implement the .update_plane() and .disable_plane() hooks in terms of a
driver's atomic entrypoints.  The transitional helpers (which we have
been using so far) create a plane state and then use the plane's atomic
entrypoints to perform the atomic begin/check/prepare/commit/finish
sequence on that single plane only.  The full atomic helpers create a
top-level atomic state (which is capable of holding multiple object
states for planes, crtc's, and/or connectors) and then passes the
top-level atomic state through the full "atomic modeset" pipeline.

Switching from the transitional to full helpers here shouldn't result in
any functional change, but will enable us to exercise/test more of the
internal atomic pipeline with the legacy API's used by existing
applications.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Until all drivers have transitioned to atomic, the framebuffer
associated with a plane is tracked in both plane->fb (for legacy) and
plane->state->fb (for all the new atomic codeflow).  All of our modeset
and plane updates use drm_plane->update_plane(), so in theory plane->fb
and plane->state->fb should always stay in sync and point at the same
thing for i915.  However we forgot about the pageflip ioctl case, which
currently only updates plane->fb and leaves plane->state->fb at a stale
value.

Surprisingly, this doesn't cause any real problems at the moment since
internally we use the plane->fb pointer in most of the places that
matter, and on the next .update_plane() call, we use plane->fb to figure
out which framebuffer to cleanup.  However when we switch to the full
atomic helpers for update_plane()/disable_plane(), those helpers use
plane->state->fb to figure out which framebuffer to cleanup, so not
having updated the plane->state->fb pointer causes things to blow up
following a pageflip ioctl.

The fix here is to just make sure we update plane->state->fb at the same
time we update plane->fb in the pageflip ioctl.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

You can _never_ assert that a lock is not held, except in some very
restricted corner cases where it's guranteed that your code is running
single-threade (e.g. driver load before you've published any pointers
leading to that lock).

In addition the early return breaks a bunch of testcases since with
highly concurrent hangcheck stress tests the reset fails to work and
the test doesn't recover and time out.

This regression has been introduced in

commit b8d24a06
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Wed Jan 28 17:03:14 2015 +0200

    drm/i915: Remove nested work in gpu error handling

Aside: It is possible to check whether a given task doesn't hold a
lock, but only when lockdep is enabled, using the lockdep_assert_held
stuff.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88908Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>

Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The get_config() functions for ddi and dp_mst, used to read the value
of cpu_transcoder from the crtc->config instead of the state passed as
an argument. On the hardware state readout path, that happens to work
since the proper value is written to it before encoder->get_config() is
called. However, in the check_crtc() path, the state will be read from
the cpu_transcoder in the software tracking, instead of the one just
read out from hw. Using the field in the supplied intel_crtc_state
should do the right thing in both cases.

v2: Fix intel_ddi_get_config() too. (Ander)
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Remove request from list before unreferencing it, in case it's actually
the only reference. (Found by Tvrtko Ursulin)

This issue has been most likely introduced in

commit 6d3d8274
Author: Nick Hoath <nicholas.hoath@intel.com>
Date:   Thu Jan 15 13:10:39 2015 +0000

    drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request
Signed-off-by: NNick Hoath <nicholas.hoath@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This simplifies __intel_set_mode() a little.
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The checking for ack and also any subsequent mmio access
will serialize with setting the forcewake bit. Drop the
posting read as superfluous.

Note that in the put side we still want to keep the posting read
as it will ensure that the hw sees our forcewake release in a
timely manner and doesn't keep the hw powered up.

Comment from Chris:

On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote:
> Ville Syrjälä <ville.syrjala@linux.intel.com> writes:
> > IIRC the posting read from same cache line actually fixed real bugs. So
> > I'm a bit worried about dropping them. But I suppose it's possible only
> > the _put side was important for those bugs.
>
> I found these:
>
> commit 6af2d180
> Author: Daniel Vetter <daniel.vetter@ffwll.ch>
> Date:   Thu Jul 26 16:24:50 2012 +0200
>
>     drm/i915: fix forcewake related hangs on snb
>
> commit 8dee3eea
> Author: Ben Widawsky <ben@bwidawsk.net>
> Date:   Sat Sep 1 22:59:50 2012 -0700
>
>     drm/i915: Never read FORCEWAKE
>
> https://bugs.freedesktop.org/show_bug.cgi?id=51738
> https://bugs.freedesktop.org/show_bug.cgi?id=52424
>
> The snb here seems to survive gem_dummy_reloc_loop and
> gem_ring_sync_loop in here with the get side posting removed.

Note that we kept the once associated with #52424, but judging by my
comments in #51738 the posting read is just a band aid anyway as a full
mb() itself was not adequate.
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
[danvet: paste relevant review discussion in.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

intel_uncore_early_sanitize() will reset the forcewake registers. When
forcewake domains were introduced, the domain init was done after the
sanitization of the forcewake registers. And as the resetting of
registers use the domain accessors, we tried to reset the forcewake
registers with unitialized forcewake domains and failed.

Fix this by sanitizing after all the domains have been initialized. Do
per domain clearing of forcewake register on domain init so that
IVB can do early access to ECOBUS do determine the final configuration.

This regression was introduced in

commit 05a2fb15
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date:   Mon Jan 19 16:20:43 2015 +0200

    drm/i915: Consolidate forcewake code

v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: NOlof Johansson <olof@lixom.net>
Tested-by: Darren Hart <dvhart@linux.intel.com> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move the CHV check into vlv_set_rps_idle() to simplify the caller a bit.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now when we declare gpu errors only through our own dedicated
hangcheck workqueue there is no need to have a separate workqueue
for handling the resetting and waking up the clients as the deadlock
concerns are no more.

The only exception is i915_debugfs::i915_set_wedged, which triggers
error handling through process context. However as this is only used through
test harness it is responsibility for test harness not to introduce hangs
through both debug interface and through hangcheck mechanism at the same time.

Remove gpu_error.work and let the hangcheck work do the tasks it used to.

v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Include intel_uncore.c in template for it to include d
documentation for intel_uncore_forcewake_get and *_put.

Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The removed functions can be resurrected in intel_dsi.c as need arises.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

All of these are replaced by the drm core mipi dsi functions.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the drm core interfaces in preparation of removing our homebrew.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Add basic support for using the drm mipi dsi framework for DSI. We don't
use device tree which is pretty much required by mipi_dsi_host_register
and friends, and we don't have the kind of device model the functions
expect either. So we cheat and use it as a library to abstract what we
need: a nice, clean interface for DSI transfers. This means we will have
to be careful with what functions we call, as the driver model devices
in mipi_dsi_host and mipi_dsi_device will *not* be initialized.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Replace intel_dsi_device and intel_dsi_dev_ops with drm_panel and
drm_panel_funcs. They are adequate for what we have now, and if we end
up needing more than this we should improve drm_panel. This will keep us
better aligned with the drm core infrastructure.

The panel driver initialization changes a bit. It still remains hideous,
but fixing that is beyond the scope here.

v2: extend mode config mutex to cover drm_panel_get_modes (Shobhit)
    vbt_panel->intel_dsi = intel_dsi in vbt panel init (Shobhit)
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Mainly taking care of some register offsets, otherwise things are similar to
hsw. Also, programming ddi aux to use hardcoded values for psr data select.

v2: introduce  EDP_PSR_AUX_BASE macro (Chris)
v3: Moving to HW tracking for SKL+ platforms, so activating source psr during
psr_enabling and then avoiding psr entries and exits for each frontbuffer
updates.
v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo)
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
[danvet: Drop the hunks to short-circuit sw tracking: We'd need to
push this down one level, and I don't fully trust the test coverage
yet to do so. So much prefer we pick a whitelist approach for the
cases we know work correctly.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The core fix was applied in

commit a63b03e2
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jan 6 10:29:35 2015 +0000

    mutex: Always clear owner field upon mutex_unlock()

(note the absence of stable@ tag)

so we can now revert our band-aid commit 226e5ae9 for -next.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We have had %x and %u intermixed. Bring everything in line and
use %x
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For example,

/sys/kernel/debug/dri/0/i915_hangcheck_info:

Hangcheck active, fires in 15887800ms
render ring:
        seqno = -4059 [current -583]
        action = 2
        score = 0
        ACTHD = 1ee8 [current 21f980]
        max ACTHD = 0

v2: Include expiration ETA. Can anyone spot a problem?
v3: Convert for workqueued hangcheck (Mika)
v4: Print seqnos as unsigned ints (Ville)
v5: Print seqnos as hex (Chris)

Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When run as a timer, i915_hangcheck_elapsed() must adhere to all the
rules of running in a softirq context. This is advantageous to us as we
want to minimise the risk that a driver bug will prevent us from
detecting a hung GPU. However, that is irrelevant if the driver bug
prevents us from resetting and recovering. Still it is prudent not to
rely on mutexes inside the checker, but given the coarseness of
dev->struct_mutex doing so is extremely hard.

Give in and run from a work queue, i.e. outside of softirq.

v2: Use own workqueue to avoid deadlocks (Daniel)
    Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris)

Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
[danvet: Remove accidental kerneldoc comment starter, to appease the 0
day builder.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

An interesting bug occurs on Pineview through which the root cause is
that the writes of the PTE values into the GTT is not serialised with
subsequent memory access through the GTT (when using WC updates of the
PTE values). This is despite there being a posting read after the GTT
update. However, by changing the address of the posting read, the memory
access is indeed serialised correctly.

Whilst we are manipulating the memory barriers, we can remove the
compiler :memory restraint on the intermediate PTE writes knowing that
we explicitly perform a posting read afterwards.

v2: Replace posting reads with explicit write memory barriers - in
particular this is advantages in case of single page objects. Update
comments to mention this issue is only with WC writes.

Testcase: igt/gem_exec_big #pnv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191
Tested-by: huax.lu@intel.com (v1)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent
with the code and the rest of the comment for this routine. This patch
fixes this typo in comment.
Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We don't have full atomic modeset support yet, but the "nuclear
pageflip" subset of functionality (i.e., plane operations only) should
be ready.  Allow the user to force atomic on for debug purposes, or for
fixed-purpose embedded devices that will only use atomic for plane
updates.

The term 'nuclear' is used here instead of 'atomic' to make it clear
that this doesn't allow full atomic modeset support, just a (very
useful) subset of the atomic functionality.

We'll drop the kernel parameter and unconditionally enable atomic in a
future patch once all of the necessary pieces are in.

v2:
 - Use module_param_named_unsafe() (Daniel)
 - Simplify comment on DRIVER_ATOMIC guard (Daniel)

v3:
 - Make the parameter "nuclear_pageflip" rather than just "nuclear"
   for clarity. (Ander)

v4:
 - Make the internal variable "nuclear_pageflip" as well as the
   command-line option. (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will exercise our atomic pipeline for legacy property updates.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The atomic helpers need these to prepare a new state object when
starting a new atomic operation.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Even though we only support atomic plane updates at the moment, we still
need to add an .atomic_get_property() entrypoint for connectors before
we allow the driver to flip on the DRIVER_ATOMIC bit.  As soon as that
bit gets set, the DRM core will start adding atomic connector properties
(in addition to the plane properties we care about at the moment), so we
need to be able to handle the new way the DRM core will interact with
us.

For simplicity, we just lookup driver-specific connector properties in
the usual shadow array maintained by the core.  Once we get real atomic
modeset support for crtc's and planes, this code should be re-written to
pull the data out of crtc/connector state structures.

v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We want to enable/test plane updates via the atomic interface, but as
soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic
codepaths to lookup properties during drmModeGetConnector() and some of
those codepaths unconditionally dereference connector->state
(specifically when looking up the CRTC ID property in
drm_atomic_connector_get_property()).  Create a dummy connector state
for each connector at init time to ensure the DRM core doesn't try to
dereference a NULL connector->state.  The actual connector properties
will never be updated or contain useful information, but since we're
doing this specifically for testing/debug of the plane operations (and
only when a specific kernel module option is given), that shouldn't
really matter.

Once we start creating connector states, the DRM core will want to be
able to clean them up for us.  We also need to hook up the destruction
entrypoint to the core's helper.

v2: Squash in the patch to set the state destruction hook (Ander & Bob)

v3: Only create dummy connector states when we're actually faking
    atomic support.  (Ander)
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>