summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2023-10-26drm/sched: Convert the GPU scheduler to variable number of run-queuesLuben Tuikov10-22/+92
The GPU scheduler has now a variable number of run-queues, which are set up at drm_sched_init() time. This way, each driver announces how many run-queues it requires (supports) per each GPU scheduler it creates. Note, that run-queues correspond to scheduler "priorities", thus if the number of run-queues is set to 1 at drm_sched_init(), then that scheduler supports a single run-queue, i.e. single "priority". If a driver further sets a single entity per run-queue, then this creates a 1-to-1 correspondence between a scheduler and a scheduled entity. Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Russell King <linux+etnaviv@armlinux.org.uk> Cc: Qiang Yu <yuq825@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Abhinav Kumar <quic_abhinavk@quicinc.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Danilo Krummrich <dakr@redhat.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian Kรถnig <christian.koenig@amd.com> Cc: Emma Anholt <emma@anholt.net> Cc: etnaviv@lists.freedesktop.org Cc: lima@lists.freedesktop.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: Luben Tuikov <luben.tuikov@amd.com> Acked-by: Christian Kรถnig <christian.koenig@amd.com> Link: https://lore.kernel.org/r/20231023032251.164775-1-luben.tuikov@amd.com
2023-10-26drm/ci: do not automatically retry on errorHelen Koike1-14/+0
Since the kernel doesn't use a bot like Mesa that requires tests to pass in order to merge the patches, leave it to developers and/or maintainers to manually retry. Suggested-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-10-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: export kernel configHelen Koike2-1/+2
Export the resultant kernel config, making it easier to verify if the resultant config was correctly generated. Suggested-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Helen Koike <helen.koike@collabora.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-9-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: increase i915 job timeout to 1h30mHelen Koike1-0/+5
With the new sharding, the default job timeout is not enough for i915 and their jobs are failing before completing. See below the current execution time: ๐Ÿž‹ job i915:tgl 8/8 has new status: success (37m3s) ๐Ÿž‹ job i915:tgl 7/8 has new status: success (19m43s) ๐Ÿž‹ job i915:tgl 6/8 has new status: success (21m47s) ๐Ÿž‹ job i915:tgl 5/8 has new status: success (18m16s) ๐Ÿž‹ job i915:tgl 4/8 has new status: success (21m43s) ๐Ÿž‹ job i915:tgl 3/8 has new status: success (17m59s) ๐Ÿž‹ job i915:tgl 2/8 has new status: success (22m15s) ๐Ÿž‹ job i915:tgl 1/8 has new status: success (18m52s) ๐Ÿž‹ job i915:cml 2/2 has new status: success (1h19m58s) ๐Ÿž‹ job i915:cml 1/2 has new status: success (55m45s) ๐Ÿž‹ job i915:whl 2/2 has new status: success (1h8m56s) ๐Ÿž‹ job i915:whl 1/2 has new status: success (54m3s) ๐Ÿž‹ job i915:kbl 3/3 has new status: success (37m43s) ๐Ÿž‹ job i915:kbl 2/3 has new status: success (36m37s) ๐Ÿž‹ job i915:kbl 1/3 has new status: success (34m52s) ๐Ÿž‹ job i915:amly 2/2 has new status: success (1h7m60s) ๐Ÿž‹ job i915:amly 1/2 has new status: success (59m18s) ๐Ÿž‹ job i915:glk 2/2 has new status: success (58m26s) ๐Ÿž‹ job i915:glk 1/2 has new status: success (50m23s) ๐Ÿž‹ job i915:apl 3/3 has new status: success (1h6m39s) ๐Ÿž‹ job i915:apl 2/3 has new status: success (1h4m45s) ๐Ÿž‹ job i915:apl 1/3 has new status: success (1h7m38s) (generated with ci_run_n_monitor.py script) The longest job is 1h19m58s, so adjust the timeout. Signed-off-by: Helen Koike <helen.koike@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-8-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: add subset-1-gfx to LAVA_TAGS and adjust shardsHelen Koike2-10/+15
The Collabora Lava farm added a tag called `subset-1-gfx` to half of devices the graphics community use. Lets use this tag so we don't occupy all the resources. This is particular important because Mesa3D shares the resources with DRM-CI and use them to do pre-merge tests, so it can block developers from getting their patches merged. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-7-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: clean up xfails (specially flakes list)Helen Koike33-287/+162
Since the script that collected the list of the expectation files was bogus and placing test to the flakes list incorrectly, restart the expectation files with the correct script. This reduces a lot the number of tests in the flakes list. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-6-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: uprev IGT and make sure core_getversion is runHelen Koike3-9/+26
IGT has recently merged a patch that makes code_getversion test to fails if the driver isn't loaded or if it isn't the expected one defined in variable IGT_FORCE_DRIVER. Without this test, jobs were passing when the driver didn't load or probe for some reason, giving the illusion that everything was ok. Uprev IGT to include this modification and include core_getversion test in all the shards. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-5-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: add helper script update-xfails.pyHelen Koike2-0/+221
Add helper script that given a gitlab pipeline url, analyse which are the failures and flakes and update the xfails folder accordingly. Example: Trigger a pipeline in gitlab infrastructure, than re-try a few jobs more than once (so we can have data if failures are consistent across jobs with the same name or if they are flakes) and execute: update-xfails.py https://gitlab.freedesktop.org/helen.fornazier/linux/-/pipelines/970661 git diff should show you that it updated files in xfails folder. Signed-off-by: Helen Koike <helen.koike@collabora.com> Tested-by: Vignesh Raman <vignesh.raman@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-4-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: fix DEBIAN_ARCH and get amdgpu probingHelen Koike4-8/+8
amdgpu driver wasn't loading because amdgpu firmware wasn't being installed in the rootfs due to the wrong DEBIAN_ARCH variable. rename ARCH to DEBIAN_ARCH also, so we don't have the confusing DEBIAN_ARCH, KERNEL_ARCH and ARCH. Signed-off-by: Helen Koike <helen.koike@collabora.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-3-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: uprev mesa version: fix container build & crosvmHelen Koike4-3/+22
When building containers, some rust packages were installed without locking the dependencies version, which got updated and started giving errors like: error: failed to compile `bindgen-cli v0.62.0`, intermediate artifacts can be found at `/tmp/cargo-installkNKRwf` Caused by: package `rustix v0.38.13` cannot be built because it requires rustc 1.63 or newer, while the currently active rustc version is 1.60.0 A patch to Mesa was added fixing this error, so update it. Also, commit in linux kernel 6.6 rc3 broke booting in crosvm. Mesa has upreved crosvm to fix this issue. Signed-off-by: Helen Koike <helen.koike@collabora.com> [crosvm mesa update] Co-Developed-by: Vignesh Raman <vignesh.raman@collabora.com> Signed-off-by: Vignesh Raman <vignesh.raman@collabora.com> [v1 container build uprev] Tested-by: Jessica Zhang <quic_jesszhan@quicinc.com> Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by: David Heidelberg <david.heidelberg@collabora.com> Link: https://lore.kernel.org/r/20231024004525.169002-2-helen.koike@collabora.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: Enable CONFIG_BACKLIGHT_CLASS_DEVICERob Clark2-0/+2
Dependency for CONFIG_DRM_PANEL_EDP. Missing this was causing the drm driver to not probe on devices that use panel-edp. Signed-off-by: Rob Clark <robdclark@chromium.org> Tested-by: Helen Koike <helen.koike@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://lore.kernel.org/r/20231002164715.157298-1-robdclark@gmail.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: force-enable CONFIG_MSM_MMCC_8996 as built-inDmitry Baryshkov1-0/+1
Enable CONFIG_MSM_MMCC_8996, the multimedia clock controller on Qualcomm MSM8996 to prevent the the board from hitting the probe deferral timeouts in CI run. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Helen Koike <helen.koike@collabora.com> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://lore.kernel.org/r/20231008132320.762542-2-dmitry.baryshkov@linaro.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-26drm/ci: pick up -external-fixes from the merge target repoDmitry Baryshkov1-0/+5
In case of the merge requests it might be useful to push repo-specific fixes which have not yet propagated to the -external-fixes branch in the main UPSTREAM_REPO. For example, in case of drm/msm development, we are staging fixes locally for testing, before pushing them to the drm/drm repo. Thus, if the CI run was triggered by merge request, also pick up the -external fixes basing on the the CI_MERGE target repo / and branch. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Helen Koike <helen.koike@collabora.com> Link: https://lore.kernel.org/r/20231008132320.762542-1-dmitry.baryshkov@linaro.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2023-10-24drm/rockchip: vop: Add NV15, NV20 and NV30 supportJonas Karlman3-17/+86
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the Rockchip Video Decoder on RK322X, RK3288, RK3328 and RK3399. Also add support for 10-bit 4:4:4 format while at it. V5: Use drm_format_info_min_pitch() for correct bpp Add missing NV21, NV61 and NV42 formats V4: Rework RK3328/RK3399 win0/1 data to not affect RK3368 V2: Added NV30 support Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Sandy Huang <hjc@rock-chips.com> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Tested-by: Christopher Obbard <chris.obbard@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231023173718.188102-3-jonas@kwiboo.se
2023-10-24drm/fourcc: Add NV20 and NV30 YUV formatsJonas Karlman1-0/+8
DRM_FORMAT_NV20 and DRM_FORMAT_NV30 formats is the 2x1 and non-subsampled variant of NV15, a 10-bit 2-plane YUV format that has no padding between components. Instead, luminance and chrominance samples are grouped into 4s so that each group is packed into an integer number of bytes: YYYY = UVUV = 4 * 10 bits = 40 bits = 5 bytes The '20' and '30' suffix refers to the optimum effective bits per pixel which is achieved when the total number of luminance samples is a multiple of 4. V2: Added NV30 format Signed-off-by: Jonas Karlman <jonas@kwiboo.se> Reviewed-by: Sandy Huang <hjc@rock-chips.com> Reviewed-by: Christopher Obbard <chris.obbard@collabora.com> Tested-by: Christopher Obbard <chris.obbard@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231023173718.188102-2-jonas@kwiboo.se
2023-10-24drm/rockchip: vop2: rename window formats to show window type using themAndy Yan1-15/+15
formats_win_full_10bit is for cluster window, formats_win_full_10bit_yuyv is for rk356x esmart, rk3588 esmart window will support more format. formats_win_lite is for smart window. Rename it based the windows type may let meaning is clearer Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231018094339.2476142-1-andyshrk@163.com
2023-10-24drm/rockchip: vop2: Add more supported 10bit formatsAndy Yan2-6/+61
Add 10 bit RGB and AFBC based YUV format supported by vop2. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231018094318.2476081-1-andyshrk@163.com
2023-10-24drm/rockchip: vop2: remove the unsupported format of cluster windowAndy Yan2-26/+1
The cluster window on vop2 doesn't support linear yuv format(NV12/16/24), it only support afbc based yuv format(DRM_FORMAT_YUV420_8BIT/10BIT), which will be added in next patch. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231018094239.2475851-1-andyshrk@163.com
2023-10-24drm/rockchip: vop: fix format bpp calculationAndy Yan1-2/+16
We can't rely on cpp for bpp calculation as the cpp of some formats(DRM_FORMAT_YUV420_8BIT/10BIT, etc) is zero. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231018094210.2475771-1-andyshrk@163.com
2023-10-24drm/bridge: synopsys: dw-mipi-dsi: Fix hcomponent lbcc for burst modeLiu Ying1-6/+12
In order to support burst mode, vendor drivers set lane_mbps higher than bandwidth through DPI interface. So, calculate horizontal component lane byte clock cycle(lbcc) based on lane_mbps instead of pixel clock rate for burst mode. Fixes: ac87d23694f4 ("drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbcc") Reported-by: Heiko Stรผbner <heiko@sntech.de> Closes: https://lore.kernel.org/linux-arm-kernel/5979575.UjTJXf6HLC@diego/T/#u Tested-by: Heiko Stรผbner <heiko@sntech.de> # px30 minievb with xinpeng xpp055c272 Signed-off-by: Liu Ying <victor.liu@nxp.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231018035212.1778767-1-victor.liu@nxp.com
2023-10-24drm/client: Convert drm_client_buffer_addfb() to drm_mode_addfb2()Geert Uytterhoeven1-8/+5
Currently drm_client_buffer_addfb() uses the legacy drm_mode_addfb(), which uses bpp and depth to guess the wanted buffer format. However, drm_client_buffer_addfb() already knows the exact buffer format, so there is no need to convert back and forth between buffer format and bpp/depth, and the function can just call drm_mode_addfb2() directly instead. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/4b84adfc686288714e69d0442d22f1259ff74903.1697379891.git.geert@linux-m68k.org
2023-10-23drm/vc4: fix typoDario Binacchi1-1/+1
Replace 'pack' with 'back'. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231023085929.1445594-1-dario.binacchi@amarulasolutions.com
2023-10-19drm/panel: ili9882t: Avoid blurred screen from fast sleepCong Yang1-1/+21
At present, we have found that there may be a problem of blurred screen during fast sleep/resume. The direct cause of the blurred screen is that the IC does not receive 0x28/0x10. Because of the particularity of the IC, before the panel enters sleep hid must stop scanning, as i2c_hid_core_suspend before ili9882t_disable. If move the ili9882t_enter_sleep_mode function to ili9882t_unprepare, touch reset will pull low before panel entersleep, which does not meet the timing requirements.. So in order to solve this problem, the IC can handle it through the exception mechanism when it cannot receive 0x28/0x10 command. Handling exceptions requires a reset 50ms delay. Refer to vendor detailed analysis [1]. Ilitek vendor also suggested switching the page before entering sleep to avoid panel IC not receiving 0x28/0x10 command. Note: 0x28 is display off, 0x10 is sleep in. [1]: https://github.com/ILITEK-LoganLin/Document/tree/main/ILITEK_Power_Sequence Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231013091844.804310-3-yangcong5@huaqin.corp-partner.google.com
2023-10-19drm/panel: ili9882t: Break out as separate driverCong Yang4-371/+769
The Starry ILI9882t-based panel should never have been part of the boe tv101wum driver, it is clearly based on the Ilitek ILI9882t display controller and if you look at the custom command sequences for the panel these clearly contain the signature Ilitek page switch (0xff) commands. The hardware has nothing in common with the other panels supported by this driver. Break this out into a separate driver and config symbol instead. If the placement here is out of convenience for using similar code, we should consider creating a helper library instead. Co-developed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231013091844.804310-2-yangcong5@huaqin.corp-partner.google.com
2023-10-19drm/ast: Move register constants to ast_reg.hThomas Zimmermann2-81/+101
Improve readability by putting all register constants into a separate header file. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-13-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_RThomas Zimmermann2-2/+2
Rename AST_IO_MISC_PORT_READ to AST_IO_VGAMR_R to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-12-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_RThomas Zimmermann2-4/+4
Rename AST_IO_INPUT_STATUS1_READ to AST_IO_VGAIR1_R to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-11-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_CRTC_PORT to AST_IO_VGACRIThomas Zimmermann8-162/+162
Rename AST_IO_CRTC_PORT to AST_IO_VGACRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-10-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_GR_PORT to AST_IO_VGAGRIThomas Zimmermann2-2/+2
Rename AST_IO_GR_PORT to AST_IO_VGAGRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-9-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_DAC_DATA to AST_IO_VGAPDRThomas Zimmermann2-4/+4
Rename AST_IO_DAC_DATA to AST_IO_VGAPDR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-8-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWRThomas Zimmermann2-2/+2
Rename AST_IO_DAC_INDEX_WRITE to AST_IO_VGADWR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-7-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRRThomas Zimmermann1-1/+1
Rename AST_IO_DAC_INDEX_READ to AST_IO_VGADRR to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-6-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_SEQ_PORT to AST_IO_VGASRIThomas Zimmermann2-12/+12
Rename AST_IO_VGA_SEQ_PORT to AST_IO_VGASRI to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-5-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAERThomas Zimmermann2-3/+3
Rename AST_IO_VGA_ENABLE_PORT to AST_IO_VGAER to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-4-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_WThomas Zimmermann3-4/+4
Rename AST_IO_MISC_PORT_WRITE to AST_IO_VGAMR_W to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-3-tzimmermann@suse.de
2023-10-19drm/ast: Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_WThomas Zimmermann2-6/+6
Rename AST_IO_AR_PORT_WRITE to AST_IO_VGAARI_W to align naming in the driver with documentation. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231017083653.10063-2-tzimmermann@suse.de
2023-10-18drm/ssd130x: Add support for the SSD132x OLED controller familyJavier Martinez Canillas5-27/+449
The Solomon SSD132x controllers (such as the SSD1322, SSD1325 and SSD1327) are used by 16 grayscale dot matrix OLED panels, extend the driver to also support this chip family. Instead adding an indirection level to allow the same modesetting pipeline to be used by both controller families, add another pipeline for SSD132x. This leads to some code duplication but it makes the driver easier to read and reason about. Once other controller families are added (e.g: SSD133x), some common code can be factored out in driver helpers to be shared by the different families. But that can be done later once these patterns emerge. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-5-javierm@redhat.com
2023-10-18drm/ssd130x: Rename commands that are shared across chip familiesJavier Martinez Canillas3-25/+30
There are some commands that are shared between the SSD130x and SSD132x controller families, define these as a common SSD13XX set of commands. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-4-javierm@redhat.com
2023-10-18drm/ssd130x: Add a controller family id to the device info dataJavier Martinez Canillas4-0/+15
To allow the driver to have a per Solomon display controller modesetting pipeline and support aother controller families besides SSD130x. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-3-javierm@redhat.com
2023-10-18drm/ssd130x: Replace .page_height field in device info with a constantJavier Martinez Canillas2-20/+18
This deemed useful to avoid hardcoding a page height and allow to support other Solomon controller families, but dividing the screen in pages seems to be something that is specific to the SSD130x chip family. For example, SSD132x chip family divides the screen in segments (columns) and common outputs (rows), so the concept of screen pages does not exist for the SSD132x family. Let's drop this field from the device info struct and just use a constant SSD130X_PAGE_HEIGHT macro to define the page height. While being there, replace hardcoded 8 values in places where it is used as the page height. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231014071520.1342189-2-javierm@redhat.com
2023-10-17drm/gpuvm: Dual-licence the drm_gpuvm code GPL-2.0 OR MITThomas Hellstrรถm1-1/+1
Dual-licence in order to make it possible for other non-GPL os'es to re-implement the code. The use of EXPORT_SYMBOL_GPL() is intentionally left untouched to prevent use of drm_gpuvm as a proxy for non-GPL drivers to access GPL-only kernel symbols. Much of the ideas and algorithms used in the drm_gpuvm code is already present in one way or another in MIT-licensed code. Cc: Danilo Krummrich <dakr@redhat.com> Cc: airlied@gmail.com Cc: daniel@ffwll.ch Cc: linux-kernel@vger.kernel.org Signed-off-by: Thomas Hellstrรถm <thomas.hellstrom@linux.intel.com> Acked-by: Danilo Krummrich <dakr@redhat.com> Reviewed-by: Francois Dugast <francois.dugast@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231010142725.8920-1-thomas.hellstrom@linux.intel.com
2023-10-16drm/panel: st7703: Add Powkiddy RGB30 Panel SupportChris Morgan1-0/+89
The Powkiddy RGB30 4 inch panel is a 4 inch 720x720 DSI panel used in the Powkiddy RGB30 handheld gaming device. Add support for it. Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231013183918.225666-4-macroalpha82@gmail.com
2023-10-16drm/rockchip: remove NR_LAYERS macro on vop2Andy Yan1-3/+1
There are 8 layers on rk3588, so a fix defined macro is not appropriate. Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231013122051.1594164-1-andyshrk@163.com
2023-10-16drm/rockchip: remove unused struct in vop2Andy Yan2-5/+0
These structs are undefined and un used. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231013122036.1594090-1-andyshrk@163.com
2023-10-16drm/rockchip: Fix type promotion bug in rockchip_gem_iommu_map()Dan Carpenter1-1/+1
The "ret" variable is declared as ssize_t and it can hold negative error codes but the "rk_obj->base.size" variable is type size_t. This means that when we compare them, they are both type promoted to size_t and the negative error code becomes a high unsigned value and is treated as success. Add a cast to fix this. Fixes: 38f993b7c59e ("drm/rockchip: Do not use DMA mapping API if attached to IOMMU domain") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/2bfa28b5-145d-4b9e-a18a-98819dd686ce@moroto.mountain
2023-10-16drm/bridge: lt9611uxc: fix the race in the error pathDmitry Baryshkov1-4/+6
If DSI host attachment fails, the LT9611UXC driver will remove the bridge without ensuring that there is no outstanding HPD work being done. In rare cases this can result in the warnings regarding the mutex being incorrect. Fix this by forcebly freing IRQ and flushing the work. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 0 PID: 10 at kernel/locking/mutex.c:582 __mutex_lock+0x468/0x77c Modules linked in: CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G U 6.6.0-rc5-next-20231011-gd81f81c2b682-dirty #1206 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Workqueue: events lt9611uxc_hpd_work pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0x468/0x77c lr : __mutex_lock+0x468/0x77c sp : ffff8000800a3c70 x29: ffff8000800a3c70 x28: 0000000000000000 x27: ffffd595fe333000 x26: ffff7c2f0002c005 x25: ffffd595ff1b3000 x24: ffffd595fccda5a0 x23: 0000000000000000 x22: 0000000000000002 x21: ffff7c2f056d91c8 x20: 0000000000000000 x19: ffff7c2f056d91c8 x18: fffffffffffe8db0 x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000 x14: 000000000006efb8 x13: 0000000000000000 x12: 0000000000000037 x11: 0000000000000001 x10: 0000000000001470 x9 : ffff8000800a3ae0 x8 : ffff7c2f0027f8d0 x7 : ffff7c2f0027e400 x6 : ffffd595fc702b54 x5 : 0000000000000000 x4 : ffff8000800a0000 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7c2f0027e400 Call trace: __mutex_lock+0x468/0x77c mutex_lock_nested+0x24/0x30 drm_bridge_hpd_notify+0x2c/0x5c lt9611uxc_hpd_work+0x6c/0x80 process_one_work+0x1ec/0x51c worker_thread+0x1ec/0x3e4 kthread+0x120/0x124 ret_from_fork+0x10/0x20 irq event stamp: 15799 hardirqs last enabled at (15799): [<ffffd595fc702ba4>] finish_task_switch.isra.0+0xa8/0x278 hardirqs last disabled at (15798): [<ffffd595fd5a1580>] __schedule+0x7b8/0xbd8 softirqs last enabled at (15794): [<ffffd595fc690698>] __do_softirq+0x498/0x4e0 softirqs last disabled at (15771): [<ffffd595fc69615c>] ____do_softirq+0x10/0x1c Fixes: bc6fa8676ebb ("drm/bridge/lontium-lt9611uxc: move HPD notification out of IRQ handler") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231011220002.382422-1-dmitry.baryshkov@linaro.org
2023-10-16drm/bridge: imx: Add i.MX93 MIPI DSI supportLiu Ying3-0/+929
Freescale i.MX93 SoC embeds a Synopsys Designware MIPI DSI host controller and a Synopsys Designware MIPI DPHY. Some configurations and extensions to them are controlled by i.MX93 media blk-ctrl. Add a DRM bridge for i.MX93 MIPI DSI by using existing DW MIPI DSI bridge helpers and implementing i.MX93 MIPI DSI specific extensions. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230821034008.3876938-10-victor.liu@nxp.com
2023-10-16drm/bridge: synopsys: dw-mipi-dsi: Disable HSTX and LPRX timeout checkLiu Ying1-2/+2
According to Synopsys DW MIPI DSI host databook, HSTX and LPRX timeout contention detections are measured in TO_CLK_DIVISION cycles. However, the current driver programs magic values to TO_CLK_DIVISION, HSTX_TO_CNT and LPRX_TO_CNT register fields, which makes timeout error event wrongly happen for some video modes, at least for the typical 1920x1080p@60 video mode read from a HDMI monitor driven by ADV7535 DSI to HDMI bridge. While at it, the current driver doesn't enable interrupt to handle or complain about the error status, so true error just happens silently except for display distortions by visual check. Disable the timeout check by setting those timeout register fields to zero for now until someone comes along with better computations for the timeout values. Although the databook doesn't mention what happens when they are set to zero, it turns out the false error doesn't happen for the 1920x1080p@60 video mode at least. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230821034008.3876938-8-victor.liu@nxp.com
2023-10-16drm/bridge: synopsys: dw-mipi-dsi: Set minimum lane byte clock cycles for โ†ตLiu Ying1-1/+13
HSA and HBP According to Synopsys support channel, each region of HSA, HBP and HFP must have minimum number of 10 bytes where constant 4 bytes are for HSS or HSE and 6 bytes are for blanking packet(header + CRC). Hence, the below table comes in. +------------+----------+-------+ | data lanes | min lbcc | bytes | +------------+----------+-------+ | 1 | 10 | 1*10 | +------------+----------+-------+ | 2 | 5 | 2*5 | +------------+----------+-------+ | 3 | 4 | 3*4 | +------------+----------+-------+ | 4 | 3 | 4*3 | +------------+----------+-------+ Implement the minimum lbcc numbers to make sure that the values programmed into DSI_VID_HSA_TIME and DSI_VID_HBP_TIME registers meet the minimum number requirement. For DSI_VID_HLINE_TIME register, it seems that the value programmed should be based on mode->htotal as-is, instead of sum up HSA, HBP, HFP and HDISPLAY. This helps the case where Raydium RM67191 DSI panel is connected, since it's video timing for hsync length is only 2 pixels and without this patch the programmed value for DSI_VID_HSA_TIME is only 2 with 4 data lanes. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230821034008.3876938-7-victor.liu@nxp.com
2023-10-16drm/bridge: synopsys: dw-mipi-dsi: Use pixel clock rate to calculate lbccLiu Ying1-1/+9
To get better accuration, use pixel clock rate to calculate lbcc instead of lane_mbps since the pixel clock rate is in KHz while lane_mbps is in MHz. Without this, distorted image can be seen on a HDMI monitor connected with i.MX93 11x11 EVK through ADV7535 DSI to HDMI bridge in 1920x1080p@60 video mode. Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230821034008.3876938-6-victor.liu@nxp.com