summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-12-12drm/xe: Stop using i915_utils in xe_wopcm.Rodrigo Vivi
We don't need any macro for a simple check we can do explicitly and clear. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Remove i915_utils dependency from xe_guc_pc.Rodrigo Vivi
To make it simpler, all of the status checks also waits and times out. Also, no ktime precision is needed in this case, and we can use usleep_range because we are not in atomic paths here. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Wait for success on guc done.Rodrigo Vivi
Rather than a constant check on proto and wait not busy, let's wait for the expected success and then check the protocol afterwards. With this, we can now use the regular xe_mmio_wait32 and kill this local need for the wait_for. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Convert guc_ready to regular xe_mmio_wait32Rodrigo Vivi
Possible now that the wait function returns the last read value. So we can remove the users of i915's wait_for one by one... Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Let's return last value read on xe_mmio_wait32.Rodrigo Vivi
This is already useful because it avoids some extra reads where registers might have changed after the timeout decision. But also, it will be important to end the kill of i915's wait_for. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Stop using i915's range_overflows_t macro.Rodrigo Vivi
Let's do it directly. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Implement a local xe_mmio_wait32Rodrigo Vivi
Then, move the i915_utils.h include to its user. The overall goal is to kill all the usages of the i915_utils stuff. Yes, wait_for also depends on <linux/delay.h>, so they go together to where it is needed. It will be likely needed anyway directly for udelay or usleep_range. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/xe: Introduce a new DRM driver for Intel GPUsMatthew Brost
Xe, is a new driver for Intel GPUs that supports both integrated and discrete platforms starting with Tiger Lake (first Intel Xe Architecture). The code is at a stage where it is already functional and has experimental support for multiple platforms starting from Tiger Lake, with initial support implemented in Mesa (for Iris and Anv, our OpenGL and Vulkan drivers), as well as in NEO (for OpenCL and Level0). The new Xe driver leverages a lot from i915. As for display, the intent is to share the display code with the i915 driver so that there is maximum reuse there. But it is not added in this patch. This initial work is a collaboration of many people and unfortunately the big squashed patch won't fully honor the proper credits. But let's get some git quick stats so we can at least try to preserve some of the credits: Co-developed-by: Matthew Brost <matthew.brost@intel.com> Co-developed-by: Matthew Auld <matthew.auld@intel.com> Co-developed-by: Matt Roper <matthew.d.roper@intel.com> Co-developed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Co-developed-by: Francois Dugast <francois.dugast@intel.com> Co-developed-by: Lucas De Marchi <lucas.demarchi@intel.com> Co-developed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Co-developed-by: Philippe Lecluse <philippe.lecluse@intel.com> Co-developed-by: Nirmoy Das <nirmoy.das@intel.com> Co-developed-by: Jani Nikula <jani.nikula@intel.com> Co-developed-by: José Roberto de Souza <jose.souza@intel.com> Co-developed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Co-developed-by: Dave Airlie <airlied@redhat.com> Co-developed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Co-developed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Co-developed-by: Mauro Carvalho Chehab <mchehab@kernel.org> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com>
2023-12-12drm/exynos: dpi: Change connector type to DPIPaul Cercueil
When exynos_drm_dpi.c was written, DRM_MODE_CONNECTOR_DPI did not exist yet and I guess that's the reason why DRM_MODE_CONNECTOR_VGA was used as the connector type. However, now it makes more sense to use DRM_MODE_CONNECTOR_DPI as the connector type. Signed-off-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12drm/exynos: Convert to platform remove callback returning voidUwe Kleine-König
The .remove() callback for a platform driver returns an int which makes many driver authors wrongly assume it's possible to do error handling by returning an error code. However the value returned is ignored (apart from emitting a warning) and this typically results in resource leaks. To improve here there is a quest to make the remove callback return void. In the first step of this quest all drivers are converted to .remove_new(), which already returns void. Eventually after all drivers are converted, .remove_new() will be renamed to .remove(). Trivially convert this driver from always returning zero in the remove callback to the void returning variant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> fix merge conflict and drop duplicated patch description. Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12drm/exynos: Call drm_atomic_helper_shutdown() at shutdown/unbind timeDouglas Anderson
Based on grepping through the source code this driver appears to be missing a call to drm_atomic_helper_shutdown() at system shutdown time and at driver unbind time. Among other things, this means that if a panel is in use that it won't be cleanly powered off at system shutdown time. The fact that we should call drm_atomic_helper_shutdown() in the case of OS shutdown/restart and at driver remove (or unbind) time comes straight out of the kernel doc "driver instance overview" in drm_drv.c. A few notes about this fix: - When adding drm_atomic_helper_shutdown() to the unbind path, I added it after drm_kms_helper_poll_fini() since that's when other drivers seemed to have it. - Technically with a previous patch, ("drm/atomic-helper: drm_atomic_helper_shutdown(NULL) should be a noop"), we don't actually need to check to see if our "drm" pointer is NULL before calling drm_atomic_helper_shutdown(). We'll leave the "if" test in, though, so that this patch can land without any dependencies. It could potentially be removed later. - This patch also makes sure to set the drvdata to NULL in the case of bind errors to make sure that shutdown can't access freed data. Suggested-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Inki Dae <inki.dae@samsung.com>
2023-12-12Merge tag 'exynos-drm-next-for-v6.7-rc5' of ↵Inki Dae
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into exynos-drm-next Two fixups - Fix a potential error pointer dereference by checking the return value of exynos_drm_crtc_get_by_type() function before accessing to crtc object. - Fix a wrong error checking in exynos_drm_dma.c modules, which was reported by Dan[1] [1] https://lore.kernel.org/all/33e52277-1349-472b-a55b-ab5c3462bfcf@moroto.mountain/
2023-12-12Backmerge tag 'v6.7-rc5' into drm-nextDave Airlie
Linux 6.7-rc5 Alex requested this for some amdkfd work relying on the symbols exports. Signed-off-by: Dave Airlie <airlied@redhat.com>
2023-12-11drm/i915/display: do not use cursor size reduction on MTLAndrzej Hajda
Cursor size reduction is not supported since MTL. Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231124-cur_size_reduction-v1-1-30495dba475f@intel.com
2023-12-11drm/msm/dpu: move encoder status to standard encoder debugfs dirDmitry Baryshkov
Now as we have standard per-encoder debugfs directory, move DPU encoder status file to that directory. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/570219/ Link: https://lore.kernel.org/r/20231203115315.1306124-4-dmitry.baryshkov@linaro.org
2023-12-11drm/bridge: ti-sn65dsi86: Associate PWM device to auxiliary deviceUwe Kleine-König
It's the ti_sn65dsi86.pwm auxiliary driver that creates the pwmchip, so let the auxiliary device be the parent of the pwm device. Note that getting a reference to the ti-sn65dsi86's pwm using pwm_get() isn't affected by this change as ti_sn65dsi86_add_aux_device() sets the auxiliary device's of_node to that of the main device. Also change PM runtime tracking and diagnostic messages to use that one. After enabling runtime PM operation for the auxiliary device, all works as expected as parent devices are handled just fine. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Tested-by: Nikita Travkin <nikita@trvn.ru> # Acer Aspire 1 Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231209153108.1988551-2-u.kleine-koenig@pengutronix.de
2023-12-11platform/x86/amd: Add support for AMD ACPI based Wifi band RFI mitigation ↵Ma Jun
feature Due to electrical and mechanical constraints in certain platform designs there may be likely interference of relatively high-powered harmonics of the (G-)DDR memory clocks with local radio module frequency bands used by Wifi 6/6e/7. To mitigate this, AMD has introduced a mechanism that devices can use to notify active use of particular frequencies so that other devices can make relative internal adjustments as necessary to avoid this resonance. Co-developed-by: Evan Quan <quanliangl@hotmail.com> Signed-off-by: Evan Quan <quanliangl@hotmail.com> Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11Documentation/driver-api: Add document about WBRF mechanismMa Jun
Add documentation about AMD's Wifi band RFI mitigation (WBRF) mechanism explaining the theory and how it is used. Signed-off-by: Ma Jun <Jun.Ma2@amd.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2023-12-11drm/i915/edp: don't write to DP_LINK_BW_SET when using rate selectJani Nikula
The eDP 1.5 spec adds a clarification for eDP 1.4x: > For eDP v1.4x, if the Source device chooses the Main-Link rate by way > of DPCD 00100h, the Sink device shall ignore DPCD 00115h[2:0]. We write 0 to DP_LINK_BW_SET (DPCD 100h) even when using DP_LINK_RATE_SET (DPCD 114h). Stop doing that, as it can cause the panel to ignore the rate set method. Moreover, 0 is a reserved value for DP_LINK_BW_SET, and should not be used. v2: Improve the comments (Ville) Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/9081 Tested-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231205180551.2476228-1-jani.nikula@intel.com
2023-12-11drm/panel: simple: Add AUO G156HAN04.0 LVDS display supportElmar Albert
G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen and 16.7M colors (RGB 8-bits) with LED backlight driving circuit. All input signals are LVDS interface compatible. G156HAN04.0 is designed for a display unit of notebook style personal computer and industrial machine. Signed-off-by: Elmar Albert <ealbert@data-modul.com> Signed-off-by: Marek Vasut <marex@denx.de> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20231209063714.1381913-2-marex@denx.de Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231209063714.1381913-2-marex@denx.de
2023-12-11dt-bindings: display: simple: Add AUO G156HAN04.0 LVDS displayElmar Albert
Document support for the AUO G156HAN04.0 LVDS display. G156HAN04.0 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 16:9 FHD, 1920(H) x 1080(V) screen and 16.7M colors (RGB 8-bits) with LED backlight driving circuit. All input signals are LVDS interface compatible. G156HAN04.0 is designed for a display unit of notebook style personal computer and industrial machine. Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Elmar Albert <ealbert@data-modul.com> Signed-off-by: Marek Vasut <marex@denx.de> Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://lore.kernel.org/r/20231209063714.1381913-1-marex@denx.de Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231209063714.1381913-1-marex@denx.de
2023-12-11drm/panel: ilitek-ili9805: add support for Tianma TM041XDHG01 panelMichael Trimarchi
Tianma TM041XDHG01 utilizes the Ilitek ILI9805 controller. Add this panel's initialzation sequence and timing to ILI9805 driver. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Link: https://lore.kernel.org/r/20231207141723.108004-10-dario.binacchi@amarulasolutions.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231207141723.108004-10-dario.binacchi@amarulasolutions.com
2023-12-11drm/panel: Add Ilitek ILI9805 panel driverMichael Trimarchi
The GPM1790A0 panel is based on the Ilitek ILI9805 Controller. Add a driver for it. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231207141723.108004-9-dario.binacchi@amarulasolutions.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231207141723.108004-9-dario.binacchi@amarulasolutions.com
2023-12-11dt-bindings: display: panel: Add Ilitek ili9805 panel controllerMichael Trimarchi
Add documentation for "ilitek,ili9805" panel. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231207141723.108004-8-dario.binacchi@amarulasolutions.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231207141723.108004-8-dario.binacchi@amarulasolutions.com
2023-12-11drm/panel: Add Synaptics R63353 panel driverMichael Trimarchi
The LS068B3SX02 panel is based on the Synaptics R63353 Controller. Add a driver for it. Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com> Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231207141723.108004-7-dario.binacchi@amarulasolutions.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231207141723.108004-7-dario.binacchi@amarulasolutions.com
2023-12-11drm/panel: st7701: Add Anbernic RG-ARC Panel SupportChris Morgan
The Powkiddy RG-ARC is a series of 2 handheld devices, each with a 4 inch 480x640 display. Add support for the display. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231208154847.130615-4-macroalpha82@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231208154847.130615-4-macroalpha82@gmail.com
2023-12-11dt-bindings: display: st7701: Add Anbernic RG-ARC panelChris Morgan
The RG-ARC panel is a panel specific to the Anbernic RG-ARC. It is 4 inches in size (diagonally) with a resolution of 480x640. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231208154847.130615-3-macroalpha82@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231208154847.130615-3-macroalpha82@gmail.com
2023-12-11drm/panel: st7701: Fix AVCL calculationChris Morgan
The AVCL register, according to the datasheet, comes in increments of -0.2v between -4.4v (represented by 0x0) to -5.0v (represented by 0x3). The current calculation is done by adding the defined AVCL value in mV to -4400 and then dividing by 200 to get the register value. Unfortunately if I subtract -4400 from -4400 I get -8800, which divided by 200 gives me -44. If I instead subtract -4400 from -4400 I get 0, which divided by 200 gives me 0. Based on the datasheet this is the expected register value. Fixes: 83b7a8e7e88e ("drm/panel/panel-sitronix-st7701: Parametrize voltage and timing") Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20231208154847.130615-2-macroalpha82@gmail.com Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231208154847.130615-2-macroalpha82@gmail.com
2023-12-11dt-bindings: display: panel: add Fascontek FS035VG158 panelJohn Watts
This is a small 3.5" 640x480 IPS LCD panel. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-7-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-7-d75adc75571f@jookia.org
2023-12-11dt-bindings: vendor-prefixes: Add fascontekJohn Watts
Fascontek manufactures LCD panels such as the FS035VG158. Signed-off-by: John Watts <contact@jookia.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-6-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-6-d75adc75571f@jookia.org
2023-12-11dt-bindings: display: panel: Clean up leadtek,ltk035c5444t propertiesJohn Watts
Remove common properties listed in common yaml files. Add required properties needed to describe the panel. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-5-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-5-d75adc75571f@jookia.org
2023-12-11drm/panel: nv3052c: Add Fascontek FS035VG158 LCD displayJohn Watts
This display is extremely similar to the LTK035C5444T, but still has some minor variations in panel initialization. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-4-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-4-d75adc75571f@jookia.org
2023-12-11drm/panel: nv3052c: Allow specifying registers per panelJohn Watts
Panel initialization registers are per-display and not tied to the controller itself. Different panels will specify their own registers. Attach the sequences to the panel info struct so future panels can specify their own sequences. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-3-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-3-d75adc75571f@jookia.org
2023-12-11drm/panel: nv3052c: Add SPI device IDsJohn Watts
SPI drivers needs their own list of compatible device IDs in order for automatic module loading to work. Add those for this driver. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-2-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-2-d75adc75571f@jookia.org
2023-12-11drm/panel: nv3052c: Document known register namesJohn Watts
Many of these registers have a known name in the public datasheet. Document them as comments for reference. Signed-off-by: John Watts <contact@jookia.org> Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20231210-fs035vg158-v5-1-d75adc75571f@jookia.org Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231210-fs035vg158-v5-1-d75adc75571f@jookia.org
2023-12-11drm/i915/selftests: Fix spelling mistake "initialiased" -> "initialised"Colin Ian King
There is a spelling mistake in a pr_err error message. Fix it. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209230541.4055786-1-colin.i.king@gmail.com
2023-12-10Linux 6.7-rc5v6.7-rc5Linus Torvalds
2023-12-10drm/ci: remove rebase-merge directoryDmitry Baryshkov
Gitlab runner can cache git repository, including the unfinished rebase merge status. New CI job will come as a fresh checkout, however this will not destroy the unfinished rebase, failing our build script. Destroy the unfinished rebase state. Suggested-by: David Heidelberg <david.heidelberg@collabora.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Helen Koike <helen.koike@collabora.com> Patchwork: https://patchwork.freedesktop.org/patch/570159/ Signed-off-by: Rob Clark <robdclark@chromium.org>
2023-12-10drm/msm/gem: Convert to drm_execRob Clark
Replace the ww_mutex locking dance with the drm_exec helper. v2: Error path fixes, move drm_exec_fini so we only call it once (and only if we have drm_exec_init() Signed-off-by: Rob Clark <robdclark@chromium.org> Patchwork: https://patchwork.freedesktop.org/patch/568342/
2023-12-10Merge tag 'sched_urgent_for_v6.7_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Borislav Petkov: - Make sure tasks are thawed exactly and only once to avoid their state getting corrupted * tag 'sched_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: freezer,sched: Do not restore saved_state of a thawed task
2023-12-10Merge tag 'perf_urgent_for_v6.7_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf event fix from Borislav Petkov: - Make sure perf event size validation is done on every event in the group * tag 'perf_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf: Fix perf_event_validate_size()
2023-12-10Merge tag 'x86_urgent_for_v6.7_rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - Add a forgotten CPU vendor check in the AMD microcode post-loading callback so that the callback runs only on AMD - Make sure SEV-ES protocol negotiation happens only once and on the BSP * tag 'x86_urgent_for_v6.7_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/CPU/AMD: Check vendor in the AMD microcode callback x86/sev: Fix kernel crash due to late update to read-only ghcb_version
2023-12-10Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds
Pull kvm fixes from Paolo Bonzini: "Generic: - Set .owner for various KVM file_operations so that files refcount the KVM module until KVM is done executing _all_ code, including the last few instructions of kvm_put_kvm(). And then revert the misguided attempt to rely on "struct kvm" refcounts to pin KVM-the-module. ARM: - Do not redo the mapping of vLPIs, if they have already been mapped s390: - Do not leave bits behind in PTEs - Properly catch page invalidations that affect the prefix of a nested guest x86: - When checking if a _running_ vCPU is "in-kernel", i.e. running at CPL0, get the CPL directly instead of relying on preempted_in_kernel (which is valid if and only if the vCPU was preempted, i.e. NOT running). - Fix a benign "return void" that was recently introduced. Selftests: - Makefile tweak for dependency generation - '-Wformat' fix" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: SVM: Update EFER software model on CR0 trap for SEV-ES KVM: selftests: add -MP to CFLAGS KVM: selftests: Actually print out magic token in NX hugepages skip message KVM: x86: Remove 'return void' expression for 'void function' Revert "KVM: Prevent module exit until all VMs are freed" KVM: Set file_operations.owner appropriately for all such structures KVM: x86: Get CPL directly when checking if loaded vCPU is in kernel mode KVM: arm64: GICv4: Do not perform a map to a mapped vLPI KVM: s390/mm: Properly reset no-dat KVM: s390: vsie: fix wrong VIR 37 when MSO is used
2023-12-10drm/exec: Pass in initial # of objectsRob Clark
In cases where the # is known ahead of time, it is silly to do the table resize dance. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Christian König <christian.koenig@amd.com> Patchwork: https://patchwork.freedesktop.org/patch/568338/
2023-12-10drm/msm/gem: Cleanup submit_cleanup_bo()Rob Clark
Now that it only handles unlock duty, drop the superfluous arg and rename it. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/568333/
2023-12-10drm/msm/gem: Split out submit_unpin_objects() helperRob Clark
Untangle unpinning from unlock/unref loop. The unpin only happens in error paths so it is easier to decouple from the normal unlock path. Since we never have an intermediate state where a subset of buffers are pinned (ie. we never bail out of the pin or unpin loops) we can replace the bo state flag bit with a global flag in the submit. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/568335/
2023-12-10drm/msm/gem: Don't queue job to sched in error casesRob Clark
We shouldn't be running the job in error cases. This also avoids having to think too hard about where the objs get unpinned (and if necessary, the resv takes over tracking that the obj is busy).. ie. error cases it always happens synchronously, and normal cases it happens from scheduler job_run() callback. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/568331/
2023-12-10drm/msm/gem: Remove submit_unlock_unpin_bo()Rob Clark
The only point it is called is before pinning objects, so the "unpin" part of the name is fiction. Just remove it and call submit_cleanup_bo() directly. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/568330/
2023-12-10drm/msm/gem: Remove "valid" trackingRob Clark
This was a small optimization for pre-soft-pin userspace. But mesa switched to soft-pin nearly 5yrs ago. So lets drop the optimization and simplify the code. Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/568328/
2023-12-10drm/msm/adreno: Fix A680 chip idBjorn Andersson
The only A680 referenced from DeviceTree is patch level 1, which since commit '90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU")' isn't a known chip id. Correct the chip id to allow the A680 to be recognized again. Fixes: 90b593ce1c9e ("drm/msm/adreno: Switch to chip-id for identifying GPU") Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/569839/ Signed-off-by: Rob Clark <robdclark@chromium.org>
generated by cgit (git 2.34.1) at 2025-09-17 23:21:32 +0000