- 21 Sep, 2016 8 commits
-
-
Pandiyan, Dhinakaran authored
Storing the port enum in intel_encoder makes it convenient to know the port attached to an encoder. Moving the port information up from intel_digital_port to intel_encoder avoids unecessary intel_digital_port access and handles MST encoders cleanly without requiring conditional checks for them (thanks danvet). v2: Renamed the port enum member from 'attached_port' to 'port' (danvet) Fixed missing initialization of port in intel_sdvo.c (danvet) v3: Fixed missing initialization of port in intel_crt.c (Ville) v4: Storing port for DVO encoders too. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474334681-22690-3-git-send-email-dhinakaran.pandiyan@intel.com
-
Pandiyan, Dhinakaran authored
Changing the return type from 'char' to 'enum port' in intel_dvo_port_name() makes it easier to later move the port information to intel_encoder. In addition, the port type conforms to what we have elsewhere. Removing the last conditional that handles invalid port because dvo_reg is intialized to valid values for all DVO devices at definition. v2: Changed return type, for real (Jani) Signed-off-by:
-
Chris Wilson authored
There is a disparity in the context image saved to disk and our own bookkeeping - that is we presume the RING_HEAD and RING_TAIL match our stored ce->ring->tail value. However, as we emit WA_TAIL_DWORDS into the ring but may not tell the GPU about them, the GPU may be lagging behind our bookkeeping. Upon hibernation we do not save stolen pages, presuming that their contents are volatile. This means that although we start writing into the ring at tail, the GPU starts executing from its HEAD and there may be some garbage in between and so the GPU promptly hangs upon resume. Testcase: igt/gem_exec_suspend/basic-S4 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96526Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
At the point of creating the hibernation image, the runtime power manage core is disabled - and using the rpm functions triggers a warn. i915_gem_shrink_all() tries to unbind objects, which requires device access and so tries to how an rpm reference triggering a warning: [ 44.235420] ------------[ cut here ]------------ [ 44.235424] WARNING: CPU: 2 PID: 2199 at drivers/gpu/drm/i915/intel_runtime_pm.c:2688 intel_runtime_pm_get_if_in_use+0xe6/0xf0 [ 44.235426] WARN_ON_ONCE(ret < 0) [ 44.235445] Modules linked in: ctr ccm arc4 rt2800usb rt2x00usb rt2800lib rt2x00lib crc_ccitt mac80211 cmac cfg80211 btusb rfcomm bnep btrtl btbcm btintel bluetooth dcdbas x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec_realtek crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 lrw gf128mul snd_hda_intel glue_helper ablk_helper cryptd snd_hda_codec hid_multitouch joydev snd_hda_core binfmt_misc i2c_hid serio_raw snd_pcm acpi_pad snd_timer snd i2c_designware_platform 8250_dw nls_iso8859_1 i2c_designware_core lpc_ich mfd_core soundcore usbhid hid psmouse ahci libahci [ 44.235447] CPU: 2 PID: 2199 Comm: kworker/u8:8 Not tainted 4.8.0-rc5+ #130 [ 44.235447] Hardware name: Dell Inc. XPS 13 9343/0310JH, BIOS A07 11/11/2015 [ 44.235450] Workqueue: events_unbound async_run_entry_fn [ 44.235453] 0000000000000000 ffff8801b2f7fb98 ffffffff81306c2f ffff8801b2f7fbe8 [ 44.235454] 0000000000000000 ffff8801b2f7fbd8 ffffffff81056c01 00000a801f50ecc0 [ 44.235456] ffff88020ce50000 ffff88020ce59b60 ffffffff81a60b5c ffffffff81414840 [ 44.235456] Call Trace: [ 44.235459] [<ffffffff81306c2f>] dump_stack+0x4d/0x6e [ 44.235461] [<ffffffff81056c01>] __warn+0xd1/0xf0 [ 44.235464] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30 [ 44.235465] [<ffffffff81056c6f>] warn_slowpath_fmt+0x4f/0x60 [ 44.235468] [<ffffffff814e73ce>] ? pm_runtime_get_if_in_use+0x6e/0xa0 [ 44.235469] [<ffffffff81433526>] intel_runtime_pm_get_if_in_use+0xe6/0xf0 [ 44.235471] [<ffffffff81458a26>] i915_gem_shrink+0x306/0x360 [ 44.235473] [<ffffffff81343fd4>] ? pci_platform_power_transition+0x24/0x90 [ 44.235475] [<ffffffff81414840>] ? i915_pm_suspend_late+0x30/0x30 [ 44.235476] [<ffffffff81458dfb>] i915_gem_shrink_all+0x1b/0x30 [ 44.235478] [<ffffffff814560b3>] i915_gem_freeze_late+0x33/0x90 [ 44.235479] [<ffffffff81414877>] i915_pm_freeze_late+0x37/0x40 [ 44.235481] [<ffffffff814e9b8e>] dpm_run_callback+0x4e/0x130 [ 44.235483] [<ffffffff814ea5db>] __device_suspend_late+0xdb/0x1f0 [ 44.235484] [<ffffffff814ea70f>] async_suspend_late+0x1f/0xa0 [ 44.235486] [<ffffffff81077557>] async_run_entry_fn+0x37/0x150 [ 44.235488] [<ffffffff8106f518>] process_one_work+0x148/0x3f0 [ 44.235490] [<ffffffff8106f8eb>] worker_thread+0x12b/0x490 [ 44.235491] [<ffffffff8106f7c0>] ? process_one_work+0x3f0/0x3f0 [ 44.235492] [<ffffffff81074d09>] kthread+0xc9/0xe0 [ 44.235495] [<ffffffff816e257f>] ret_from_fork+0x1f/0x40 [ 44.235496] [<ffffffff81074c40>] ? kthread_park+0x60/0x60 [ 44.235497] ---[ end trace e438706b97c7f132 ]--- Alternatively, to actually shrink everything we have to do so slightly earlier in the hibernation process. To keep lockdep silent, we need to take struct_mutex for the shrinker even though we know that we are the only user during the freeze. Fixes: 7aab2d53 ("drm/i915: Shrink objects prior to hibernation") Signed-off-by:
-
Chris Wilson authored
Following commit 821ed7df ("drm/i915: Update reset path to fix incomplete requests") we no longer mark the context as lost on reset as we keep the requests (and contexts) alive. However, RPS remains reset and we need to restore the current state to match the in-flight requests. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97824 Fixes: 821ed7df ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-1-chris@chris-wilson.co.uk
-
Imre Deak authored
While user space has control over the scheduling priority of its page flipping thread, the corresponding work the driver schedules for MMIO flips always runs from the generic system workqueue which has some scheduling overhead due it being CPU bound. This would hinder an application that wants more stringent guarantees over flip timing (to avoid missing a flip at the next frame count). Fix this by scheduling the work from the unbound system workqueue which provides for minimal scheduling latency. v2: - Use an unbound workqueue instead of a high-prio one. (Tvrtko, Chris) v3: - Use the system unbound wq instead of a dedicated one. (Maarten) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97775 Testcase: igt/kms_cursor_legacy CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> CC: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474372699-22841-1-git-send-email-imre.deak@intel.com
-
Ben Widawsky authored
v2: (Imre) - Access only subslices that are known to exist. - Reset explicitly the MCR selector to slice/sub-slice ID 0 after the readout. - Use the subslice INSTDONE bits for the hangcheck/subunits-stuck detection too. - Take the uncore lock for the MCR-select/subslice-readout sequence. Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
Consolidate the instdone logic so we can get a bit fancier. This patch also removes the duplicated print of INSTDONE[0]. v2: (Imre) - Rebased on top of hangcheck INSTDONE changes. - Move all INSTDONE registers into a single struct, store it within the engine error struct during error capturing. Signed-off-by:
-
- 20 Sep, 2016 3 commits
-
-
Imre Deak authored
Reapply the PPS register unlock workaround after GPU reset on platforms where the reset clobbers the display HW state. This at least gets rid of the related WARN during LVDS encoder enabling on PNV. Fixes: ed6143b8 ("drm/i915/lvds: Restore initial HW state during encoder enabling") Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Shawn Lee authored
Backlight enable is supposed to do a full setup of the backlight. We were missing the PWM alternate increment bit in the south chicken registers on lpt+ pch. This potentially caused a PWM frequency change when the chicken register value was lost e.g. on suspend. v2 by Jani, rebase on the patch caching alt increment Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97486 References: https://bugs.freedesktop.org/show_bug.cgi?id=67454 Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: Wei Shun Chen <wei.shun.chang@intel.com> Cc: Gary C Wang <gary.c.wang@intel.com> Cc: stable@vger.kernel.org # v4.4+ 32b421e7 drm/i915/backlight: setup and cache... Cc: stable@vger.kernel.org # v4.4+ Reviewed-by:
Shawn Lee <shawn.c.lee@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/8265f5935bd31c039ddfc82819d26c2ca1ae9cba.1474281249.git.jani.nikula@intel.com
-
Jani Nikula authored
This will also be needed later on when setting up the alternate increment in backlight enable. Cc: Shawn Lee <shawn.c.lee@intel.com> Reviewed-by:
-
- 19 Sep, 2016 8 commits
-
-
Jani Nikula authored
Be a little paranoid in case the specs change or something. Reviewed-by:
-
Jani Nikula authored
Leave behind some debugging clues in case some panels don't work properly. Reviewed-by:
-
Jani Nikula authored
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add them where it feels logical. The drm panel hooks don't currently offer us more granularity anyway. Reviewed-by:
-
Jani Nikula authored
Based on the documentation alone, it's anyone's guess when exactly we should be running these sequences. Add power on/off sequences where they feel logical and update assert/deassert reset. The drm panel hooks don't currently offer us more granularity anyway. v2: update assert/deassert reset as well (Ville) Reviewed-by:
-
Jani Nikula authored
In sequence block v3 these are gracefully skipped anyway, but add the functions so we can have some debug breadcrumbs. v2: the pmic block is 15 bytes (Ville) Reviewed-by:
-
Jani Nikula authored
Just simple breadcrumbs for now. While at it, rename the i2c skip function. Reviewed-by:
-
Jani Nikula authored
This is not interesting. They are not "missing", they are just not part of the VBT sequences for the panel. Reviewed-by:
-
Daniel Vetter authored
Signed-off-by:
-
- 16 Sep, 2016 4 commits
-
-
Mika Kahola authored
Fix missing parameter description for DisplayPort branch device ID. This fixes warning of "No description found for parameter 'id[6]'" when creating documentation by 'make htmldocs'. Reported-by:
kbuild test robot <fengguang.wu@intel.com> References: https://lists.freedesktop.org/archives/intel-gfx/2016-September/106645.html Fixes: 266d783b ("drm: Read DP branch device id") Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
Jani Nikula authored
Fix sparse warning: drivers/gpu/drm/i915/i915_cmd_parser.c:987:72: warning: Using plain integer as NULL pointer Fixes: 52a42cec ("drm/i915/cmdparser: Accelerate copies from WC memory") Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Jani Nikula authored
Fixes sparse warning: drivers/gpu/drm/i915/intel_dpll_mgr.c:1712:24: warning: Using plain integer as NULL pointer Fixes: a277ca7d ("drm/i915: Split bxt_ddi_pll_select()") Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Cc: Durgadoss R <durgadoss.r@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
-
Jani Nikula authored
Fix sparse warning: drivers/gpu/drm/i915/intel_dp.c:1527:5: warning: symbol 'intel_dp_compute_bpp' was not declared. Should it be static? Fixes: f9bb705e ("drm/i915: Update bits per component for display info") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jim Bride <jim.bride@linux.intel.com> Reviewed-by:
Jim Bride <jim.bride@linux.intel.com> Signed-off-by:
-
- 15 Sep, 2016 16 commits
-
-
Mika Kahola authored
Read DisplayPort branch device info from through debugfs interface. v2: use drm_dp_helper routines to collect data v3: cleanup to match the drm_dp_helper.c patches introduced earlier in this series v4: move DP branch device info to function 'intel_dp_branch_device_info()' v5: initial step to move debugging info from intel_dp. to drm_dp_helper.c (Daniel) v6: read hw and sw revision without using specific drm_dp_helper routines v7: indentation fixes (Jim Bride) Signed-off-by: -
Mika Kahola authored
DisplayPort branch device may define max supported bits per component. Update display info based on this value if bpc is defined. v2: cleanup to match the drm_dp_helper.c patches introduced earlier in this series v3: Fill bpc for connector's display info in separate drm_dp_helper function (Daniel) v4: remove updating bpc for display info as it may be overridden when parsing EDID. Instead, check bpc for DP branch device during compute_config v5: Indentation fixes (Jim Bride) Signed-off-by: -
Mika Kahola authored
Filter out a mode that exceeds the max pixel rate setting for DP to VGA dongle. This is defined in DPCD register 0x81 if detailed cap info i.e. info field is 4 bytes long and it is available for DP downstream port. The register defines the pixel rate divided by 8 in MP/s. v2: DPCD read outs and computation moved to drm (Ville, Daniel) v3: Sink pixel rate computation moved to drm_dp_max_sink_dotclock() function (Daniel) v4: Use of drm_dp_helper.c routines to compute max pixel clock (Ville) v5: Use of intel_dp->downstream_ports to read out port capabilities. Code restructuring (Ville) v6: Move DP branch device check to drm_dp_helper.c (Daniel) v7: Cleanup as suggested by Ville Reviewed-by: -
Mika Kahola authored
SW revision is mandatory field for DisplayPort branch devices. This is defined in DPCD register fields 0x50A and 0x50B. v2: move drm_dp_ds_revision structure to be part of drm_dp_link structure (Daniel) v3: remove dependency to drm_dp_helper but instead parse DPCD and print SW revision info to dmesg (Ville) v4: commit message fix (Jim Bride) Signed-off-by: -
Mika Kahola authored
HW revision is mandatory field for DisplayPort branch devices. This is defined in DPCD register field 0x509. v2: move drm_dp_ds_revision structure to be part of drm_dp_link structure (Daniel) v3: remove dependency to drm_dp_helper but instead parse DPCD and print HW revision info to dmesg (Ville) Reviewed-by: -
Mika Kahola authored
Let's remove reference to "struct intel_connector *connector" in intel_dp_aux_init() function as it is no longer required. Reviewed-by:
-
Mika Kahola authored
Read DisplayPort branch device id string. Reviewed-by:
Dave Airlie <airlied@gmail.com> Signed-off-by:
-
Mika Kahola authored
Helper routine to read out maximum supported bits per component for DisplayPort legay converters. v2: Return early if detailed port cap info is not available. Replace if-else ladder with switch-case (Ville) Reviewed-by: -
Mika Kahola authored
Helper routine to read out maximum supported pixel rate for DisplayPort legay VGA converter or TMDS clock rate for other digital legacy converters. The helper returns clock rate in kHz. v2: Return early if detailed port cap info is not available. Replace if-else ladder with switch-case (Ville) Reviewed-by: -
Mika Kahola authored
Drop "VGA" from bits per component definitions as these are also used by other standards such as DVI, HDMI, DP++. Reviewed-by:
-
Mika Kahola authored
Add missing DisplayPort downstream port types. The introduced new port types are DP++ and Wireless. Reviewed-by:
-
Deepak M authored
Adding the ddb size into the devide info will avoid platform checks while computing wm. v2: Added comment and WARN_ON if ddb size is zero.(Jani) v3: Added WARN_ON at the right place.(Jani) Suggested-by:
Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by:
Deepak M <m.deepak@intel.com> Signed-off-by:
-
Dave Gordon authored
Renaming to more consistent scheme, and updating comments, mostly about i915_guc_wq_reserve(), aka i915_guc_wq_check_space(). Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1473711577-11454-4-git-send-email-david.s.gordon@intel.comReviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Dave Gordon authored
Renaming to more consistent scheme, delete unused definitions Signed-off-by:
-
Dave Gordon authored
No functional changes; just renaming a bit, tweaking a datatype, prettifying layout, and adding comments, in particular in the GuC setup code that touches this data. Signed-off-by:
-
Dave Gordon authored
Commentary from Chris Wilson's original version: > I was looking at some wait_for() timeouts on a slow system, with lots of > debug enabled (KASAN, lockdep, mmio_debug). Thinking that we were > mishandling the timeout, I tried to ensure that we loop at least once > after first testing COND. However, the double test of COND either side > of the timeout check makes that unlikely. But we can do an equivalent > loop, that keeps the COND check after testing for timeout (required so > that we are not preempted between testing COND and then testing for a > timeout) without expanding COND twice. > > The advantage of only expanding COND once is a dramatic reduction in > code size: > > text data bss dec hex > 1308733 5184 1152 1315069 1410fd before > 1305341 5184 1152 1311677 1403bd after but it turned out that due to a missing iniitialiser, gcc had "gone wild trimming undefined code" :( This version acheives a rather more modest (but still worthwhile) gain of ~550 bytes. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
- 14 Sep, 2016 1 commit
-
-
Ville Syrjälä authored
Turns out commit a0562819 ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer <rob@solution-space.com> Cc: Martin van Es <martin@mrvanes.com> Cc: Andrea Arcangeli <aarcange@redhat.com> Cc: Dave Airlie <airlied@linux.ie> Cc: Marco Krüger <krgsch@gmail.com> Cc: Sean Greenslade <sean@seangreenslade.com> Cc: Trudy Tective <bertslany@gmail.com> Cc: Robin Müller <rm1990@gmx.de> Cc: Alexander Kobel <a-kobel@a-kobel.de> Cc: Alexey Shumitsky <alexey.shumitsky@gmail.com> Cc: Emil Andersen Lauridsen <mine809@gmail.com> Cc: oceans112@gmail.com Cc: James Hogan <james@albanarts.com> Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: stable@vger.kernel.org References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a0562819 ("drm/i915: Get panel_type from OpRegion panel details") Tested-by:
Marco Krüger <krgsch@gmail.com> Tested-by:
Alexey Shumitsky <alexey.shumitsky@gmail.com> Tested-by:
Sean Greenslade <sean@seangreenslade.com> Tested-by:
Emil Andersen Lauridsen <mine809@gmail.com> Tested-by:
Robin Müller <rm1990@gmx.de> Tested-by: oceans112@gmail.com Tested-by:
Rob Kramer <rob@solution-space.com> Signed-off-by:
-
