aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2022-01-25drm/amdgpu: filter out radeon secondary ids as wellAlex Deucher1-0/+81
Older radeon boards (r2xx-r5xx) had secondary PCI functions which we solely there for supporting multi-head on OSs with special requirements. Add them to the unsupported list as well so we don't attempt to bind to them. The driver would fail to bind to them anyway, but this does so in a cleaner way that should not confuse the user. Cc: stable@vger.kernel.org Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: change FIFO reset condition to embedded display onlyZhan Liu1-1/+1
[Why] FIFO reset is only necessary for fast boot sequence, where otg is disabled and dig fe is enabled when changing dispclk. Fast boot is only enabled on embedded displays. [How] Change FIFO reset condition to "embedded display only". Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Correct MPC split policy for DCN301Zhan Liu1-1/+1
[Why] DCN301 has seamless boot enabled. With MPC split enabled at the same time, system will hang. [How] Revert MPC split policy back to "MPC_SPLIT_AVOID". Since we have ODM combine enabled on DCN301, pipe split is not necessary here. Signed-off-by: Zhan Liu <zhan.liu@amd.com> Reviewed-by: Charlene Liu <charlene.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/amd/display: Fix for otg synchronization logicMeenakshikumar Somasundaram7-13/+105
[Why] During otg sync trigger, plane states are used to decide whether the otg is already synchronized or not. There are scenarions when otgs are disabled without plane state getting disabled and in such case the otg is excluded from synchronization. [How] Introduced pipe_idx_syncd in pipe_ctx that tracks each otgs master pipe. When a otg is disabled/enabled, pipe_idx_syncd is reset to itself. On sync trigger, pipe_idx_syncd is checked to decide whether a otg is already synchronized and the otg is further included or excluded from synchronization. v2: Don't drop is_blanked logic Reviewed-by: Jun Lei <Jun.Lei@amd.com> Reviewed-by: Mustapha Ghaddar <mustapha.ghaddar@amd.com> Acked-by: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Signed-off-by: meenakshikumar somasundaram <meenakshikumar.somasundaram@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Harry Wentland <harry.wentland@amd.com> Cc: torvalds@linux-foundation.org Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2022-01-25drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correctMatthew Brost1-6/+27
Realized that the GuC multi-lrc fini breadcrumb emit code is very delicate as the math this code does relies on functions it calls to emit a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is correct. v2: - Rebase + resend for CI (Checkpatch) - Fix blank line warning Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119210639.33053-1-matthew.brost@intel.com
2022-01-25drm/i915: Flush TLBs before releasing backing storeTvrtko Ursulin9-4/+161
We need to flush TLBs before releasing backing store otherwise userspace is able to encounter stale entries if a) it is not declaring access to certain buffers and b) it races with the backing store release from a such undeclared execution already executing on the GPU in parallel. The approach taken is to mark any buffer objects which were ever bound to the GPU and to trigger a serialized TLB flush when their backing store is released. Alternatively the flushing could be done on VMA unbind, at which point we would be able to ascertain whether there is potential a parallel GPU execution (which could race), but essentially it boils down to paying the cost of TLB flushes potentially needlessly at VMA unbind time (when the backing store is not known to be going away so not needed for safety), versus potentially needlessly at backing store relase time (since we at that point cannot tell whether there is anything executing on the GPU which uses that object). Thereforce simplicity of implementation has been chosen for now with scope to benchmark and refine later as required. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by: Dave Airlie <airlied@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-25drm/etnaviv: relax submit size limitsLucas Stach1-2/+2
While all userspace tried to limit commandstreams to 64K in size, a bug in the Mesa driver lead to command streams of up to 128K being submitted. Allow those to avoid breaking existing userspace. Fixes: 6dfa2fab8ddd ("drm/etnaviv: limit submit sizes") Cc: stable@vger.kernel.org Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com>
2022-01-25drm/msm/gpu: Cancel idle/boost work on suspendRob Clark1-2/+19
With system suspend using pm_runtime_force_suspend() we can't rely on the pm_runtime_get_if_in_use() trick to deal with devfreq callbacks after (or racing with) suspend. So flush any pending idle or boost work in the suspend path. Signed-off-by: Rob Clark <robdclark@chromium.org> Link: https://lore.kernel.org/r/20220108180913.814448-3-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-01-25drm/msm/gpu: Wait for idle before suspendingRob Clark3-0/+24
System suspend uses pm_runtime_force_suspend(), which cheekily bypasses the runpm reference counts. This doesn't actually work so well when the GPU is active. So add a reasonable delay waiting for the GPU to become idle. Alternatively we could just return -EBUSY in this case, but that has the disadvantage of causing system suspend to fail. v2: s/ret/remaining [sboyd], and switch to using active_submits count to ensure we aren't racing with submit cleanup (and devfreq idle work getting scheduled, etc) v3: fix inverted logic Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20220108180913.814448-2-robdclark@gmail.com Signed-off-by: Rob Clark <robdclark@chromium.org>
2022-01-25drm/edid: Support type 7 timingsYaroslav Bolyukin1-4/+8
Per VESA DisplayID Standard v2.0: Type VII Timing – Detailed Timing Data Definitions were already provided as type I, but not used Signed-off-by: Yaroslav Bolyukin <iam@lach.pw> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220123191955.57994-1-iam@lach.pw
2022-01-25drm/vc4: hdmi: Change CSC callback prototypeMaxime Ripard2-1/+7
In order to support the YUV output, we'll need the atomic state to know what is the state of the associated property in the CSC setup callback. Let's change the prototype of that callback to allow us to access it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-11-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Define colorspace matricesMaxime Ripard1-29/+49
The current CSC setup code for the BCM2711 uses a sequence of register writes to configure the CSC depending on whether we output using a full or limited range. However, with the upcoming introduction of the YUV output, we're going to add new matrices to perform the conversions, so we should switch to something a bit more flexible that takes the matrix as an argument and programs the CSC accordingly. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-10-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Replace CSC_CTL hardcoded value by definesMaxime Ripard2-3/+5
On BCM2711, the HDMI_CSC_CTL register value has been hardcoded to an opaque value. Let's replace it with properly defined values. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-9-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Move XBAR setup to csc_setupMaxime Ripard1-1/+2
On the BCM2711, the HDMI_VEC_INTERFACE_XBAR register configuration depends on whether we're using an RGB or YUV output. Let's move that configuration to the CSC setup. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-8-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Use full range helper in csc functionsMaxime Ripard2-22/+13
The CSC callbacks takes a boolean as an argument to tell whether we're using the full range or limited range RGB. However, with the upcoming YUV support, the logic will be a bit more complex. In order to address this, let's make the callbacks take the entire mode, and call our new helper to tell whether the full or limited range RGB should be used. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-7-maxime@cerno.tech
2022-01-25drm/vc4: hdmi: Add full range RGB helperMaxime Ripard1-2/+10
We're going to need to tell whether we want to run with a full or limited range RGB output in multiple places in the code, so let's create a helper that will return whether we need with full range or not. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-6-maxime@cerno.tech
2022-01-25drm/connector: Fix typo in output formatMaxime Ripard8-36/+36
The HDMI specification mentions YCbCr everywhere, but our enums have YCrCb. Let's rename it to match. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-5-maxime@cerno.tech
2022-01-25drm/edid: Split deep color modes between RGB and YUV444Maxime Ripard4-7/+8
The current code assumes that the RGB444 and YUV444 formats are the same, but the HDMI 2.0 specification states that: The three DC_XXbit bits above only indicate support for RGB 4:4:4 at that pixel size. Support for YCBCR 4:4:4 in Deep Color modes is indicated with the DC_Y444 bit. If DC_Y444 is set, then YCBCR 4:4:4 is supported for all modes indicated by the DC_XXbit flags. So if we have YUV444 support and any DC_XXbit flag set but the DC_Y444 flag isn't, we'll assume that we support that deep colour mode for YUV444 which breaks the specification. In order to fix this, let's split the edid_hdmi_dc_modes field in struct drm_display_info into two fields, one for RGB444 and one for YUV444. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-4-maxime@cerno.tech
2022-01-25drm/edid: Don't clear formats if using deep colorMaxime Ripard1-8/+0
The current code, when parsing the EDID Deep Color depths, that the YUV422 cannot be used, referring to the HDMI 1.3 Specification. This specification, in its section 6.2.4, indeed states: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is not permitted for any Deep Color mode. This indeed can be interpreted like the code does, but the HDMI 1.4 specification further clarifies that statement in its section 6.2.4: For each supported Deep Color mode, RGB 4:4:4 shall be supported and optionally YCBCR 4:4:4 may be supported. YCBCR 4:2:2 is also 36-bit mode but does not require the further use of the Deep Color modes described in section 6.5.2 and 6.5.3. This means that, even though YUV422 can be used with 12 bit per color, it shouldn't be treated as a deep color mode. This is also broken with YUV444 if it's supported by the display, but DRM_EDID_HDMI_DC_Y444 isn't set. In such a case, the code will clear color_formats of the YUV444 support set previously in drm_parse_cea_ext(), but will not set it back. Since the formats supported are already setup properly in drm_parse_cea_ext(), let's just remove the code modifying the formats in drm_parse_hdmi_deep_color_info() Fixes: d0c94692e0a3 ("drm/edid: Parse and handle HDMI deep color modes.") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-3-maxime@cerno.tech
2022-01-25drm/edid: Rename drm_hdmi_avi_infoframe_colorspace to _colorimetryMaxime Ripard4-7/+7
The drm_hdmi_avi_infoframe_colorspace() function actually sets the colorimetry and extended_colorimetry fields in the hdmi_avi_infoframe structure with DRM_MODE_COLORIMETRY_* values. To make things worse, the hdmi_avi_infoframe structure also has a colorspace field used to signal whether an RGB or YUV output is being used. Let's remove the inconsistency and allow for the colorspace usage by renaming the function. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220120151625.594595-2-maxime@cerno.tech
2022-01-25drm/docs: Document where the C8 color lut is storedDaniel Vetter1-0/+4
Also add notes that for atomic drivers it's really somewhere else and no longer in struct drm_crtc. Maybe we should put a bigger warning here that this is confusing, since the pixel format is a plane property, but the GAMMA_LUT property is on the crtc. But I think we can fix this if/when someone finds a need for a per-plane CLUT, since I'm not sure such hw even exists. I'm also not sure whether even hardware with a CLUT and a full color correction pipeline with degamm/cgm/gamma exists. Motivated by comments from Geert that we have a gap here. v2: More names for color luts (Laurent). Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124221633.952374-1-daniel.vetter@ffwll.ch
2022-01-24drm/atomic: Add the crtc to affected crtc only if uapi.enable = trueManasi Navare1-4/+8
In case of a modeset where a mode gets split across multiple CRTCs in the driver specific implementation (bigjoiner in i915) we wrongly count the affected CRTCs based on the drm_crtc_mask and indicate the stolen CRTC as an affected CRTC in atomic_check_only(). This triggers a warning since affected CRTCs doent match requested CRTC. To fix this in such bigjoiner configurations, we should only increment affected crtcs if that CRTC is enabled in UAPI not if it is just used internally in the driver to split the mode. v3: Add the same uapi crtc_state->enable check in requested crtc calc (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Simon Ser <contact@emersion.fr> Cc: Pekka Paalanen <pekka.paalanen@collabora.co.uk> Cc: Daniel Stone <daniels@collabora.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.11+ Fixes: 919c2299a893 ("drm/i915: Enable bigjoiner") Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211004115913.23889-1-manasi.d.navare@intel.com
2022-01-25drm/i915/overlay: Prevent divide by zero bugs in scalingDan Carpenter1-0/+3
Smatch detected a divide by zero bug in check_overlay_scaling(). drivers/gpu/drm/i915/display/intel_overlay.c:976 check_overlay_scaling() error: potential divide by zero bug '/ rec->dst_height'. drivers/gpu/drm/i915/display/intel_overlay.c:980 check_overlay_scaling() error: potential divide by zero bug '/ rec->dst_width'. Prevent this by ensuring that the dst height and width are non-zero. Fixes: 02e792fbaadb ("drm/i915: implement drmmode overlay support v4") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124122409.GA31673@kili
2022-01-25drm/msm/dsi: invalid parameter check in msm_dsi_phy_enableJosé Expósito1-1/+3
The function performs a check on the "phy" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 5c8290284402b ("drm/msm/dsi: Split PHY drivers to separate files") Addresses-Coverity-ID: 1493860 ("Null pointer dereference") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220116181844.7400-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm/a6xx: Add missing suspend_count incrementRob Clark1-0/+2
Reported-by: Danylo Piliaiev <dpiliaiev@igalia.com> Fixes: 3ab1c5cc3939 ("drm/msm: Add param for userspace to query suspend count") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220113163215.215367-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm: Fix wrong size calculationXianting Tian1-1/+1
For example, memory-region in .dts as below, reg = <0x0 0x50000000 0x0 0x20000000> We can get below values, struct resource r; r.start = 0x50000000; r.end = 0x6fffffff; So the size should be: size = r.end - r.start + 1 = 0x20000000 Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com> Fixes: 072f1f9168ed ("drm/msm: add support for "stolen" mem") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220112123334.749776-1-xianting.tian@linux.alibaba.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pccJosé Expósito1-2/+9
The function performs a check on the "ctx" input parameter, however, it is used before the check. Initialize the "base" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: 4259ff7ae509e ("drm/msm/dpu: add support for pcc color block in dpu driver") Addresses-Coverity-ID: 1493866 ("Null pointer dereference") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20220109192431.135949-1-jose.exposito89@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm/hdmi: Fix missing put_device() call in msm_hdmi_get_phyMiaoqian Lin1-1/+6
The reference taken by 'of_find_device_by_node()' must be released when not needed anymore. Add the corresponding 'put_device()' in the error handling path. Fixes: e00012b256d4 ("drm/msm/hdmi: Make HDMI core get its PHY") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20220107085026.23831-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm/dsi: Fix missing put_device() call in dsi_get_phyMiaoqian Lin1-1/+6
If of_find_device_by_node() succeeds, dsi_get_phy() doesn't a corresponding put_device(). Thus add put_device() to fix the exception handling. Fixes: ec31abf ("drm/msm/dsi: Separate PHY to another platform device") Signed-off-by: Miaoqian Lin <linmq006@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211230070943.18116-1-linmq006@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-25drm/msm: remove variable set but not usedYang Li1-3/+0
The code that uses variable mdss has been removed, So the declaration and assignment of the variable can be removed. Eliminate the following clang warning: drivers/gpu/drm/msm/msm_drv.c:513:19: warning: variable 'mdss' set but not used [-Wunused-but-set-variable] Reported-by: Abaci Robot <abaci@linux.alibaba.com> Fixes: 2027e5b3413d ("drm/msm: Initialize MDSS irq domain at probe time") Signed-off-by: Yang Li <yang.lee@linux.alibaba.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20211216031103.34146-1-yang.lee@linux.alibaba.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2022-01-24drm/i915/dg2: Add Wa_18018781329Matt Roper2-0/+10
A few more MOD registers need to be programmed on DG2. Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120234147.1200574-1-matthew.d.roper@intel.com Reviewed-by: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
2022-01-24drm/gma: Remove calls to kmap()Ira Weiny2-8/+6
kmap() is being deprecated and these instances are easy to convert to kmap_local_page(). Furthermore, in gma_crtc_cursor_set() use the memcpy_from_page() helper instead of an open coded use of kmap_local_page(). Signed-off-by: Ira Weiny <ira.weiny@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220124015409.807587-4-ira.weiny@intel.com
2022-01-24drm/edid: improve non-desktop quirk loggingJani Nikula1-7/+10
Improve non-desktop quirk logging if the EDID indicates non-desktop. If both are set, note about redundant quirk. If there's no quirk but the EDID indicates non-desktop, don't log non-desktop is set to 0. Cc: Philipp Zabel <philipp.zabel@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Philipp Zabel <philipp.zabel@gmail.com> Tested-by: Philipp Zabel <philipp.zabel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211228101051.317989-1-jani.nikula@intel.com
2022-01-24drm/edid: remove non_desktop quirk for HPN-3515 and LEN-B800.Philipp Zabel1-2/+0
Now that there is support for the Microsoft VSDB for HMDs, remove the non-desktop quirk for two devices that are verified to contain it in their EDID: HPN-3515 and LEN-B800. Presumably most of the other Windows Mixed Reality headsets contain it as well, but there are ACR-7FCE and SEC-5194 devices without it. Tested with LEN-B800. Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220123101653.147333-2-philipp.zabel@gmail.com
2022-01-24drm/edid: support Microsoft extension for HMDs and specialized monitorsPhilipp Zabel1-0/+34
Add minimal support for parsing VSDBs documented in Microsoft's "EDID extension for head-mounted and specialized monitors" [1]. The version field and the desktop usage flag can be used to set the non_desktop connector property. [1] https://docs.microsoft.com/en-us/windows-hardware/drivers/display/specialized-monitors-edid-extension Tested with HPN-36C1 and LEN-B800. Signed-off-by: Philipp Zabel <philipp.zabel@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220123101653.147333-1-philipp.zabel@gmail.com
2022-01-24drm/i915/cdclk: convert to drm device based loggingJani Nikula1-1/+1
Prefer drm device based logging. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0074a45193873aea0becdf7cc87c0f06754ab706.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/cdclk: update intel_dump_cdclk_config() loggingJani Nikula4-13/+15
Gather some intel_dump_cdclk_config() changes together to avoid extra churn: Rename to intel_cdclk_dump_config() to following naming conventions. Pass in i915. Use i915 for struct drm_device based logging. Switch to KMS drm debug class. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/80469a83a74912ad69c4518d9cc68f07d65e9aaf.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/lspcon: convert to drm device based loggingJani Nikula1-67/+77
Prefer drm device based logging. Do some related dev_priv->i915 and dp->intel_dp renames while at it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/8f83a4de60be1a4a964aa4334204db95d2db3689.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/sprite: convert to drm device based loggingJani Nikula1-11/+13
Prefer drm device based logging. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/f2a3b656c8c63bc9474b5d9cb5b5c018cde28546.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/plane: convert to drm device based logging and WARNJani Nikula2-6/+9
Prefer drm device based logging and WARN. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/9742b56ee0935a6b833f108ca8f72a29935853df.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/dp: convert to drm device based loggingJani Nikula1-15/+20
Prefer drm device based logging. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/b1cffaa70fcc614574f2dce4461e28be7a407e30.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/hotplug: convert to drm device based loggingJani Nikula1-7/+7
Prefer drm device based logging. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/a8276434c0a899009be05cb987fdbf80d25fd175.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/pps: convert to drm device based loggingJani Nikula1-9/+13
Prefer drm device based logging. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/3caf86f20680478763321e8e3a5fbfa30ab06ec3.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915/snps: convert to drm device based loggingJani Nikula1-14/+15
Prefer drm device based logging. Do some dev_priv->i915 conversions while at it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/ca6908452a63bd74a9c9d75ecd295182c80c7205.1642769982.git.jani.nikula@intel.com
2022-01-24drm/i915: nuke local versions of WARN_ON/WARN_ON_ONCEJani Nikula1-15/+0
In general, we should avoid redefining kernel macros like this. It can get confusing, and what gets used will depend on whether the header is included or not. Moreover, we should prefer drm_WARN_ON() and drm_WARN_ON_ONCE() anyway, which include the stringified error condition in the message. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220121132957.3778555-1-jani.nikula@intel.com
2022-01-24drm/i915: fix header file inclusion for might_alloc()Andi Shyti1-1/+1
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion as the first is not required, while the second, if not included, prodouces the following error: drivers/gpu/drm/i915/i915_vma_resource.c: In function ‘i915_vma_resource_bind_dep_await’: drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of function ‘might_alloc’; did you mean ‘might_lock’? [-Werror=implicit-function-declaration] 381 | might_alloc(gfp); | ^~~~~~~~~~~ | might_lock Fixes: 2f6b90da9192 ("drm/i915: Use vma resources for async unbinding") Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124094418.2661-1-andi.shyti@linux.intel.com
2022-01-24drm/amdgpu: use ttm_resource_manager_debugChristian König1-5/+5
Instead of calling the debug operation directly. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124124430.20859-10-christian.koenig@amd.com
2022-01-24drm/radeon: use ttm_resource_manager_debugChristian König1-2/+2
Instead of calling the debug operation directly. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211124124430.20859-8-christian.koenig@amd.com
2022-01-24drm/i915: Nuke dg2_ddi_pre_enable_dp()Ville Syrjälä1-113/+4
dg2_ddi_pre_enable_dp() has outlived its usefulness so eliminate it. The one thing that tgl_ddi_pre_enable_dp() is missing that we need is intel_ddi_config_transcoder_dp2(). So we'll bring that over. tgl_ddi_pre_enable_dp() does also have a few things that dg2_ddi_pre_enable_dp() didn't have: - icl_program_mg_dp_mode() -> nop due to intel_phy_is_tc()==false on DG2 - intel_ddi_power_up_lanes() -> nop due to intel_phy_is_combo()==false on DG2 - intel_ddi_mso_configure() -> only matters for MSO panels Another slight difference is that dg2_ddi_pre_enable_dp() was missing a bigjoiner check around intel_dsc_enable(), which tgl_ddi_pre_enable_dp() does have. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119122150.12941-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2022-01-24drm/i915/hdmi: Clean up TMDS clock limit exceeding user mode handlingVille Syrjälä3-47/+62
Currently we just use all the hdmi_deep_color_possible() stuff to compute whether deep color is possible, and leave the 8bpc case to do its own thing. That doesn't mesh super well with 4:2:0 handling because we might end up going for 8bpc RGB without considering that it's essentially illegal and we could instead go for a legal 4:2:0 config. So let's run through all the clock checks even for 8bpc first. If we've fully exhausted all options only then do we re-run the computation for 8bpc while ignoring the downstream TMDS clock limits. This will guarantee that if there's a config that respects all limits we will find it, and if there is not we still allow the user to override the mode manually. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211015133921.4609-7-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Copyright © 1996 – 2026 Jason A. Donenfeld. All Rights Reverse Engineered.