aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2023-10-13Merge tag 'drm-misc-fixes-2023-10-12' of ↵Dave Airlie16-61/+89
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes Short summary of fixes pull: * atomic-helper: Relax checks for unregistered connectors * dma-buf: Work around race condition when retrieving fence timestamp * gem: Avoid OOB access in BO memory range * panel: * boe-tv101wun-ml6: Fix flickering * simpledrm: Fix error output * vwmgfx: * Fix size calculation in texture-state code * Ref GEM BOs in surfaces Signed-off-by: Dave Airlie <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20231012111638.GA25037@linux-uq9g
2023-10-12drm/nouveau/disp: fix DP capable DSM connectorsKarol Herbst1-1/+13
Just special case DP DSM connectors until we properly figure out how to deal with this. This resolves user regressions on GPUs with such connectors without reverting the original fix. Cc: Lyude Paul <[email protected]> Cc: [email protected] # 6.4+ Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/255 Fixes: 2b5d1c29f6c4 ("drm/nouveau/disp: PIOR DP uses GPIO for HPD, not PMGR AUX interrupts") Signed-off-by: Karol Herbst <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/panel: Move AUX B116XW03 out of panel-edp back to panel-simpleDouglas Anderson2-29/+35
In commit 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") I moved a pile of panels out of panel-simple driver into the newly created panel-edp driver. One of those panels, however, shouldn't have been moved. As is clear from commit e35e305eff0f ("drm/panel: simple: Add AUO B116XW03 panel support"), AUX B116XW03 is an LVDS panel. It's used in exynos5250-snow and exynos5420-peach-pit where it's clear that the panel is hooked up with LVDS. Furthermore, searching for datasheets I found one that makes it clear that this panel is LVDS. As far as I can tell, I got confused because in commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Jitao Shi added "DRM_MODE_CONNECTOR_eDP". That seems wrong. Looking at the downstream ChromeOS trees, it seems like some Mediatek boards are using a panel that they call "auo,b116xw03" that's an eDP panel. The best I can guess is that they actually have a different panel that has similar timing. If so then the proper panel should be used or they should switch to the generic "edp-panel" compatible. When moving this back to panel-edp, I wasn't sure what to use for .bus_flags and .bus_format and whether to add the extra "enable" delay from commit 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on"). I've added formats/flags/delays based on my (inexpert) analysis of the datasheet. These are untested. NOTE: if/when this is backported to stable, we might run into some trouble. Specifically, before 474c162878ba ("arm64: dts: mt8183: jacuzzi: Move panel under aux-bus") this panel was used by "mt8183-kukui-jacuzzi", which assumed it was an eDP panel. I don't know what to suggest for that other than someone making up a bogus panel for jacuzzi that's just for the stable channel. Fixes: 88d3457ceb82 ("drm/panel: auo,b116xw03: fix flash backlight when power on") Fixes: 5f04e7ce392d ("drm/panel-edp: Split eDP panels out of panel-simple") Tested-by: Anton Bambura <[email protected]> Acked-by: Hsin-Yi Wang <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230925150010.1.Iff672233861bcc4cf25a7ad0a81308adc3bda8a4@changeid
2023-10-12drm/bridge: ti-sn65dsi86: Associate DSI device lifetime with auxiliary deviceStephen Boyd1-7/+7
The kernel produces a warning splat and the DSI device fails to register in this driver if the i2c driver probes, populates child auxiliary devices, and then somewhere in ti_sn_bridge_probe() a function call returns -EPROBE_DEFER. When the auxiliary driver probe defers, the dsi device created by devm_mipi_dsi_device_register_full() is left registered because the devm managed device used to manage the lifetime of the DSI device is the parent i2c device, not the auxiliary device that is being probed. Associate the DSI device created and managed by this driver to the lifetime of the auxiliary device, not the i2c device, so that the DSI device is removed when the auxiliary driver unbinds. Similarly change the device pointer used for dev_err_probe() so the deferred probe errors are associated with the auxiliary device instead of the parent i2c device so we can narrow down future problems faster. Cc: Douglas Anderson <[email protected]> Cc: Maxime Ripard <[email protected]> Fixes: c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our DSI device at probe") Signed-off-by: Stephen Boyd <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/dsi: Add some debug logging to mipi_exec_i2c (v2)Hans de Goede1-0/+3
Add some debug logging to mipi_exec_i2c, to make debugging various issues seen with it easier. Changes in v2: - Drop unnecessary __func__ drm_dbg_kms() argument Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for backlight control issues on Lenovo Yoga ↵Hans de Goede1-0/+34
Tab 3 (v2) On the Lenovo Yoga Tab 3 Pro YT3-X90F there are 2 issues with the backlight on/off MIPI sequences: 1. The backlight on sequence has an I2C MIPI sequence element which uses bus 0, but there is a bogus I2cSerialBus resource under the GPU in the DSDT which causes i2c_acpi_find_adapter() to pick the wrong bus. 2. There is no backlight off sequence, causing the backlight to stay on. Add a DMI quirk fixing both issues. v2: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9380 Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for wrong I2C bus and panel size on Lenovo ↵Hans de Goede1-0/+52
Yoga Tablet 2 series (v3) On the Lenovo Yoga Tablet 2 830 / 1050 there are 2 problems: 1. The I2C MIPI sequence elements reference bus 3. ACPI has I2C1 - I2C7 which under Linux become bus 0 - 6. And the MIPI sequence reference to bus 3 is indented for I2C3 which is bus 2 under Linux. This leads to errors like these: [ 178.244049] i2c_designware 80860F41:03: controller timed out [ 178.245703] i915 0000:00:02.0: [drm] *ERROR* Failed to xfer payload of size (1) to reg (169) There are 3 timeouts when the panel is on, delaying waking up the screen on a key press by 3 seconds. Note mipi_exec_i2c() cannot just subtract 1 from the bus given in the I2C MIPI sequence element. Since on other devices the I2C bus-numbers used in the MIPI sequences do actually start at 0. 2. width_/height_mm contain a bogus 192mm x 120mm size. This is especially a problem on the 8" 830 version which uses a 10:16 portrait screen where as the bogus size is 16:10. Add a DMI quirk to override the I2C bus and the panel size with the correct values. Note both the 10" 1050 models as well as the 8" 830 models use the same mainboard and thus the same DMI strings. The 10" 1050 uses a 1920x1200 landscape screen, where as the 8" 830 uses a 1200x1920 portrait screen, so the quirk handling uses the display resolution to detect the model. v2: - Also override i2c_bus_num to fix mipi_exec_i2c() timeouts v3: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9379 Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/vlv_dsi: Add DMI quirk for wrong panel modeline in BIOS on Asus ↵Hans de Goede1-0/+44
TF103C (v3) Vtotal is wrong in the BIOS supplied modeline for the DSI panel on the Asus TF103C leading to the last line of the display being shown as the first line. Original: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 820 0x8 0xa Fixed: "1280x800": 60 67700 1280 1312 1328 1376 800 808 812 816 0x8 0xa The factory installed Android has a hardcoded modeline in its kernel, causing it to not suffer from this BIOS bug; and the Android boot-splash which uses the EFI FB which does have this bug has the last line all black causing the bug to not be visible. This commit introduces a generic DMI based quirk mechanism to vlv_dsi for doing various fixups, and uses this to correct the modeline. v2: - s/mode_fixup/dmi_quirk/ to make the new DMI quirk mechanism more generic - Add a comment with the old and new modelines to the patch and commit msg v3: - Add Closes tag to gitlab issue with drm.debug=0xe, VBT info Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9381 Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Acked-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/tiny: correctly print `struct resource *` on errorJoey Gouly1-1/+1
The `res` variable is already a `struct resource *`, don't take the address of it. Fixes incorrect output: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [??? 0xffff4be88a387d00-0xfffffefffde0a240 flags 0x0]: -16 To be correct: simple-framebuffer 9e20dc000.framebuffer: [drm] *ERROR* could not acquire memory range [mem 0x9e20dc000-0x9e307bfff flags 0x200]: -16 Signed-off-by: Joey Gouly <[email protected]> Fixes: 9a10c7e6519b ("drm/simpledrm: Add support for system memory framebuffers") Cc: Thomas Zimmermann <[email protected]> Cc: Thierry Reding <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: [email protected] Cc: <[email protected]> # v6.3+ Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm: Do not overrun array in drm_gem_get_pages()Matthew Wilcox (Oracle)1-2/+4
If the shared memory object is larger than the DRM object that it backs, we can overrun the page array. Limit the number of pages we install from each folio to prevent this. Signed-off-by: "Matthew Wilcox (Oracle)" <[email protected]> Reported-by: Oleksandr Natalenko <[email protected]> Tested-by: Oleksandr Natalenko <[email protected]> Link: https://lore.kernel.org/lkml/[email protected]/ Fixes: 3291e09a4638 ("drm: convert drm_gem_put_pages() to use a folio_batch") Cc: [email protected] # 6.5.x Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/simpledrm: Fix power domain device link validity checkThierry Reding1-1/+1
We need to check if a link is non-NULL before trying to delete it. Fixes: 61df9ca23107 ("drm/simpledrm: Add support for multiple "power-domains"") Signed-off-by: Thierry Reding <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Cc: Janne Grunau <[email protected]> Cc: Eric Curtin <[email protected]> Cc: Neal Gompa <[email protected]> Cc: Sven Peter <[email protected]> Cc: Javier Martinez Canillas <[email protected]> Cc: [email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm: Replace drm_framebuffer plane size functions with its equivalentsCarlos Eduardo Gallo Filho2-61/+5
The functions drm_framebuffer_plane_{width,height} and fb_plane_{width,height} do exactly the same job of its equivalents drm_format_info_plane_{width,height} from drm_fourcc. The only reason to have these functions on drm_framebuffer would be if they would added a abstraction layer to call it just passing a drm_framebuffer pointer and the desired plane index, which is not the case, where these functions actually implements just part of it. In the actual implementation, every call to both drm_framebuffer_plane_{width,height} and fb_plane_{width,height} should pass some drm_framebuffer attribute, which is the same as calling the drm_format_info_plane_{width,height} functions. The drm_format_info_pane_{width,height} functions are much more consistent in both its implementation and its location on code. The kind of calculation that they do is intrinsically derivated from the drm_format_info struct and has not to do with drm_framebuffer, except by the potential motivation described above, which is still not a good justification to have drm_framebuffer functions to calculate it. So, replace each drm_framebuffer_plane_{width,height} and fb_plane_{width,height} call to drm_format_info_plane_{width,height} and remove them. Signed-off-by: Carlos Eduardo Gallo Filho <[email protected]> Reviewed-by: André Almeida <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915: Remove the module parameter 'fastboot'Arun R Murthy3-9/+0
By default fastboot is enabled on all Display 9+ platforms and disabled on older platforms. Its not necessary to retain this as a module parameter. Signed-off-by: Arun R Murthy <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/hdcp: Move common message filling function to its own fileSuraj Kandpal4-598/+682
Create a new file intel_hdcp_gsc_message that contain functions which fill the hdcp messages we send to gsc cs this refactor will help us reuse code for Xe later on --v2 -add the missed file for proper build --v3 -use forward declarations instead of #includes [Jani] --v4 -move linux/err.h to intel_hdcp_gsc_message.c from intel_hdcp_gsc_message.h [Jani] --v5 -move linux include on top of drm includes [Uma] Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/hdcp: Move checks for gsc health statusSuraj Kandpal3-7/+16
Move checks for gsc components required for HDCP 2.2 to work into intel_hdcp_gsc.c. This will also help with XE refactor on HDCP's side. Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/msm/dp: use correct lifetime device for devm_drm_bridge_addDmitry Baryshkov1-1/+1
The lifetime of the created drm_bridge is attached to the drm_device rather than the DP's platform_device. Use correct lifetime for devm_drm_bridge_add() call. Fixes: 61a72d5efce5 ("drm/msm/dp: switch to devm_drm_bridge_add()") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/562203/ Link: https://lore.kernel.org/r/[email protected]
2023-10-12drm/msm/hdmi: use correct lifetime device for devm_drm_bridge_addDmitry Baryshkov1-1/+1
The lifetime of the created drm_bridge is attached to the drm_device rather than the HDMI's platform_device. Use correct lifetime for devm_drm_bridge_add() call. Fixes: 719093a67c7f ("drm/msm/hdmi: switch to devm_drm_bridge_add()") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/562201/ Link: https://lore.kernel.org/r/[email protected]
2023-10-12drm/msm/dsi: use correct lifetime device for devm_drm_bridge_addDmitry Baryshkov1-1/+1
The lifetime of the created drm_bridge is attached to the drm_device rather than the DSI's platform_device. Use correct lifetime for devm_drm_bridge_add() call. Fixes: 5f403fd7d5c2 ("drm/msm/dsi: switch to devm_drm_bridge_add()") Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/562200/ Link: https://lore.kernel.org/r/[email protected]
2023-10-12drm/i915/display: Use correct method to free crtc_stateSuraj Kandpal1-1/+2
Even though there is no leaking of resource here lets just use the correct method to free crtc_state Signed-off-by: Suraj Kandpal <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-12drm/i915/display: Use intel_crtc_destroy_state instead kfreeSuraj Kandpal1-2/+2
intel_encoder_current_mode() seems to leak some resource because it uses kfree instead of intel_crtc_destroy_state let us fix that. Signed-off-by: Suraj Kandpal <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/tegra: gem: Do not return NULL in tegra_bo_mmap()Thierry Reding1-2/+11
It's confusing for a function to return NULL and ERR_PTR()-encoded error codes on failure. Make sure we only ever return the latter since that's what callers already expect. Reported-by: Sui Jingfeng <[email protected]> Reviewed-by: Sui Jingfeng <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/tegra: Zero-initialize iosys_mapMikko Perttunen1-1/+1
UBSAN reports an invalid load for bool, as the iosys_map is read later without being initialized. Zero-initialize it to avoid this. Reported-by: Ashish Mhetre <[email protected]> Signed-off-by: Mikko Perttunen <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/tegra: hub: Increase buffer size to ensure all possible values can be storedLee Jones1-1/+1
When converting from int to string, we must allow for up to 10-chars (2147483647). Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/tegra/hub.c: In function ‘tegra_display_hub_probe’: drivers/gpu/drm/tegra/hub.c:1106:47: warning: ‘%u’ directive output may be truncated writing between 1 and 10 bytes into a region of size 4 [-Wformat-truncation=] drivers/gpu/drm/tegra/hub.c:1106:42: note: directive argument in the range [0, 4294967294] drivers/gpu/drm/tegra/hub.c:1106:17: note: ‘snprintf’ output between 6 and 15 bytes into a destination of size 8 Signed-off-by: Lee Jones <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/tegra: Remove two unused function declarationsYue Haibing1-3/+0
Commit 776dc3840367 ("drm/tegra: Move subdevice infrastructure to host1x") removed the implementation but not the declaration. Signed-off-by: Yue Haibing <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/tegra: Remove surplus else after returnSui Jingfeng1-9/+10
else is not generally useful after return Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915: enable W=1 warnings by defaultJani Nikula1-14/+26
We enable a bunch more compiler warnings than the kernel defaults. However, they've drifted to become a unique set of warnings, and have increasingly fallen behind from the W=1 set. Align with the W=1 warnings from scripts/Makefile.extrawarn for clarity, by copy-pasting them with s/KBUILD_CFLAGS/subdir-ccflags-y/ to make it easier to compare in the future. Some of the -Wextra warnings do need to be disabled, just like in Makefile.extrawarn, but take care to not disable them for W=2 or W=3 builds, depending on the warning. v2: Add back some -Wextra warning disables (Nathan) Cc: Arnd Bergmann <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> [Final s/KBUILD_CFLAGS/subdir-ccflags-y/ fix while applying] Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/69a812273091b6535ddc7f9346289d71bb30f43d.1697009258.git.jani.nikula@intel.com
2023-10-11drm/i915: drop -Wall and related disables from cflags as redundantJani Nikula1-5/+3
The kernel top level Makefile, and recently scripts/Makefile.extrawarn, have included -Wall, and the disables -Wno-format-security and $(call cc-disable-warning,frame-address,) for a very long time. They're redundant in our local subdir-ccflags-y and can be dropped. Cc: Arnd Bergmann <[email protected]> Cc: Nick Desaulniers <[email protected]> Cc: Nathan Chancellor <[email protected]> Cc: Masahiro Yamada <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Acked-by: Nick Desaulniers <[email protected]> Reviewed-by: Masahiro Yamada <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/5ab754ddc2e342c75deb8476275984918e573beb.1697009258.git.jani.nikula@intel.com
2023-10-11drm/i915/cx0: Only clear/set the Pipe Reset bit of the PHY Lanes OwnedKhaled Almahallawy1-2/+1
Currently, with MFD/pin assignment D, the driver clears the pipe reset bit of lane 1 which is not owned by display. This causes the display to block S0iX. By not clearing this bit for lane 1 and keeping whatever default, S0ix started to work. This is already what the driver does at the end of the phy lane reset sequence (Step#8) Bspec: 65451 Fixes: 619a06dba6fa ("drm/i915/mtl: Reset only one lane in case of MFD") Cc: Mika Kahola <[email protected]> Cc: Gustavo Sousa <[email protected]> Signed-off-by: Khaled Almahallawy <[email protected]> Reviewed-by: Gustavo Sousa <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11intel drm: Remove now superfluous sentinel element from ctl_table arrayJoel Granados1-1/+0
This commit comes at the tail end of a greater effort to remove the empty elements at the end of the ctl_table arrays (sentinels) which will reduce the overall build time size of the kernel and run time memory bloat by ~64 bytes per sentinel (further information Link : https://lore.kernel.org/all/ZO5Yx5JFogGi%[email protected]/) Remove sentinel from oa_table Signed-off-by: Joel Granados <[email protected]> Signed-off-by: Luis Chamberlain <[email protected]>
2023-10-11drm/i915/gvt: move structs intel_gvt_irq_info and intel_gvt_irq_map to ↵Jani Nikula2-25/+23
interrupt.c Structs intel_gvt_irq_info and intel_gvt_irq_map are not used outside of interrupt.c. Hide them, and reduce includes. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915/gvt: move struct engine_mmio to mmio_context.cJani Nikula3-10/+10
struct engine_mmio is not used outside of mmio_context.c. Hide it, and reduce includes. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915/gvt: don't include gvt.h from intel_gvt_mmio_table.hJani Nikula1-1/+2
intel_gvt_mmio_table.c has no need to include the massive gvt.h. Simplify. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915/gvt: remove unused to_gvt() and reduce includesJani Nikula1-6/+1
gvt.h has no need to include i915_drv.h once the unused to_gvt() has been removed. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Zhenyu Wang <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915/xe2lpd: update the scaler feature capabilityVinod Govindapillai1-0/+7
Update the number of scalers per pipe based on the display capabilities reported. v1: define the field values instead of the magic number (JaniN) Bspec: 71161 Signed-off-by: Vinod Govindapillai <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jouni Högander <[email protected]>
2023-10-11drm/i915/xe2lpd: update the dsc feature capabilityVinod Govindapillai1-0/+8
Update the global dsc flag based on the display capabilities reported. v1: define the field values instead of the magic number (JaniN) Bspec: 71161 Signed-off-by: Vinod Govindapillai <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jouni Högander <[email protected]>
2023-10-11drm/i915/xe2lpd: display capability register definitionsVinod Govindapillai1-0/+7
Register definitions to track the reported scalable display feature configurations Bspec: 71161 Signed-off-by: Vinod Govindapillai <[email protected]> Reviewed-by: Jouni Högander <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Jouni Högander <[email protected]>
2023-10-11drm/bridge_connector: implement oob_hotplug_eventDmitry Baryshkov1-3/+28
Implement the oob_hotplug_event() callback. Translate it to the HPD notification sent to the HPD bridge in the chain. Reviewed-by: Janne Grunau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/bridge_connector: stop filtering events in drm_bridge_connector_hpd_cb()Dmitry Baryshkov1-5/+0
In some cases the bridge drivers would like to receive hotplug events even in the case new status is equal to the old status. In the DP case this is used to deliver "attention" messages to the DP host. Stop filtering the events in the drm_bridge_connector_hpd_cb() and let drivers decide whether they would like to receive the event or not. Reviewed-by: Janne Grunau <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm: Add HPD state to drm_connector_oob_hotplug_event()Bjorn Andersson3-5/+21
In some implementations, such as the Qualcomm platforms, the display driver has no way to query the current HPD state and as such it's impossible to distinguish between disconnect and attention events. Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD state. Also push the test for unchanged state in the displayport altmode driver into the i915 driver, to allow other drivers to act upon each update. Signed-off-by: Bjorn Andersson <[email protected]> Reviewed-by: Hans de Goede <[email protected]> Acked-by: Heikki Krogerus <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11drm/i915: Add wrapper for getting display stepChaitanya Kumar Borah3-1/+7
Add a wrapper around intel_step_name that takes in driver data as an argument. This wrapper will help maintain compatibility with the proposed xe driver. Signed-off-by: Chaitanya Kumar Borah <[email protected]> Signed-off-by: Animesh Manna <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Uma Shankar <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-11Merge drm/drm-next into drm-misc-nextThomas Zimmermann962-15822/+32967
Updating drm-misc-next to the state of Linux v6.6-rc2. Signed-off-by: Thomas Zimmermann <[email protected]>
2023-10-10drm/i915: More use of GT specific print helpersJohn Harrison3-10/+9
Update a bunch of GT related print messages in non-GT files to use the GT specific helpers. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10drm/i915/gt: More use of GT specific print helpersJohn Harrison5-43/+39
A bunch of print messages got missed in the update to using sub-system specific helpers. So update those. Signed-off-by: John Harrison <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10drm/i915/display: Free crtc_state in verify_crtc_stateSuraj Kandpal1-1/+4
Free hw_crtc_state in verify_crtc_state after we are done using this or else it's just a resource leak. Fixes: 2745bdda2095 ("drm/i915: Stop clobbering old crtc state during state check") Signed-off-by: Suraj Kandpal <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10drm/panel: ltk050h3146w: add support for Leadtek LTK050H3148W-CTA6 variantKlaus Goger1-0/+89
The LTK050H3148W-CTA6 is a 5.0" 720x1280 DSI display, whose driving controller is a Himax HX8394-F, slightly different from LTK050H3146W by its init sequence, mode details and mode flags. Cc: Quentin Schulz <[email protected]> Signed-off-by: Klaus Goger <[email protected]> Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Paul Kocialkowski <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10drm/panel: ltk050h3146w: add mipi_dsi_device.mode_flags to of_match_dataQuentin Schulz1-2/+6
To prepare for a new display to be supported by this driver which has a slightly different set of DSI mode related flags, let's move the currently hardcoded mode flags to the .data field of of_device_id structure. Cc: Quentin Schulz <[email protected]> Signed-off-by: Quentin Schulz <[email protected]> Reviewed-by: Paul Kocialkowski <[email protected]> Signed-off-by: Heiko Stuebner <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10drm/msm: fix fault injection supportDmitry Baryshkov1-0/+1
Readd the header that was erroneously dropped during KMS code refactoring. Fixes: 506efcba3129 ("drm/msm: carve out KMS code from msm_drv.c") Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Dmitry Baryshkov <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/561739/ Signed-off-by: Rob Clark <[email protected]>
2023-10-10drm/atomic-helper: relax unregistered connector checkSimon Ser1-4/+13
The driver might pull connectors which weren't submitted by user-space into the atomic state. For instance, intel_dp_mst_atomic_master_trans_check() pulls in connectors sharing the same DP-MST stream. However, if the connector is unregistered, this later fails with: [ 559.425658] i915 0000:00:02.0: [drm:drm_atomic_helper_check_modeset] [CONNECTOR:378:DP-7] is not registered Skip the unregistered connector check to allow user-space to turn off connectors one-by-one. See this wlroots issue: https://gitlab.freedesktop.org/wlroots/wlroots/-/issues/3407 Previous discussion: https://lore.kernel.org/intel-gfx/[email protected]/ Signed-off-by: Simon Ser <[email protected]> Cc: [email protected] Reviewed-by: Ville Syrjälä <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-10-10x86/cpu: Encapsulate topology information in cpuinfo_x86Thomas Gleixner1-1/+1
The topology related information is randomly scattered across cpuinfo_x86. Create a new structure cpuinfo_topo and move in a first step initial_apicid and apicid into it. Aside of being better readable this is in preparation for replacing the horribly fragile CPU topology evaluation code further down the road. Consolidate APIC ID fields to u32 as that represents the hardware type. No functional change. Signed-off-by: Thomas Gleixner <[email protected]> Tested-by: Juergen Gross <[email protected]> Tested-by: Sohil Mehta <[email protected]> Tested-by: Michael Kelley <[email protected]> Tested-by: Peter Zijlstra (Intel) <[email protected]> Tested-by: Zhang Rui <[email protected]> Acked-by: Peter Zijlstra (Intel) <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2023-10-10drm/panel: boe-tv101wum-nl6: Completely pull GPW to VGL before TP termRuihai Zhou1-3/+1
The sta_himax83102 panel sometimes shows abnormally flickering horizontal lines. The front gate output will precharge the X point of the next pole circuit before TP(TouchPanel Enable) term starts, and wait until the end of the TP term to resume the CLK. For this reason, the X point must be maintained during the TP term. In abnormal case, we measured a slight leakage at point X. This because during the TP term, the GPW does not fully pull the VGL low, causing the TFT to not be closed tightly. To fix this, we completely pull GPW to VGL before entering the TP term. This will ensure that the TFT is closed tightly and prevent the abnormal display. Fixes: 1bc2ef065f13 ("drm/panel: Support for Starry-himax83102-j02 TDDI MIPI-DSI panel") Signed-off-by: Ruihai Zhou <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.