summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-03-03drm/i915/gem: Check that the context wasn't closed during setupChris Wilson
As setup takes a long time, the user may close the context during the construction of the execbuf. In order to make sure we correctly track all outstanding work with non-persistent contexts, we need to serialise the submission with the context closure and mop up any leaks. 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/20200303080546.1140508-3-chris@chris-wilson.co.uk
2020-03-03drm/i915/gt: Prevent allocation on a banned contextChris Wilson
If a context is banned even before we submit our first request to it, report the failure before we attempt to allocate any resources for the context. 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/20200303080546.1140508-2-chris@chris-wilson.co.uk
2020-03-03drm/i915/gem: Consolidate ctx->engines[] releaseChris Wilson
Use the same engine_idle_release() routine for cleaning all old ctx->engine[] state, closing any potential races with concurrent execbuf submission. v2ish: Use the ce->pin_count to close the execbuf gap. Closes: https://gitlab.freedesktop.org/drm/intel/issues/1241 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200303080546.1140508-1-chris@chris-wilson.co.uk
2020-03-03drm/i915: Polish CHV .load_luts() a bitVille Syrjälä
It irks me to use crtc_state_is_legacy_gamma() inside the guts of the CHV color management code. Let's get rid of it and instead just consult cgm_mode to figure out if we want to enable the pipe gamma or the CGM gamma. Also CHV display engine is based on i965/g4x so we should fall back to the i965 path when the CGM gamma is not used. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-3-ville.syrjala@linux.intel.com Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
2020-03-03drm/i915/gvt: only include intel_gvt.h where neededJani Nikula
i915_drv.c is the only caller. 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-3-jani.nikula@intel.com
2020-03-03drm/i915/gvt: make intel_gvt_active internal to intel_gvtJani Nikula
Nobody else uses it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20200227144408.24345-2-jani.nikula@intel.com
2020-03-03drm/i915/vgpu: improve vgpu abstractionsJani Nikula
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
2020-03-03drm/i915: Fix kbuild test robot build errorAnshuman Gupta
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: d54c1a513c48 ("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: Jani Nikula <jani.nikula@intel.com> Signed-off-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
2020-03-03drm/i915/hdcp: conversion to struct drm_device based logging macros.Ramalingam C
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 65833c463886 ("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
2020-03-03drm/i915: move watermark structs more towards usageJani Nikula
Shrink i915_drv.h a bit by moving watermark structs where they are needed. 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-3-jani.nikula@intel.com
2020-03-03drm/i915: Fix doclinksChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302145254.520447-1-chris@chris-wilson.co.uk
2020-03-03drm/i915/dmc: Use firmware v2.06 for TGLJosé Roberto de Souza
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 <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200227235005.18706-1-jose.souza@intel.com
2020-03-03drm/i915: fix documentation build after renameJani Nikula
intel_csr.c was moved under display. Fixes: 06d3ff6e7451 ("drm/i915: move intel_csr.[ch] under display/") Reported-by: 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/20200302170218.16496-1-jani.nikula@intel.com
2020-03-02drm/i915/huc: update TGL HuC to v7.0.12Daniele Ceraolo Spurio
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: José Roberto de Souza <jose.souza@intel.com> Acked-by: Tony Ye <tony.ye@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200229012042.27487-1-daniele.ceraolospurio@intel.com
2020-03-02drm/i915/execlists: Check the sentinel is alone in the ELSPChris Wilson
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200302085812.4172450-12-chris@chris-wilson.co.uk
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
generated by cgit (git 2.34.1) at 2025-05-30 10:27:37 +0000