Userspace can pass a mode with an unspecified vsync/hsync polarity
setting. All encoders in the Intel driver take this to mean a negative
polarity setting. The HW readout/state checker code on the other hand
needs these flags to be explicitly set, otherwise the state checker will
WARN about the mismatch.

Get rid of the WARN by making the polarity setting explicit in the
adjusted mode flags based on the requested mode flags. This will keep
the existing behavior otherwise.

Note that we could guess from the other timing parameters whether the
user wanted a VESA or other standard mode and set the polarity
accordingly. This is what the NV driver does
(drivers/gpu/drm/nouveau/dispnv04/crtc.c), but I think that's not very
exact and would change the existing behavior of the Intel driver.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65442Signed-off-by: NImre Deak <imre.deak@intel.com>
Tested-by: Ncancan,feng <cancan.feng@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV wants encoder enabling before the pipe is up. With the previously
rearranged VLV DP and HDMI ->pre_enable and ->enable callbacks in place,
this no longer depends on the early ->enable hook call. Move the
->enable call at the end of the sequence, similar to the crtc enable on
other platforms. This will be needed e.g. for moving the eDP backlight
enabling to the right place in the sequence, currently done too early on
VLV.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.

Rearrange the HDMI callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV wants encoder enabling before the pipe is up. This is currently
achieved through calling the ->enable callback early, right after the
->pre_enable callback, in valleyview_crtc_enable(). This loses both the
distinction between ->pre_enable and ->enable on VLV and the possibility
to use a hook at the end of the modeset sequence.

Rearrange the DP callbacks to make it possible to move ->enable call
later. Basically do everything in ->pre_enable on VLV, and make ->enable
a NOP.

There should be no functional changes.

v2: Rebase.

v3: Explain why this is needed in the commit message (Chris).
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Otherwise we get flooded by the kernel warning us that we are doing
long sequences of IO without serialisation. For example,

 WARNING: CPU: 0 PID: 11136 at drivers/gpu/drm/i915/intel_sideband.c:40 vlv_sideband_rw+0x48/0x1ef()
 Modules linked in:
 CPU: 0 PID: 11136 Comm: kworker/u2:0 Tainted: G        W    3.11.0-rc2+ #4
 Call Trace:
  [<c2028564>] ?  warn_slowpath_common+0x63/0x78
  [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
  [<c20285dd>] ?  warn_slowpath_null+0xf/0x13
  [<c227ad43>] ?  vlv_sideband_rw+0x48/0x1ef
  [<c227b060>] ?  vlv_dpio_write+0x1c/0x21
  [<c2262b3b>] ?  intel_dp_set_signal_levels+0x24a/0x385
  [<c2264909>] ?  intel_dp_complete_link_train+0x25/0x1d1
  [<c2264c55>] ?  intel_dp_check_link_status+0xf7/0x106
  [<c2238ced>] ?  i915_hotplug_work_func+0x17b/0x221
  [<c203a204>] ?  process_one_work+0x12e/0x210
  [<c203a5e4>] ?  worker_thread+0x116/0x1ad
  [<c203a4ce>] ?  rescuer_thread+0x1cb/0x1cb
  [<c203d8f5>] ?  kthread+0x67/0x6c
  [<c2457ebb>] ?  ret_from_kernel_thread+0x1b/0x30
  [<c203d88e>] ?  init_completion+0x18/0x18

v2: Retire the locking in vlv_crtc_enable() and do it close to the meat.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
[danvet: Squash in a s/mutex_lock/mutex_unlock/ fixup spotted by the 0
day kernel build/coccinelle and reported by Dan Carpenter.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Art confirms that this should work fine.  Since most panels are 18bpp
with dithering from 24bpp, the existing code wouldn't be enabled in most
cases.
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

SNB and IVB have slightly a different way to read out the
watermark latency values.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The LP1+ watermark latency values need to be multiplied by 5 to
make them suitable for watermark calculations. However on pre-HSW
platforms we're going to need the raw value later when we have to
write it to the WM_LPn registers' latency field. So delay the
multiplication until it's needed.

Note: Paulo complains that the units of wm (now in 100ns) aren't
really clear and I agree. But that can be fixed later on ...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add a comment about the unit obfuscation.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Move parsing of MCH_SSKPD to a separate function, we'll add other
platforms there later.

Note: Chris spotted an empty struct initializer and wondered whether
that is hiding a compilier warning. Ville explained that it should
have been part of the patch that extends this function to snb/ivb,
which don't have all levels hsw has. I've figured it's ok to keep it
here with a small note.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add note about the ominous struct initializer.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The latency values fit in uint16_t, so let's save a few bytes.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The FBC watermark doesn't depend on the latency value, so no point in
passing it in.

Note: It actually depends upon the latency, but only through priv_val
...
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review comment from Paulo to the commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

These functions are appropriate for everything since ILK.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

hsw_wm_get_pixel_rate() isn't specific to HSW. In fact it should be made
to handle all gens, but for now it depends on the PCH panel fitter
state, so give it an ilk_ prefix.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Using the destination width in the sprite WM calculations isn't correct.
We should be using the source width.

Note: This doesn't affect hsw since it does not support sprite
scaling.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Add review note from Paulo to the commit message.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Don't subtract one from the sprite width before watermark calculations.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For calculating watermarks we want to know whether sprites are
scaled. Pass that information to update_sprite_watermarks() so that
eventually we may do some watermark pre-computing.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Some of our macros we trying to convert from an drm_device to a
drm_i915_private and then use the pointer inline. This is not only
cumbersome but prone to error. Replacing it with a typesafe function
should help catch those errors in future.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
[danvet: Squash in fixup to correctly order static vs. inline
qualifiers, static comes first. Also fix up another offender.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NStéphane Marchesin <marcheu@chromium.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The PTE layouts are the same for both ppgtt and gtt, so we can simplify
the setup for ppgtt by copying the encoding function pointer from gtt.
This prevents bugs where we update one function pointer, but forget the
other.

For instance,

commit 4d15c145
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Thu Jul 4 11:02:06 2013 -0700

    drm/i915: Use eLLC/LLC by default when available

only extends the gtt to use eLLC/LLC cacheing and forgets to also update
the ppgtt function pointer.

v2: Actually mention the bug being fixed (Kenneth)
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Almost invariably the reason why FBC cannot be turned on is the same
every time (disabled via parameter, too many pipes, pipe too large etc)
as modesetting and framebuffer configuration changes less frequently
than trying to enable FBC.
Signed-off-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>

In the old days of the crtc helpers we've only had the encoder and
crtc ->mode_fixup callbacks. So when the lvds connector wanted to
adjust the crtc timings it had to set a driver-private mode flag to
tell the crtc mode fixup code to not overwrite them with the generic
ones.

When converting things to the new infrastructure I've kept the entire
logic and only moved the flag to pipe_config->timings_set. But this
logic is pretty tricky and already caused regressions:

commit 21d8a475
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 12 08:07:30 2013 +0200

    drm/i915: fix pfit regression for non-autoscaled resolutions

So take advantage of the flexibility our own modeset infrastructure
affords us and prefill default crtc timings. This allows us to rip out
->timings_set. Note that we overwrite things again when retrying the
pipe config computation due to bandwidth constraints to avoid bogus
crtc timings if the encoder only does relative adjustments (which is
how the pfit code works). Only a theoretical concern though since
platforms where we retry (pch-split platforms) do not need
adjustements (since only the old gmch pfit needs that). But let's
better be safe than sorry.

Since we now initialize the crtc timings before calling the
encoder->compute_config functions the crtc initialization in the gmch
pfit code is now redudant and so can be removed.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add a paragraph to the commit message to explain why we can
ditch the crtc timings initialization call from the gmch pfit code, to
answer a question from Rodrigo's review.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The encoder->mode_set callback from the crtc helpers is now completely
unused in our driver. Good riddance!
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Same conversion as for hdmi/dp.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Does nothing, so trivial conversion. But update the outdated comment
while at it.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Usual drill applies. Again I've not switched the upcast helpers to use
intel_encoder instead of drm_encoder since that's much more invasive
and will change also the hdmi and ddi encoders.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Again drop the intel_ prefix from the intel_crtc local variable to
save a bit of space. But here I didn't switch the upcast macros to
intel_encoder since all our infoframe interfaces still use
drm_encoder. That needs to be changed first.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also drop the intel_ prefix from the local intel_crtc variable and
reorder the upcast macros a bit for more reuse.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Also switch to intel_encoder for the upcast helper while at it.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

It's what all callers (except for the destroy callback which is called
from drm core) actually want.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Everyone is now using our own ->compute_config callback, which means
we can now also make that callback mandatory.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is the last encoder ->mode_fixup callback we have left, so
convert it.

Note that we want to only rip out the encoder->mode_fixup callback.
But we still have the dvo_slave->mode_fixup callback. dvo is gen2
only, so we won't ever touch this again. Hence why I didn't go through
all 6-7 dvo slave drivers and give them the same treatment. I'll add a
note to the commit message about this when merging, presuming there's
nothing else in the patch that needs to be fixed up.
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
[danvet: Add note about why we keep the dvo->mode_fixup callback to
answer a question from Rodrigo's review.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

More natural and will soon be even better!
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Fixes regression from
commit 4906557e
Author: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Date:   Thu Jul 11 18:45:05 2013 -0300

    drm/i915: Hook PSR functionality

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67526Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We need the correct clock to accurately assess whether we need to
enable the double wide pipe mode or not.

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Cc: Stuart Abercrombie <sabercrombie@google.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The w/a db makes the recommendation to both use a non-default value for
the initial clock and then to retry with an alternative clock for
Haswell with the Lakeport PCH.

"On LPT:H, use a divider value of 63 decimal (03Fh). If there is a
failure, retry at least three times with 63, then retry at least three
times with 72 decimal (048h)."
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

For HPD storm detection we now mask out individual interrupt source
bits. We have already seen a case where HPD interrupt enable bits
were assigned to the wrong pins. To track these conditions more
easily add some debugging messages.

v2: Spelling fixes as suggested by Jani Nikula <jani.nikula@linux.intel.com>
Signed-off-by: NEgbert Eich <eich@suse.de>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This fixes a typo which set the wrong vsync and possibly also hsync
polarity for any modes with positive vsync polarity.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just use a spinlock to protect them.

v2: Rebase onto the new object create refcount fix patch.

v3: Don't kill dev_priv->mm.object_memory as requested by Chris and
hence just use a spinlock instead of atomic_t.

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