summaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2019-05-07drm/i915: Remove delay for idle_workChris Wilson5-19/+12
The original intent for the delay before running the idle_work was to provide a hysteresis to avoid ping-ponging the device runtime-pm. Since then we have also pulled in some memory management and general device management for parking. But with the inversion of the wakeref handling, GEM is no longer responsible for the wakeref and by the time we call the idle_work, the device is asleep. It seems appropriate now to drop the delay and just run the worker immediately to flush the cached GEM state before sleeping. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190507121108.18377-2-chris@chris-wilson.co.uk
2019-05-07drm/i915: Flush the switch-to-kernel-context harder for DROP_IDLEChris Wilson1-2/+14
To complete the idle worker, we must complete 2 passes of wait-for-idle. At the end of the first pass, we queue a switch-to-kernel-context and may only idle after waiting for its completion. Speed up the flush_work by doing the wait explicitly, which then allows us to remove the unbounded loop trying to complete the flush_work in the next patch. References: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy") Testcase: igt/gem_ppgtt/flind-and-close-vma-leak Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190507121108.18377-1-chris@chris-wilson.co.uk
2019-05-07drm/i915/icl: Set GCP_COLOR_INDICATION only for 10/12 bit deep colorClinton Taylor1-15/+2
v2: Fix commit msg to reflect why issue occurs(Jani) Set GCP_COLOR_INDICATION only when we set 10/12 bit deep color. Changing settings from 10/12 bit deep color to 8 bit(& vice versa) doesn't work correctly using xrandr max bpc property. When we connect a monitor which supports deep color, the highest deep color setting is selected; which sets GCP_COLOR_INDICATION. When we change the setting to 8 bit color, we still set GCP_COLOR_INDICATION which doesn't allow the switch back to 8 bit color. v3,4: Add comments & drop changes in intel_hdmi_compute_config(Ville) Since HSW+, GCP_COLOR_INDICATION is not required for 8bpc. Drop the changes in intel_hdmi_compute_config as desired_bpp is needed to change values for pipe_bpp based on bw_constrained flag. v5: Fix missing logical && in condition for setting GCP_COLOR_INDICATION. v6: Fix comment formatting (Ville) v7: Add reviewed by Ville v8: Set GCP_COLOR_INDICATION based on spec: For Gen 7.5 or later platforms, indicate color depth only for deep color modes. Bspec: 8135,7751,50524 Pre DDI platforms, indicate color depth if deep color is supported by sink. Bspec: 7854 Exception: CHERRYVIEW behaves like Pre DDI platforms. Bspec: 15975 Check pipe_bpp is less than bpp * 3 in hdmi_deep_color_possible, to not set 12 bit deep color for every modeset. This fixes the issue where 12 bit color was selected even when user selected 10 bit.(Ville) v9: Maintain a consistent behavior for all platforms and support GCP_COLOR_INDICATION only when we are in deep color mode. Remove hdmi_sink_is_deep_color() - no longer needed as checking pipe_bpp > 24 takes care of the deep color mode scenario. Separate patch for fixing switch from 12 bit to 10 bit deep color mode. Co-developed-by: Aditya Swarup <aditya.swarup@intel.com> Signed-off-by: Clinton Taylor <Clinton.A.Taylor@intel.com> Signed-off-by: Aditya Swarup <aditya.swarup@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429230811.9983-1-aditya.swarup@intel.com
2019-05-07drm/i915: Assert the local engine->wakeref is activeChris Wilson2-2/+5
Due to the asynchronous tasklet and recursive GT wakeref, it may happen that we submit to the engine (underneath it's own wakeref) prior to the central wakeref being marked as taken. Switch to checking the local wakeref for greater consistency. Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503115225.30831-3-chris@chris-wilson.co.uk
2019-05-07drm/i915: Prefer checking the wakeref itself rather than the counterChris Wilson2-4/+18
The counter goes to zero at the start of the parking cycle, but the wakeref itself is held until the end. Likewise, the counter becomes one at the end of the unparking, but the wakeref is taken first. If we check the wakeref instead of the counter, we include the unpark/unparking time as intel_wakeref_is_active(), and do not spuriously declare inactive if we fail to park (i.e. the parking and wakeref drop is postponed). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503115225.30831-2-chris@chris-wilson.co.uk
2019-05-07drm/i915: Assert breadcrumbs are correctly ordered in the signal handlerChris Wilson1-0/+19
Inside the signal handler, we expect the requests to be ordered by their breadcrumb such that no later request may be complete if we find an earlier incomplete. Add an assert to check that the next breadcrumb should not be logically before the current. v2: Move the overhanging line into its own function and reuse it after doing the insertion. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503152214.26517-1-chris@chris-wilson.co.uk
2019-05-07drm/i915: Acquire the signaler's timeline HWSP lastChris Wilson1-4/+4
Acquiring the signaler's timeline takes an active reference to their HWSP that we would like to avoid if possible, so take it after performing all of our allocations required to set up the fencing. The acquisition also provides the final check that the target has not already signaled allowing us to avoid the semaphore at the last moment. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503140239.32668-1-chris@chris-wilson.co.uk
2019-05-06drm/i915: Move the hsw/bdw pc8 code to intel_runtime_pm.cVille Syrjälä5-223/+230
hsw_enable_pc8()/hsw_disable_pc8() are more less equivalent to the display core init/unit functions of later platforms. Relocate the hsw/bdw code into intel_runtime_pm.c so that it sits next to its cousins. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503193143.28240-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-05-06drm/i915: Replace intel_ddi_pll_init()Ville Syrjälä2-26/+21
intel_ddi_pll_init() is an anachronism. Rename it to hsw_assert_cdclk() and move it to the power domain init code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503193143.28240-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2019-05-06drm/i915: Move w/a 0477/WaDisableIPC:skl into intel_init_ipc()Ville Syrjälä2-7/+14
Move the w/a to disable IPC on SKL closer to the actual code that implements IPS. Otherwise I just end up confused as to what is excluding SKL from considerations. IMO this makes more sense anyway since the hw does have the feature, we're just not supposed to use it. And this also makes us actually disable IPC in case eg. the BIOS enabled it when it shouldn't have. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503173807.10834-3-ville.syrjala@linux.intel.com
2019-05-06drm/i915: Drop WaIncreaseLatencyIPCEnabled/1140 for cnlVille Syrjälä1-2/+1
Drop WaIncreaseLatencyIPCEnabled/Display w/a #1140 for early cnl steppings. v2: Drop the IS_GEN9_BC() change since other related parts of the code also use the KBL||CFL pattern Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503173807.10834-2-ville.syrjala@linux.intel.com
2019-05-06drm/i915: Document that we implement WaIncreaseLatencyIPCEnabledVille Syrjälä1-1/+4
Display w/a #1141 is also known as WaIncreaseLatencyIPCEnabled. Add that to the comment. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503173807.10834-1-ville.syrjala@linux.intel.com
2019-05-04drm/i915: Disable semaphore busywaits on saturated systemsChris Wilson3-1/+44
Asking the GPU to busywait on a memory address, perhaps not unexpectedly in hindsight for a shared system, leads to bus contention that affects CPU programs trying to concurrently access memory. This can manifest as a drop in transcode throughput on highly over-saturated workloads. The only clue offered by perf, is that the bus-cycles (perf stat -e bus-cycles) jumped by 50% when enabling semaphores. This corresponds with extra CPU active cycles being attributed to intel_idle's mwait. This patch introduces a heuristic to try and detect when more than one client is submitting to the GPU pushing it into an oversaturated state. As we already keep track of when the semaphores are signaled, we can inspect their state on submitting the busywait batch and if we planned to use a semaphore but were too late, conclude that the GPU is overloaded and not try to use semaphores in future requests. In practice, this means we optimistically try to use semaphores for the first frame of a transcode job split over multiple engines, and fail if there are multiple clients active and continue not to use semaphores for the subsequent frames in the sequence. Periodically, we try to optimistically switch semaphores back on whenever the client waits to catch up with the transcode results. With 1 client, on Broxton J3455, with the relative fps normalized by %cpu: x no semaphores + drm-tip * patched +------------------------------------------------------------------------+ | * | | *+ | | **+ | | **+ x | | x * +**+ x | | x x * * +***x xx | | x x * * *+***x *x | | x x* + * * *****x *x x | | + x xx+x* + *** * ********* x * | | + x xx+x* * *** +** ********* xx * | | * + ++++* + x*x****+*+* ***+*************+x* * | |*+ +** *+ + +* + *++****** *xxx**********x***+*****************+*++ *| | |__________A_____M_____| | | |_______________A____M_________| | | |____________A___M________| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 2.60475 3.50941 3.31123 3.2143953 0.21117399 + 120 2.3826 3.57077 3.25101 3.1414161 0.28146407 Difference at 95.0% confidence -0.0729792 +/- 0.0629585 -2.27039% +/- 1.95864% (Student's t, pooled s = 0.248814) * 120 2.35536 3.66713 3.2849 3.2059917 0.24618565 No difference proven at 95.0% confidence With 10 clients over-saturating the pipeline: x no semaphores + drm-tip * patched +------------------------------------------------------------------------+ | ++ ** | | ++ ** | | ++ ** | | ++ ** | | ++ xx *** | | ++ xx *** | | ++ xxx*** | | ++ xxx*** | | +++ xxx*** | | +++ xx**** | | +++ xx**** | | +++ xx**** | | +++ xx**** | | ++++ xx**** | | +++++ xx**** | | +++++ x x****** | | ++++++ xxx******* | | ++++++ xxx******* | | ++++++ xxx******* | | ++++++ xx******** | | ++++++ xxxx******** | | ++++++ xxxx******** | | ++++++++ xxxxx********* | |+ + + + ++++++++ xxx*xx**********x* *| | |__A__| | | |__AM__| | | |__A_| | +------------------------------------------------------------------------+ N Min Max Median Avg Stddev x 120 2.47855 2.8972 2.72376 2.7193402 0.074604933 + 120 1.17367 1.77459 1.71977 1.6966782 0.085850697 Difference at 95.0% confidence -1.02266 +/- 0.0203502 -37.607% +/- 0.748352% (Student's t, pooled s = 0.0804246) * 120 2.57868 3.00821 2.80142 2.7923878 0.058646477 Difference at 95.0% confidence 0.0730476 +/- 0.0169791 2.68622% +/- 0.624383% (Student's t, pooled s = 0.0671018) Indicating that we've recovered the regression from enabling semaphores on this saturated setup, with a hint towards an overall improvement. Very similar, but of smaller magnitude, results are observed on both Skylake(gt2) and Kabylake(gt4). This may be due to the reduced impact of bus-cycles, where we see a 50% hit on Broxton, it is only 10% on the big core, in this particular test. One observation to make here is that for a greedy client trying to maximise its own throughput, using semaphores is the right choice. It is only the holistic system-wide view that semaphores of one client impacts another and reduces the overall throughput where we would choose to disable semaphores. The most noticeable negactive impact this has is on the no-op microbenchmarks, which are also very notable for having no cpu bus load. In particular, this increases the runtime and energy consumption of gem_exec_whisper. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Cc: Dmitry Ermilov <dmitry.ermilov@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190504070707.30902-1-chris@chris-wilson.co.uk
2019-05-03drm/i915: Use mul_u32_u32() moreVille Syrjälä4-11/+11
We have a lot of '(u64)foo * bar' everywhere. Replace with mul_u32_u32() to avoid gcc failing to use a regular 32x32->64 multiply for this. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190408152702.4153-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2019-05-03drm/i915: Allow ICL pipe "HDR mode" when the cursor is visibleVille Syrjälä1-1/+2
Turns out the cursor is compatible with the pipe "HDR mode". It's only the actual SDR planes that get entirely bypassed during blending. So let's ignore the cursor when checking if we have any planes active that aren't HDR compatible. This fixes the regressions in the kms_cursor_crc and kms_plane_cursor tests. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110579 Fixes: 09b25812db10 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502200607.14504-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-05-03drm/i915: Move the PIPEMISC write the correct placeVille Syrjälä1-3/+3
I fumbled the PIPEMISC write into the wrong place. It only gets called for fastsets, but since value needs to be updated based on the set of active planes it needs to be done for all plane updates. Move it to the correct spot. The symptoms include SDR planes never showing up if a previous modeset/fastset left the pipe in HDR mode. This was immediately obvious when running the kms_plane pixel format tests. Unfortunately the test didn't realize it was scanning out pure black all the time and declared success anyway. Cc: Uma Shankar <uma.shankar@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Fixes: 09b25812db10 ("drm/i915: Enable pipe HDR mode on ICL if only HDR planes are used") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502200607.14504-1-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com>
2019-05-03drm/i915: Delay semaphore submission until the start of the signalerChris Wilson1-0/+19
Currently we submit the semaphore busywait as soon as the signaler is submitted to HW. However, we may submit the signaler as the tail of a batch of requests, and even not as the first context in the HW list, i.e. the busywait may start spinning far in advance of the signaler even starting. If we wait until the request before the signaler is completed before submitting the busywait, we prevent the busywait from starting too early, if the signaler is not first in submission port. To handle the case where the signaler is at the start of the second (or later) submission port, we will need to delay the execution callback until we know the context is promoted to port0. A challenge for later. Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni sation on gen8+") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501114541.10077-9-chris@chris-wilson.co.uk
2019-05-03drm/i915/hangcheck: Track context changesChris Wilson2-3/+10
Given sufficient preemption, we may see a busy system that doesn't advance seqno while performing work across multiple contexts, and given sufficient pathology not even notice a change in ACTHD. What does change between the preempting contexts is their RING, so take note of that and treat a change in the ring address as being an indication of forward progress. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501114541.10077-1-chris@chris-wilson.co.uk
2019-05-03drm/i915: Leave engine parking to the enginesChris Wilson1-17/+1
Drop the check in GEM parking that the engines were already parked. The intention here was that before we dropped the GT wakeref, we were sure that no more interrupts could be raised -- however, we have already dropped the wakeref by this point and the warning is no longer valid. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502150024.16636-2-chris@chris-wilson.co.uk
2019-05-03drm/i915/execlists: Flush the tasklet on parkingChris Wilson5-14/+35
Tidy up the cleanup sequence by always ensure that the tasklet is flushed on parking (before we cleanup). The parking provides a convenient point to ensure that the backend is truly idle. v2: Do the full check for idleness before parking, to be sure we flush any residual interrupt. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190503080942.30151-1-chris@chris-wilson.co.uk
2019-05-03drm/i915/guc: Fix runtime suspendChris Wilson3-9/+19
We are not allowed to rpm_get() inside the runtime-suspend callback, so split the intel_uc_suspend() into the core that assumes the caller holds the wakeref (intel_uc_runtime_suspend), and one that acquires the wakeref as necessary (intel_uc_suspend). Reported-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Fixes: 79ffac8599c4 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502203009.15727-1-chris@chris-wilson.co.uk
2019-05-03drm/i915: extract intel_gmbus.h from i915_drv.h and rename intel_i2c.cJani Nikula15-30/+63
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. While at it, rename intel_i2c.c to intel_gmbus.c and the functions to intel_gmbus_*. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/5834b8fbbfd4ac2e3d0159e69c87f6926066f537.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: move more generic utils to i915_utils.hJani Nikula3-152/+153
Reduce clutter from i915_drv.h and intel_drv.h. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8c197872384fc35442b738c21ba0da9336e02a85.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: make i915_utils.h self-containedJani Nikula2-2/+5
And ensure it stays that way. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/69bcebefa6d8689d4a962394b0c6db04904354ed.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: move i915_vgacntrl_reg() where neededJani Nikula2-10/+10
Reduce clutter from i915_drv.h. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/d30a79d008b875f708f5acf7924f9ca8ab06b575.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: extract i915_debugfs.h from i915_drv.hJani Nikula8-12/+29
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2843b028d65e118dc40316aa84bf620a93f6c67b.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: extract intel_acpi.h from i915_drv.hJani Nikula6-9/+23
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9bc1317a67df0b9d019eca5b36f474b76a1cad26.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: extract intel_lpe_audio.h from i915_drv.hJani Nikula6-12/+30
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9101a58b9f10bcf11332175e17b6e6e45f4ebd17.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: extract intel_dpio_phy.h from i915_drv.hJani Nikula10-41/+66
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/876a1671a84c6839bcafdf276cf9c4e1da6c631c.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915/csr: move CSR version macros to intel_csr.hJani Nikula4-4/+6
Reduce clutter from i915_drv.h. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8222df3f559b056387b5c7e6e04a878cbf8b4e2e.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: remove unused/stale macros and comments from intel_drv.hJani Nikula1-9/+0
Reduce clutter from intel_drv.h. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/963ba7fa0111135c3e796bfc9f86d6e33724758e.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: move ranges to intel_display.cJani Nikula2-15/+15
Reduce clutter from intel_drv.h with the minimal change. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2c9248b50e620e95d85b8b9252d020a547c9474a.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915/dsi: move operation mode types to intel_dsi.hJani Nikula2-3/+3
Reduce clutter from intel_drv.h with the minimal change. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/72de677e844220d8522a836aae206c278ea45284.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915/dvo: move DVO chip types to intel_dvo.cJani Nikula2-5/+5
Reduce clutter from intel_drv.h with the minimal change. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/95203dbf844061da95f33614d0cb61533a11fdd4.1556809195.git.jani.nikula@intel.com
2019-05-03drm/i915: add single combo phy init/unit functionsJani Nikula3-13/+27
Work on the principle that files should prefer not to expose platform specific functions. v2, v3: Rebase Cc: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502145234.7002-1-jani.nikula@intel.com
2019-05-02drm/i915: Tune down WARN about incorrect VBT TC legacy flagImre Deak1-3/+6
Looks like VBT contains again the wrong information about a port's TypeC legacy vs. DP-alt/TBT-alt type. There is no further issues after we notice this and fix it up, so tune down the WARN to be a a DRM_ERROR. This also avoids CI tainting the kernel and stopping the test run. v2: - Update also code coment accordingly. (Jani) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110578 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190502101754.29219-1-imre.deak@intel.com
2019-05-02drm/i915: Include fence signaled bit in print_request()Chris Wilson1-1/+4
Show the fence flags view of request completion in addition to the normal hwsp check and whether signaling is enabled. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501114541.10077-2-chris@chris-wilson.co.uk
2019-05-02drm/i915/icl: Add missing combo PHY lane power setupImre Deak1-0/+10
This step of the BSpec combo PHY port enabling is missing, so add it now. v2: - Rebased on the new fixed v2 version of the helper. v3: - Use intel_ instead of icl_ prefix. (Jani) Reported-by: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190425185253.3197-2-imre.deak@intel.com
2019-05-02drm/i915/icl: Factor out combo PHY lane power setup helperImre Deak4-24/+62
Factor out the combo PHY lane power configuration code to a separate helper; it will be also needed by the next patch adding the same configuration for DDI ports. Add support for DDI ports and lane reversal as preparation for the next patch. The PWR_DOWN_LN_1 value is unspecified in the BSpec register description so remove it. v2: - Fix up the wrong assumption that the encodings are the same for DDI and DSI ports. (Jani) v3: - Use intel_ instead of icl_ prefix. (Jani) - Add required headers to intel_combo_phy.h after the upstream header refactoring. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> (v2) Link: https://patchwork.freedesktop.org/patch/msgid/20190425185253.3197-1-imre.deak@intel.com
2019-05-02drm/i915: hsw+ audio regs are per-transocderVille Syrjälä2-35/+32
s/pipe/transcoder/ when dealing with hsw+ audio registers. This won't actually make any real difference since there is no audio on the EDP transcoder. But this should avoid a bit of confusion when cross checking against the spec. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430142901.7302-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-05-02drm/i915: Don't skip audio enable if ELD is bogusVille Syrjälä1-1/+3
We've already committed to enabling audio when intel_audio_codec_enable() is called. We can't back out even if the ELD has turned sour in the meantime. So just spew some debug log and plow ahead. Otherwise the state checker gets unhappy when audio isn't enabled when it is expected to be. I suppose we really ought to precompute the ELD as well, but let's just toss in a FIXME for the future. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103841 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430142901.7302-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-05-02drm/i915/csr: alpha_support doesn't depend on csr or vice versaJani Nikula1-2/+0
Debug logging should not be dependent on alpha support flag. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190429142253.15882-1-jani.nikula@intel.com
2019-05-02drm/i915: Corrupt DSI picture fix for GeminiLakeStanislav Lisovskiy1-0/+9
Currently due to regression CI machine displays show corrupt picture. Problem is when CDCLK is as low as 79200, picture gets unstable, while DSI and DE pll values were confirmed to be correct. Limiting to 158400 as agreed with Ville. We could not come up with any better solution yet, as PLL divider values both for MIPI(DSI PLL) and CDCLK(DE PLL) are correct, however seems that due to some boundary conditions, when clocking is too low we get wrong timings for DSI display. Similar workaround exists for VLV though, so just took similar condition into use. At least that way GLK platform will start to be usable again, with current drm-tip. v2: Fixed commit subject as suggested. v3: Added generic bugs(crc failures, screen not init for GLK DSI which might be affected). v4: Added references tag for bugs affected. Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://bugs.freedesktop.org/show_bug.cgi?id=109267 References: https://bugs.freedesktop.org/show_bug.cgi?id=103184 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430125119.7478-1-stanislav.lisovskiy@intel.com
2019-05-01drm/i915: Complete both freed-object passes before draining the workqueueChris Wilson1-3/+3
The workqueue code complains viciously if we try to queue more work onto the queue while attampting to drain it. As we asynchronously free objects and defer their enqueuing with RCU, it is quite tricky to quiesce the system before attempting to drain the workqueue. Yet drain we must to ensure that the worker is idle before unloading the module. Give the freed object drain 3 whole passes with multiple rcu_barrier() to give the defer freeing of several levels each protected by RCU and needing a grace period before its parent can be freed, ultimately resulting in a GEM object being freed after another RCU period. A consequence is that it will make module unload even slower. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110550 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501135753.8711-1-chris@chris-wilson.co.uk
2019-05-01drm/i915: Move the engine->destroy() vfunc onto the engineChris Wilson7-108/+77
Make the engine responsible for cleaning itself up! This removes the i915->gt.cleanup vfunc that has been annoying the casual reader and myself for the last several years, and helps keep a future patch to add more cleanup tidy. v2: Assert that engine->destroy is set after the backend starts allocating its own state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190501103204.18632-1-chris@chris-wilson.co.uk
2019-04-30drm/i915: Enable pipe HDR mode on ICL if only HDR planes are usedVille Syrjälä3-4/+16
The pipe has a special HDR mode with higher precision when only HDR planes are active. Let's use it. Curiously this fixes the kms_color gamma/degamma tests when using a HDR plane, which is always the case unless one hacks the test to use an SDR plane. If one does hack the test to use an SDR plane it does pass already. I have no actual explanation how the output after the gamma LUT can be different between the two modes. The way the tests are written should mean that the output should be identical between the solid color vs. the gradient. But clearly that somehow doesn't hold true for the HDR planes in non-HDR pipe mode. Anyways, as long as we stick to one type of plane the test should produce sensible results now. v2: s/HDR_MODE/HDR_MODE_PRECISION/ (Shashank) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412183009.8237-2-ville.syrjala@linux.intel.com Reviewed-by: Uma Shankar <uma.shankar@intel.com> Tested-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
2019-04-30drm/i915: Flatten and rename haswell_set_pipemisc()Ville Syrjälä1-35/+33
Move the platform checks out from haswell_set_pipemisc() and rename it to bdw_set_pipemisc() to make it clear when to call it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190412183009.8237-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2019-04-30drm/i915: Wait for the struct_mutex on idlingChris Wilson1-7/+1
When the system is idling, contention for struct_mutex should be low and so we will be more efficient to wait for a contended mutex than reschedule. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190430094405.6127-1-chris@chris-wilson.co.uk
2019-04-30drm/i915: extract intel_combo_phy.h from i915_drv.hJani Nikula5-6/+19
It used to be handy that we only had a couple of headers, but over time i915_drv.h has become unwieldy. Extract declarations to a separate header file corresponding to the implementation module, clarifying the modularity of the driver. Ensure the new header is self-contained, and do so with minimal further includes, using forward declarations as needed. Include the new header only where needed, and sort the modified include directives while at it and as needed. No functional changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/6aea17072684dec0b04b6831c0c0e5a134edf87e.1556540890.git.jani.nikula@intel.com
2019-04-30drm/i915: move some leftovers to intel_pm.h from i915_drv.hJani Nikula5-15/+20
Commit 696173b064c6 ("drm/i915: extract intel_pm.h from intel_drv.h") missed the declarations in i915_drv.h. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/770f5f1c2dd99e4d6a314b70184e71b928a6d362.1556540890.git.jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-21 03:54:27 +0000