aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-06-22drm: bridge: dw-mipi-dsi: Fix enable/disable of DSI controllerOndrej Jirman1-12/+16
Before this patch, booting to Linux VT and doing a simple: echo 2 > /sys/class/graphics/fb0/blank echo 0 > /sys/class/graphics/fb0/blank would result in failures to re-enable the panel. Mode set callback is called only once during boot in this scenario, while calls to enable/disable callbacks are balanced afterwards. The driver doesn't work unless userspace calls modeset before enabling the CRTC/connector. This patch moves enabling of the DSI host from mode_set into pre_enable callback, and removes some old hacks where this bridge driver is directly calling into other bridge driver's callbacks. pre_enable_prev_first flag is set on the panel's bridge so that panel drivers will get their prepare function called between DSI host's pre_enable and enable callbacks, so that they get a chance to perform panel setup while DSI host is already enabled in command mode. Otherwise panel's prepare would be called before DSI host is enabled, and any DSI communication used in prepare callback would fail. With all these changes, the enable/disable sequence is now well balanced, and host's and panel's callbacks are called in proper order documented in the drm_panel API documentation without needing the old hacks. (Mainly that panel->prepare is called when DSI host is ready to allow the panel driver to send DSI commands and vice versa during disable.) Tested on Pinephone Pro. Trace of the callbacks follows. Before: [ 1.253882] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.290732] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.475576] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.475593] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 13.722799] panel-himax-hx8394 ff960000.dsi.0: disable [ 13.774502] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 13.774526] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 17.735796] panel-himax-hx8394 ff960000.dsi.0: prepare [ 17.923522] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 17.923540] panel-himax-hx8394 ff960000.dsi.0: enable [ 17.944330] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 17.944335] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 17.944340] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 echo 2 > /sys/class/graphics/fb0/blank [ 431.148583] panel-himax-hx8394 ff960000.dsi.0: disable [ 431.169259] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 431.169268] panel-himax-hx8394 ff960000.dsi.0: Failed to enter sleep mode: -110 [ 431.169282] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 431.169316] panel-himax-hx8394 ff960000.dsi.0: unprepare [ 431.169357] pclk_mipi_dsi0 already disabled echo 0 > /sys/class/graphics/fb0/blank [ 432.796851] panel-himax-hx8394 ff960000.dsi.0: prepare [ 432.981537] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 432.981568] panel-himax-hx8394 ff960000.dsi.0: enable [ 433.002290] dw-mipi-dsi-rockchip ff960000.dsi: failed to write command FIFO [ 433.002299] panel-himax-hx8394 ff960000.dsi.0: sending command 0xb9 failed: -110 [ 433.002312] panel-himax-hx8394 ff960000.dsi.0: Panel init sequence failed: -110 ----------------------------------------------------------------------- After: [ 1.248372] dw-mipi-dsi-rockchip ff960000.dsi: mode_set [ 1.248704] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 1.285377] panel-himax-hx8394 ff960000.dsi.0: prepare [ 1.468392] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 1.468421] panel-himax-hx8394 ff960000.dsi.0: enable echo 2 > /sys/class/graphics/fb0/blank [ 16.210357] panel-himax-hx8394 ff960000.dsi.0: disable [ 16.261315] dw-mipi-dsi-rockchip ff960000.dsi: post_disable [ 16.261339] panel-himax-hx8394 ff960000.dsi.0: unprepare echo 0 > /sys/class/graphics/fb0/blank [ 19.161453] dw-mipi-dsi-rockchip ff960000.dsi: pre_enable [ 19.197869] panel-himax-hx8394 ff960000.dsi.0: prepare [ 19.382141] dw-mipi-dsi-rockchip ff960000.dsi: enable [ 19.382158] panel-himax-hx8394 ff960000.dsi.0: enable (But depends on functionality intorduced in Linux 6.3, so this patch will not build on older kernels when applied to older stable branches.) Fixes: 46fc51546d44 ("drm/bridge/synopsys: Add MIPI DSI host controller bridge") Signed-off-by: Ondrej Jirman <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/sched: Make sure we wait for all dependencies in kill_jobs_cb()Boris Brezillon1-8/+33
drm_sched_entity_kill_jobs_cb() logic is omitting the last fence popped from the dependency array that was waited upon before drm_sched_entity_kill() was called (drm_sched_entity::dependency field), so we're basically waiting for all dependencies except one. In theory, this wait shouldn't be needed because resources should have their users registered to the dma_resv object, thus guaranteeing that future jobs wanting to access these resources wait on all the previous users (depending on the access type, of course). But we want to keep these explicit waits in the kill entity path just in case. Let's make sure we keep all dependencies in the array in drm_sched_job_dependency(), so we can iterate over the array and wait in drm_sched_entity_kill_jobs_cb(). We also make sure we wait on drm_sched_fence::finished if we were originally asked to wait on drm_sched_fence::scheduled. In that case, we assume the intent was to delegate the wait to the firmware/GPU or rely on the pipelining done at the entity/scheduler level, but when killing jobs, we really want to wait for completion not just scheduling. v2: - Don't evict deps in drm_sched_job_dependency() v3: - Always wait for drm_sched_fence::finished fences in drm_sched_entity_kill_jobs_cb() when we see a sched_fence v4: - Fix commit message - Fix a use-after-free bug v5: - Flag deps on which we should only wait for the scheduled event at insertion time v6: - Back to v4 implementation - Add Christian's R-b Cc: Frank Binns <[email protected]> Cc: Sarah Walker <[email protected]> Cc: Donald Robson <[email protected]> Cc: Luben Tuikov <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Sumit Semwal <[email protected]> Cc: "Christian König" <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Suggested-by: "Christian König" <[email protected]> Reviewed-by: "Christian König" <[email protected]> Acked-by: Luben Tuikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/i2c: Switch i2c drivers back to use .probe()Uwe Kleine-König2-2/+2
After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type"), all drivers being converted to .probe_new() and then commit 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert back to (the new) .probe() to be able to eventually drop .probe_new() from struct i2c_driver. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Handle HS/VS polarityMarek Vasut1-2/+25
Add support for handling the HS/VS sync signals polarity in the bridge driver, otherwise e.g. DSIM bridge feeds the TC358762 inverted polarity sync signals and the image is shifted to the left, up, and wobbly. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Guess the meaning of LCDCTRL bitsMarek Vasut1-3/+13
The register content and behavior is very similar to TC358764 VP_CTRL. All the bits except for unknown bit 6 also seem to match, even though the datasheet is just not available. Add a comment and reuse the bit definitions. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Instruct DSI host to generate HSE packetsMarek Vasut1-1/+1
This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Switch to atomic opsMarek Vasut1-6/+9
Switch the bridge driver over to atomic ops. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358762: Split register programming from pre-enable to enableMarek Vasut1-2/+9
Move the register programming part, which actually enables the bridge and makes it push data out of its DPI side, into the enable callback. The DSI host like DSIM may not be able to transmit commands in pre_enable, moving the register programming into enable assures it can transmit commands. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/bridge: tc358764: Use BIT() macro for actual bitsMarek Vasut1-6/+6
None of these four bits are bitfields, use BIT() macro and treat them as bits. No functional change. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-22drm/panel: simple: Add connector_type for innolux_at043tn24Fabio Estevam1-0/+1
The innolux at043tn24 display is a parallel LCD. Pass the 'connector_type' information to avoid the following warning: panel-simple panel: Specify missing connector_type Signed-off-by: Fabio Estevam <[email protected]> Fixes: 41bcceb4de9c ("drm/panel: simple: Add support for Innolux AT043TN24") Reviewed-by: Sam Ravnborg <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm/shmem-helper: Switch to reservation lockDmitry Osipenko5-135/+115
Replace all drm-shmem locks with a GEM reservation lock. This makes locks consistent with dma-buf locking convention where importers are responsible for holding reservation lock for all operations performed over dma-bufs, preventing deadlock between dma-buf importers and exporters. Suggested-by: Daniel Vetter <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Reviewed-by: Emil Velikov <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm: Don't assert held reservation lock for dma-buf mmappingDmitry Osipenko4-8/+0
Don't assert held dma-buf reservation lock on memory mapping of exported buffer. We're going to change dma-buf mmap() locking policy such that exporters will have to handle the lock. The previous locking policy caused deadlock problem for DRM drivers in a case of self-imported dma-bufs once these drivers are moved to use reservation lock universally. The problem is solved by moving the lock down to exporters. This patch prepares DRM drivers for the locking policy update. Reviewed-by: Emil Velikov <[email protected]> Acked-by: Christian König <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm/i915/guc/slpc: Apply min softlimit correctlyVinay Belgaumkar1-1/+1
The scenario being fixed here is depicted in the following sequence- modprobe i915 echo 1 > /sys/class/drm/card0/gt/gt0/slpc_ignore_eff_freq echo 300 > /sys/class/drm/card0/gt_min_freq_mhz (RPn) cat /sys/class/drm/card0/gt_cur_freq_mhz --> cur == RPn as expected echo 1 > /sys/kernel/debug/dri/0/gt0/reset --> reset cat /sys/class/drm/card0/gt_min_freq_mhz --> cached freq is RPn cat /sys/class/drm/card0/gt_cur_freq_mhz --> it's not RPn, but RPe!! When SLPC reinitializes, it sets SLPC min freq to efficient frequency. Even if we disable efficient freq post that, we should restore the cached min freq (via H2G) for it to take effect. v2: Clarify commit message (Ashutosh) Fixes: 95ccf312a1e4 ("drm/i915/guc/slpc: Allow SLPC to use efficient frequency") Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm/etnaviv: slow down FE idle pollingLucas Stach3-5/+15
Currently the FE is spinning way too fast when polling for new work in the FE idleloop. As each poll fetches 16 bytes from memory, a GPU running at 1GHz with the current setting of 200 wait cycle between fetches causes 80 MB/s of memory traffic just to check for new work when the GPU is otherwise idle, which is more FE traffic than in some GPU loaded cases. Significantly increase the number of wait cycles to slow down the poll interval to ~30µs, limiting the FE idle memory traffic to 512 KB/s, while providing a max latency which should not hurt most use-cases. The FE WAIT command seems to have some unknown discrete steps in the wait cycles so we may over/undershoot the target a bit, but that should be harmless. If the GPU core base frequency is unknown keep the 200 wait cycles as a sane default. Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Sui Jingfeng <[email protected]> Tested-by: Sui Jingfeng <[email protected]> Reviewed-by: Christian Gmeiner <[email protected]>
2023-06-21drm/bridge: lt9611uxc: Add MODULE_FIRMWARE macroJuerg Haefliger1-1/+5
The module loads firmware so add a MODULE_FIRMWARE macro to provide that information via modinfo. Signed-off-by: Juerg Haefliger <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm: etnaviv: Replace of_platform.h with explicit includesRob Herring1-1/+3
Etnaviv doesn't use anything from of_platform.h, but depends on of.h, of_device.h, and platform_device.h which are all implicitly included, but that is going to be removed soon. Signed-off-by: Rob Herring <[email protected]> Tested-by: Sui Jingfeng <[email protected]> Signed-off-by: Lucas Stach <[email protected]>
2023-06-21drm/i915/psr: Use hw.adjusted mode when calculating io/fast wake timesJouni Högander1-2/+2
Encoder compute config is changing hw.adjusted mode. Uapi.adjusted mode doesn't get updated before psr compute config gets called. This causes io and fast wake line calculation using adjusted mode containing values before encoder adjustments. Fix this by using hw.adjusted mode instead of uapi.adjusted mode. Cc: Stanislav Lisovskiy <[email protected]> Signed-off-by: Jouni Högander <[email protected]> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8475 Fixes: cb42e8ede5b4 ("drm/i915/psr: Use calculated io and fast wake lines") Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/mtl: Skip using vbt hdmi_level_shifter selection on MTLRadhakrishna Sripada1-1/+2
The hdmi_level_shifter part of General Bytes definition in VBT, which was used for choosing different levels on earlier platforms is now a hidden optin and shows the default value of 0. The level shifter is now to be deduced from hdmi_default_entry in intel_ddi_buf_trans for each phy. Skip providing the default hw provided value to force driver to choose hdmi default entry. Bspec: 20124 Cc: Khaled Almahallawy <[email protected]> Cc: Lee Shawn C <[email protected]> Cc: Clint Taylor <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Clint Taylor <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/mtl: Fix SSC selection for MPLLARadhakrishna Sripada1-1/+2
Driver does not clear the default SSC for MPLLA. This causes link training failure when trying to use 10G and 20G rates. Fix the behaviour and enable ssc only when we really want. Fixes: 237e7be0bf57 ("drm/i915/mtl: For DP2.0 10G and 20G rates use MPLLA") Cc: Mika Kahola <[email protected]> Cc: Clint Taylor <[email protected]> Cc: Khaled Almahallawy <[email protected]> Cc: Arun R Murthy <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Tested-by: Khaled Almahallawy <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/mtl: Add new vswing table for C20 phy to support DP 1.4Lee Shawn C1-2/+24
Add vswing table to support DP 1.4 for C20 phy. v2: rename mtl_c10_trans v3: add default_entry for mtl_c20_trans_dp14 v4: rename mtl_cx0_trans_dp14 Bspec: 74104 Signed-off-by: Lee Shawn C <[email protected]> Cc: Mika Kahola <[email protected]> Cc: Clint Taylor <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Cc: Uma Shankar <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Reviewed-by: Radhakrishna Sripada <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/mtl: update DP 2.0 vswing table for C20 phyLee Shawn C1-1/+1
Update preset 15 setting to align the latest bspec value. Bspec: 74104 Signed-off-by: Lee Shawn C <[email protected]> Cc: Mika Kahola <[email protected]> Cc: Clint Taylor <[email protected]> Cc: Radhakrishna Sripada <[email protected]> Cc: Uma Shankar <[email protected]> Reviewed-by: Mika Kahola <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2Jeff Layton1-1/+1
I've been experiencing some intermittent crashes down in the display driver code. The symptoms are ususally a line like this in dmesg: amdgpu 0000:30:00.0: [drm] Failed to create MST payload for port 000000006d3a3885: -5 ...followed by an Oops due to a NULL pointer dereference. Switch to using mgr->dev instead of state->dev since "state" can be NULL in some cases. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855 Suggested-by: Jani Nikula <[email protected]> Signed-off-by: Jeff Layton <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/gsc: Fix intel_gsc_uc_fw_proxy_init_done with directed wakerefsAlan Previn4-9/+14
intel_gsc_uc_fw_proxy_init_done is used by a few code paths and usages. However, certain paths need a wakeref while others can't take a wakeref such as from the runtime_pm_resume callstack. Add a param into this helper to allow callers to direct whether to take the wakeref or not. This resolves the following bug: INFO: task sh:2607 blocked for more than 61 seconds. Not tainted 6.3.0-pxp-gsc-final-jun14+ #297 "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:sh state:D stack:13016 pid:2607 ppid:2602 flags:0x00004000 Call Trace: <TASK> __schedule+0x47b/0xe10 schedule+0x58/0xd0 rpm_resume+0x1cc/0x800 ? __pfx_autoremove_wake_function+0x10/0x10 __pm_runtime_resume+0x42/0x80 __intel_runtime_pm_get+0x19/0x80 [i915] gsc_uc_get_fw_status+0x10/0x50 [i915] intel_gsc_uc_fw_init_done+0x9/0x20 [i915] intel_gsc_uc_load_start+0x5b/0x130 [i915] __uc_resume+0xa5/0x280 [i915] intel_runtime_resume+0xd4/0x250 [i915] ? __pfx_pci_pm_runtime_resume+0x10/0x10 __rpm_callback+0x3c/0x160 Fixes: 8c33c3755b75 ("drm/i915/gsc: take a wakeref for the proxy-init-completion check") Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Convert HSW/BDW to use port_mask for DDI probeVille Syrjälä2-19/+33
Make HSW/BDW use port_mask for output probing as well. To achieve that the strap checks are moved into intel_ddi_init() itself. Or should we move them to the runtime port_mask init instead? Maybe not since the hardware is still there, just not connected to anything. v2: Account for DDI-E in strap detection Keep to the old CRT->DDI init order Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Init DDI outputs based on port_mask on skl+Ville Syrjälä1-67/+13
Instead of listing every platform's possible DDI outputs in intel_setup_outputs() just loop over the new port_mask to achieve the same thing. HSW/BDW were left as is since they still look at the straps as well. DSI is still a mess. For now just check for the relevant platforms explicitly. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Beef up SDVO/HDMI port checksVille Syrjälä2-5/+29
The SDVO code already warns when the port in question doesn't actually support SDVO. Let's make that also bail the encoder registration like the generic assert_port_valid() we added. And add a similar thing for g4x HDMI, mainly because on g4x itsefl port D only supports DP but not SDVO/HDMI. For the other platforms the generic port_mask check should actually be sufficient, but since we're here might as well list the ports. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Assert that the port being initialized is validVille Syrjälä8-0/+24
Sprinkle some asserts to catch any mishaps in the port_mask vs. output init. For DDI/DP/HDMI/SDVO I decided that we want to bail out for an invalid port since those are the encoder types where we might want consider driving the whole thing from the VBT child device list, and bogus VBTs could be a real issue (if for no other reason than the i915.vbt_firmware). For DVO and HSW/BDW CRT port I just threw the assert in there for good measure. Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Assert that device info bitmasks have enough bitsVille Syrjälä1-0/+4
Sprinkle in some BUILD_BUG_ON()s to make sure some of the bitmasks used in the device info have enough bits. Do we have a better place for this sort of stuff? v2: Relocate to the new place Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Introduce device info port_maskVille Syrjälä3-50/+113
Declare the available DVO/SDVO/HDMI/DP/DDI ports in the device info. The other outputs (LVDS/TV/DSI/VGA) are left out since for most of them we don't consider them as "ports". DSI we should probably perhaps include somehow in the device info. Just not sure how. Or we just introduce a HAS_DSI() and call it a day? TODO: figure out what to do about the subplatform stuff. Would it be better to declare those directly with a different device info or not? Also not sure the icl port-f stuff matters even. Bspec claims there are icl SKUs with far less ports than that and we don't seem to check for those either? v2: Fix TC5 vs. TC6 mixup on TGL (Jani) Drop DDI C for now on TGL, and add a FIXME (Jani) Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Remove bogus DDI-F from hsw/bdw output initVille Syrjälä1-2/+0
HSW/BDW don't have DDI-F so don't go looking for one. Seems to have been accidentally left behind when the skl+ stuff got split out in commit 097d9e902068 ("drm/i915/display: remove strap checks from gen 9"). Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915/adlp+: Allow DC states along with PW2 only for PWB functionalityImre Deak1-8/+8
A recent bspec update added a restriction on when DC states can be enabled: [Before enabling DC states:] """ PG2 can be kept enabled only because PGB requires PG2. Do not use PG2 functions, such as type-C DDIs. DMC will dynamically control PG1, PGA, PG2, PGB. """ Accordingly prevent DC states if PW2 (aka PG2) is enabled for any other functionality. Bpsec: 49193 Fixes: 88c487938414 ("drm/i915: Use separate "DC off" power well for ADL-P and DG2") Reported-by: Kai Vehmanen <[email protected]> Tested-by: Ambica Pramod <[email protected]> Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-20drm/i915: Fix a NULL vs IS_ERR() bugDan Carpenter1-2/+2
The mmap_offset_attach() function returns error pointers, it doesn't return NULL. Fixes: eaee1c085863 ("drm/i915: Add a function to mmap framebuffer obj") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ZH7tHLRZ9oBjedjN@moroto (cherry picked from commit 3a89311387cde27da8e290458b2d037133c1f7b5) Signed-off-by: Tvrtko Ursulin <[email protected]>
2023-06-20drm/i915: make i915_drm_client_fdinfo() reference conditional againArnd Bergmann2-3/+1
The function is only defined if CONFIG_PROC_FS is enabled: ld.lld: error: undefined symbol: i915_drm_client_fdinfo >>> referenced by i915_driver.c >>> drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in archive vmlinux.a Use the PTR_IF() helper to make the reference NULL otherwise. Fixes: e894b724c316d ("drm/i915: Use the fdinfo helper") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8084c63743a88472af0a34ba209eebf9caea1dae) Signed-off-by: Tvrtko Ursulin <[email protected]>
2023-06-20drm/i915/huc: Fix missing error code in intel_huc_init()Harshit Mogalapalli1-0/+1
Smatch warns: drivers/gpu/drm/i915/gt/uc/intel_huc.c:388 intel_huc_init() warn: missing error code 'err' When the allocation of VMAs fail: The value of err is zero at this point and it is passed to PTR_ERR and also finally returning zero which is success instead of failure. Fix this by adding the missing error code when VMA allocation fails. Fixes: 08872cb13a71 ("drm/i915/mtl/huc: auth HuC via GSC") Signed-off-by: Harshit Mogalapalli <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit ce432fd34cc6c7b7af06d1403ec0be19d1e518dc) Signed-off-by: Tvrtko Ursulin <[email protected]>
2023-06-20drm/i915/gsc: take a wakeref for the proxy-init-completion checkAlan Previn1-8/+14
Ensure intel_gsc_uc_fw_init_done and intel_gsc_uc_fw_proxy_init takes a wakeref before reading GSC Shim registers. NOTE: another patch in review also adds a call from selftest to this same function. (https://patchwork.freedesktop.org/series/117713/) which is why i am adding the wakeref inside the callee, not the caller. v2: - add a helper, 'gsc_uc_get_fw_status' for both callers (Daniele Ceraolo) Fixes: 99afb7cc8c44 ("drm/i915/pxp: Add ARB session creation and cleanup") Signed-off-by: Alan Previn <[email protected]> Reviewed-by: Daniele Ceraolo Spurio <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 8c33c3755b75c98d8eb490df345b4187a295a1a8) Signed-off-by: Tvrtko Ursulin <[email protected]>
2023-06-19drm/vkms: Fix all kernel-doc warnings of the vkms_composer fileMaíra Canal1-2/+4
Fix the following warnings: drivers/gpu/drm/vkms/vkms_composer.c:42: warning: Function parameter or member 'frame_info' not described in 'pre_mul_alpha_blend' drivers/gpu/drm/vkms/vkms_composer.c:42: warning: Excess function parameter 'src_frame_info' description in 'pre_mul_alpha_blend' drivers/gpu/drm/vkms/vkms_composer.c:93: warning: Cannot understand * @wb_frame_info: The writeback frame buffer metadata on line 93 - I thought it was a doc line by correcting variable names and adding function name. Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19drm/vkms: Add kernel-doc to the function vkms_compose_row()Maíra Canal1-0/+13
The function vkms_compose_row() was introduced in the code without any documentation. In order to make the function more clear, add a kernel-doc to it. Suggested-by: Melissa Wen <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19mm: ptep_get() conversionRyan Roberts1-2/+6
Convert all instances of direct pte_t* dereferencing to instead use ptep_get() helper. This means that by default, the accesses change from a C dereference to a READ_ONCE(). This is technically the correct thing to do since where pgtables are modified by HW (for access/dirty) they are volatile and therefore we should always ensure READ_ONCE() semantics. But more importantly, by always using the helper, it can be overridden by the architecture to fully encapsulate the contents of the pte. Arch code is deliberately not converted, as the arch code knows best. It is intended that arch code (arm64) will override the default with its own implementation that can (e.g.) hide certain bits from the core code, or determine young/dirty status by mixing in state from another source. Conversion was done using Coccinelle: ---- // $ make coccicheck \ // COCCI=ptepget.cocci \ // SPFLAGS="--include-headers" \ // MODE=patch virtual patch @ depends on patch @ pte_t *v; @@ - *v + ptep_get(v) ---- Then reviewed and hand-edited to avoid multiple unnecessary calls to ptep_get(), instead opting to store the result of a single call in a variable, where it is correct to do so. This aims to negate any cost of READ_ONCE() and will benefit arch-overrides that may be more complex. Included is a fix for an issue in an earlier version of this patch that was pointed out by kernel test robot. The issue arose because config MMU=n elides definition of the ptep helper functions, including ptep_get(). HUGETLB_PAGE=n configs still define a simple huge_ptep_clear_flush() for linking purposes, which dereferences the ptep. So when both configs are disabled, this caused a build error because ptep_get() is not defined. Fix by continuing to do a direct dereference when MMU=n. This is safe because for this config the arch code cannot be trying to virtualize the ptes because none of the ptep helpers are defined. Link: https://lkml.kernel.org/r/[email protected] Reported-by: kernel test robot <[email protected]> Link: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Signed-off-by: Ryan Roberts <[email protected]> Cc: Adrian Hunter <[email protected]> Cc: Alexander Potapenko <[email protected]> Cc: Alexander Shishkin <[email protected]> Cc: Alex Williamson <[email protected]> Cc: Al Viro <[email protected]> Cc: Andrey Konovalov <[email protected]> Cc: Andrey Ryabinin <[email protected]> Cc: Christian Brauner <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Dimitri Sivanich <[email protected]> Cc: Dmitry Vyukov <[email protected]> Cc: Ian Rogers <[email protected]> Cc: Jason Gunthorpe <[email protected]> Cc: Jérôme Glisse <[email protected]> Cc: Jiri Olsa <[email protected]> Cc: Johannes Weiner <[email protected]> Cc: Kirill A. Shutemov <[email protected]> Cc: Lorenzo Stoakes <[email protected]> Cc: Mark Rutland <[email protected]> Cc: Matthew Wilcox <[email protected]> Cc: Miaohe Lin <[email protected]> Cc: Michal Hocko <[email protected]> Cc: Mike Kravetz <[email protected]> Cc: Mike Rapoport (IBM) <[email protected]> Cc: Muchun Song <[email protected]> Cc: Namhyung Kim <[email protected]> Cc: Naoya Horiguchi <[email protected]> Cc: Oleksandr Tyshchenko <[email protected]> Cc: Pavel Tatashin <[email protected]> Cc: Roman Gushchin <[email protected]> Cc: SeongJae Park <[email protected]> Cc: Shakeel Butt <[email protected]> Cc: Uladzislau Rezki (Sony) <[email protected]> Cc: Vincenzo Frascino <[email protected]> Cc: Yu Zhao <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-06-19drivers/gpu: use ARCH_DMA_MINALIGN instead of ARCH_KMALLOC_MINALIGNCatalin Marinas1-3/+3
ARCH_DMA_MINALIGN represents the minimum (static) alignment for safe DMA operations while ARCH_KMALLOC_MINALIGN is the minimum kmalloc() objects alignment. Link: https://lkml.kernel.org/r/[email protected] Signed-off-by: Catalin Marinas <[email protected]> Tested-by: Isaac J. Manjarres <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Alasdair Kergon <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: Arnd Bergmann <[email protected]> Cc: Christoph Hellwig <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Herbert Xu <[email protected]> Cc: Jerry Snitselaar <[email protected]> Cc: Joerg Roedel <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Jonathan Cameron <[email protected]> Cc: Lars-Peter Clausen <[email protected]> Cc: Logan Gunthorpe <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Mark Brown <[email protected]> Cc: Mike Snitzer <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Robin Murphy <[email protected]> Cc: Saravana Kannan <[email protected]> Cc: Vlastimil Babka <[email protected]> Cc: Will Deacon <[email protected]> Signed-off-by: Andrew Morton <[email protected]>
2023-06-19drm/amdgpu: Remove struct drm_driver.gem_prime_mmapThomas Zimmermann1-1/+0
The callback struct drm_driver.gem_prime_mmap as been removed in commit 0adec22702d4 ("drm: Remove struct drm_driver.gem_prime_mmap"). Do not assign to it. The assigned function, drm_gem_prime_mmap(), is now the default for the operation, so there is no change in functionality. Signed-off-by: Thomas Zimmermann <[email protected]> Fixes: 0adec22702d4 ("drm: Remove struct drm_driver.gem_prime_mmap") Cc: Thomas Zimmermann <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Cc: [email protected] Cc: [email protected] Reviewed-by: Christian König <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19Merge drm/drm-next into drm-misc-nextThomas Zimmermann878-18960/+67627
Backmerging into drm-misc-next to get commit 2c1c7ba457d4 ("drm/amdgpu: support partition drm devices"), which is required to fix commit 0adec22702d4 ("drm: Remove struct drm_driver.gem_prime_mmap"). Signed-off-by: Thomas Zimmermann <[email protected]>
2023-06-19drm/i915: Fix a NULL vs IS_ERR() bugDan Carpenter1-2/+2
The mmap_offset_attach() function returns error pointers, it doesn't return NULL. Fixes: eaee1c085863 ("drm/i915: Add a function to mmap framebuffer obj") Signed-off-by: Dan Carpenter <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ZH7tHLRZ9oBjedjN@moroto
2023-06-19drm: Remove struct drm_driver.gem_prime_mmapThomas Zimmermann20-39/+3
All drivers initialize this field with drm_gem_prime_mmap(). Call the function directly and remove the field. Simplifies the code and resolves a long-standing TODO item. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19drm/msm: Initialize mmap offset after constructing the buffer objectThomas Zimmermann2-10/+8
Only the msm driver provides its own implementation of gem_prime_mmap from struct drm_driver. All other drivers use the drm_gem_prime_mmap() helper. Initialize the mmap offset when constructing the buffer object in msm and reduce the gem_prime_mmap code to the generic helper. Prepares msm for the removal of struct drm_driver.gem_prime_mmap. Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19drm/i915: make i915_drm_client_fdinfo() reference conditional againArnd Bergmann2-3/+1
The function is only defined if CONFIG_PROC_FS is enabled: ld.lld: error: undefined symbol: i915_drm_client_fdinfo >>> referenced by i915_driver.c >>> drivers/gpu/drm/i915/i915_driver.o:(i915_drm_driver) in archive vmlinux.a Use the PTR_IF() helper to make the reference NULL otherwise. Fixes: e894b724c316d ("drm/i915: Use the fdinfo helper") Signed-off-by: Arnd Bergmann <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Acked-by: Randy Dunlap <[email protected]> Tested-by: Randy Dunlap <[email protected]> # build-tested Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19drm/tidss: Add support for AM625 DSSAradhya Bhatia3-1/+59
Add support for the DSS controller on TI's AM625 SoC in the tidss driver. The AM625 DSS supports 2 video planes connecting to 2 video ports. The first plane is a full plane supporting all the features, while the 2nd plane is a "lite" plane without scaling support. The first video port in AM625 DSS internally provides DPI output to 2 OLDI transmitters. Each OLDI TX outputs 4 differential lanes of video output and 1 of clock output. This patch does not automatically enable the OLDI features of AM625 yet. That support for OLDI will be added subsequently. The second video port outputs DPI data directly out of the SoC. It has 24 data lines and can support a maximum of RGB888 output bus format. Signed-off-by: Aradhya Bhatia <[email protected]> Reviewed-by: Tomi Valkeinen <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-19Merge tag 'drm-msm-next-2023-06-18' of ↵Dave Airlie95-2469/+3884
https://gitlab.freedesktop.org/drm/msm into drm-next Updates for v6.5.. this includes a backmerg of drm-next tree to be able to use new DRM DSC helpers. Core: + Add Marijn Suijten as drm/msm reviewer + Adreno A660 bindings + SM8350 MDSS bindings fix + Fix adreno_is_a690() warnings + More generic (DRM) and MSM-specific DSC helpers DP: + Removed obsolete USB-PD remains + Documented DP compatible string for sm8550 platform DPU: + Enable missing features (DSPP, DSC, split display) on sc8180x, sc8280xp, sm8450 + Enabled writeback on sc7280 + Implemented tearcheck support to support vsync on SM150 and newer platforms + Native HDMI output support + Dropped unused features: regdma, GC, IGC + Fixed the DSC flush operations + Simplified QoS handling, removing obsolete and unused features and merging SSPP and WB code paths + Reworked dpu_encoder initialisation path + Enabled DSPP support on sdm845 + Disabled color-management if DSPP blocks are not available + Added support for DSC 1.2 blocks found on sm8350 and later + Added .fb_dirty to fix CMD panels DSI: + Drop powerup quirks in favour of using pre_enable_prev_first for downstream bridges + Fixed 14nm DSI PHY programming + Added support for DSI and 28nm DSI PHY on MSM8226 platform + Make use of DRM and MSM DSC helpers MDP5: + Added support for display controller on MSM8226 platform GPU: + A690 support + Don't set IO_PGTABLE_QUIRK_ARM_OUTER_WBWA on devices with coherent SMMU (like A690) + Move cmdstream dumping out of fence signaling path + Cleanups + Support for a6xx devices without GMU (aka "GMU wrapper" + a610 support + a619_holi support (a619 variant without GMU) Signed-off-by: Dave Airlie <[email protected]> From: Rob Clark <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/CAF6AEGsUB=tRB4nR6ZCJMuLhro5zN3BQWUSywVYbaipqqDZ_cQ@mail.gmail.com
2023-06-19Backmerge tag 'v6.4-rc7' of ↵Dave Airlie53-300/+262
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 6.4-rc7 Need this to pull in the msm work. Signed-off-by: Dave Airlie <[email protected]>
2023-06-19Merge tag 'amd-drm-next-6.5-2023-06-16' of ↵Dave Airlie91-427/+1206
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.5-2023-06-16: amdgpu: - Misc display fixes - W=1 fixes - Improve scheduler naming - DCN 3.1.4 fixes - kdoc fixes - Enable W=1 - VCN 4.0 fix - xgmi fixes - TOPDOWN fix for large BAR systems - eDP fix - PSR fixes - SubVP fixes - Freesync fix - DPIA fix - SMU 13.0.5 fixes - vblflash fix - RAS fixes - SDMA 4 fix - BO locking fix - BO backing store fix - NBIO 7.9 fixes - GC 9.4.3 fixes - GPU reset recovery fixes - HMM fix amdkfd: - Fix NULL check - Trap fixes - Queue count fix - Add event age tracking radeon: - fbdev client fix scheduler: - Avoid an infinite loop UAPI: - Add KFD event age tracking: Proposed ROCT-Thunk-Interface: https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/efdbf6cfbc026bd68ac3c35d00dacf84370eb81e https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/commit/1820ae0a2db85b6f584611dc0cde1a00e7c22915 Proposed ROCR-Runtime: https://github.com/RadeonOpenCompute/ROCR-Runtime/compare/master...zhums:ROCR-Runtime:new_event_wait_review https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/e1f5bdb88eb882ac798aeca2c00ea3fbb2dba459 https://github.com/RadeonOpenCompute/ROCR-Runtime/commit/7d26afd14107b5c2a754c1a3f415d89f3aabb503 drm: - DP MST fix Signed-off-by: Dave Airlie <[email protected]> From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-18drm/msm/a6xx: Add A610 speedbin supportKonrad Dybcio1-0/+27
A610 is implemented on at least three SoCs: SM6115 (bengal), SM6125 (trinket) and SM6225 (khaje). Trinket does not support speed binning (only a single SKU exists) and we don't yet support khaje upstream. Hence, add a fuse mapping table for bengal to allow for per-chip frequency limiting. Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Akhil P Oommen <[email protected]> Signed-off-by: Konrad Dybcio <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/542780/ Signed-off-by: Rob Clark <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.