More implicit dev_priv removal.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610120608.15477-4-tvrtko.ursulin@linux.intel.com

More removal of implicit dev_priv.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610120608.15477-3-tvrtko.ursulin@linux.intel.com

No excuse for code located in intel_uncore.c to not use intel_uncore_
helpers.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610120608.15477-2-tvrtko.ursulin@linux.intel.com

On the path of removing mmio accessors with implicit dev_priv, easy first
step is to remove all such unused macros.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190610120608.15477-1-tvrtko.ursulin@linux.intel.com

Gen10 added an additional NOA_WRITE register (high bits) and we forgot
to whitelist it for userspace.

Fixes: 95690a02 ("drm/i915/perf: enable perf support on CNL")
Signed-off-by: NLionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: NKenneth Graunke <kenneth@whitecape.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190601225845.12600-1-lionel.g.landwerlin@intel.com

The code is logically about reset so it makes sense.

It also enables making i915_clear_error_registers static.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607115932.20271-1-tvrtko.ursulin@linux.intel.com

Fix the grammar.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607113118.14645-1-geert+renesas@glider.be

This no longer exists.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606122203.13416-4-jani.nikula@intel.com

Some function declarations in intel_drv.h were missed when
intel_atomic_plane.h was created.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606122203.13416-3-jani.nikula@intel.com

intel_mark_busy(), intel_mark_idle(), and skl_cdclk_get_vco() no longer
exist.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606122203.13416-2-jani.nikula@intel.com

Move more missed declarations from i915_drv.h to intel_pm.h.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606122203.13416-1-jani.nikula@intel.com

The size has been increased to 2MB starting from Gen11. GuC and HuC FWs
fit in 1MB so we were fine even with the legacy define, but let's still
move to the correct one before the blobs grow to avoid being caught off
guard in the future.

v2: return early if the platform doesn't have GuC, fix nits (Michal)

Bspec: 12690
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: NStuart Summers <stuart.summers@intel.com>
[ickle: use SZ consistently]
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606224225.14287-2-daniele.ceraolospurio@intel.com

Now that we've moved the Gen9 GuC blobs to version 32 we have CTB
support on all gens, so no need to restrict the usage to Gen11+.
Note that MMIO communication is still required for CTB initialization.

v2: fix commit message nits (Michal)
Signed-off-by: NDaniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606224225.14287-1-daniele.ceraolospurio@intel.com

The GOP sometimes initializes the pclk at a (slightly) different frequency
then the pclk which we've calculated.

This commit makes the DSI code read-back the pclk set by the GOP and
if that is within a reasonable margin of the calculated pclk, uses
that instead.

This fixes the first modeset being a full modeset instead of a
fast modeset on systems where the GOP pclk is different.

Changes in v2:
-Use intel_encoder_current_mode() to get the pclk setup by the GOP

Changes in v3:
-Back to the readback approach, skipping the dsi_pll.ctrl / .dev checks
 in intel_pipe_config_compare() when adjust is set leads to:
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.ctrl (...)
 [drm:pipe_config_err [i915]] *ERROR* mismatch in dsi_pll.div (...)
-Do the readback and pclk overriding from vlv_dsi_init(), rather then from
 intel_dsi_vbt_init() as the vbt code should not be touching the hw
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605181735.7020-3-hdegoede@redhat.com

The vlv/icl_dphy_param_init calls do various calculations to set dphy
parameters based on the pclk.

Move the calling of vlv/icl_dphy_param_init to vlv_dsi_init to give
vlv_dsi_init a chance to tweak the pclk before these calculations are done.

Changes in v2:
-Also moves the icl and vlv specific dphy_param_init functions from the
 generic intel_dsi_vbt.c file into the icl_ and vlv_dsi.c specific files.

Note icl_dphy_param_init() and vlv_dphy_param_init() are only moved,
otherwise they are completely unchanged.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605181735.7020-2-hdegoede@redhat.com

This is a preparation patch for moving the calling of *_dphy_param_init()
out of intel_dsi_vbt_init.
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605181735.7020-1-hdegoede@redhat.com

It's much easier to figure out why the SDVO encoder refuses to cooperate
if we can see what status we got back.

v2: Zero initialize only the first character, not the whole buffer
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20190410170941.28142-1-ville.syrjala@linux.intel.com

Pass the length returned by hdmi_infoframe_pack_only() to
intel_sdvo_write_infoframe() so that we don't end up writing
stack garbage into the hbuf.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-7-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Pass the length returned by intel_sdvo_read_infoframe() to
hdmi_infoframe_unpack() so that we don't try to unpack any
leftover stack garbage.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-6-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Before we go writing the infoframe let's make sure we have
the space for it. Not that it really matters since the write
loop would just terminate early in that case.

v2: Check after the debug print and ++ (Chris)
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410170835.18867-1-ville.syrjala@linux.intel.comReviewed-by: NRadhakrishna Sripada <radhakrishna.sripada@intel.com>

The "audio enable" bit on the SDVO/HDMI control register is only meant
for HDMI. Audio is never delivered over the SDVO bus. Rename the define
to reflect this fact.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-4-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

Our SDVO audio support is pretty bogus. We can't push audio over the
SDVO bus, so trying to enable audio in the SDVO control register doesn't
do anything. In fact it looks like the SDVO encoder will always mix in
the audio coming over HDA, and there's no (at least documented) way to
disable that from our side. So HDMI audio does work currently on gen4
but only by luck really. On gen3 it got broken by the referenced commit.
And what has always been missing on every platform is the ELD.

To pass the ELD to the audio driver we need to write it to magic buffer
in the SDVO encoder hardware which then gets pulled out via HDA in the
other end. Ie. pretty much the same thing we had for native HDMI before
we started to just pass the ELD between the drivers. This sort of
explains why we even have that silly hardware buffer with native HDMI.

$ cat /proc/asound/card0/eld#1.0
-monitor_present		0
-eld_valid		0
+monitor_present		1
+eld_valid		1
+monitor_name		LG TV
+connection_type		HDMI
+...

This also fixes our state readout since we can now query the SDVO
encoder about the state of the "ELD valid" and "presence detect"
bits. As mentioned those don't actually control whether audio
gets sent over the HDMI cable, but it's the best we can do. And with
the state checker appeased we can re-enable HDMI audio for gen3.

Cc: stable@vger.kernel.org
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: zardam@gmail.com
Tested-by: zardam@gmail.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108976
Fixes: de44e256 ("drm/i915/sdvo: Shut up state checker with hdmi cards on gen3")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-3-ville.syrjala@linux.intel.comReviewed-by: NImre Deak <imre.deak@intel.com>

The AVI infoframe readout code currently issues a
SDVO_CMD_GET_HBUF_TXRATE before SDVO_CMD_SET_HBUF_INDEX, which is
not the correct order for these two operations. So far this wasn't
a problem since we left the index pointing at the AVI infoframe
buffer at the end of the modeset. However once we start to write
to other buffers (namely ELD) that is no longer going to be true.
Fix up the order so that we always read out the TX rate for the
correct buffer.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409144054.24561-2-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>

We forgot to set .has_alpha=true for the A+CCS formats when the code
started to consult .has_alpha. This manifests as A+CCS being treated
as X+CCS which means no per-pixel alpha blending. Fix the format
list appropriately.

Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Heinrich Fink <heinrich.fink@daqri.com>
Reported-by: NHeinrich Fink <heinrich.fink@daqri.com>
Tested-by: NHeinrich Fink <heinrich.fink@daqri.com>
Fixes: b2081525 ("drm/i915: Add plane alpha blending support, v2.")
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190603142500.25680-1-ville.syrjala@linux.intel.comReviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>

intel_dp_link_down() is static and it's only called from the pre-ddi
DP functions, so having a WARN_ON(HAS_DDI) in there is quite pointless.
Remove it.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604140214.9947-2-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

It's a bit silly to go through intel_dp.c to assign the
prepare_link_train vfunc for ddi platforms when we can just
assign it directly from intel_ddi.c.
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604140214.9947-1-ville.syrjala@linux.intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>

Get to uncore from the engine for better logic organization and use
already available i915 everywhere.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607084521.16845-2-tvrtko.ursulin@linux.intel.com

Remove a couple dev_priv locals as a consequence.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607084521.16845-1-tvrtko.ursulin@linux.intel.com

These two are only used from within i915_gem_gtt.c and can trivially be
made static.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607082557.31670-5-tvrtko.ursulin@linux.intel.com

Just tidying the flow a bit.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607082557.31670-4-tvrtko.ursulin@linux.intel.com

Similar to earlier conversions, eliminate the implicit dev_priv by
introducing some helpers which take the engine parameter (since the
register itself is per engine).

v2:
 * Always use parentheses in macro arguments.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607101535.767-1-tvrtko.ursulin@linux.intel.com

We can use intel_engine_mask_t to align with the rest of the codebase.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607082557.31670-2-tvrtko.ursulin@linux.intel.com

Pass down the engine mask to i915_clear_error_registers so only affected
engines can be reset on the Gen6/7 path.
Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607082557.31670-1-tvrtko.ursulin@linux.intel.com

While loading the DMC firmware we were double checking the headers made
sense, but in no place we checked that we were actually reading memory
we were supposed to. This could be wrong in case the firmware file is
truncated or malformed.

Before this patch:
	# ls -l /lib/firmware/i915/icl_dmc_ver1_07.bin
	-rw-r--r-- 1 root root  25716 Feb  1 12:26 icl_dmc_ver1_07.bin
	# truncate -s 25700 /lib/firmware/i915/icl_dmc_ver1_07.bin
	# modprobe i915
	# dmesg| grep -i dmc
	[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
	[drm] Finished loading DMC firmware i915/icl_dmc_ver1_07.bin (v1.7)

i.e. it loads random data. Now it fails like below:
	[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
	[drm:csr_load_work_fn [i915]] *ERROR* Truncated DMC firmware, rejecting.
	i915 0000:00:02.0: Failed to load DMC firmware i915/icl_dmc_ver1_07.bin. Disabling runtime power management.
	i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915

Before reading any part of the firmware file, validate the input first.

Fixes: eb805623 ("drm/i915/skl: Add support to load SKL CSR firmware.")
Cc: stable@vger.kernel.org
Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605235535.17791-1-lucas.demarchi@intel.com

On i915_gem_load_power_context() we do care whether or not we succeed in
completing the switch back to the kernel context (via idling the
engines). Currently, we detect if an error occurs while we wait, but we
do not report one if it occurred beforehand (and the status of the
switch is undefined). Check the current terminally wedged status on
entering the wait, and report it after flushing the requests, as if it
had occurred during our own wait.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110824Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190531113245.30042-1-chris@chris-wilson.co.uk

The intent was to skip unused HW contexts by checking ce->state.
However, this only works for execlists where the ppGTT pointers is
stored inside the HW context. For gen7, the ppGTT is alongside the
logical state and must be updated on all active engines but, crucially,
only on active engines. As we need different checks, and to keep
context_barrier_task() agnostic, pass in the predicate.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110836
Fixes: 62c8e423 ("drm/i915: Skip unused contexts for context_barrier_task()")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190604152408.24468-1-chris@chris-wilson.co.uk

Use i915_gem_object_lock() to guard the LUT and active reference to
allow us to break free of struct_mutex for handling GEM_CLOSE.

Testcase: igt/gem_close_race
Testcase: igt/gem_exec_parallel
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMatthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190606112320.9704-1-chris@chris-wilson.co.uk

Just a straightforward bag of fixes for a clean htmldocs build.
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605095657.23601-2-jani.nikula@intel.com

The error messages could be more descriptive, but fix these caused by
file moves:

WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
    ./drivers/gpu/drm/i915/i915_gem_shrinker.c' failed with return code 2
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
    User command execution ./drivers/gpu/drm/i915/i915_gem_execbuffer.c'
    failed with return code 1
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -internal
    ./drivers/gpu/drm/i915/i915_gem_tiling.c' failed with return code 2
WARNING: kernel-doc './scripts/kernel-doc -rst -enable-lineno -function
    buffer object tiling ./drivers/gpu/drm/i915/i915_gem_tiling.c'
    failed with return code 1

Fixes: 10be98a7 ("drm/i915: Move more GEM objects under gem/")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605095657.23601-1-jani.nikula@intel.com

Unlike ICL, EHL's combo PHYs can support HBR3 data rates.  Note that
this just extends the upper limit; we will continue to honor the max
data rate specified in the VBT in cases where it is lower than HBR3.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605211832.23945-1-matthew.d.roper@intel.comReviewed-by: NManasi Navare <manasi.d.navare@intel.com>