aboutsummaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2020-03-02drm/i915/perf: Reintroduce wait on OA configuration completionChris Wilson
We still need to wait for the initial OA configuration to happen before we enable OA report writes to the OA buffer. Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1f876 ("drm/i915/perf: execute OA configuration from command stream") Closes: https://gitlab.freedesktop.org/drm/intel/issues/1356 Testcase: igt/perf/stream-open-close Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-7-chris@chris-wilson.co.uk
2020-03-02drm/i915/tgl: Add Wa number to WaAllowPMDepthAndInvocationCountAccessFromUMDJosé Roberto de Souza
Just to make easier to check that the Wa was implemetend when comparing to the number in BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-10-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note about Wa_1409142259José Roberto de Souza
Different issues with the same fix, so justing adding Wa_1409142259, Wa_1409252684, Wa_1409217633, Wa_1409207793, Wa_1409178076 and 1408979724 to the comment so other devs can check if this Was were implemetend with a simple grep. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-8-jose.souza@intel.com
2020-03-02drm/i915/tgl: Fix the Wa number of a fixJosé Roberto de Souza
The Wa number for this fix is Wa_1607087056 the BSpec bug id is 1607087056, just updating to match BSpec. BSpec: 52890 Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-7-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note about Wa_1607063988José Roberto de Souza
This issue workaround in Wa_1607063988 has the same fix as Wa_1607138336, so just adding a note in the code. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-6-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add note to Wa_1607297627José Roberto de Souza
Add note about the confliting information in BSpec about this WA. BSpec: 52890 Acked-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-5-jose.souza@intel.com
2020-03-02drm/i915/tgl: Extend Wa_1606931601 for all steppingsAnusha Srivatsa
According to BSpec. Wa_1606931601 applies for all TGL steppings. This patch moves the WA implementation out of A0 only block of rcs_engine_wa_init(). The WA is has also been referred to by an alternate name Wa_1607090982. Bspec: 46045, 52890 Fixes: 3873fd1a43c7 ("drm/i915: Use engine wa list for Wa_1607090982") Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-4-jose.souza@intel.com
2020-03-02drm/i915/tgl: Add Wa_1409085225, Wa_14010229206Matt Atwood
Disable Push Constant buffer addition for TGL. v2: typos, add additional Wa reference v3: use REG_BIT macro, move to rcs_engine_wa_init, clean up commit message. Bspec: 52890 Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-3-jose.souza@intel.com
2020-03-02drm/i915/tgl: Implement Wa_1806527549José Roberto de Souza
This will whitelist the HIZ_CHICKEN register so mesa can disable the optimizations and avoid hang when using D16_UNORM. v2: moved to the right place and used the right function() (Chris) Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rafael Antognolli <rafael.antognolli@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-2-jose.souza@intel.com
2020-03-02drm/i915/tgl: Implement Wa_1409804808José Roberto de Souza
This workaround the CS not done issue on PIPE_CONTROL. v2: - replaced BIT() by REG_BIT() in all GEN7_ROW_CHICKEN2() bits - shortened the name of the new bit BSpec: 52890 BSpec: 46218 Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-1-jose.souza@intel.com
2020-03-02drm/i915: Unify the DPLL ref clock frequency trackingImre Deak
All platforms using the shared DPLL framework use 3 reference clocks for their DPLLs: SSC, non-SSC and DSI. For a more unified way across platforms store the frequency of these ref clocks as part of the DPLL global state. This also allows us to keep the HW access reading out the ref clock value separate from the DPLL frequency calculation that depends on the ref clock. For now add only the SSC and non-SSC ref clocks, as the pre-ICL DSI code has its own logic for calculating DPLL parameters instead of the shared DPLL framework. v2: - Apply the ICL combo PHY PLL ref_clock/2 adjustment during the frequency->PLL param conversion direction as well. (CI shards) - s/kHZ/kHz/ (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228153328.17842-1-imre.deak@intel.com
2020-03-02drm/i915/hsw: Use the read-out WRPLL/SPLL state instead of reading out againImre Deak
Instead of reading out the WRPLL/SPLL control values from HW, we can use the DPLL state that was already read out, or swapped-to. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-13-imre.deak@intel.com
2020-03-02drm/i915/skl, cnl: Split out the WRPLL/LCPLL frequency calculationImre Deak
Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-12-imre.deak@intel.com
2020-03-02drm/i915/hsw: Split out the WRPLL, LCPLL, SPLL frequency calculationImre Deak
Split out the PLL parameter->frequency conversion logic for each type of PLL for symmetry with their corresponding inverse conversion functions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-11-imre.deak@intel.com
2020-03-02drm/i915/hsw: Split out the SPLL parameter calculationImre Deak
For consistency with the WRPLL/LCPLL parameter calculation functions, split out the SPLL specific logic to its own function. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-10-imre.deak@intel.com
2020-03-02drm/i915/hsw: Rename the get HDMI/DP DPLL funcs to get WRPLL/LCPLLImre Deak
The types of PLLs used for HDMI/DP on HSW are WRPLL/LCPLL accordingly, so use these names to align better with the rest of WRPLL/LCPLL function names elsewhere. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-9-imre.deak@intel.com
2020-03-02drm/i915/skl: Parametrize the DPLL ref clock instead of open-coding itImre Deak
For clarity keep the SKL DPLL ref clock in a variable instead of open-coding it. Store the value in kHZ units as done on other platforms. This allows us in a later patch to keep track of the DPLL ref clock in a more unified way across all platforms. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-8-imre.deak@intel.com
2020-03-02drm/i915: Move DPLL frequency calculation to intel_dpll_mgr.cImre Deak
Move all the DPLL params->DPLL frequency conversion functions to intel_dpll_mgr.c where the corresponding inverse conversions are. The GEN11+ TBT PLL outputs multiple frequencies and for selecting the one in use we need to check the DDI CLK mux. As part of the DDI clock logic this selection is kept in intel_ddi.c. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-7-imre.deak@intel.com
2020-03-02drm/i915/hsw: Use the DPLL ID when calculating DPLL clockImre Deak
Instead of converting DPLL ID to CLK_SEL to identify the DPLL use the DPLL ID directly for this. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-6-imre.deak@intel.com
2020-03-02drm/i915: Move the DPLL vfunc inits after the func definesImre Deak
Move the per-platform DPLL and DPLL-manager vfunc initializations right after the corresponding function definitions. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-5-imre.deak@intel.com
2020-03-02drm/i915: Keep the global DPLL state in a DPLL specific structImre Deak
For clarity add a new DPLL specific struct to the i915 device struct and move all DPLL fields into it. Accordingly remove the dpll_ prefixes, as the new struct already provides the required namespacing. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-4-imre.deak@intel.com
2020-03-02drm/i915: Move DPLL HW readout/sanitize fns to intel_dpll_mgr.cImre Deak
Move the HW readout/sanitize functions to intel_dpll_mgr.c which contains the rest of shared DPLL functionality. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-3-imre.deak@intel.com
2020-03-02drm/i915: Fix bounds check in intel_get_shared_dpll_id()Imre Deak
Fix an off-by-one error in the upper-bound check and while at it clear up a bit the function. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200226203455.23032-2-imre.deak@intel.com
2020-03-02drm/i915: Use intel_plane_data_rate for min_cdclk calculationStanislav Lisovskiy
There seems to be a bit of confusing redundancy in a way, how plane data rate/min cdclk are calculated. In fact both min cdclk, pixel rate and plane data rate are all part of the same formula as per BSpec. However currently we have intel_plane_data_rate, which is used to calculate plane data rate and which is also used in bandwidth calculations. However for calculating min_cdclk we have another piece of code, doing almost same calculation, but a bit differently and in a different place. However as both are actually part of same formula, probably would be wise to use plane data rate calculations as a basis anyway, thus avoiding code duplication and possible bugs related to this. Another thing is that I've noticed that during min_cdclk calculations we account for plane scaling, while for plane data rate, we don't. crtc->pixel_rate seems to account only for pipe ratio, however it is clearly stated in BSpec that plane data rate also need to account plane ratio as well. So what this commit does is: - Adds a plane ratio calculation to intel_plane_data_rate - Removes redundant calculations from skl_plane_min_cdclk which is used for gen9+ and now uses intel_plane_data_rate as a basis from there as well. v2: - Don't use 64 division if not needed(Ville Syrjälä) - Now use intel_plane_pixel_rate as a basis for calculations both at intel_plane_data_rate and skl_plane_min_cdclk(Ville Syrjälä) v3: - Again fix the division macro - Fix plane_pixel_rate to pixel_rate at intel_plane_pixel_rate callsites v4: - Renamed skl_plane_ratio function back(Ville Syrjälä) v5: - Don't precalculate plane pixel rate for invisible plane, check for visibility first, as in invisible case it will have dst_w and dst_h equal to zero, causing divide error. v6: - Removed useless warn in intel_plane_pixel_rate(Ville Syrjälä) - Fixed alignment in intel_plane_data_rate(Ville Syrjälä) - Changed pixel_rate type to be unsigned int in skl_plane_min_cdclk(Ville Syrjälä) Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227150935.2107-1-stanislav.lisovskiy@intel.com
2020-03-02drm/i915: Use a sentinel to terminate the dbuf slice arraysVille Syrjälä
Make life a bit simpler by sticking a sentinel at the end of the dbuf slice arrays. This way we don't need to pass in the size. Also unify the types (u8 vs. u32) for active_pipes. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-5-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-03-02drm/i915: Add missing commas to dbuf tablesVille Syrjälä
The preferred style is to sprinkle commas after each array and structure initialization, whether or not it happens to be the last element/member (only exception being sentinel entries which never have anything after them). This leads to much prettier diffs if/when new elements/members get added to the end of the initialization. We're not bound by some ancient silly mandate to omit the final comma. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-4-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-03-02drm/i915: Remove garbage WARNsVille Syrjälä
These things can never happen, and probably we'd have oopsed long ago if they did. Just get rid of this pointless noise in the code. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-3-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-03-02drm/i915: Handle some leftover s/intel_crtc/crtc/Ville Syrjälä
Switch to the preferred 'crtc' name for our crtc variables. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200225171125.28885-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2020-03-02drm/i915: Fix 90/270 degree rotated RGB565 src coord checksVille Syrjälä
Supposedly both src coordinates have to even when doing 90/270 degree rotation with RGB565. This is definitely true for the X coordinate (we just get a black screen when it is odd). My experiments didn't show any misbehaviour with an odd Y coordinate, but let's trust the spec and reject that one as well. v2: Ignore ccs hsub/vsub v3: Clarify the CCS special (Maarten) Deal with tgl+ CCS modifiers where we do need to look at hsub/vsub Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #v2 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228160523.1064-1-ville.syrjala@linux.intel.com
2020-03-02drm/i915/dp: Use BDB_GENERAL_FEATURES VBT block info for builtin ↵Hans de Goede
panel-orientation Some devices with a builtin panel have the panel mounted upside down, this is indicated by the rotate_180 bit in the BDB_GENERAL_FEATURES VBT block. We store this info in dev_priv->vbt.orientation, use this to set the connector's orientation property so that fbcon and userspace will show the image the right way up on devices with an upside-down mounted panel. This fixes the image being upside-down on a Teclast X89 tablet. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228114110.187792-3-hdegoede@redhat.com
2020-03-02drm/i915/dsi: Remove readback of panel orientation on BYT / CHTHans de Goede
Commit 82daca297506 ("drm/i915: Add "panel orientation" property to the panel connector, v6.") uses hardware state readback to determine if the GOP is rotating the image by 180 degrees to compensate for upside-down mounted panels. When I wrote that commit I tried to find the VBT bits the GOP used to decide to rotate the image, but I could not find them. Back then I only looked at the rotation bits in struct mipi_config and these read 0 on the 1 BYT device I have with an upside-down mounted panel (a GP-electronic T701 tablet). While working on a similar problem on a BYT device with an eDP panel I noticed that the new intel_dsi_get_panel_orientation() helper which gets used on newer SoCs (Apollo-Lake, etc.) checks the rotate_180 bit in the BDB_GENERAL_FEATURES VBT block. I've checked and this bit indeed is set on the GP-electronic T701 tablet, so using the generic intel_dsi_get_panel_orientation() helper there does the right thing without needing any extra readback of hw state. This commit removes the special handling of the panel orientation for DSI panels on BYT/CHT devices, bringing the handling in line with the handling of DSI panels on other devices. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228114110.187792-2-hdegoede@redhat.com
2020-03-02drm/i915: remove unused orig_clock i915 memberJani Nikula
Unused since commit f97108d1d0fa ("drm/i915: add dynamic performance control support for Ironlake"). That's a little over ten years. Good riddance. 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/20200227170047.31089-2-jani.nikula@intel.com
2020-03-02drm/i915: add i915_ioc32.h for compatJani Nikula
Keep reducing 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/20200227170047.31089-1-jani.nikula@intel.com
2020-03-02drm/i915/dram: hide the dram structs betterJani Nikula
Finish the job started in d28ae3b28187 ("drm/i915: split out intel_dram.[ch] from i915_drv.c") by moving struct dram_dimm_info and dram_channel_info inside intel_dram.c, the only user of the structs. 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/20200227145359.17543-1-jani.nikula@intel.com
2020-03-02drm/i915/crc: move pipe_crc from drm_i915_private to intel_crtcJani Nikula
Having an array pipe_crc[I915_MAX_PIPES] in struct drm_i915_private should be an obvious clue this should be located in struct intel_crtc instead. Make it so. As a side-effect, fix some errors in indexing pipe_crc with both pipe and crtc index. And, of course, reduce the size of i915_drv.h. Cc: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.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/20200227161253.15741-1-jani.nikula@intel.com
2020-02-28drm/i915/gt: Expose heartbeat interval via sysfsChris Wilson
We monitor the health of the system via periodic heartbeat pulses. The pulses also provide the opportunity to perform garbage collection. However, we interpret an incomplete pulse (a missed heartbeat) as an indication that the system is no longer responsive, i.e. hung, and perform an engine or full GPU reset. Given that the preemption granularity can be very coarse on a system, we let the sysadmin override our legacy timeouts which were "optimised" for desktop applications. The heartbeat interval can be adjusted per-engine using, /sys/class/drm/card?/engine/*/heartbeat_interval_ms Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-7-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose preempt reset timeout via sysfsChris Wilson
After initialising a preemption request, we give the current resident a small amount of time to vacate the GPU. The preemption request is for a higher priority context and should be immediate to maintain high quality of service (and avoid priority inversion). However, the preemption granularity of the GPU can be quite coarse and so we need a compromise. The preempt timeout can be adjusted per-engine using, /sys/class/drm/card?/engine/*/preempt_timeout_ms and can be disabled by setting it to 0. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-6-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose reset stop timeout via sysfsChris Wilson
When we allow ourselves to sleep before a GPU reset after disabling submission, even for a few milliseconds, gives an innocent context the opportunity to clear the GPU before the reset occurs. However, how long to sleep depends on the typical non-preemptible duration (a similar problem to determining the ideal preempt-reset timeout or even the heartbeat interval). As this seems of a hard policy decision, punt it to userspace. The timeout can be adjusted using /sys/class/drm/card?/engine/*/stop_timeout_ms Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-5-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose busywait duration to sysfsChris Wilson
We busywait on an inflight request (one that is currently executing on HW, and so might complete quickly) prior to setting up an interrupt and sleeping. The trade off is that we keep an expensive CPU core busy in order to avoid wake up latency: where that trade off should lie is best left to the sysadmin. The busywait mechanism can be compiled out with ./scripts/config --set-val DRM_I915_SPIN_REQUEST 0 The maximum busywait duration can be adjusted per-engine using, /sys/class/drm/card?/engine/*/ms_busywait_duration_ns Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-4-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose timeslice duration to sysfsChris Wilson
Execlists uses a scheduling quantum (a timeslice) to alternate execution between ready-to-run contexts of equal priority. This ensures that all users (though only if they of equal importance) have the opportunity to run and prevents livelocks where contexts may have implicit ordering due to userspace semaphores. The timeslicing mechanism can be compiled out with ./scripts/config --set-val DRM_I915_TIMESLICE_DURATION 0 The timeslice duration can be adjusted per-engine using, /sys/class/drm/card?/engine/*/timeslice_duration_ms Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-3-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose engine->mmio_base via sysfsChris Wilson
Use the per-engine sysfs directory to let userspace discover the mmio_base of each engine. Prior to recent generations, the user accessible registers on each engine are at a fixed offset relative to each engine -- but require absolute addressing. As the absolute address depends on the actual physical engine, this is not always possible to determine from userspace (for example icl may expose vcs1 or vcs2 as the second vcs engine). Make this easy for userspace to discover by providing the mmio_base in sysfs. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-2-chris@chris-wilson.co.uk
2020-02-28drm/i915/gt: Expose engine properties via sysfsChris Wilson
Preliminary stub to add engines underneath /sys/class/drm/cardN/, so that we can expose properties on each engine to the sysadmin. To start with we have basic analogues of the i915_query ioctl so that we can pretty print engine discovery from the shell, and flesh out the directory structure. Later we will add writeable sysadmin properties such as per-engine timeout controls. An example tree of the engine properties on Braswell: /sys/class/drm/card0 └── engine    ├── bcs0    │   ├── capabilities    │   ├── class    │   ├── instance    │   ├── known_capabilities    │   └── name    ├── rcs0    │   ├── capabilities    │   ├── class    │   ├── instance    │   ├── known_capabilities    │   └── name    ├── vcs0    │   ├── capabilities    │   ├── class    │   ├── instance    │   ├── known_capabilities    │   └── name    └── vecs0       ├── capabilities    ├── class    ├── instance       ├── known_capabilities    └── name v2: Include stringified capabilities v3: Include all known capabilities for futureproofing. v4: Combine the two caps loops into one v5: Hide underneath Kconfig.unstable for wider discussion Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Tested-by: Steve Carbonari <steven.carbonari@intel.com> Reviewed-by: Steve Carbonari <steven.carbonari@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228131716.3243616-1-chris@chris-wilson.co.uk
2020-02-28drm/i915/selftests: Fix return in assert_mmap_offset()Dan Carpenter
The assert_mmap_offset() returns type bool so if we return an error pointer that is "return true;" or success. If we have an error, then we should return false. Fixes: 3d81d589d6e3 ("drm/i915: Test exhaustion of the mmap space") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200228141413.qfjf4abr323drlo4@kili.mountain
2020-02-28drm/i915: Drop WaDDIIOTimeout:glkVille Syrjälä
WaDDIIOTimeout is only for A1 (pre-prod) glk steppings. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-02-28drm/i915: Limit display Wa_1405510057 to gen11Ville Syrjälä
TGL+ supposedly do not need Wa_1405510057 so limit it to gen11 only. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-2-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-02-28drm/i915: Nuke pre-production GLK HDMI w/a 1139Ville Syrjälä
w/a #1139 is only needed for pre-production GLK. Nuke it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2020-02-28drm/i915/gt: Reset queue_priority_hint after wedgingChris Wilson
An odd and highly unlikely path caught us out. On delayed submission (due to an asynchronous reset handler), we poked the priority_hint and kicked the tasklet. However, we had already marked the device as wedged and swapped out the tasklet for a no-op. The result was that we never cleared the priority hint and became upset when we later checked. <0> [574.303565] i915_sel-6278 2.... 481822445us : __i915_subtests: Running intel_execlists_live_selftests/live_error_interrupt <0> [574.303565] i915_sel-6278 2.... 481822472us : __engine_unpark: 0000:00:02.0 rcs0: <0> [574.303565] i915_sel-6278 2.... 481822491us : __gt_unpark: 0000:00:02.0 <0> [574.303565] i915_sel-6278 2.... 481823220us : execlists_context_reset: 0000:00:02.0 rcs0: context:f4ee reset <0> [574.303565] i915_sel-6278 2.... 481824830us : __intel_context_active: 0000:00:02.0 rcs0: context:f51b active <0> [574.303565] i915_sel-6278 2.... 481825258us : __intel_context_do_pin: 0000:00:02.0 rcs0: context:f51b pin ring:{start:00006000, head:0000, tail:0000} <0> [574.303565] i915_sel-6278 2.... 481825311us : __i915_request_commit: 0000:00:02.0 rcs0: fence f51b:2, current 0 <0> [574.303565] i915_sel-6278 2d..1 481825347us : __i915_request_submit: 0000:00:02.0 rcs0: fence f51b:2, current 0 <0> [574.303565] i915_sel-6278 2d..1 481825363us : trace_ports: 0000:00:02.0 rcs0: submit { f51b:2, 0:0 } <0> [574.303565] i915_sel-6278 2.... 481826809us : __intel_context_active: 0000:00:02.0 rcs0: context:f51c active <0> [574.303565] <idle>-0 7d.h2 481827326us : cs_irq_handler: 0000:00:02.0 rcs0: CS error: 1 <0> [574.303565] <idle>-0 7..s1 481827377us : process_csb: 0000:00:02.0 rcs0: cs-irq head=3, tail=4 <0> [574.303565] <idle>-0 7..s1 481827379us : process_csb: 0000:00:02.0 rcs0: csb[4]: status=0x10000001:0x00000000 <0> [574.305593] <idle>-0 7..s1 481827385us : trace_ports: 0000:00:02.0 rcs0: promote { f51b:2*, 0:0 } <0> [574.305611] <idle>-0 7..s1 481828179us : execlists_reset: 0000:00:02.0 rcs0: reset for CS error <0> [574.305611] i915_sel-6278 2.... 481828284us : __intel_context_do_pin: 0000:00:02.0 rcs0: context:f51c pin ring:{start:00007000, head:0000, tail:0000} <0> [574.305611] i915_sel-6278 2.... 481828345us : __i915_request_commit: 0000:00:02.0 rcs0: fence f51c:2, current 0 <0> [574.305611] <idle>-0 7dNs2 481847823us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence f51b:2, current 1 <0> [574.305611] <idle>-0 7dNs2 481847857us : execlists_hold: 0000:00:02.0 rcs0: fence f51b:2, current 1 on hold <0> [574.305611] <idle>-0 7.Ns1 481847863us : intel_engine_reset: 0000:00:02.0 rcs0: flags=4 <0> [574.305611] <idle>-0 7.Ns1 481847945us : execlists_reset_prepare: 0000:00:02.0 rcs0: depth<-1 <0> [574.305611] <idle>-0 7.Ns1 481847946us : intel_engine_stop_cs: 0000:00:02.0 rcs0: <0> [574.305611] <idle>-0 7.Ns1 538584284us : intel_engine_stop_cs: 0000:00:02.0 rcs0: timed out on STOP_RING -> IDLE <0> [574.305611] <idle>-0 7.Ns1 538584347us : __intel_gt_reset: 0000:00:02.0 engine_mask=1 <0> [574.305611] <idle>-0 7.Ns1 538584406us : execlists_reset_rewind: 0000:00:02.0 rcs0: <0> [574.305611] <idle>-0 7dNs2 538585050us : __i915_request_reset: 0000:00:02.0 rcs0: fence f51b:2, current 1 guilty? yes <0> [574.305611] <idle>-0 7dNs2 538585063us : __execlists_reset: 0000:00:02.0 rcs0: replay {head:0000, tail:0068} <0> [574.306565] <idle>-0 7.Ns1 538588457us : intel_engine_cancel_stop_cs: 0000:00:02.0 rcs0: <0> [574.306565] <idle>-0 7dNs2 538588462us : __i915_request_submit: 0000:00:02.0 rcs0: fence f51c:2, current 0 <0> [574.306565] <idle>-0 7dNs2 538588471us : trace_ports: 0000:00:02.0 rcs0: submit { f51c:2, 0:0 } <0> [574.306565] <idle>-0 7.Ns1 538588474us : execlists_reset_finish: 0000:00:02.0 rcs0: depth->1 <0> [574.306565] kworker/-202 2.... 538588755us : i915_request_retire: 0000:00:02.0 rcs0: fence f51c:2, current 2 <0> [574.306565] ksoftirq-46 7..s. 538588773us : process_csb: 0000:00:02.0 rcs0: cs-irq head=11, tail=1 <0> [574.306565] ksoftirq-46 7..s. 538588774us : process_csb: 0000:00:02.0 rcs0: csb[0]: status=0x10000001:0x00000000 <0> [574.306565] ksoftirq-46 7..s. 538588776us : trace_ports: 0000:00:02.0 rcs0: promote { f51c:2!, 0:0 } <0> [574.306565] ksoftirq-46 7..s. 538588778us : process_csb: 0000:00:02.0 rcs0: csb[1]: status=0x10000018:0x00000020 <0> [574.306565] ksoftirq-46 7..s. 538588779us : trace_ports: 0000:00:02.0 rcs0: completed { f51c:2!, 0:0 } <0> [574.306565] kworker/-202 2.... 538588826us : intel_context_unpin: 0000:00:02.0 rcs0: context:f51c unpin <0> [574.306565] i915_sel-6278 6.... 538589663us : __intel_gt_set_wedged.part.32: 0000:00:02.0 start <0> [574.306565] i915_sel-6278 6.... 538589667us : execlists_reset_prepare: 0000:00:02.0 rcs0: depth<-0 <0> [574.306565] i915_sel-6278 6.... 538589710us : intel_engine_stop_cs: 0000:00:02.0 rcs0: <0> [574.306565] i915_sel-6278 6.... 538589732us : execlists_reset_prepare: 0000:00:02.0 bcs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589733us : intel_engine_stop_cs: 0000:00:02.0 bcs0: <0> [574.307591] i915_sel-6278 6.... 538589757us : execlists_reset_prepare: 0000:00:02.0 vcs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589758us : intel_engine_stop_cs: 0000:00:02.0 vcs0: <0> [574.307591] i915_sel-6278 6.... 538589771us : execlists_reset_prepare: 0000:00:02.0 vcs1: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589772us : intel_engine_stop_cs: 0000:00:02.0 vcs1: <0> [574.307591] i915_sel-6278 6.... 538589778us : execlists_reset_prepare: 0000:00:02.0 vecs0: depth<-0 <0> [574.307591] i915_sel-6278 6.... 538589780us : intel_engine_stop_cs: 0000:00:02.0 vecs0: <0> [574.307591] i915_sel-6278 6.... 538589786us : __intel_gt_reset: 0000:00:02.0 engine_mask=ff <0> [574.307591] i915_sel-6278 6.... 538591175us : execlists_reset_cancel: 0000:00:02.0 rcs0: <0> [574.307591] i915_sel-6278 6.... 538591970us : execlists_reset_cancel: 0000:00:02.0 bcs0: <0> [574.307591] i915_sel-6278 6.... 538591982us : execlists_reset_cancel: 0000:00:02.0 vcs0: <0> [574.307591] i915_sel-6278 6.... 538591996us : execlists_reset_cancel: 0000:00:02.0 vcs1: <0> [574.307591] i915_sel-6278 6.... 538592759us : execlists_reset_cancel: 0000:00:02.0 vecs0: <0> [574.307591] i915_sel-6278 6.... 538592977us : execlists_reset_finish: 0000:00:02.0 rcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538592996us : execlists_reset_finish: 0000:00:02.0 bcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593023us : execlists_reset_finish: 0000:00:02.0 vcs0: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593037us : execlists_reset_finish: 0000:00:02.0 vcs1: depth->0 <0> [574.307591] i915_sel-6278 6.N.. 538593051us : execlists_reset_finish: 0000:00:02.0 vecs0: depth->0 <0> [574.307591] i915_sel-6278 6.... 538593407us : __intel_gt_set_wedged.part.32: 0000:00:02.0 end <0> [574.307591] kworker/-210 7d..1 551958381us : execlists_unhold: 0000:00:02.0 rcs0: fence f51b:2, current 2 hold release <0> [574.307591] i915_sel-6278 0.... 559490788us : i915_request_retire: 0000:00:02.0 rcs0: fence f51b:2, current 2 <0> [574.307591] i915_sel-6278 0.... 559490793us : intel_context_unpin: 0000:00:02.0 rcs0: context:f51b unpin <0> [574.307591] i915_sel-6278 0.... 559490798us : __engine_park: 0000:00:02.0 rcs0: parked <0> [574.307591] i915_sel-6278 0.... 559490982us : __intel_context_retire: 0000:00:02.0 rcs0: context:f51c retire runtime: { total:30004ns, avg:30004ns } <0> [574.307591] i915_sel-6278 0.... 559491372us : __engine_park: __engine_park:261 GEM_BUG_ON(engine->execlists.queue_priority_hint != (-((int)(~0U >> 1)) - 1)) 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/20200227085723.1961649-9-chris@chris-wilson.co.uk
2020-02-28drm/i915/selftests: Be a little more lenient for reset workersChris Wilson
Give the reset worker a kick before losing help when waiting for hang recovery, as the CPU scheduler is a little unreliable. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-15-chris@chris-wilson.co.uk
2020-02-28drm/i915: Add glk to intel_detect_preproduction_hw()Ville Syrjälä
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod since the spec is a bit of a mess but feels more or less correct. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-4-ville.syrjala@linux.intel.com Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2020-02-28drm/i915/selftests: Wait for the context switchChris Wilson
As we require a context switch to ensure that the current context is switched out and saved to memory, perform an explicit switch to the kernel context and wait for it. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1336 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200228082330.2411941-18-chris@chris-wilson.co.uk
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-15 10:48:50 +0000