- 08 Apr, 2021 5 commits
-
-
Lyude Paul authored
Looks like that there actually are another subset of laptops on the market that don't support the Intel HDR backlight interface, but do advertise support for the VESA DPCD backlight interface despite the fact it doesn't seem to work. Note though I'm not entirely clear on this - on one of the machines where this issue was observed, I also noticed that we appeared to be rejecting the VBT defined backlight frequency in intel_dp_aux_vesa_calc_max_backlight(). It's noted in this function that: /* Use highest possible value of Pn for more granularity of brightness * adjustment while satifying the conditions below. * ... * - FxP is within 25% of desired value. * Note: 25% is arbitrary value and may need some tweak. */ So it's possible that this value might just need to be tweaked, but for now let's just disable the VESA backlight interface unless it's specified in the VBT just to be safe. We might be able to try enabling this again by default in the future. Fixes: 2227816e ("drm/i915/dp: Allow forcing specific interfaces through enable_dpcd_backlight") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/3169Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210318170204.513000-1-lyude@redhat.com
-
Jani Nikula authored
Sync up with topic/i915-gem-next and drm-intel-gt-next. Signed-off-by: -
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Features: - Add support for FBs requiring a power-of-two stride padding (Imre) Refactoring: - Disassociate display version from gen (Matt) - Refactor legacy DP and HDMI code to separate files (Ville) - Refactor FB plane code to a separate file (Imre) - Refactor VBT child device info parsing and usage (Jani) - Refactor KBL/TGL/ADL-S display and gt stepping schemes (Jani) Fixes: - DP Link-Training Tunable PHY Repeaters (LTTPR) fixes (Imre) - HDCP fixes (Anshuman) - DP 2.0 HDMI 2.1 PCON Fixed Rate Link (FRL) fixes (Ankit) - Set HDA link parameters in driver (Kai) - Fix enabled_planes bitmask (Ville) - Fix transposed arguments to skl_plane_wm_level() (Ville) - Stop adding planes to the commit needlessly (Ville) Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87v996ml17.fsf@intel.com
-
Dave Airlie authored
Merge tag 'drm-intel-gt-next-2021-04-06' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: - Prepare for local/device memory support on DG1 by starting to use it for kernel internal allocations: context, ring and engine scratch (Matt A, CQ, Abdiel, Imre) - Sandybridge fix to avoid hard hang on ring resume (Chris) - Limit imported dma-buf size to int32 (Matt A) - Double check heartbeat timeout before resetting (Chris) - Use new tasklet API for execution list (Emil) - Fix SPDX checkpats warnings (Chris) - Fixes for various checkpatch warnings (Chris) - Selftest improvements (Chris) - Move the defer_request waiter active assertion to correct spot (Chris) - Make local-memory probing a GT operation (Matt, Tvrtko) - Protect against request freeing during cancellation on wedging (Chris) - Retire unexpected starting state error dumping (Chris) - Distinction of memory regions in debugging (Zbigniew) - Always flush the submission queue on checking for idle (Chris) - Consolidate 2big error check to helper (Matt) - Decrease number of subplatform bits (Tvrtko) - Remove unused internal request priority levels (Chris) - Document the unused internal header bits in buddy allocator (Matt) - Cleanup the region class/instance encoding (Matt) Signed-off-by:
-
Dave Airlie authored
Merge tag 'mediatek-drm-next-5.13' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next Mediatek DRM Next for Linux 5.13 1. Fine tune the line time for EOTp. 2. Add support mt8192 dpi. 3. Make crtc config-updating atomic. 4. Don't support hdmi connector creation. From: Chun-Kuang Hu <chunkuang.hu@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210405082248.3578-1-chunkuang.hu@kernel.orgSigned-off-by:
-
- 07 Apr, 2021 3 commits
-
-
Matt Roper authored
Now that we've eliminated INTEL_GEN(), IS_GEN_RANGE(), etc. from the display code, we should also kill off our use of the IS_GEN9_* macros too. We'll do the conversion manually this time instead of using Coccinelle since the most logical substitution can depend heavily on the code context, and sometimes we can keep the code simpler if we make additional adjustments such as swapping the order of if/else arms. v2: - Restore a lost negation in intel_pll_is_valid(). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210407203945.1432531-1-matthew.d.roper@intel.com
-
Takashi Iwai authored
intel_dsm_platform_mux_info() tries to parse the ACPI package data from _DSM for the debug information, but it assumes the fixed format without checking what values are stored in the elements actually. When an unexpected value is returned from BIOS, it may lead to GPF or NULL dereference, as reported recently. Add the checks of the contents in the returned values and skip the values for invalid cases. v1->v2: Check the info contents before dereferencing, too BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=1184074 Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210402082317.871-1-tiwai@suse.de
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.13: UAPI Changes: Cross-subsystem Changes: Core Changes: - mst: Improve topology logging - edid: Rework and improvements for displayid Driver Changes: - anx7625: Regulators support - bridge: Support for the Chipone ICN6211, Lontium LT8912B - lt9611: Fix 4k panels handling Signed-off-by:
-
- 06 Apr, 2021 1 commit
-
-
Xuezhi Zhang authored
Fix the following coccicheck warning: drivers/gpu/drm/i915//i915_sysfs.c:266:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:285:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:276:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:335:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:390:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:465:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:107:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:75:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:83:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:91:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:99:8-16: WARNING: use scnprintf or sprintf drivers/gpu/drm/i915//i915_sysfs.c:326:8-16: WARNING: use scnprintf or sprintf Signed-off-by:
Xuezhi Zhang <zhangxuezhi1@yulong.com> Signed-off-by:
-
- 02 Apr, 2021 1 commit
-
-
Gwan-gyeong Mun authored
Due to the changed sequence of activating/deactivating DC3CO, disable DC3CO until the changed dc3co activating/deactivating sequence is applied. References: https://gitlab.freedesktop.org/drm/intel/-/issues/3134Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
- 01 Apr, 2021 7 commits
-
-
Imre Deak authored
We need to wait for the DMC FW loader work to complete during shutdown, even if it's unlikely to be still pending by that time, fix this. This also fixes the wakeref tracking WARN during shutdown about the leaked reference we hold due to a missing DMC firmware. While at it add a TODO comment about unifying the shutdown and PM power-off sequences and later these sequences with the driver remove and system/runtime suspend sequences. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> References: https://lore.kernel.org/lkml/20210303055517.GB2708@xsang-OptiPlex-9020Reported-and-tested-by:
kernel test robot <oliver.sang@intel.com> Reported-and-tested-by:
Edward Baker <edward.baker@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Ville Syrjälä authored
According to bspec icl+ no longer need any extra cdclk guardband for 64bpp formats. Make it so. Signed-off-by:
-
Ville Syrjälä authored
Split the glk+ stuff into it's own version of the .min_cdclk() vfunc. Signed-off-by:
-
Dafna Hirschfeld authored
commit f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") broke the display support for elm device since mtk_dpi calls drm_bridge_attach with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR while mtk_hdmi does not yet support this flag. Fix this by accepting DRM_BRIDGE_ATTACH_NO_CONNECTOR in bridge attachment. Implement the drm_bridge_funcs .detect() and .get_edid() operations, and call drm_bridge_hpd_notify() to report HPD. This provides the necessary API to support disabling connector creation. In addition, the field 'conn' is removed from the mtk_hdmi struct since mtk_hdmi don't create a connector. It is replaced with a pointer 'curr_conn' that points to the current connector which can be access through the global state. This patch is inspired by a similar patch for bridge/synopsys/dw-hdmi.c: commit ec971aaa ("drm: bridge: dw-hdmi: Make connector creation optional") But with the difference that in mtk-hdmi only the option of not creating a connector is supported. Fixes: f0119514 ("drm/mediatek: mtk_dpi: Create connector for bridges") Signed-off-by:
Dafna Hirschfeld <dafna.hirschfeld@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Chun-Kuang Hu <chunkuang.hu@kernel.org>
-
Dafna Hirschfeld authored
The bridge operation '.enable' and the audio cb '.get_eld' access hdmi->conn. In the future we will want to support the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR and then we will not have direct access to the connector. The atomic version '.atomic_enable' allows accessing the current connector from the state. This patch switches the bridge to the atomic version to prepare access to the connector in later patches. Signed-off-by:
-
Hsin-Yi Wang authored
When suspending the driver, anx7625_power_standby() will be called to turn off reset-gpios and enable-gpios. However, power supplies are not disabled. To save power, the driver can get the power supply regulators and turn off them in anx7625_power_standby(). Signed-off-by:
Hsin-Yi Wang <hsinyi@chromium.org> Reviewed-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
Xin Ji <xji@analogixsemi.com> Signed-off-by:
-
Hsin-Yi Wang authored
anx7625 requires 3 power supply regulators. Signed-off-by:
Rob Herring <robh@kernel.org> Reviewed-by:
-
- 31 Mar, 2021 16 commits
-
-
Dave Airlie authored
Merge tag 'exynos-drm-next-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next One cleanup - Based on the patch[1], clean up the use of request_irq function series. [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git/commit/?id=cbe16f35bee6880becca6f20d2ebf6b457148552Signed-off-by:
-
ssh://git.freedesktop.org/git/drm/drmDave Airlie authored
special i915-gem-next pull as requested - Conversion to dma_resv_locking, obj->mm.lock is gone (Maarten, with help from Thomas Hellström) - watchdog (Tvrtko, one patch to cancel individual request from Chris) - legacy ioctl cleanup (Jason+Ashutosh) - i915-gem TODO and RFC process doc (me) - i915_ prefix for vma_lookup (Liam Howlett) just because I spotted it and put it in here too Signed-off-by:
-
Imre Deak authored
Fix the Documentation/gpu/i915:22: /drivers/gpu/drm/i915/intel_runtime_pm.c:423: WARNING: Inline strong start-string without end-string. warning from the htmldocs build. Fixes: 9d58aa46 ("drm/i915: Fix the GT fence revocation runtime PM logic") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20210330150118.1105079-1-imre.deak@intel.com
-
Jani Nikula authored
Avoid any confusion with High Dynamic Range. No functional changes. Reviewed-by:
-
Jani Nikula authored
The DisplayID specifications explicitly call out 0 as a valid payload length for data blocks. The mere presence of a data block, or the information coded in the block specific data (bits 7:3 in offset 1), may be enough to convey the necessary information. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. Remove excessive debug logging while at it, no other functional changes. The old displayid iterator becomes unused; remove it as well as make drm_find_displayid_extension() static. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Neatly reduce displayid boilerplate in code. No functional changes. Reviewed-by:
-
Jani Nikula authored
Iterating DisplayID blocks across sections (in EDID extensions) is unnecessarily complicated for the caller. Implement DisplayID iterators to go through all blocks in all sections. Usage example: const struct displayid_block *block; struct displayid_iter iter; displayid_iter_edid_begin(edid, &iter); displayid_iter_for_each(block, &iter) { /* operate on block */ } displayid_iter_end(&iter); When DisplayID is stored in EDID extensions, the DisplayID sections map to extensions as described in VESA DisplayID v1.3 Appendix B: DisplayID as an EDID Extension. This is implemented here. When DisplayID is stored in its dedicated DDC device 0xA4, according to VESA E-DDC v1.3, different rules apply for the structure. This is not implemented here, as we don't currently use it, but the idea is you'd have a different call for beginning the iteration, for example simply: displayid_iter_begin(displayid, &iter); instead of displayid_iter_edid_begin(), and everything else would be hidden away in the iterator functions. v2: - sizeof(struct displayid_block) -> sizeof(*block) (Ville) - remove __ prefix from displayid_iter_block Reviewed-by: -
Jani Nikula authored
We'll be adding more DisplayID specific functions going forward, so start off by splitting out a few functions to a separate file. We don't bother with exporting the functions; at least for now they should be needed solely within drm.ko. No functional changes. Reviewed-by:
-
Jani Nikula authored
If there's no need to change it, it should be const. There's more to be done, but start off with changes that make follow-up work easier. No functional changes. Reviewed-by:
-
Boris Brezillon authored
This patch adds the missing MODULE_DEVICE_TABLE definitions on different Mediatek drivers which generates correct modalias for automatic loading when these drivers are compiled as an external module. Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by:
Enric Balletbo i Serra <enric.balletbo@collabora.com> Reviewed-by:
-
Anshuman Gupta authored
Fix LC_Send_L_Prime message timeout to 16 as documented in DP HDCP 2.2 errata page 3. https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf Cc: Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Acked-by:
Maxime Ripard <mripard@kernel.org> Signed-off-by:
-
Anshuman Gupta authored
As documented in HDCP 2.2 DP Errata spec transmitter should abort the authentication protocol in case transmitter has not received the entire {AKE_Send_Cert, AKE_Send_H_prime, AKE_Send_Paring_Info} msg within {110,7,5} miliseconds. Adding above msg timeout values and aborting the HDCP authentication in case it timedout to read entire msg. https://www.digital-cp.com/sites/default/files/HDCP%202_2_DisplayPort_Errata_v3_0.pdf v2: - Removed redundant variable msg_can_timedout. [Ankit] Cc: Ramalingam C <ramalingam.c@intel.com> Signed-off-by: -
Ankit Nautiyal authored
Add the check if source control mode is supported by the PCON, before starting configuring PCON for FRL training, as per spec VESA DP2.0-HDMI2.1 PCON Draft-1 Sec-7. v2: Added spec details for the change. (Uma) Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
Ankit Nautiyal authored
Currently the FRL training mode (Concurrent, Sequential) and training type (Normal, Extended) are not defined properly and are passed as bool values in drm_helpers for pcon configuration for FRL training. This patch: -Add register masks for Sequential and Normal FRL training options. -Fixes the drm_helpers for FRL Training configuration to use the appropriate masks. -Modifies the calls to the above drm_helpers in i915/intel_dp as per the above change. v2: Re-used the register masks for these options, instead of enum. (Ville) Signed-off-by:
-
- 29 Mar, 2021 7 commits
-
-
Imre Deak authored
Add selftests to test the POT stride padding functionality added in the previous patch. Signed-off-by:
-
Imre Deak authored
An upcoming platform has a restriction that the FB stride must be power-of-two aligned. To support framebuffer layouts that are not in this layout add a logic that pads the tile rows to the POT aligned size. The HW won't read the padding PTEs, so these don't have to point to an allocated address, or even have their valid flag set. So use a NULL PTE instead for instance the scratch page, which is simple and keeps the SG table compact. v2: - Simplify plane_view_dst_stride(). (Ville) - Pass pitch_tiles as unsigned int. v3: - Drop unintentional s/plane_state->rotation/plane_config->rotation/ change. Signed-off-by:
-
Imre Deak authored
An upcoming patch adds a new dst_stride field to the intel_remapped_plane_info struct, so for clarity rename the current stride field to src_stride. Signed-off-by:
-
Imre Deak authored
Always use the modified copy of the intel_remapped_plane_info variables. An upcoming patch updates the dst_stride field in these copies after which we can't use the original versions. v2: Init view in igt_vma_rotate_remap() when declaring it. (Ville) Signed-off-by:
-
Imre Deak authored
Save some place in the GTT VMAs by using a u16 instead of unsigned int to store the view dimensions. The maximum FB stride is 256kB which is 4096 tiles in the worst case (yf-tiles), the maximum FB height is 16k pixels, which is 16384 tiles in the worst case (linear 4x1 tiled FB). v2: - Fix worst case tile height formula in commit log. (Ville) - Add an assign_chk_ovf helper to simplify the related assignments. v3: - Enclose params of the assign_chk_ovf macro in parentheses. Signed-off-by:
-
Imre Deak authored
Factor out to a new function the logic to calculate the FB remapping parameters both during creating the FB and when flipping to it. v2: - Keep stride next to offset calculation. (Ville) - Enclose check_array_bounds macro arguments in parentheses. v3: - Rebase on top of the struct intel_fb_view refactoring. Signed-off-by:
-
Imre Deak authored
Instead of copying separately the GTT remapped and color plane view info from the FB to the plane state, do this by copying the whole intel_fb_view struct. For this we make sure the FB view state is fully inited (that is also including the view type) already during FB creation, so this init is not required during atomic check time. This also means the we don't need to reset the unused color plane info during atomic check, as these are already reset during FB creation. I noticed that initial FBs will only work atm if they are page aligned (which BIOS most probably always ensures), but add a comment to sanitize this part once. Also we won't disable the plane if get_initial_plane_config() failed for some reason (for instance due to unsupported rotation), add a TODO: comment for this too. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
