- 03 Mar, 2020 8 commits
-
-
Jani Nikula authored
Add intel_vgpu_register() abstraction, rename i915_detect_vgpu() to intel_vgpu_detect() to match other function naming, un-inline intel_vgpu_active(), intel_vgpu_has_full_ppgtt() and intel_vgpu_has_huge_gtt() to reduce header interdependencies. The i915_vgpu.[ch] filename and intel_vgpu_ prefix discrepancy remains. Cc: Chris Wilson <chris@chris-wilson.co.uk> 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/20200227144408.24345-1-jani.nikula@intel.com
-
Anshuman Gupta authored
has_transcoder() was unused because function which was using it, intel_display_capture_error_state() defined under CONFIG_DRM_I915_CAPTURE_ERROR. Moving has_transcoder() to under CONFIG_DRM_I915_CAPTURE_ERROR. No functional change. Fixes: d54c1a51 ("drm/i915: Fix broken transcoder err state") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
kbuild test robot <lkp@intel.com> Reviewed-by:
Anshuman Gupta <anshuman.gupta@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227175147.11362-1-anshuman.gupta@intel.com
-
Ramalingam C authored
Converts remaining instances of the printk based logging macros in i915/display/intel_hdcp.c with the struct drm_device based macros manually. This is continuation of commit 65833c46 ("drm/i915/hdcp: conversion to struct drm_device based logging macros.") v2: i915_dev_priv is used instead of drm_device for reusability [JaniN] v3: Made it independent from the series. once instance of dev_priv naming is changed to i915 [Jani N] Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200212123007.6659-1-ramalingam.c@intel.com
-
Jani Nikula authored
Shrink i915_drv.h a bit by moving watermark structs where they are needed. Reviewed-by:
-
Chris Wilson authored
Update locations for ./drivers/gpu/drm/i915/i915_vma.h:1: warning: 'Virtual Memory Address' not found ./drivers/gpu/drm/i915/i915_gem_gtt.c:1: warning: 'Global GTT views' not found Signed-off-by:
-
José Roberto de Souza authored
New firmware contains minor fixes around context restore. Reviewed-by:
Swati Sharma <swati2.sharma@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jani Nikula authored
intel_csr.c was moved under display. Fixes: 06d3ff6e ("drm/i915: move intel_csr.[ch] under display/") Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniele Ceraolo Spurio authored
Update to the latest available TGL HuC, which includes changes required by the media team. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tony Ye <tony.ye@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200229012042.27487-1-daniele.ceraolospurio@intel.com
-
- 02 Mar, 2020 32 commits
-
-
Chris Wilson authored
We only use sentinel requests for "preempt-to-idle" passes, so assert that they are the only request in a new submission. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-12-chris@chris-wilson.co.uk
-
Chris Wilson authored
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: 15d0ace1 ("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:
-
José Roberto de Souza authored
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 authored
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:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227220101.321671-8-jose.souza@intel.com
-
José Roberto de Souza authored
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 authored
This issue workaround in Wa_1607063988 has the same fix as Wa_1607138336, so just adding a note in the code. Reviewed-by:
-
José Roberto de Souza authored
Add note about the confliting information in BSpec about this WA. BSpec: 52890 Acked-by:
-
Anusha Srivatsa authored
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: 3873fd1a ("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:
-
Matt Atwood authored
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 Atwood <matthew.s.atwood@intel.com> Signed-off-by:
-
José Roberto de Souza authored
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 authored
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:
-
Imre Deak authored
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:
-
Imre Deak authored
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 authored
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 authored
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 authored
For consistency with the WRPLL/LCPLL parameter calculation functions, split out the SPLL specific logic to its own function. Signed-off-by:
-
Imre Deak authored
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 authored
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 authored
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 authored
Instead of converting DPLL ID to CLK_SEL to identify the DPLL use the DPLL ID directly for this. Signed-off-by:
-
Imre Deak authored
Move the per-platform DPLL and DPLL-manager vfunc initializations right after the corresponding function definitions. Signed-off-by:
-
Imre Deak authored
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 authored
Move the HW readout/sanitize functions to intel_dpll_mgr.c which contains the rest of shared DPLL functionality. Signed-off-by:
-
Imre Deak authored
Fix an off-by-one error in the upper-bound check and while at it clear up a bit the function. Signed-off-by:
-
Stanislav Lisovskiy authored
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ä authored
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ä authored
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ä authored
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ä authored
Switch to the preferred 'crtc' name for our crtc variables. Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Ville Syrjälä authored
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: -
Hans de Goede authored
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:
-
Hans de Goede authored
Commit 82daca29 ("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:
-
