take out pin_fb code so the commit phase can't fail anymore.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Take out the pin_fb code so commit phase can't fail anymore.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The power seqeuencer kick procedure requires the DPLL to be running
in order to complete successfully. In case the DPLL isn't currently
running when we need to kick the power seqeuncer enable it
temporarily. This can happen eg. during ->detect() when the pipe is
not already active.

To avoid needlessly duplicating the DPLL programming re-use the already
existing functions by passing a temporary pipe config to them instead
of having them consult the current pipe config at crtc->config.

v2: Introduce vlv_force_pll_{on,off}() (Daniel)
v3: Rebase due to drm_crtc vs. intel_crtc changes
    Fix a typo in commit msg (checkpatch)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> (v1)
[danvet: Appease checkpatch.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

eDP ports need the power seqeuncer whenever the port is active. Warn if
we accidentally steal the power sequener from an active eDP port. This
should not happen unless there's a bug somewhere else, but it's best to
scream loudly if it happens to help with debugging.

Note that this only checks for active pipes and not for enabled pipes
which are turned off with dpms. Which means we might run the risk that
the pps might get stolen and we can't reacquire one when enabling the
pipe again with dpms on. But on current platforms that's impossible
since we only support two edp ports with just two panel power
sequencers. So a more elaborate scheme which reserves the pps even
when the pipe is inactive isn't required.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Summarize my discussion with Ville about dpms on/off issues.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We should never enable the panel power twice. That would indicate a bug
somewhere else as we would need to enable the port twice without
disabling it in between. Also print the port name.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Print the port name in the VDD/PPS debugs messages.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In case we fumble something and end up picking an already used power
seqeuencer in vlv_power_sequencer_pipe() at least try to steal it
gracefully. In theory this should never happen though.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no power sequencer on pipe C on VLV/CHV so scream a bit if we
try to steal one from pipes other than A and B.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VLV gets confused if two power sequencers have the same port selected.
It would seem the port doesn't start up properly in the is case and
vlv_wait_port_ready() will fail as will the link training. Clearing the
port select in the PP_ON_DELAYS register fixes this problem.

CHV doesn't seem to need this, but it doesn't seem to hurt either so
let's just do it for both to keep the code between the platforms as
uniform as possible.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If there's no power sequencer assigned to the port currently we can't
very well have vdd or panel power enabled either. If we would try to
check that from the pps registers we'd need to pick a power seqeuncer
and kick it. So let's skip the register read and the kick.

Note that there's still a bit an issue about correctly recovering pps
state from resume if the bios is nasty: With this check we'll always
assume that the pps is off. But that's better done in a follow-up
patch and it shouldn't be too harmful - at most we waste time enabling
the pps if it's on already.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Add note about resume issues Imre spotted.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When we pick a new power sequencer for the port but we're not doing a
full modeset, the power sequencer may have locked on to another port (or
no port). So kick it a bit to make sure it controls the port we want.

Again just like when we attempt to actually enable the DP port, we
must first write the port register with the approriate value except
the enable bit, and then we must enable the port to make the power
sequencer happy. In this case since we don't want the port actually
enabled we just toggle it on and immediately back off. Going forward
the power sequencer will keep working on that specific port until again
moved to another port.

v2: Refine the kick procedure
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

When switching from one pipe to another, the power sequencer of the new
pipe seems to need a bit of kicking to lock into the port. Even the vdd
force bit doesn't work before the power sequencer has been sufficiently
kicked, so this must be done before any AUX transactions are attempted.

After extensive experimentation I've determined that it's sufficient
to first write the port register with the correct values except the
port must remain disabled, then we can do a second write to enable the
port, after which the power sequencer is operational and allows the port
to start up properly.

Contrary to my earlier theories we don't need to enable the port with
the idle pattern, so let's just use training pattern 1 as that's what
other platforms use here.

v2: Refine the kick procedure
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's no point in checking if the data lanes came out of reset after
link training. If the data lanes aren't ready link training will fail
anyway.
Suggested-by: NTodd Previte <tprevite@gmail.com>
Cc: Todd Previte <tprevite@gmail.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Acked-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Just grab the pps_mutex once and do all the pps panel startup operations
while holding the mutex instead of grabbing the mutex separately for
each individual step.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We'll be needing to the call the power seqeuencer functions while
already holding pps_mutex, so split the locking out to small wrapper
functions.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since we read the current power seqeuncer delays from the registers
(as well as looking at the vbt and spec values) we may end up
corrupting delays we already initialized when we switch to another
pipe and the power seqeuncer there has different values currently
in the registers.

So make sure we only initialize the delays once even if
intel_dp_init_panel_power_sequencer() gets called multiple times.

There was some discussion in the review about when exactly we need to
unlock the pps. Quoting Bspec:

"If this bit is not a zero, it activates the register write protect
 and writes to those registers will be ignored unless the write
 protect key value is set in the panel sequencing control register."
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
[danvet: Add Bspec quote per review discussion between Imre and
Ville.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The power seqeuncer delays are fixed for a given panel, so we can keep
them around once computed.

Not that on VLV/CHV we still re-compute them every time we initialize
the power seqeuncer registers, but that will change soon enough.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

want_panel_vdd is a bool so it can't cope with interleaving on/off calls
from multiple threads. If we want to make that possible we'd need to
convert want_panel_vdd into a proper ref count. But an easier fix is to
remove the high level vdd on/off calls from detect/hpd code paths and
just rely on the delayed vdd off to avoid needless vdd on<->off ping
pong.

After this change only the encoder enable/disable paths use the high
level functions, which is fine since both the on and off low level edp
vdd calls from intel_dp_aux_ch() happen without dropping pps_mutex in
between and so want_panel_vdd can't change in between.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Only ports B and C have the power sequencer and backlight controls,
so complain if we ever try to register an eDP connector on some other
port.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Because I got annoyed that I had to document what values "int
ddi_personality" is supposed to hold.

A good side-effect of this change is that now the compilers can do
some additional checks on our code, which may prevent some bugs in the
future. A bad side-effect of this change is that now the compilers do
some additional checks on our code and complain when a switch
statement doesn't check for all possible values, so we need to add
"default" cases to all those switches. Hopefully, this may help
preventing confusions against DRM_MODE_CONNECTOR_* and
DRM_MODE_ENCODER_*.

I guess that just by looking at the patch, some people will think this
change is not worth its benefits. In this case, I don't really mind
dropping the patch.

Also, there's probably still a few more places where we can
s/int/enum intel_output_type/, but we can change that later, when we
spot the places.
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: Resolve conflict due to reordered patches.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will simplify things later on. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Everything else can be derived from that. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Most importantly, "i" need not be the universal variable used for
everything. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Const is good.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In preparation for some additional cleanup. No functional changes.
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The fb check introduced to drm_plane_helper_check_update() just make this
check impossible to branch in.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We can't let visible set true while the fb is null, some places of
the code only check for visible to base its decisions.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

use_mmio_flip() makes sure we only enable MMIO flips on gen5+. So we
don't need to take into account older devices.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There is no point in flipping a buffer for a disabled crtc.
Signed-off-by: NGustavo Padovan <gustavo.padovan@collabora.co.uk>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This patch includes the Gen9 batch buffer to generate
a 'golden context' for that product family.
Signed-off-by: NArmin Reese <armin.c.reese@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The file drivers/gpu/drm/i915/intel_renderstate_gen8.c is
updated to the version created by IGT null_state_gen
Signed-off-by: NArmin Reese <armin.c.reese@intel.com>
Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

libva uses chained batch buffers in a way that the command parser
can't generally handle. Fortunately, libva doesn't need to write
registers from batch buffers in the way that mesa does, so this
patch causes the driver to fall back to non-secure dispatch if
the parser detects a chained batch buffer.

Note: The 2nd hunk to munge the error code of the parser looks a bit
superflous. At least until we have the batch copy code ready and can
run the cmd parser in granting mode. But it isn't since we still need
to let existing libva buffers pass (though not with elevated privs
ofc!).

Testcase: igt/gem_exec_parse/chained-batch
Signed-off-by: NBrad Volkin <bradley.d.volkin@intel.com>
[danvet: Add note - this confused me in review and Brad clarified
things (after a few mails ...).]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This allows the cursor plane to be updated the same way as primary and sprites,
and same set_property handler is used for all of these planes.

v2 (by Matt Roper): Rework to apply to latest di-nightly codebase.  The
        switch to split check/commit plane programming changed the code
        flow enough that the original patch could no longer be applied.
Signed-off-by: NSonika Jindal <sonika.jindal@intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by (IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

If these flags are on the object level it will be more difficult to allow
for multiple VMAs per object.

v2: Simplification and cleanup after code review comments (Chris Wilson).
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

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

This will hopefully make it easier to navigate the code without the need
to consult the full PM documentation.

v2:
- add a comment that the freeze handler is also called after rebooting
- add a comment that the thaw handler is also called to recover from
  errors (Ville)
- add the PM event names (PMSG_THAW etc.) for reference (Ville)
- add comments that s0ix can be handled both via system and runtime
  suspend (Ville)
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By now we handle switcheroo and legacy suspend/resume the same way, so
no need to keep separate functions for them.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The suspend_late handler saves some registers and powers off the device,
so it doesn't have a big overhead. Calling it at S4 poweroff_late time
makes the power off handling identical to the S3 suspend and S4 freeze
handling, so do this for consistency.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By now the S4 freeze/thaw and S3 suspend/resume events are handled the
same way, so we can rename the freeze/thaw internal helpers to
suspend/resume accordingly to make clearer what the helpers do. Also
rename i915_resume_early to i915_drm_resume_early aligning it with the
rest of the helper names.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The S3 and S4 events are now handled the same way internally, there is no
need to keep separate wrapper functions around them. Simply reuse the
suspend/resume versions everywhere.

No functional change.
Signed-off-by: NImre Deak <imre.deak@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>