i915_gem_suspend() tries to access the device to ensure it is idle and
all writes from the device are flushed to memory. It assumed is already
held the runtime pm wakeref, but we should explicitly acquire it for our
access to be safe.

[  619.926287] WARNING: CPU: 3 PID: 9353 at drivers/gpu/drm/i915/intel_drv.h:1750 gen6_write32+0x23e/0x2a0 [i915]
[  619.926300] RPM wakelock ref not held during HW access
[  619.926311] Modules linked in: vgem x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec coretemp snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul snd_pcm mei_me mei lpc_ich ghash_clmulni_intel i915(-) sdhci_pci sdhci mmc_core e1000e ptp pps_core prime_numbers [last unloaded: snd_hda_intel]
[  619.926578] CPU: 3 PID: 9353 Comm: drv_module_relo Tainted: G     U          4.10.0-CI-Trybot_609+ #1
[  619.926585] Hardware name: LENOVO 42962WU/42962WU, BIOS 8DET56WW (1.26 ) 12/01/2011
[  619.926592] Call Trace:
[  619.926609]  dump_stack+0x67/0x92
[  619.926625]  __warn+0xc6/0xe0
[  619.926640]  warn_slowpath_fmt+0x4a/0x50
[  619.926726]  gen6_write32+0x23e/0x2a0 [i915]
[  619.926801]  gen6_mm_switch+0x38/0x70 [i915]
[  619.926871]  i915_switch_context+0xec/0xa10 [i915]
[  619.926942]  i915_gem_switch_to_kernel_context+0x13c/0x2b0 [i915]
[  619.927019]  i915_gem_suspend+0x2b/0x180 [i915]
[  619.927079]  i915_driver_unload+0x22/0x200 [i915]
[  619.927093]  ? __this_cpu_preempt_check+0x13/0x20
[  619.927105]  ? trace_hardirqs_on_caller+0xe7/0x200
[  619.927118]  ? trace_hardirqs_on+0xd/0x10
[  619.927128]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  619.927192]  i915_pci_remove+0x14/0x20 [i915]
[  619.927205]  pci_device_remove+0x34/0xb0
[  619.927219]  device_release_driver_internal+0x158/0x210
[  619.927234]  driver_detach+0x3b/0x80
[  619.927245]  bus_remove_driver+0x53/0xd0
[  619.927256]  driver_unregister+0x27/0x50
[  619.927267]  pci_unregister_driver+0x25/0xa0
[  619.927351]  i915_exit+0x1a/0xb1a [i915]
[  619.927362]  SyS_delete_module+0x193/0x1e0
[  619.927378]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  619.927386] RIP: 0033:0x7f82b46c5d37
[  619.927393] RSP: 002b:00007ffdb6f610d8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
[  619.927408] RAX: ffffffffffffffda RBX: ffffffff81481ff3 RCX: 00007f82b46c5d37
[  619.927415] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 000000000224f558
[  619.927422] RBP: ffffc90001187f88 R08: 0000000000000000 R09: 00007ffdb6f61100
[  619.927428] R10: 000000000224f4e0 R11: 0000000000000246 R12: 0000000000000000
[  619.927435] R13: 00007ffdb6f612b0 R14: 0000000000000000 R15: 0000000000000000
[  619.927451]  ? __this_cpu_preempt_check+0x13/0x20

or

[  641.646590] WARNING: CPU: 1 PID: 8913 at drivers/gpu/drm/i915/intel_drv.h:1750 intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
[  641.646595] RPM wakelock ref not held during HW access
[  641.646600] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul ghash_clmulni_intel snd_pcm mei_me mei i915(-) r8169 mii prime_numbers i2c_hid [last unloaded: snd_hda_intel]
[  641.646825] CPU: 1 PID: 8913 Comm: drv_module_relo Tainted: G     U          4.10.0-CI-Trybot_609+ #1
[  641.646836] Hardware name: TOSHIBA SATELLITE P50-C/06F4                            , BIOS 1.20 10/08/2015
[  641.646843] Call Trace:
[  641.646857]  dump_stack+0x67/0x92
[  641.646869]  __warn+0xc6/0xe0
[  641.646880]  warn_slowpath_fmt+0x4a/0x50
[  641.646893]  ? __this_cpu_preempt_check+0x13/0x20
[  641.646904]  ? trace_hardirqs_on_caller+0xe7/0x200
[  641.646957]  intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
[  641.647022]  __i915_add_request+0x423/0x540 [i915]
[  641.647080]  i915_gem_switch_to_kernel_context+0x148/0x2b0 [i915]
[  641.647145]  i915_gem_suspend+0x2b/0x180 [i915]
[  641.647189]  i915_driver_unload+0x22/0x200 [i915]
[  641.647200]  ? __this_cpu_preempt_check+0x13/0x20
[  641.647210]  ? trace_hardirqs_on_caller+0xe7/0x200
[  641.647220]  ? trace_hardirqs_on+0xd/0x10
[  641.647231]  ? _raw_spin_unlock_irqrestore+0x3d/0x60
[  641.647276]  i915_pci_remove+0x14/0x20 [i915]
[  641.647293]  pci_device_remove+0x34/0xb0
[  641.647307]  device_release_driver_internal+0x158/0x210
[  641.647321]  driver_detach+0x3b/0x80
[  641.647330]  bus_remove_driver+0x53/0xd0
[  641.647338]  driver_unregister+0x27/0x50
[  641.647348]  pci_unregister_driver+0x25/0xa0
[  641.647415]  i915_exit+0x1a/0xb1a [i915]
[  641.647429]  SyS_delete_module+0x193/0x1e0
[  641.647444]  entry_SYSCALL_64_fastpath+0x1c/0xb1
[  641.647453] RIP: 0033:0x7fc622bd2d37
[  641.647463] RSP: 002b:00007ffff8ffb5c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000b0
[  641.647475] RAX: ffffffffffffffda RBX: ffffffff81481ff3 RCX: 00007fc622bd2d37
[  641.647480] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000000000d49118
[  641.647485] RBP: ffffc90000997f88 R08: 0000000000000000 R09: 00007ffff8ffb5f0
[  641.647491] R10: 0000000000d490a0 R11: 0000000000000246 R12: 0000000000000000
[  641.647498] R13: 00007ffff8ffb7a0 R14: 0000000000000000 R15: 0000000000000000
[  641.647510]  ? __this_cpu_preempt_check+0x13/0x20

v2: Keep holding rpm until the end to cover i915_gem_sanitize() as well.

Fixes: 5ab57c70 ("drm/i915: Flush logical context image out to memory upon suspend")
Fixes: 1c777c5d ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302083029.19576-1-chris@chris-wilson.co.ukReviewed-by: NImre Deak <imre.deak@intel.com>
Cc: <stable@vger.kernel.org> # v4.9+

Commit 62b69566 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to

    Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler

Fixes: 62b69566 ("drm/i915: Only enable DDI IO power domains after enabling DPLL")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: NImre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301141318.3607-2-ander.conselvan.de.oliveira@intel.com

The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301121131.11588-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Reintroduce a lock around tiling vs framebuffer creation to prevent
modification of the obj->tiling_and_stride whilst the framebuffer is
being created. Rather than use struct_mutex once again, use the
per-object lock - this will also be required in future to prevent
changing the tiling whilst submitting rendering.
Reported-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Fixes: 24dbf51a ("drm/i915: struct_mutex is not required for allocating the framebuffer")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301154128.2841-2-chris@chris-wilson.co.uk

No more direct return -EINVAL as we have to unwind the
obj->framebuffer_references.

Fixes: 24dbf51a ("drm/i915: struct_mutex is not required for allocating the framebuffer")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301154128.2841-1-chris@chris-wilson.co.uk

For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-11-git-send-email-jani.nikula@intel.com

According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-10-git-send-email-jani.nikula@intel.com

For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-9-git-send-email-jani.nikula@intel.com

According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.

Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-8-git-send-email-jani.nikula@intel.com

Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-7-git-send-email-jani.nikula@intel.com

Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-6-git-send-email-jani.nikula@intel.com

Move the DPOunit clock gate workaround to directly after the PLL enable.

The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:

1) This moves it out of the middle of the init sequence from the spec,
   making it easier to follow the init sequence / compare it to the spec

2) It is grouped with the pll disable call in intel_dsi_post_disable,
   so for consistency it should be grouped with the pll enable in
   intel_dsi_pre_enable
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-5-git-send-email-jani.nikula@intel.com

Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-4-git-send-email-jani.nikula@intel.com

intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant.

In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against the VBT spec.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-3-git-send-email-jani.nikula@intel.com

Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-2-git-send-email-jani.nikula@intel.com

Leave the runtime check in place in case the platform variable itself
comes from bogus sources.
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488280303-9323-1-git-send-email-jani.nikula@intel.com

After
commit 2c7d0602
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Dec 5 18:27:37 2016 +0200

    drm/i915/gen9: Fix PCODE polling during CDCLK change notification

there is still one report of the CDCLK-change request timing out on a
KBL machine, see the Reference link. On that machine the maximum time
the request took to succeed was 34ms, so increase the timeout to 50ms.

v2:
- Change timeout from 100 to 50 ms to maintain the current 50 ms limit
  for atomic waits in the driver. (Chris, Tvrtko)

Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: NImre Deak <imre.deak@intel.com>
Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com

v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Jani's Review comment for aligning code to platforms and added
wrapper functions.
v4: Corrected enable/disable seuqence as per BSPEC
v5: Corrected waiting twice for same bit (Review comments: Jani)
v6: Rebased to Han's patches(dsi restructuring code)
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488352893-29916-2-git-send-email-madhav.chauhan@intel.com

drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’:
drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

which is caused by the compiling expanding every _MIPI_PORT into an
on-stack array of u32[3] at every callsite. Not sure why only one
machine/compiler appears susceptible, but with a minor tweak to _MIPI_PORT
we can defer the error until later.

This is a partial revert of commit ce64645d ("drm/i915: use variadic
macros and arrays to choose port/pipe based registers") for a particular
bad offender.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228145519.18012-1-chris@chris-wilson.co.ukAcked-by: NJani Nikula <jani.nikula@intel.com>

A couple of operations, the flushes and the tracepoint, do not require
serialisation by client->wq_lock, so move them before we take it.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228112803.11646-3-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission backend.

v4: Document that __i915_guc_submit is always under an irq disabled
section
v5: Move wq_rsvd adjustment to its own function

Fixes: 67b807a8 ("drm/i915: Delay disabling the user interrupt for breadcrumbs")
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NMichal Wajdeczko <michal.wajdeczko@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228112803.11646-2-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>

On some devices only MIPI PORT C is used, in this case checking the
MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
on VLV/CHT) will result in false positive "DSI LP not going Low" errors
as this checks the PORT A clk status.

In case both ports are used we have already checked the AFE_LATCHOUT
bit when going through the for_each_dsi_port() loop for PORT A and
checking the same bit again for PORT C is a no-op.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97061Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/242e4438bf29ebffc66eaa182f22b9d60d304bc2.1488273823.git.jani.nikula@intel.com

The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
not fine grained enough to abstract all the different steps we need to
take (and VBT sequences we need to exec) properly. So simply remove the
panel _enable/disable and prepare/unprepare callbacks and instead
export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
and call that from intel_dsi_enable/disable().

No functional changes.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/b4ca5185d4788d92df2ed60837a24b8962a8e8ba.1488273823.git.jani.nikula@intel.com

Move the intel_dsi_clear_device_ready() function to higher up in
intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs
intel_dsi_*enable* with intel_dsi_*disable without
intel_dsi_clear_device_ready() sitting in the middle of them.

This commit purely moves code around, it does not make any
changes what-so-ever.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/f971d18ea6d350890447860aeb541dba072a6e47.1488273823.git.jani.nikula@intel.com

The enable path has an intel_dsi_prepare() helper which prepares various
registers for the mode-set. Move the code undoing this to a new
intel_dsi_unprepare() helper function for better symmetry between the
enable and disable paths. No functional changes.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cc0baaf04ea74a20031b4b5bb128591dcfa78406.1488273823.git.jani.nikula@intel.com

intel_dsi_disable/enable only have one caller, merge them into their
respective callers.

Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy,
otherwise no functional changes.

The main advantage of this change is that it makes it easier to
follow all the steps of the panel enable / disable sequence when
reading the code.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/d7249612e6d2e9639ecd1d8d106ca37d5794f2a4.1488273823.git.jani.nikula@intel.com

Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling
a drm_panel_foo helper which calls VBT sequences, move it to the VBT
mipi_exec_send_packet helper, which is the one VBT instruction which
actually puts data in the fifo.

This results in a nice cleanup making it clearer what all the steps on
intel_dsi_enable / disable are and this also makes the VBT code properly
wait till a command has actually been send before executing the next
steps (typically a delay) in the VBT sequence.
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Reviewed-by: NBob Paauwe <bob.j.paauwe@intel.com>
Acked-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/289977b5699e252fea5c211d1d1645f9e79cca79.1488273823.git.jani.nikula@intel.com

Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.

v2: Add %pF caller
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228085018.3225-1-chris@chris-wilson.co.uk

As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A.
Therefore only for PORT A PLL divider value should be validated.
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-8-git-send-email-madhav.chauhan@intel.com

v2: Addressed Jani's Review comments(renamed bit field macros)

Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-7-git-send-email-madhav.chauhan@intel.com

Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-6-git-send-email-madhav.chauhan@intel.com

PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.

v2: Code restructure using min and max ratio variables (Ander)
v3: Code changes to avoid "maybe-uninitialized" warning (Jani)
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-5-git-send-email-madhav.chauhan@intel.com

Program the clk lane and tlpx time count registers
to configure DSI PHY.

v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Program clk lane timing reg same as dphy param reg.
v4: Removed "line over 80 character" warning
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-3-git-send-email-madhav.chauhan@intel.com

For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.

v2: Added comments to clarify ddr clock count calculation
v3: Use multiplier variable instead of IS_GEMINILAKE()
check everywhere (Jani)
Signed-off-by: NDeepak M <m.deepak@intel.com>
Signed-off-by: NMadhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: NJani Nikula <jani.nikula@intel.com>
Signed-off-by: NJani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-2-git-send-email-madhav.chauhan@intel.com

A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.

v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
v7: Improve commentary for declaring a missed wakeup
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-4-chris@chris-wilson.co.uk

By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-3-chris@chris-wilson.co.uk

As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.

v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-2-chris@chris-wilson.co.uk

The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.

To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.

v2: s/ret/result/
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-1-chris@chris-wilson.co.uk

After initiating a sideband transaction, we only want to wait for the
transaction to become idle. If, as we are, we wait for both the busy
and error flag to clear, if an error is raised we just spin until the
timeout. Once the hw is idle, we can then check to see if the hw flagged
an error, and report it distinctly.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223141020.13250-1-chris@chris-wilson.co.ukReviewed-by: NJani Nikula <jani.nikula@intel.com>

No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-3-chris@chris-wilson.co.uk