DSC params like the enable, compressed bpp, slice count and
dsc_split are added to the intel_crtc_state. These parameters
are set based on the requested mode and available link parameters
during the pipe configuration in atomic check phase.
These values are then later used to populate the remaining DSC
and RC parameters before enbaling DSC in atomic commit.

v15:
* Rebase over drm-tip
v14:
Remove leftovers, use dsc_bpc, refine dsc_compute_config (Ville)
v13:
* Compute DSC bpc only when DSC is req to be enabled (Ville)
v12:
* Override bpp with dsc dpcd color depth (Manasi)
v11:
* Const crtc_state, reject DSC on DP without FEC (Ville)
* Dont set dsc_split to false (Ville)
v10:
* Add a helper for dp_dsc support (Ville)
* Set pipe_config to max bpp, link params for DSC for now (Ville)
* Compute bpp - use dp dsc support helper (Ville)
v9:
* Rebase on top of drm-tip that now uses fast_narrow config
for edp (Manasi)
v8:
* Check for DSC bpc not 0 (manasi)

v7:
* Fix indentation in compute_m_n (Manasi)

v6 (From Gaurav):
* Remove function call of intel_dp_compute_dsc_params() and
invoke intel_dp_compute_dsc_params() in the patch where
it is defined to fix compilation warning (Gaurav)

v5:
Add drm_dsc_cfg in intel_crtc_state (Manasi)

v4:
* Rebase on refactoring of intel_dp_compute_config on tip (Manasi)
* Add a comment why we need to check PSR while enabling DSC (Gaurav)

v3:
* Check PPR > max_cdclock to use 2 VDSC instances (Ville)

v2:
* Add if-else for eDP/DP (Gaurav)

Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128213621.21391-1-manasi.d.navare@intel.com

Basic DSC parameters and DSC configuration data needs to be computed
for each of the requested mode during atomic check. This is
required since for certain modes, valid DSC parameters and config
data might not be computed in which case compression cannot be
enabled for that mode.
For that reason we need to add these params and config structure
to the intel_crtc_state so that if valid this state information
can directly be used while enabling DSC in atomic commit.

v2:
* Rebase on drm-tip (Manasi)

Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128202628.20238-1-manasi.d.navare@intel.com

In the future framebuffer stride alignment requirements won't exactly
match the units in which skl+ plane stride is specified. So extract
the code for the skl+ stuff into a separate helper.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180925193714.25280-3-ville.syrjala@linux.intel.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

Let's try to make sure the fb offset computations never hit
an integer overflow by making sure the entire fb stays
below 32bits. framebuffer_check() in the core already does
the same check, but as it doesn't know about tiling some things
can slip through. Repeat the check in the driver with tiling
taken into account.

v2: Use add_overflows() after massaging it to work for me (Chris)
v3: Call it add_overflow_t() to match min_t() & co. (Chris)

Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181023160201.9840-1-ville.syrjala@linux.intel.comReviewed-by: Chris Wilson <chris@chris-wilson.co.uk>

On icl+ the plane state that gets passed to update_slave() is not
the plane state of the plane we're programming. With NV12 the
plane state would be coming from the master (UV) plane whereas
the plane we're programming is the slave (Y) plane. For that reason
we need to explicitly pass around the slave plane (or we'd have to
otherwise deduce it by checking whether we were called via
.update_plane() or .update_slave()).

In the case of icl_program_input_csc_coeff() it's actually OK to
assume that we are always the master plane because the input CSC
only exists on HDR planes which can never be a slave plane. But
for consistency let's pass in the plane explicitly anyway.

While at it drop the "_coeff" from the function name since it's
kinda redundant, and this makes the name a bit shorter :)

Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-14-ville.syrjala@linux.intel.comReviewed-by: Uma Shankar <uma.shankar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>

A variable whose name is 'plane_id' is expected to be of the
enum plane_id type. In this case we have a raw int, which turns
out to refer to the plane of the framebuffer. Rename the variable
to 'color_plane' in line with the trend started earlier.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-13-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

skl+ can go belly up if there are overlapping ddb allocations between
planes. If we could absolutely guarantee that we can perform the atomic
update within a single frame we shouldn't have to worry about this. But
we can't rely on that so let's steal the ddb overlap check trick from
skl_update_crtcs() and apply it to the plane updates. Since each step
of the sequence is free from ddb overlaps we don't have to worry about
a vblank sneaking up on us in the middle of the sequence. The partial
state that gets latched by the hardware will be safe. And unlike
skl_update_crtcs() we don't have to intoduce any extra vblank waits
on account of only having to worry about a single pipe.

v2: Fix typo in commit msg (Matt)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-12-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

On SKL+ the plane WM/BUF_CFG registers are a proper part of each
plane's register set. That means accessing them will cancel any
pending plane update, and we would need a PLANE_SURF register write
to arm the wm/ddb change as well.

To avoid all the problems with that let's just move the wm/ddb
programming into the plane update/disable hooks. Now all plane
registers get written in one (hopefully atomic) operation.

To make that feasible we'll move the plane ddb tracking into
the crtc state. Watermarks were already tracked there.

v2: Rebase due to input CSC
v3: Split out a bunch of junk (Matt)
v4: Add skl_wm_add_affected_planes() to deal with
    cursor special case and non-zero wm register reset value
v5: Drop the unrelated for_each_intel_plane_mask() fix (Matt)
    Remove the redundant ddb memset() (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v3
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127165900.31298-1-ville.syrjala@linux.intel.com

Simplify the calling convention of the skl+ watermark functions
by not passing around dev_priv needlessly. The callees have
what they need to dig it out anyway.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-10-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Make a cleaner split between the skl+ and icl+ ways of computing
watermarks. This way skl_build_pipe_wm() doesn't have to know any
of the gritty details of icl+ master/slave planes.

We can also simplify a bunch of the lower level code by pulling
the plane visibility checks a bit higher up.

v2: WARN_ON(!visible) for the icl+ master plane case (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127165726.31122-1-ville.syrjala@linux.intel.com

We have to pass both level 0 watermark struct and the transition
watermark struct to skl_compute_transition_wm(). Make life less
confusing by just passing the entire plane watermark struct that
contains both aforementioned structures.

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-8-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

We memset(0) the entire watermark struct the start, so there's no
need to clear things later on.

v2: Rebase due to some stale w/a removal
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-7-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

If the level 0 latency is 0 we can't do anything. Return an error
rather than success.

While this can't happen due to WaWmMemoryReadLatency, it can
happen if the user clears out the level 0 latency via debugfs.

v2: Clarify how how we can end here with zero level 0 latency (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-6-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

We're going to need access to the new crtc state in ->disable_plane()
for SKL+ wm/ddb programming and pre-skl pipe gamma/csc control. Pass
the crtc state down.

We'll also try to make intel_crtc_disable_planes() do the right
thing as much as it's possible. The fact that we don't have a
separate crtc state for the disabled state when we're going to
re-enable the crtc later means we might end up poking at a few
extra planes in there. But that's harmless. I suppose one might
argue that we wouldn't have to care about proper ddb/wm/csc/gamma
if the pipe is going to permanently disable anyway, but the state
checker probably cares so we should try our best to make sure
everything is programmed correctly even in that case.

v2: Fix the commit message a bit (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-5-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Keep track which planes need updating during the commit. For now
we set the bit for any plane that was or will be visible (including
icl+ nv12 slave planes). In the future I'll have need to update
invisible planes as well, for skl plane ddbs and for pre-skl pipe
gamma/csc control (which lives in the primary plane control register).

v2: Pimp the commit message to mention icl+ nv12 slave planes (Matt)
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127163742.30215-1-ville.syrjala@linux.intel.com

The plane color correction registers are single buffered. So
ideally we would write them at the start of vblank just after the
double buffered plane registers have been latched. Since we have
no convenient way to do that for now let's at least move the
single buffered register writes to happen after the double
buffered registers have been written.
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-3-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Some observations about the plane registers:
- the control register will self-arm if the plane is not already
  enabled, thus we want to write it as close to (or ideally after)
  the surface register
- tileoff/linoff/offset/aux_offset are self-arming as well so we want
  them close to the surface register as well
- color keying registers we maybe self arming before SKL. Not 100%
  sure but we can try to keep them near to the surface register
  as well
- chv pipe b csc register are double buffered but self arming so
  moving them down a bit
- the rest should be mostly armed by the surface register so we can
  safely write them first, and to just for some consistency let's try
  to follow keep them in order based on the register offset

None of this will have any effect of course unless the vblank evasion
fails (which it still does sometimes). Another potential future benefit
might be pulling the non-self armings registers outside the vblank
evasion since they won't latch until the arming register has been
written. This would make the critical section a bit lighter and thus
less likely to exceed the deadline.

v2: Rebase due to input CSC
v3: Swap LINOFF/TILEOFF and KEYMSK/KEYMAX to actually follow
    the last rule above (Matt)
    Add a bit more rationale to the commit message (Matt)

Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181114210729.16185-2-ville.syrjala@linux.intel.comReviewed-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>

Mark A0 as the one and only pre-production variant of Kabylake and
remove its couple of workarounds, consigning them to the annals of
history.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181128135325.10641-1-chris@chris-wilson.co.uk

DSC specification defines linebuf_depth which contains the
line buffer bit depth used to generate the bitstream.
These values are defined as per Table 4.1 in DSC 1.2 spec

v2 (From Manasi):
* Rename as MAX_LINEBUF_DEPTH for DSC 1.1 and DSC 1.2

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-6-manasi.d.navare@intel.com

According to Display Stream compression spec 1.2, the picture
parameter set metadata is sent from source to sink device
using the DP Secondary data packet. An infoframe is formed
for the PPS SDP header and PPS SDP payload bytes.
This patch adds helpers to fill the PPS SDP header
and PPS SDP payload according to the DSC 1.2 specification.

v7:
* Use BUILD_BUG_ON() to protect changing struct size (Ville)
* Remove typecaseting (Ville)
* Include byteorder.h in drm_dsc.c (Ville)
* Correct kernel doc spacing (Anusha)
v6:
* Use proper sequence points for breaking down the
assignments (Chris Wilson)
* Use SPDX identifier
v5:
Do not use bitfields for DRM structs (Jani N)
v4:
* Use DSC constants for params that dont change across
configurations
v3:
* Add reference to added kernel-docs in
Documentation/gpu/drm-kms-helpers.rst (Daniel Vetter)

v2:
* Add EXPORT_SYMBOL for the drm functions (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-5-manasi.d.navare@intel.com

DSC has some Rate Control values that remain constant
across all configurations. These are as per the DSC
standard.

v3:
* Define them in drm_dsc.h as they are
DSC constants (Manasi)
v2:
* Add DP_DSC_ prefix (Jani Nikula)

Cc: dri-devel@lists.freedesktop.org
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Srivatsa, Anusha <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-4-manasi.d.navare@intel.com

This defines all the DSC parameters as per the VESA DSC spec
that will be required for DSC encoder/decoder

v6: (From Manasi)
* Add a bit mask for RANGE_BPG_OFFSET for 6 bits(Manasi)
v5 (From Manasi)
* Add the RC constants as per the spec
v4 (From Manasi)
* Add the DSC_MUX_WORD_SIZE constants (Manasi)

v3 (From Manasi)
* Remove the duplicate define (Suggested By:Harry Wentland)

v2: Define this struct in DRM (From Manasi)
* Changed the data types to u8/u16 instead of unsigned longs (Manasi)
* Remove driver specific fields (Manasi)
* Move this struct definition to DRM (Manasi)
* Define DSC 1.2 parameters (Manasi)
* Use DSC_NUM_BUF_RANGES (Manasi)
* Call it drm_dsc_config (Manasi)

Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Co-developed-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Acked-by: Harry Wentland <harry.wentland@amd.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-3-manasi.d.navare@intel.com

This patch defines a new header file for all the DSC 1.2 structures
and creates a structure for PPS infoframe which will be used to send
picture parameter set secondary data packet for display stream compression.
All the PPS infoframe syntax elements are taken from DSC 1.2 specification
from VESA.

v4:
* Remove redundant blankline in doc (Ville)
* use drm_dsc namespace for all structs (Ville)
* Use packed struct (Ville)
v3:
* Add the SPDX shorthand (Chris Wilson)
v2:
* Do not use bitfields in the struct (Jani Nikula)

Cc: Gaurav K Singh <gaurav.k.singh@intel.com>
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Harry Wentland <harry.wentland@amd.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Harry Wentland <harry.wentland@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-2-manasi.d.navare@intel.com

DSC DPCD color depth register advertises its color depth capabilities
by setting each of the bits that corresponding to a specific color
depth. This patch defines those specific color depths and adds
a helper to return an array of color depth capabilities.

v2:
* Simplify the logic (Ville)
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Acked-by: Sean Paul <seanpaul@chromium.org> (For merging through
drm-intel)
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181127214125.17658-1-manasi.d.navare@intel.com

If the engine's seqno is already at our target seqno (most likely it
hasn't been used since the last reset), we can skip serialising the
engine and leave it as is.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126095610.20962-1-chris@chris-wilson.co.uk

We may be simply restarting too fast for the culmudgeonly gen3/gen4 as
we still see missing interrupts following a reset. So let's try
restarting a little slower, first wake up the ring empty and then tell
it about the work it has to perform.

References: https://bugs.freedesktop.org/show_bug.cgi?id=108735Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181126122821.4537-1-chris@chris-wilson.co.uk

Currently, we convert the error state into a string every time we read
from sysfs (and sysfs reads in page size (4KiB) chunks). We do try to
window the string and only capture the portion that is being read, but
that means that we must always convert up to the window to find the
start. For a very large error state bordering on EXEC_OBJECT_CAPTURE
abuse, this is noticeable as it degrades to O(N^2)!

As we do not have a convenient hook for sysfs open(), and we would like
to keep the lazy conversion into a string, do the conversion of the
whole string on the first read and keep the string until the error state
is freed.

v2: Don't double advance simple_read_from_buffer
v3: Due to extreme pain of lack of vrealloc, use a scatterlist
v4: Keep the forward iterator loosely cached
v5: Stylistic improvements to reduce patch size
Reported-by: Jason Ekstrand <jason@jlekstrand.net>
Testcase: igt/gem_exec_capture/many*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181123132325.26541-1-chris@chris-wilson.co.uk

We should not access hardware while computing config also we don't
support stereo 3D so this test was never true.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-6-jose.souza@intel.com

If a PSR error happened and the driver is reloaded, the EDP_PSR_IIR
will still keep the error set even after the reset done in the
irq_preinstall and irq_uninstall hooks.
And enabling in this situation cause the screen to freeze in the
first time that PSR HW tries to activate so lets keep PSR disabled
to avoid any rendering problems.

v5: rebased: using edp_psr_shift()

v4: Moved handling from intel_psr_compute_config() to
intel_psr_init() to avoid hardware access during compute(Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>

squash
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-5-jose.souza@intel.com

While PSR is active hardware will do aux transactions by it self to
wakeup sink to receive a new frame when necessary. If that
transaction is not acked by sink, hardware will trigger this
interruption.

So let's disable PSR as it is a hint that there is problem with this
sink.

The removed FIXME was asking to manually train the link but we don't
need to do that as by spec sink should do a short pulse when it is
out of sync with source, we just need to make sure it is awaken and
the SDP header with PSR inactive set it will trigger the short pulse
with a error set in the link status.

v3: added workarround to fix scheduled work starvation cause by
to frequent PSR error interruption

v4: only setting irq_aux_error as we don't care in clear it and
not using dev_priv->irq_lock as consequence.

v5: rebased: using edp_psr_shift()

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-4-jose.souza@intel.com

When we detect a error and disable PSR, it is kept disabled until the
next modeset but as the sink already show signs that it do not
properly work with PSR lets disabled it for good to avoid any
additional flickering.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-3-jose.souza@intel.com

When a PSR error happens sink sets the PSR error register and also
set the link status to a error status.
So in the short pulse handling it was returning earlier and doing a
full detection and attempting to retrain but it fails as PSR HW is
in change of the main-link.

Just call intel_psr_short_pulse() before
intel_dp_needs_link_retrain() is not the right fix as
intel_dp_needs_link_retrain() would return true and trigger a full
detection while PSR HW is still in change of main-link.

Check for PSR active is also not safe as it could be inactive due a
frontbuffer invalidate and still doing the PSR exit sequence.

v3: added comment in intel_dp_needs_link_retrain()

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-2-jose.souza@intel.com

Some eDP panels do not set a valid sink count value and even for the
ones that sets is should always be one for eDP, that is why it is not
cached in intel_edp_init_dpcd().

But intel_dp_short_pulse() compares the old count with the read one
if there is a mistmatch a full port detection will be executed, what
was happening in the first short pulse interruption of eDP panels
that sets sink count.

Instead of just skip the compasison for eDP panels, lets not read
the sink count at all for eDP.

v2: the previous version of this patch it was caching the sink count
in intel_edp_init_dpcd() but I was pointed out by Ville a patch that
handled a case of a eDP panel that do not set sink count and as sink
count is not used to eDP certification was choosed to just not read
it at all.

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121225441.18785-1-jose.souza@intel.com

While trying to add a chamelium test for short HPD IRQs, I ran into
issues where a hotplug storm would be triggered, but the point at which
it would be reported by the kernel would be after igt actually finished
checking i915_hpd_storm_ctl's status. So, fix this by simply
synchronizing our IRQ work, dig_port_work, and hotplug_work before
printing out the HPD storm status in i915_hpd_storm_ctl_show().
Signed-off-by: Lyude Paul <lyude@redhat.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121003718.17704-1-lyude@redhat.com

Replace the messy framebuffer format/modifier validation code
with a single call to drm_any_plane_has_format(). The code was
extremely annoying to maintain as you had to have a lot of platform
checks for different formats. The new code requires zero maintenance.

v2: Nuke the modifier checks as well since the core does that too now
v3: Call drm_any_plane_has_format() from the driver code
v4: Rebase

Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181029183453.28541-2-ville.syrjala@linux.intel.comReviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Signed-off-by: Jani Nikula <jani.nikula@intel.com>

There is no need to rebuild i915_gpu_error.o when the version string
changes as the version is available in init_utsname()->release.
Signed-off-by: Hans Holmberg <hans.holmberg@cnexlabs.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121095423.20760-1-hans.ml.holmberg@owltronix.com

When showing the list of waiters, include the task's status so that we
can tell if they have been woken up and are waiting for the CPU, or if
they are still waiting to be woken.

v2: task_state_to_char()
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181121151653.24595-1-chris@chris-wilson.co.uk

If we need to force a full plane update before userspace/fbdev
have given us a proper plane state we should try to maintain the
current plane state as much as possible (apart from the parts
of the state we're trying to fix up with the plane update).
To that end add basic readout for the plane rotation and
maintain it during the initial fb takeover.

Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: 516a49cc ("drm/i915: Fix assert_plane() warning on bootup with external display")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181120135450.3634-2-ville.syrjala@linux.intel.comTested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>