summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2016-04-19Merge tag 'v4.6-rc4' into x86/asm, to pick up fixesIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-04-18drm/i915/kbl: Reset secondary power well requests left on by DMC/KVMRImre Deak
The workaround added in commit c6782b76d31a ("drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR") needs to be applied on Kabylake too as shown by the corresponding timeout errors about power well 1 and MISC IO power well disabling in the latest CI run. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460748778-4484-1-git-send-email-imre.deak@intel.com
2016-04-18drm/i915: Replace nondescript 'WARN_ON(!lret)' with a sensible error messageVille Syrjälä
When a vblank wait times out in intel_atomic_wait_for_vblanks() we just get a cryptic 'WARN_ON(!ret)' backtrace in dmesg. Repace it with something that tells you what actually happened. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460978973-24945-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-04-18drm/radeon: print a message if ATPX dGPU power control is missingAlex Deucher
It will help identify problematic boards. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-18Revert "drm/radeon: disable runtime pm on PX laptops without dGPU power control"Alex Deucher
This reverts commit e64c952efb8e0c15ae82cec8e455ab4910690ef1. ATPX is the ACPI method for controlling AMD PowerXpress laptops. There are flags to indicate which methods are supported. If the dGPU power down flag is not supported, the driver needs to implement the dGPU power down manually. We had previously always forced the driver to assume the ATPX dGPU power down was present, but this causes problems on boards where it is not, leading to GPU hangs when attempting to power down the dGPU. Manual dGPU power down is not currently supported in the Linux driver. Some laptops indicate that the ATPX dGPU power down method is not present, but it actually apparently is. I'm not sure if this is a bios bug and it should be set or if there is a reason it was unset and the method should not be used. This is not an issue on other OSes since both the ATPX and the manual driver power down methods are supported. This is apparently fairly widespread, so just revert for now. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=115321 https://bugzilla.kernel.org/show_bug.cgi?id=116581 https://bugzilla.kernel.org/show_bug.cgi?id=116251 Cc: stable@vger.kernel.org
2016-04-18drm/amdgpu/acp: fix resume on CZ systems with AZ audioAlex Deucher
Nothing to do on resume on systems with AZ audio. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-18drm/radeon: add a quirk for a XFX R9 270XAlex Deucher
bug: https://bugs.freedesktop.org/show_bug.cgi?id=76490 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2016-04-18drm/radeon: print pci revision as well as pci ids on driver loadAlex Deucher
The pci revision id is useful in debugging certain things as it's part of how SKUs are defined on newer asics. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-04-18drm/atomic-helper: Print an error if vblank wait times outVille Syrjälä
Vblank waits timing out is no a normal thing to happen, so let's inform people when it happens. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460978973-24945-2-git-send-email-ville.syrjala@linux.intel.com
2016-04-18drm/i915: Avoid stalling on pending flips for legacy cursor updatesChris Wilson
The legacy cursor ioctl expects to be asynchronous with respect to other screen updates, in particular page flips. As X updates the cursor from a signal context, if the cursor blocks then it will stall both the input and output chains causing bad stuttering and horrible UX. Reported-and-tested-by: Rafael Ristovski <rafael.ristovski@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94980 Fixes: 5008e874edd34 ("drm/i915: Make wait_for_flips interruptible.") Suggested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Link: http://patchwork.freedesktop.org/patch/msgid/1460922166-20292-1-git-send-email-chris@chris-wilson.co.uk Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
2016-04-18drm/i915: Use fw_domains_put_with_fifo() on HSWVille Syrjälä
HSW still has the wake FIFO, so let's check it. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Deepak S <deepak.s@linux.intel.com> Fixes: 05a2fb157e44 ("drm/i915: Consolidate forcewake code") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460633942-24013-1-git-send-email-ville.syrjala@linux.intel.com Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (cherry picked from commit 3d7d0c85e41afb5a05e98b3a8a72c38357f02594) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915: Force ringbuffers to not be at offset 0Chris Wilson
For reasons unknown Sandybridge GT1 (at least) will eventually hang when it encounters a ring wraparound at offset 0. The test case that reproduces the bug reliably forces a large number of interrupted context switches, thereby causing very frequent ring wraparounds, but there are similar bug reports in the wild with the same symptoms, seqno writes stop just before the wrap and the ringbuffer at address 0. It is also timing crucial, but adding various delays hasn't helped pinpoint where the window lies. Whether the fault is restricted to the ringbuffer itself or the GTT addressing is unclear, but moving the ringbuffer fixes all the hangs I have been able to reproduce. References: (e.g.) https://bugs.freedesktop.org/show_bug.cgi?id=93262 Testcase: igt/gem_exec_whisper/render-contexts-interruptible #snb-gt1 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460565315-7748-12-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit a687a43a48f0f91ba37dce5a14b467258ed6f035) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915: Adjust size of PIPE_CONTROL used for gen8 render seqno writeMichał Winiarski
We started to use PIPE_CONTROL to write render ring seqno in order to combat seqno write vs interrupt generation problems. This was introduced by commit 7c17d377374d ("drm/i915: Use ordered seqno write interrupt generation on gen8+ execlists"). On gen8+ size of PIPE_CONTROL with Post Sync Operation should be 6 dwords. When we're using older 5-dword variant it's possible to observe inconsistent values written by PIPE_CONTROL with Post Sync Operation from user batches, resulting in rendering corruptions. v2: Fix BAT failures v3: Comments on alignment and thrashing high dword of seqno (Chris) v4: Updated commit msg (Mika) Testcase: igt/gem_pipe_control_store_loop/*-qword-write Issue: VIZ-7393 Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460469115-26002-1-git-send-email-michal.winiarski@intel.com (cherry picked from commit ce81a65c79d6012a384563caf76d47e28947a347) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915/skl: Fix spurious gpu hang with gt3/gt4 revsMika Kuoppala
Experiments with heaven 4.0 benchmark and skylake gt3e (rev 0xa) suggest that WaForceContextSaveRestoreNonCoherent is needed for all revs. Extending this to all revs cures a gpu hang with rev 0xa when running heaven4.0 gpu benchmark. We have been here before, with problems enabling gt4e and extending up to revision F0 instead of false claims of bspec of E0 only. See commit <e238659ddd88> ("drm/i915/skl: Default to noncoherent access up to F0"). In retrospect we should have covered this with this big blanket back then already, as E0 vs F0 discrepancy was suspicious enough. Previously the WaForceEnableNonCoherent has been tied to context non-coherence, atleast in relevant hsds. So keep this tie and extended this alongside. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: stable@vger.kernel.org Reported-by: Mike Lothian <mike@fireburn.co.uk> References: https://bugs.freedesktop.org/show_bug.cgi?id=93491 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 97ea6be161c55dec896b65c95157d953c330ae05) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915/skl: Fix rc6 based gpu/system hangMika Kuoppala
For all gt3 and gt4 skylake variants, extend the usage of WaRsDisableCoarsePowerGating for all revisions. Without this gt3 and gt4 skylakes up to atleast rev 0xa can gpu hang or system hang. Cc: Abdiel Janulgue <abdiel.janulgue@linux.intel.com> Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: <stable@vger.kernel.org> Reported-by: Mikael Djurfeldt <mikael@djurfeldt.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=94161 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Timo Aaltonen <tjaalton@ubuntu.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459860977-27751-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 185c66e57ce725afeb58a3cfa48547706af3a7af) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915/userptr: Hold mmref whilst calling get-user-pagesChris Wilson
Holding a reference to the containing task_struct is not sufficient to prevent the mm_struct from being reaped under memory pressure. If this happens whilst we are calling get_user_pages(), explosions erupt - sometimes an immediate GPF, sometimes page flag corruption. To prevent the target mm from being reaped as we are reading from it, acquire a reference before we begin. Testcase: igt/gem_shrink/*userptr Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459864801-28606-2-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 40313f0cd0b711a7a5905e5182422799e157d8aa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915: Fixup the free space logic in ring_prepareAkash Goel
Currently for the case where there is enough space at the end of Ring buffer for accommodating only the base request, the wrapround is done immediately and as a result the base request gets added at the start of Ring buffer. But there may not be enough free space at the beginning to accommodate the base request, as before the wraparound, the wait was effectively done for the reserved_size free space from the start of Ring buffer. In such a case there is a potential of Ring buffer overflow, the instructions at the head of Ring (ACTHD) can get overwritten. Since the base request can fit in the remaining space, there is no need to wraparound immediately. The wraparound will anyway happen later when the reserved part starts getting used. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1457688402-10411-1-git-send-email-akash.goel@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org (cherry picked from commit 782f6bc0aba037436d6a04d19b23f8b61020a576) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915/skl+: Use plane size for relative data rate calculationKumar, Mahesh
Use plane size for relative data rate calculation. don't always use pipe source width & height. adjust height & width according to rotation. use plane size for watermark calculations also. v2: Address Matt's comments. Use intel_plane_state->visible to avoid divide-by-zero error. Where FB was present but not visible so causing total data rate to be zero, hence divide-by-zero. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93917 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94044 Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Kumar, Mahesh <mahesh1.kumar@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459956399-1296-1-git-send-email-matthew.d.roper@intel.com (cherry picked from commit a280f7dd9f1a85eed242d0f62498bfc11520a1a3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-04-18drm/i915/dsi: fix CHV dsi encoder hardware state readout on port CJani Nikula
Due to "some hardware limitation" the DPI enable bit in port C control register does not get set on VLV. As a workaround we check the status in pipe B conf register instead. The workaround was added in commit c0beefd29fcb1ca998f0f9ba41be8539f8eeba9b Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Tue Dec 9 10:59:20 2014 +0530 drm/i915: Software workaround for getting the HW status of DSI Port C on BYT Empirical evidence (on Surface 3 with DSI on port C per VBT) shows that this is the case also on CHV, so extend the workaround to CHV. We still have the device ready register check in place, so this should not get confused with e.g. HDMI on pipe B. This fixes a number of state checker warnings on CHV DSI port C. Cc: stable@vger.kernel.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460724451-13810-1-git-send-email-jani.nikula@intel.com
2016-04-15drm/i915: Show pin mapped counts and sizes in debugfsTvrtko Ursulin
Show a total and purgeable number of pin mapped objects and their total and purgeable size. Example output (new stat prefixed with a star): # cat i915_gem_objects 19920 objects, 289243136 bytes 19920 [18466] objects, 288714752 [267911168] bytes in gtt 0 [0] active objects, 0 [0] bytes 19917 [18466] inactive objects, 288714752 [267911168] bytes 0 unbound objects, 0 bytes 0 purgeable objects, 0 bytes 1 pinned mappable objects, 3145728 bytes 0 fault mappable objects, 0 bytes * 19914 [0] pin mapped objects, 285560832 [0] bytes [purgeable] 4294967296 [268435456] gtt total Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1460716493-27826-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-04-15drm/i915: Show pin mapped status in describe_objTvrtko Ursulin
Reflect the status of obj->mapping as added with the i915_gem_object_pin_map API. 'M' was chosen to designate the pin mapped status. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-04-15drm/i915: Reject 'Center' scaling mode for eDP/DSI on GMCH platformsVille Syrjälä
We don't have a LVDS_BORDER_ENABLE type of bit for either eDP or DSI, and just trying to frob the display timings to include borders results in a corrupted picture. So reject the 'Center' scaling mode on GMCH platforms for eDP and DSI. TODO: Should really filter out the unsupported modes from the prop, but that would be fairly invasive since the prop is now created and stored by drm core. So leave it for a rainy day. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-6-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Hook up pfit for DSIVille Syrjälä
Add the scaling mode property to DSI connectors, handle changes in the property value, and compute the panel fitter state during .compute_config(). v2: Handle BXT as well Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-5-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Eliminate {vlv,bxt}_configure_dsi_pll()Ville Syrjälä
Fold the DSI PLL configuration functions into the DSI PLL enable functions since they are small and not called from anywhere else. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-4-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Compute DSI PLL parameters during .compute_config()Ville Syrjälä
Compute the DSI PLL parameters during .compute_config() rather than .pre_pll_enable() so that we can fail gracefully if we can't find suitable parameters. In order to do that we need to store the DSI PLL parameters in pipe_config. v2: Handle BXT too Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-3-git-send-email-ville.syrjala@linux.intel.com Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915: Setup DPLL/DPLLMD for DSI too on VLV/CHVVille Syrjälä
Set up DPLL and DPLL_MD even when driving DSI output on VLV/CHV. While the DPLL isn't used to provide the clock we still need the refclock, and it appears that the pixel repeat factor also has an effect on DSI output. So set up eveyrhing in DPLL and DPLL_MD as we would do for DP/HDMI/VGA, but don't actually enable the DPLL or configure the dividers via DPIO. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460488478-18311-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Jani Nikula <jani.nikula@intel.com>
2016-04-15drm/i915/bxt: PORT_PLL_REF_SEL bit should be set for all BXT variationsDongwon Kim
This patch is to correct one thing in this commit: commit 25a56705332add0363e47b3a0eca001d6fbd5bec Author: Dongwon Kim <dongwon.kim@intel.com> Date: Wed Mar 16 18:06:13 2016 -0700 drm/i915/bxt: Reversed polarity of PORT_PLL_REF_SEL bit This reversed bit polarity is actually common for all BXT and APL SoCs. Therefore, revision checking in the original commit should be removed to make the bit set regardless of revision ID of GFX block. Signed-off-by: Dongwon Kim <dongwon.kim@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1460673463-14453-1-git-send-email-dongwon.kim@intel.com
2016-04-15drm/dp/mst: Restore primary hub guid on resumeLyude
Some hubs are forgetful, and end up forgetting whatever GUID we set previously after we do a suspend/resume cycle. This can lead to hotplugging breaking (along with probably other things) since the hub will start sending connection notifications with the wrong GUID. As such, we need to check on resume whether or not the GUID the hub is giving us is valid. Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460580618-7421-1-git-send-email-cpaul@redhat.com
2016-04-15drm: Release driver references to handle before making it available againChris Wilson
When userspace closes a handle, we remove it from the file->object_idr and then tell the driver to drop its references to that file/handle. However, as the file/handle is already available again for reuse, it may be reallocated back to userspace and active on a new object before the driver has had a chance to drop the old file/handle references. Whilst calling back into the driver, we have to drop the file->table_lock spinlock and so to prevent reusing the closed handle we mark that handle as stale in the idr, perform the callback and then remove the handle. We set the stale handle to point to the NULL object, then any idr_find() whilst the driver is removing the handle will return NULL, just as if the handle is already removed from idr. Note: This will be used to have a direct handle -> vma lookup table, instead of first a handle -> obj lookup, and then an (obj, vm) -> vma lookup. v2: Use NULL rather than an ERR_PTR to avoid having to adjust callers. idr_alloc() tracks existing handles using an internal bitmap, so we are free to use the NULL object as our stale identifier. v3: Needed to update the return value check after changing from using the stale error pointer to NULL. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: dri-devel@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Thierry Reding <treding@nvidia.com> [danvet: Add note about the use-case.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460721308-32405-1-git-send-email-chris@chris-wilson.co.uk
2016-04-15drm/i915/dp/mst: Add source port info to debugfs outputJim Bride
Modify the debugfs output for i915_dp_mst_info to list the source port for the DP MST topology in question. v2: rebase v3: rebase v4: rebase cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-3-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/dp/mst: Enhance DP MST debugfs outputJim Bride
Add some additional information (input vs. output port, sink associated with VC, peer device type, max number of VCs supported) and ensure that any embedded '\0' characters in a branch device's devid string are not written to debugfs. v2: Rebase + change drm_edid_get_monitor_name() call to reflect new signature. v3: Minor changes suggested by Jani + rebase. v4: Rebase cc: dri-devel@lists.freedesktop.org cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-2-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/edid: Add drm_edid_get_monitor_name()Jim Bride
In order to include monitor name information in debugfs output we needed to add a function that would extract the monitor name from the EDID, and that function needed to reside in the file where the rest of the EDID helper functions are implemented. v2: Refactor to have drm_edid_get_monitor_name() and drm_edid_to_eld() use a common helper function to extract the monitor name from the edid. [Jani] + rebase. v3: Minor changes suggested by Jani + rebase. v4: Few more minor changes suggested by Jani + rebase. cc: dri-devel@lists.freedesktop.org cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460654317-31288-1-git-send-email-jim.bride@linux.intel.com
2016-04-15drm/i915/bxt: Enable runtime PMImre Deak
With the preceding fixes runtime PM should be functional, I could runtime suspend/resume the device without problems. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-17-git-send-email-imre.deak@intel.com
2016-04-15Revert "drm/i915/bxt: Disable power well support"Imre Deak
With the preceding fixes power well support should be functional on Broxton, I could enter/exit DC5 without problems. This reverts commit 18024199579882265653bfe9e2b1a3dcb5697cd9. CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-16-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add HW state verification for DDI PHY and CDCLKImre Deak
I caught a few errors in our current PHY/CDCLK programming by sanity checking the actual programmed state, so I thought it would be also useful for the future. In addition to verifying the state after programming it also verify it after exiting DC5, to make sure DMC restored/kept intact everything related. v2: - Inlining __phy_reg_verify_state() doesn't make sense and also incorrect, so don't do it (PW/CI gcc) v3: - Rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459780030-15781-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't reprogram an already enabled DDI PHYImre Deak
If BIOS has already programmed and enabled a PHY, don't reprogram it as that may interfere with the currently active outputs. A follow-up patch will add state verification, so we can catch any misconfiguration on BIOS's behalf. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-14-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Sanitize the DBUF HW state together with CDCLKImre Deak
When determining whether CDCLK is enabled by BIOS and so we should skip reprogramming it, we didn't check the related DBUF power request and state. In theory BIOS could enable one without the other so check for this case and reprogram things if something is amiss. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-13-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Don't toggle power well 1 on-demandImre Deak
Power well 1 is managed by the DMC firmware so don't toggle it on-demand from the driver. This means we need to follow the BSpec display initialization sequence during driver loading and resuming (both system and runtime) and enable power well 1 only once there. Afterwards DMC will toggle power well 1 whenever entering/exiting DC5. For this to work we also need to do away getting the PLL power domain, since that just kept runtime PM disabled for good. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-12-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Power down DDI PHYs separately during the per PHY uninitImre Deak
The power-down step logically belongs to the individual PHY uninit sequence so move it there. The only functional change is that we will power down now PHY 1 separately before PHY 0 and preserve the other bits in the register which are defined as reserved. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-11-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Pass drm_i915_private to DDI PHY, CDCLK helpersImre Deak
For internal APIs passing dev_priv is preferred to reduce indirections, so convert over a few DDI PHY, CDCLK helpers. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-10-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/skl: Unexport skl_pw1_misc_io_initImre Deak
On Broxton we need to enable/disable power well 1 during the init/unit display sequence similarly to Skylake/Kabylake. The code for this will be added in a follow-up patch, but to prepare for that unexport skl_pw1_misc_io_init(). It's a simple function called only from a single place and having it inlined in the Skylake display core init/unit functions will make it easier to compare it with its Broxton counterpart. This also flips the order of Misc IO and power well 1 disabling which matches the enabling order. The specification doesn't prescribe the disabling order, so this should be fine. v2: - Fix incorrect enable vs. disable power well call in skl_display_core_uninit() (Patrik) - Add commit comment about chaning the order of PW1 and Misc IO power well disabling (Patrik) CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459773777-10701-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Suspend power domains during suspend-to-idleImre Deak
On SKL/KBL suspend-to-idle (aka freeze/s0ix) is performed with DMC firmware assistance where the target display power state is DC6. On Broxton on the other hand we don't use the firmware for this, but rely instead on a manual DC9 flow. For this we have to uninitialize the display following the BSpec display uninit sequence, just as during S3/S4, so make sure we follow this sequence. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-8-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Fix DMC/DC state assertsImre Deak
The display power well support and DC state management doesn't depend on runtime PM support, so remove the incorrect asserts about this. Also Broxton does support DC5, so the related assert in assert_can_enable_dc5() is incorrect. There is a more generic and correct assert for this already in gen9_set_dc_state(), so we can remove all the other ones. At the same time convert WARNs to WARN_ONCE for consistency with the other DC state asserts. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-7-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Make power well disabling synchronousImre Deak
So far we only power well enabling was synchronous not disabling. Since we don't exactly know how the firmware (both DMC and PCU) synchronizes against the actual power well state during DC transitions, make the disabling also synchronous. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-6-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMRImre Deak
DMC forces on power well 1 and the misc IO power well by setting the corresponding request bits both in the BIOS and the DEBUG power well request registers. This is somewhat unexpected since the firmware should really just save and restore state but not alter it. We also depend on being able to disable power well 1, and the misc IO power well before entering S3/S4 on BXT and SKL or entering DC9 on BXT. To fix this make sure these request bits are cleared whenever we want to disable the given power wells. On SKL there is another twist where the firmware also clears the power well 1 request bit in HSW_POWER_WELL_DRIVER (but not that of the misc IO power well). This happens to not cause a problem due to the forced-on request bits in the other request registers. I've filed a bug about all this, but fixing that may take a while and having this sanity check in place makes sense even for future firmware versions. At the same time also check the KVMR request bits. I haven't seen this being altered, but we don't expect any request bits in here either, so sanitize this register as well. v2: - Apply the workaround on SKL as well. I noticed the related failure from the CI report, later Patrik also reported seeing it on his machine. CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459851965-6137-1-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Add a note about BXT_PORT_CL1CM_DW30 being read-onlyImre Deak
This register is read-only, so we have never actually set OCL2_LDOFUSE_PWR_DIS in it as specified by the specification. Add a code comment about this. I filed a specification update request to clarify this there. CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-4-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Fix GRC code register field definitionsImre Deak
This has been corrected in BSpec quite some time ago, but we missed it somehow. The wrong field definitions resulted in configuring PHY0 with an incorrect GRC value. v2: - Remove the FIXME comment, we left in the code exactly about this issue. (Ville) CC: Arthur J Runyan <arthur.j.runyan@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-3-git-send-email-imre.deak@intel.com
2016-04-15drm/i915/bxt: Reject DMC firmware versions with known bugsImre Deak
DMC version 1.06 has a known bug, where the firmware polls forever for a port PLL to lock, if the PLL was disabled when entering DC5, which locks up the machine. Version 1.07 fixes this, so make that the minimum required version on BXT. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1459515767-29228-2-git-send-email-imre.deak@intel.com
2016-04-15drm/i915: use drm_crtc_send_vblank_event()Gustavo Padovan
Replace the legacy drm_send_vblank_event() with the new helper function. Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1460656118-16766-4-git-send-email-gustavo@padovan.org
2016-04-14drm/vc4: Fix NULL deref in HDMI init error pathEric Anholt
If you make it here other than through err_destroy_encoder, vc4->hdmi is still NULL. Signed-off-by: Eric Anholt <eric@anholt.net>
generated by cgit (git 2.34.1) at 2025-09-14 13:29:05 +0000