We more or less randomly call the "bytes per pixel" value
'cpp', 'bytes_per_pixel', 'pixel_size', or even 'bpp'. Let's just pick
one and stick to it. I've chosen 'cpp'.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Using 'unsigned long' for ggtt offsets doesn't make much sense. Use
'u32' instead since we've not yet seen a >4GiB ggtt.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1453316739-13296-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since intel_gen4_compute_page_offset() can now handle tiling formats
all the way down to gen2, rename it to intel_compute_tile_offset().
Not that we actually use it on gen2/3 since there's no DSPSURF etc.
registers which would take a page aligned address.

v2: s/page/tile/ (Daniel)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-7-git-send-email-ville.syrjala@linux.intel.com

I find more usual to think about tile widths than heights, so changing
the intel_tile_height() to calculate the tile height as
tile_size/tile_width is easier than the opposite to the poor brain.

v2: Reorder arguments for consistency
    Constify dev_priv arguments
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-4-git-send-email-ville.syrjala@linux.intel.com

Pull the tile width calculations from intel_fb_stride_alignment() into a
new function intel_tile_width().

Also take the opportunity to pass aroun dev_priv instead of dev to
intel_fb_stride_alignment().

v2: Reorder argumnents to be more consistent with other functions
    Change intel_fb_stride_alignment() to accept dev_priv instead of dev
v3: Deal with Y tilling (Daniel)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-3-git-send-email-ville.syrjala@linux.intel.com

In preparation for handling more than X tiling, pass the fb modifier to
gen4_compute_page_offset() instead of the obj->tiling_mode.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1452625717-9713-2-git-send-email-ville.syrjala@linux.intel.com

Use update_plane and disable_plane directly.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-3-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Don't use plane->state directly, use the pointer from commit_plane.

Changes since v1:
- Fix uses of plane->state->rotation and color key to use the passed state too.
- Only pass crtc_state and plane_state to update_plane.
Changes since v2:
- Rebased.
Changes since v3:
- Small whitespace changes and only assign 1 variable per line.
- Constify plane_state and crtc_state. (vsyrjala)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1452164052-21752-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

Done with coccinelle for the most part. It choked on
msm/mdp/mdp5/mdp5_plane.c like so:
"BAD:!!!!!  enum drm_plane_type type;"
No idea how to deal with that, so I just fixed that up
by hand.

Also it thinks '...' is part of the semantic patch, so I put an
'int DOTDOTDOT' placeholder in its place and got rid of it with
sed afterwards.

I didn't convert drm_plane_init() since passing the varargs through
would mean either cpp macros or va_list, and I figured we don't
care about these legacy functions enough to warrant the extra pain.

@@
typedef uint32_t;
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
                              struct drm_plane *plane,
                              unsigned long possible_crtcs,
                              const struct drm_plane_funcs *funcs,
                              const uint32_t *formats,
                              unsigned int format_count,
                              enum drm_plane_type type
+                             ,const char *name, int DOTDOTDOT
                              )
{ ... }

@@
identifier dev, plane, possible_crtcs, funcs, formats, format_count, type;
@@
 int drm_universal_plane_init(struct drm_device *dev,
                              struct drm_plane *plane,
                              unsigned long possible_crtcs,
                              const struct drm_plane_funcs *funcs,
                              const uint32_t *formats,
                              unsigned int format_count,
                              enum drm_plane_type type
+                             ,const char *name, int DOTDOTDOT
                              );

@@
expression E1, E2, E3, E4, E5, E6, E7;
@@
 drm_universal_plane_init(E1, E2, E3, E4, E5, E6, E7
+                         ,NULL
                          )

v2: Split crtc and plane changes apart
    Pass NUL for no-name instead of ""
    Leave drm_plane_init() alone
v3: Add ', or NULL...' to @name kernel doc (Jani)
    Annotate the function with __printf() attribute (Jani)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449670795-2853-1-git-send-email-ville.syrjala@linux.intel.com

The cherryview device shares many characteristics with the valleyview
device.  When support was added to the driver for cherryview, the
corresponding device info structure included .is_valleyview = 1.
This is not correct and leads to some confusion.

This patch changes .is_valleyview to .is_cherryview in the cherryview
device info structure and simplifies the IS_CHERRYVIEW macro.
Then where appropriate, instances of IS_VALLEYVIEW are replaced with
IS_VALLEYVIEW || IS_CHERRYVIEW or equivalent.

v2: Use IS_VALLEYVIEW || IS_CHERRYVIEW instead of defining a new macro.
    Also add followup patches to fix issues discovered during the first
    review. (Ville)
v3: Fix some style issues and one gen check. Remove CRT related changes
    as CRT is not supported on CHV. (Imre, Ville)
v4: Make a few more optimizations. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: NWayne Boyer <wayne.boyer@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1449692975-14803-1-git-send-email-wayne.boyer@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>

Allow the caller to specify a "prefix" string to drm_rect_debug_print()
to make it easier to see which drm_rect is being printed.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

VMA offsets are 64 bits. Plane surface offsets are in ggtt and
the hardware register to set this is thus 32 bits. Be explicit
about these and convert carefully to from vma to final size.

This will make sparse happy by not creating 32bit pointers out
of 64bit vma offsets.

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.comReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>

The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update.  However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call.  Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com>
Link: http://patchwork.freedesktop.org/patch/60372/

The crtc->active guards are no longer needed now that all state
updates are outside the commit.

Changes since v1:
- Only check crtc->state->active before calling commit_planes_on_crtc.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

We still had one lingering RMW in ivb_sprite_disable(), all the other
RMWs were killed off from the sprite code some time ago. Kill the
straggler too.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Since SKL has universal planes, we should configure the sprite planes
and the primary plane the same.  For the primary plane we do enable
the pipe gamma on the plane so do the same for the non-primary planes.

Without this, the pipe CRC values will be different for something
displayed on the primary plane and something displayed on a sprite
plane when the ARGB8888 format is used.
Signed-off-by: NBob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This is a squash of the following commits:

Revert "drm/i915: Drop intel_update_sprite_watermarks"
This reverts commit 47c99438.

Revert "drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check"
This reverts commit 7809e5ae.

Revert "drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)"
This reverts commit 3a05f5e2.

With these reverts, SKL finally stops failing every single FBC test
with FIFO underrun error messages. After some brief testing, it also
seems that this commit prevents the machine from completely freezing
when we run igt/kms_fbc_crc (see fd.o #92355).

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92355
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The only platform that still has an update_sprite_wm entrypoint is SKL;
on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and
then performs a regular watermark update.  However intel_plane->wm is
only used to update a couple fields in intel_wm_config, and those fields
are never used by the SKL code, so on SKL an update_sprite_wm is
effectively identical to an update_wm call.  Since we're already
ensuring that the regular intel_update_wm is called any time we'd try to
call intel_update_sprite_watermarks, the whole call is redundant and can
be dropped.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Rename the function argument to 'adjusted_mode' whenever the function
only ever gets passed the adjusted_mode.

v2: Update due to intel_dsi.c changes
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Always name any variable pointing at the adjusted mode as
'adjustead_mode'. This will make it much easier to identify
when we should use the crtc_ timings and when we shoudln't.

Conversion was performed with coccinelle:
@@
expression E;
identifier I;
@@
- struct drm_display_mode *I = &E.adjusted_mode;
+ struct drm_display_mode *adjusted_mode = &E.adjusted_mode;
<...
- I
+ adjusted_mode
...>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NMika Kahola <mika.kahola@intel.com>
[danvet: Fixup conflicts.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This will be needed for NV12 support.

v2: Rebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Use the new debug info in the intel_crtc struct in these functions
rather than passing them as args.

v2: move min/max assignment back above first trace call (Ville)
    use scanline from crtc->debug rather than fetching a new one (Ville)
v3: fix up trace_i915_pipe_update_end, needs end scanline (Ville)
Requested-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

I used these additional fields to track down the issue I saw on HSW.

v2: move debug fields into a substruct (Ville)
v3: clean up debug code more (Ville)

References: https://bugs.freedesktop.org/show_bug.cgi?id=91579Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>

Shared frontbuffer bits are causing warnings when same FB is displayed
in another plane without clearing the bits from previous plane.

v2: Removing coversion of fb bits to 64 bit as it is not needed for now. (Daniel)

Change-Id: Ic2df80747f314b82afd22f8326297c57d1e652c6
Signed-off-by: NSagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: NKumar, Mahesh <mahesh1.kumar@intel.com>
[danvet: Drop INTEL_FRONTBUFFER_SPRITE_MASK since unused.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Unfortunately fbc still depends on legacy primary state, so
it can't be killed off completely yet.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This makes the error message slightly more useful.

Changes since v1:
- Use ktime_get() while irqs are still disabled. (vsyrjala)
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

There's already a per crtc member that can be used for it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This can only fail because of a bug in the code.
Suggested-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
[danvet: Squash in follow-up to also remove start_vbl_count from
intel_crtc->atomic and put it into the intel_crtc directly - it's not
precomputed state.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

In order to get decnet memory self refresh residency on VLV, flip it
over to the new CHV way of doing things. VLV doesn't do PM5 or DDR DVFS
so it's a bit simpler.

I'm not sure the currently memory latency used for CHV is really
appropriate for VLV. Some further testing will probably be needed to
figure that out.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NClint Taylor <Clinton.A.Taylor@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Avoid some 'switch (plane->type)' by storing the fronbuffer_bits in
intel_plane.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
[danvet: use singular frontbuffer_bits in intel_plane since a plan can
only ever have one bit. Discussed with Ville on irc.]
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By making color key atomic there are no more transitional helpers.
The plane check function will reject the color key when a scaler is
active.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Now that all planes are added during a modeset we can use the
calculated changes before disabling a plane, and then either commit
or force disable a plane before disabling the crtc.

The code is shared with atomic_begin/flush, except watermark updating
and vblank evasion are not used.

This is needed for proper atomic suspend/resume support.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90868Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The idea was good, but planes can have a fb even though
they're disabled. This makes the force argument useless
and always true, because only the commit function updates
state.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

By passing crtc_state to the check_plane functions a lot of duplicated
code can be removed. There are still some transitional helper calls,
they will be removed later.

Changes since v1:
- Revert state->visible changes.
- Use plane->state->crtc instead of plane->crtc.
- Use drm_atomic_get_existing_crtc_state.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

No point in hiding behind big ifs. This will be true most of the time.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

This makes it easier to verify that no changes are done when
calling this from crtc instead.

Changes since v1:
 - Make intel_wm_need_update static and always check it.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

commit 2c310b9d2859863826c3688c88218d607d5dd19a
Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Date:   Mon May 18 12:28:52 2015 +0200

drm/i915: Split skl_update_scaler, v4.

It's easier to read separate functions for crtc and plane scaler state.

Changes since v1:
 - Update documentation.
Changes since v2:
 - Get rid of parameters to skl_update_scaler only used for traces.
   This avoids needing to document the other parameters.
Changes since v3:
 - Rename scaler_idx to scaler_user.
Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: NMatt Roper <matthew.d.roper@intel.com>
Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Currently intel_gen4_compute_page_offset() simply picks the closest
page boundary below the linear offset. That however may not be suitably
aligned to satisfy any hardware specific restrictions. So let's make
sure the page boundary we choose is properly aligned.

Also to play it a bit safer lets split the remaining linear offset into
x and y values instead of just x. This should make no difference for
most platforms since we convert the x and y offsets back into a linear
offset before feeding them to the hardware. HSW+ are different however
and use x and y offsets even with linear buffers, so they might have
trouble if either the x or y get too big.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

I noticed one of those and it turned out we have a few lingering around.
Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>