aboutsummaryrefslogtreecommitdiff
path: root/include/drm
AgeCommit message (Collapse)AuthorFilesLines
2023-08-10drm/exec: use unique instead of local labelChristian König1-7/+7
GCC forbids to jump to labels in loop conditions and a new clang check stumbled over this. So instead using a local label inside the loop condition use an unique label outside of it. Fixes: 09593216bff1 ("drm: execution context for GEM buffers v7") Link: https://gcc.gnu.org/onlinedocs/gcc/Statement-Exprs.html Link: https://github.com/ClangBuiltLinux/linux/issues/1890 Link: https://github.com/llvm/llvm-project/commit/20219106060208f0c2f5d096eb3aed7b712f5067 Reported-by: Nathan Chancellor <[email protected]> Reported-by: Naresh Kamboju <[email protected]> CC: Boris Brezillon <[email protected]> Signed-off-by: Christian König <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Signed-off-by: Boris Brezillon <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-04drm/gem: fix lockdep check for dma-resv lockDanilo Krummrich1-6/+9
When no custom lock is set to protect a GEMs GPUVA list, lockdep checks should fall back to the GEM objects dma-resv lock. With the current implementation we're setting the lock_dep_map of the GEM objects 'resv' pointer (in case no custom lock_dep_map is set yet) on drm_gem_private_object_init(). However, the GEM objects 'resv' pointer might still change after drm_gem_private_object_init() is called, e.g. through ttm_bo_init_reserved(). This can result in the wrong lock being tracked. To fix this, call dma_resv_held() directly from drm_gem_gpuva_assert_lock_held() and fall back to the GEMs lock_dep_map pointer only if an actual custom lock is set. Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings") Reviewed-by: Dave Airlie <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-08-03drm/drm_plane.h: fix grammar of the commentSui Jingfeng1-1/+1
Signed-off-by: Sui Jingfeng <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Daniel Vetter <[email protected]>
2023-08-03drm/panel: Fix kernel-doc typo for `follower_lock`Douglas Anderson1-1/+1
In the kernel doc for the `follower_lock` member of `struct drm_panel` there was a typo where it was called `followers_lock`. This resulted in a warning when making "htmldocs": ./include/drm/drm_panel.h:270: warning: Function parameter or member 'follower_lock' not described in 'drm_panel' Fix the typo. Fixes: de0874165b83 ("drm/panel: Add a way for other devices to follow panel state") Reported-by: Stephen Rothwell <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230802074727.1.I4036706ad5e7f45e80d41b777164258e52079cd8@changeid
2023-08-02drm/bridge: Add debugfs print for bridge chainsTomi Valkeinen1-0/+3
DRM bridges are not visible to the userspace and it may not be immediately clear if the chain is somehow constructed incorrectly. I have had two separate instances of a bridge driver failing to do a drm_bridge_attach() call, resulting in the bridge connector not being part of the chain. In some situations this doesn't seem to cause issues, but it will if DRM_BRIDGE_ATTACH_NO_CONNECTOR flag is used. Add a debugfs file to print the bridge chains. For me, on this TI AM62 based platform, I get the following output: encoder[39] bridge[0] type: 0, ops: 0x0 bridge[1] type: 0, ops: 0x0, OF: /bus@f0000/i2c@20000000/dsi@e:toshiba,tc358778 bridge[2] type: 0, ops: 0x3, OF: /bus@f0000/i2c@20010000/hdmi@48:lontium,lt8912b bridge[3] type: 11, ops: 0x7, OF: /hdmi-connector:hdmi-connector Tested-by: Alexander Stein <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Tomi Valkeinen <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230802-drm-bridge-chain-debugfs-v4-1-7e3ae3d137c0@ideasonboard.com
2023-08-01drm/panel: Add a way for other devices to follow panel stateDouglas Anderson1-0/+82
These days, it's fairly common to see panels that have touchscreens attached to them. The panel and the touchscreen can somewhat be thought of as totally separate devices and, historically, this is how Linux has treated them. However, treating them as separate isn't necessarily the best way to model the two devices, it was just that there was no better way. Specifically, there is little practical reason to have the touchscreen powered on when the panel is turned off, but if we model the devices separately we have no way to keep the two devices' power states in sync with each other. The issue described above makes it sound as if the problem here is just about efficiency. We're wasting power keeping the touchscreen powered up when the screen is off. While that's true, the problem can go deeper. Specifically, hardware designers see that there's no reason to have the touchscreen on while the screen is off and then build hardware assuming that software would never turn the touchscreen on while the screen is off. In the very simplest case of hardware designs like this, the touchscreen and the panel share some power rails. In most cases, this turns out not to be terrible and is, again, just a little less efficient. Specifically if we tell Linux that the touchscreen and the panel are using the same rails then Linux will keep the rails on when _either_ device is turned on. That ends to work OK-ish, but now if you turn the panel off not only will the touchscreen remain powered, but the power rails for the panel itself won't be switched off, burning extra power. The above two inefficiencies are _extra_ minor when you consider the fact that laptops rarely spend much time with the screen off. The main use case would be when an external screen (and presumably a power supply) is attached. Unfortunately, it gets worse from here. On sc7180-trogdor-homestar, for instance, the display's TCON (timing controller) sometimes crashes if you don't power cycle it whenever you stop and restart the video stream (like during a modeset). The touchscreen keeping the power rails on causes real problems. One proposal in the homestar timeframe was to move the touchscreen to an always-on rail, dedicating the main power rail to the panel. That caused _different_ problems as talked about in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to the regulator"). The end result of all of this was to add an extra regulator to the board, increasing cost. Recently, Cong Yang posted a patch [1] where things are even worse. The panel and touch controller on that system seem even more intimately tied together and really can't be thought of separately. To address this issue, let's start allowing devices to register themselves as "panel followers". These devices will get called after a panel has been powered on and before a panel is powered off. This makes the panel the primary device in charge of the power state, which matches how userspace uses it. The panel follower API should be fairly straightforward to use. The current code assumes that panel followers are using device tree and have a "panel" property pointing to the panel to follow. More flexibility and non-DT implementations could be added as needed. Right now, panel followers can follow the prepare/unprepare functions. There could be arguments made that, instead, they should follow enable/disable. I've chosen prepare/unprepare for now since those functions are guaranteed to power up/power down the panel and it seems better to start the process earlier. A bit of explaining about why this is a roll-your-own API instead of using something more standard: 1. In standard APIs in Linux, parent devices are automatically powered on when a child needs power. Applying that here, it would mean that we'd force the panel on any time someone was listening to the touchscreen. That, unfortunately, would have broken homestar's need (if we hadn't changed the hardware, as per above) where the panel absolutely needs to be able to power cycle itself. While one could argue that homestar is broken hardware and we shouldn't have the API do backflips for it, _officially_ the eDP timing guidelines agree with homestar's needs and the panel power sequencing diagrams show power going off. It's nice to be able to support this. 2. We could, conceibably, try to add a new flag to device_link causing the parent to be in charge of power. Then we could at least use normal pm_runtime APIs. This sounds great, except that we run into problems with initial probe. As talked about in the later patch ("HID: i2c-hid: Support being a panel follower") the initial power on of a panel follower might need to do things (like add sub-devices) that aren't allowed in a runtime_resume function. The above complexities explain why this API isn't using common functions. That being said, this patch is very small and self-contained, so if someone was later able to adapt it to using more common APIs while solving the above issues then that could happen in the future. [1] https://lore.kernel.org/r/20230519032316.3464732-1-yangcong5@huaqin.corp-partner.google.com Reviewed-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.3.Icd5f96342d2242051c754364f4bee13ef2b986d4@changeid
2023-08-01drm/panel: Check for already prepared/enabled in drm_panelDouglas Anderson1-0/+14
In a whole pile of panel drivers, we have code to make the prepare/unprepare/enable/disable callbacks behave as no-ops if they've already been called. It's silly to have this code duplicated everywhere. Add it to the core instead so that we can eventually delete it from all the drivers. Note: to get some idea of the duplicated code, try: git grep 'if.*>prepared' -- drivers/gpu/drm/panel git grep 'if.*>enabled' -- drivers/gpu/drm/panel NOTE: arguably, the right thing to do here is actually to skip this patch and simply remove all the extra checks from the individual drivers. Perhaps the checks were needed at some point in time in the past but maybe they no longer are? Certainly as we continue transitioning over to "panel_bridge" then we expect there to be much less variety in how these calls are made. When we're called as part of the bridge chain, things should be pretty simple. In fact, there was some discussion in the past about these checks [1], including a discussion about whether the checks were needed and whether the calls ought to be refcounted. At the time, I decided not to mess with it because it felt too risky. Looking closer at it now, I'm fairly certain that nothing in the existing codebase is expecting these calls to be refcounted. The only real question is whether someone is already doing something to ensure prepare()/unprepare() match and enabled()/disable() match. I would say that, even if there is something else ensuring that things match, there's enough complexity that adding an extra bool and an extra double-check here is a good idea. Let's add a drm_warn() to let people know that it's considered a minor error to take advantage of drm_panel's double-checking but we'll still make things work fine. We'll also add an entry to the official DRM todo list to remove the now pointless check from the panels after this patch lands and, eventually, fixup anyone who is triggering the new warning. [1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid Acked-by: Neil Armstrong <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid
2023-07-31drm/tests: helpers: Create a helper to allocate an atomic stateMaxime Ripard1-0/+5
As we gain more tests, boilerplate to allocate an atomic state and free it starts to be there more and more as well. In order to reduce the allocation boilerplate, we can create a helper to create that atomic state, and call an action when the test is done. This will also clean up the exit path. Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-07-31drm/tests: helpers: Create a helper to allocate a locking ctxMaxime Ripard1-0/+2
As we get more and more tests, the locking context initialisation creates more and more boilerplate, both at creation and destruction. Let's create a helper that will allocate, initialise a context, and register kunit actions to clean up once the test is done. Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-07-29drm: Remove references to removed transitional helpersGeert Uytterhoeven2-32/+21
The transitional helpers were removed a long time ago, but some references stuck. Remove them. Fixes: 21ebe615c16994f3 ("drm: Remove transitional helpers") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ad4a2f1f9fa7da083132f6c35469c77a3f9e2f0e.1689779916.git.geert+renesas@glider.be
2023-07-29drm: Spelling s/randevouz/rendez-vous/Geert Uytterhoeven1-1/+1
Fix a misspelling of "rendez-vous". Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Hamza Mahfooz <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/084bf178dd676a4f07933eb9fcd04d3e30a779ba.1689600209.git.geert+renesas@glider.be
2023-07-29drm: Spelling s/sempahore/semaphore/Geert Uytterhoeven1-1/+1
Fix misspellings of "semaphore". Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Hamza Mahfooz <[email protected]> Acked-by: Rodrigo Vivi <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/8b0542c12a2427f34a792c41ac2d2a2922874bfa.1689600102.git.geert+renesas@glider.be
2023-07-25drm/fb-helper: Remove unused inline function drm_fb_helper_defio_init()YueHaibing1-5/+0
Since commit 8e86dee02253 ("drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs") this inline helper not used anymore. Fixes: 8e86dee02253 ("drm/fb-helper: Remove drm_fb_helper_defio_init() and update docs") Signed-off-by: YueHaibing <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24Merge drm/drm-next into drm-misc-nextThomas Zimmermann1-3/+2
Backmerging to get v6.5-rc2. Signed-off-by: Thomas Zimmermann <[email protected]>
2023-07-20drm/syncobj: add IOCTL to register an eventfdSimon Ser1-1/+5
Introduce a new DRM_IOCTL_SYNCOBJ_EVENTFD IOCTL which signals an eventfd from a syncobj. This is useful for Wayland compositors to handle wait-before-submit. Wayland clients can send a timeline point to the compositor before the point has materialized yet, then compositors can wait for the point to materialize via this new IOCTL. The existing DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT IOCTL is not suitable because it blocks. Compositors want to integrate the wait with their poll(2)-based event loop. Requirements for new uAPI: - User-space patch: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262 - IGT: https://lists.freedesktop.org/archives/igt-dev/2023-July/057893.html v2: - Wait for fence when flags is zero - Improve documentation (Pekka) - Rename IOCTL (Christian) - Fix typo in drm_syncobj_add_eventfd() (Christian) v3: - Link user-space + IGT patches - Add reference from overview docs v4: fix IOCTL number conflict with GETFB2 (Nicholas Choi, Vitaly Prosyak) Signed-off-by: Simon Ser <[email protected]> Reviewed-by: Christian König <[email protected]> Acked-by: Pekka Paalanen <[email protected]> Cc: Jason Ekstrand <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Bas Nieuwenhuizen <[email protected]> Cc: Daniel Stone <[email protected]> Cc: James Jones <[email protected]> Cc: Austin Shafer <[email protected]> Cc: Vitaly Prosyak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-20drm: debugfs: provide infrastructure to dump a DRM GPU VA spaceDanilo Krummrich1-0/+25
This commit adds a function to dump a DRM GPU VA space and a macro for drivers to register the struct drm_info_list 'gpuvas' entry. Most likely, most drivers might maintain one DRM GPU VA space per struct drm_file, but there might also be drivers not having a fixed relation between DRM GPU VA spaces and a DRM core infrastructure, hence we need the indirection via the driver iterating it's maintained DRM GPU VA spaces. Reviewed-by: Boris Brezillon <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-20drm: manager to keep track of GPUs VA mappingsDanilo Krummrich3-0/+791
Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, using an interval tree (RB-tree). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Acked-by: Thomas Hellström <[email protected]> Acked-by: Matthew Brost <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Tested-by: Matthew Brost <[email protected]> Tested-by: Donald Robson <[email protected]> Suggested-by: Dave Airlie <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-17Merge tag 'drm-misc-next-2023-07-13' of ↵Daniel Vetter8-66/+138
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for v6.6: UAPI Changes: * fbdev: * Make fbdev userspace interfaces optional; only leaves the framebuffer console active * prime: * Support dma-buf self-import for all drivers automatically: improves support for many userspace compositors Cross-subsystem Changes: * backlight: * Fix interaction with fbdev in several drivers * base: Convert struct platform.remove to return void; part of a larger, tree-wide effort * dma-buf: Acquire reservation lock for mmap() in exporters; part of an on-going effort to simplify locking around dma-bufs * fbdev: * Use Linux device instead of fbdev device in many places * Use deferred-I/O helper macros in various drivers * i2c: Convert struct i2c from .probe_new to .probe; part of a larger, tree-wide effort * video: * Avoid including <linux/screen_info.h> Core Changes: * atomic: * Improve logging * prime: * Remove struct drm_driver.gem_prime_mmap plus driver updates: all drivers now implement this callback with drm_gem_prime_mmap() * gem: * Support execution contexts: provides locking over multiple GEM objects * ttm: * Support init_on_free * Swapout fixes Driver Changes: * accel: * ivpu: MMU updates; Support debugfs * ast: * Improve device-model detection * Cleanups * bridge: * dw-hdmi: Improve support for YUV420 bus format * dw-mipi-dsi: Fix enable/disable of DSI controller * lt9611uxc: Use MODULE_FIRMWARE() * ps8640: Remove broken EDID code * samsung-dsim: Fix command transfer * tc358764: Handle HS/VS polarity; Use BIT() macro; Various cleanups * Cleanups * ingenic: * Kconfig REGMAP fixes * loongson: * Support display controller * mgag200: * Minor fixes * mxsfb: * Support disabling overlay planes * nouveau: * Improve VRAM detection * Various fixes and cleanups * panel: * panel-edp: Support AUO B116XAB01.4 * Support Visionox R66451 plus DT bindings * Cleanups * ssd130x: * Support per-controller default resolution plus DT bindings * Reduce memory-allocation overhead * Cleanups * tidss: * Support TI AM625 plus DT bindings * Implement new connector model plus driver updates * vkms * Improve write-back support * Documentation fixes Signed-off-by: Daniel Vetter <[email protected]> From: Thomas Zimmermann <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20230713090830.GA23281@linux-uq9g
2023-07-17drm/file: use explicit values for enum drm_minor_typeSimon Ser1-4/+4
This makes it clearer that the values cannot be changed because they are ABI. Signed-off-by: Simon Ser <[email protected]> Reviewed-by:James Zhu <[email protected]> Reviewed-by: Thomas Zimmermann <[email protected]> Cc: Christian König <[email protected]> Cc: Marek Olšák <[email protected]> Cc: Daniel Vetter <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-12drm: execution context for GEM buffers v7Christian König1-0/+123
This adds the infrastructure for an execution context for GEM buffers which is similar to the existing TTMs execbuf util and intended to replace it in the long term. The basic functionality is that we abstracts the necessary loop to lock many different GEM buffers with automated deadlock and duplicate handling. v2: drop xarray and use dynamic resized array instead, the locking overhead is unnecessary and measurable. v3: drop duplicate tracking, radeon is really the only one needing that. v4: fixes issues pointed out by Danilo, some typos in comments and a helper for lock arrays of GEM objects. v5: some suggestions by Boris Brezillon, especially just use one retry macro, drop loop in prepare_array, use flags instead of bool v6: minor changes suggested by Thomas, Boris and Danilo v7: minor typos pointed out by checkpatch.pl fixed Signed-off-by: Christian König <[email protected]> Reviewed-by: Boris Brezillon <[email protected]> Reviewed-by: Danilo Krummrich <[email protected]> Tested-by: Danilo Krummrich <[email protected]> Acked-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-11Merge v6.5-rc1 into drm-misc-fixesMaxime Ripard20-133/+302
Boris needs 6.5-rc1 in drm-misc-fixes to prevent a conflict. Signed-off-by: Maxime Ripard <[email protected]>
2023-06-27drm/bridge: dw-hdmi: change YUV420 selection logic at clock setupAdrián Larumbe1-0/+2
Right now clocking value selection code is prioritising RGB, YUV444 modes over YUV420 for HDMI2 sinks. However, because of the bus format selection procedure in dw-hdmi, for HDMI2 sinks YUV420 is the format that will always be picked during the drm bridge chain check stage. Later on dw_hdmi_setup will configure a colour space based on the bus format that doesn't match the pixel value we had calculated as described above. Fix it by bringing back dw-hdmi bus format check when picking the right pixel clock. Signed-off-by: Adrián Larumbe <[email protected]> Acked-by: Neil Armstrong <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/6230bfae2cd97cf6527fc62ba5c850464919ccf8.1687702042.git.adrian.larumbe@collabora.com
2023-06-26drm/prime: Unexport helpers for fd/handle conversionThomas Zimmermann1-7/+0
Unexport drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). Both are only used internally within the PRIME code. v2: * reword docs as functions are now unexported (Simon) Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Simon Ser <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-26drm: Clear fd/handle callbacks in struct drm_driverThomas Zimmermann3-14/+6
Clear all assignments of struct drm_driver's fd/handle callbacks to drm_gem_prime_fd_to_handle() and drm_gem_prime_handle_to_fd(). These functions are called by default. Add a TODO item to convert vmwgfx to the defaults as well. v2: * remove TODO item (Zack) * also update amdgpu's amdgpu_partition_driver Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Simon Ser <[email protected]> Acked-by: Alex Deucher <[email protected]> Acked-by: Jeffrey Hugo <[email protected]> # qaic Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-26drm: Enable PRIME import/export for all driversThomas Zimmermann1-10/+2
Call drm_gem_prime_handle_to_fd() and drm_gem_prime_fd_to_handle() by default if no PRIME import/export helpers have been set. Both functions are the default for almost all drivers. DRM drivers implement struct drm_driver.gem_prime_import_sg_table to import dma-buf objects from other drivers. Having the function drm_gem_prime_fd_to_handle() functions set by default allows each driver to import dma-buf objects to itself, even without support for other drivers. For drm_gem_prime_handle_to_fd() it is similar: using it by default allows each driver to export to itself, even without support for other drivers. This functionality enables userspace to share per-driver buffers across process boundaries via PRIME (e.g., wlroots requires this functionality). The patch generalizes a pattern that has previously been implemented by GEM VRAM helpers [1] to work with any driver. For example, gma500 can now run the wlroots-based sway compositor. v2: * clean up docs and TODO comments (Simon, Zack) * clean up style in drm_getcap() Signed-off-by: Thomas Zimmermann <[email protected]> Link: https://lore.kernel.org/dri-devel/[email protected]/ # 1 Reviewed-by: Simon Ser <[email protected]> Acked-by: Alex Deucher <[email protected]> Reviewed-by: Jeffrey Hugo <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-26drm/sched: Call drm_sched_fence_set_parent() from drm_sched_fence_scheduled()Boris Brezillon1-3/+2
Drivers that can delegate waits to the firmware/GPU pass the scheduled fence to drm_sched_job_add_dependency(), and issue wait commands to the firmware/GPU at job submission time. For this to be possible, they need all their 'native' dependencies to have a valid parent since this is where the actual HW fence information are encoded. In drm_sched_main(), we currently call drm_sched_fence_set_parent() after drm_sched_fence_scheduled(), leaving a short period of time during which the job depending on this fence can be submitted. Since setting parent and signaling the fence are two things that are kinda related (you can't have a parent if the job hasn't been scheduled), it probably makes sense to pass the parent fence to drm_sched_fence_scheduled() and let it call drm_sched_fence_set_parent() before it signals the scheduled fence. Here is a detailed description of the race we are fixing here: Thread A Thread B - calls drm_sched_fence_scheduled() - signals s_fence->scheduled which wakes up thread B - entity dep signaled, checking the next dep - no more deps waiting - entity is picked for job submission by drm_gpu_scheduler - run_job() is called - run_job() tries to collect native fence info from s_fence->parent, but it's NULL => BOOM, we can't do our native wait - calls drm_sched_fence_set_parent() v2: * Fix commit message v3: * Add a detailed description of the race to the commit message * Add Luben's R-b Signed-off-by: Boris Brezillon <[email protected]> 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]> Reviewed-by: Luben Tuikov <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-23drm/sysfs: rename drm_sysfs_connector_status_event()Simon Ser1-2/+2
Rename drm_sysfs_connector_status_event() to drm_sysfs_connector_property_event(). Indeed, "status" is a bit vague: it can easily be confused with the connected/disconnected status of the connector. This function has nothing to do with connected/disconnected: it merely sends a notification that a connector's property has changed (e.g. HDCP, privacy screen, etc). Signed-off-by: Simon Ser <[email protected]> Cc: Manasi Navare <[email protected]> Cc: Sam Ravnborg <[email protected]> Cc: Harry Wentland <[email protected]> Cc: Daniel Vetter <[email protected]> Reviewed-by: Sam Ravnborg <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-21drm/shmem-helper: Switch to reservation lockDmitry Osipenko1-13/+1
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-19Merge drm/drm-next into drm-misc-nextThomas Zimmermann10-44/+161
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: Remove struct drm_driver.gem_prime_mmapThomas Zimmermann4-20/+2
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-19Merge tag 'drm-msm-next-2023-06-18' of ↵Dave Airlie1-0/+4
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 Airlie1-1/+17
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-15drm/dp_mst: Clear MSG_RDY flag before sending new messageWayne Lin1-2/+5
[Why] The sequence for collecting down_reply from source perspective should be: Request_n->repeat (get partial reply of Request_n->clear message ready flag to ack DPRX that the message is received) till all partial replies for Request_n are received->new Request_n+1. Now there is chance that drm_dp_mst_hpd_irq() will fire new down request in the tx queue when the down reply is incomplete. Source is restricted to generate interveleaved message transactions so we should avoid it. Also, while assembling partial reply packets, reading out DPCD DOWN_REP Sideband MSG buffer + clearing DOWN_REP_MSG_RDY flag should be wrapped up as a complete operation for reading out a reply packet. Kicking off a new request before clearing DOWN_REP_MSG_RDY flag might be risky. e.g. If the reply of the new request has overwritten the DPRX DOWN_REP Sideband MSG buffer before source writing one to clear DOWN_REP_MSG_RDY flag, source then unintentionally flushes the reply for the new request. Should handle the up request in the same way. [How] Separete drm_dp_mst_hpd_irq() into 2 steps. After acking the MST IRQ event, driver calls drm_dp_mst_hpd_irq_send_new_request() and might trigger drm_dp_mst_kick_tx() only when there is no on going message transaction. Changes since v1: * Reworked on review comments received -> Adjust the fix to let driver explicitly kick off new down request when mst irq event is handled and acked -> Adjust the commit message Changes since v2: * Adjust the commit message * Adjust the naming of the divided 2 functions and add a new input parameter "ack". * Adjust code flow as per review comments. Changes since v3: * Update the function description of drm_dp_mst_hpd_irq_handle_event Changes since v4: * Change ack of drm_dp_mst_hpd_irq_handle_event() to be an array align the size of esi[] Signed-off-by: Wayne Lin <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Acked-by: Jani Nikula <[email protected]> Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-15drm/display/dsc: Add drm_dsc_get_bpp_int helperJessica Zhang1-0/+1
Add helper to get the integer value of drm_dsc_config.bits_per_pixel Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Jessica Zhang <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/539268/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-06-15drm/display/dsc: add helper to set semi-const parametersDmitry Baryshkov1-0/+1
Add a helper setting config values which are typically constant across operating modes (table E-4 of the standard) and mux_word_size (which is a const according to 3.5.2). Signed-off-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Signed-off-by: Jessica Zhang <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/539280/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-06-15drm/display/dsc: Add flatness and initial scale value calculationsJessica Zhang1-0/+2
Add helpers to calculate det_thresh_flatness and initial_scale_value as these calculations are defined within the DSC spec. Reviewed-by: Marijn Suijten <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Signed-off-by: Jessica Zhang <[email protected]> Patchwork: https://patchwork.freedesktop.org/patch/539282/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2023-06-15Merge tag 'amd-drm-next-6.5-2023-06-09' of ↵Dave Airlie4-31/+106
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-6.5-2023-06-02: amdgpu: - SR-IOV fixes - Warning fixes - Misc code cleanups and spelling fixes - DCN 3.2 updates - Improved DC FAMS support for better power management - Improved DC SubVP support for better power management - DCN 3.1.x fixes - Max IB size query - DC GPU reset fixes - RAS updates - DCN 3.0.x fixes - S/G display fixes - CP shadow buffer support - Implement connector force callback - Z8 power improvements - PSP 13.0.10 vbflash support - Mode2 reset fixes - Store MQDs in VRAM to improve queue switch latency - VCN 3.x fixes - JPEG 3.x fixes - Enable DC_FP on LoongArch - GFXOFF fixes - GC 9.4.3 partition support - SDMA 4.4.2 partition support - VCN/JPEG 4.0.3 partition support - VCN 4.0.3 updates - NBIO 7.9 updates - GC 9.4.3 updates - Take NUMA into account when allocating memory - Handle NUMA for partitions - SMU 13.0.6 updates - GC 9.4.3 RAS updates - Stop including unused swiotlb.h - SMU 13.0.7 fixes - Fix clock output ordering on some APUs - Clean up DC FPGA code - GFX9 preemption fixes - Misc irq fixes - S0ix fixes - Add new DRM_AMDGPU_WERROR config parameter to help with CI - PCIe fix for RDNA2 - kdoc fixes - Documentation updates amdkfd: - Query TTM mem limit rather than hardcoding it - GC 9.4.3 partition support - Handle NUMA for partitions radeon: - Fix possible double free - Stop including unused swiotlb.h - Fix possible division by zero ttm: - Add query for TTM mem limit - Add NUMA awareness to pools - Export ttm_pool_fini() UAPI: - Add new ctx query flag to better handle GPU resets Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22290 - Add new interface to query and set shadow buffer for RDNA3 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21986 - Add new INFO query for max IB size Proposed userspace: https://gitlab.freedesktop.org/bnieuwenhuizen/mesa/-/commits/ib-rejection-v3 amd-drm-next-6.5-2023-06-09: amdgpu: - S0ix fixes - Initial SMU13 Overdrive support - kdoc fixes - Misc clode cleanups - Flexible array fixes - Display OTG fixes - SMU 13.0.6 updates - Revert some broken clock counter updates - Misc display fixes - GFX9 preemption fixes - Add support for newer EEPROM bad page table format - Add missing radeon secondary id - Add support for new colorspace KMS API - CSA fix - Stable pstate fixes for APUs - make vbl interface admin only - Handle PCI accelerator class amdkfd: - Add debugger support for gdb radeon: - Fix possible UAF drm: - Add Colorspace functionality UAPI: - Add debugger interface for enabling gdb Proposed userspace: https://github.com/ROCm-Developer-Tools/ROCdbgapi/tree/wip-dbgapi - Add KMS colorspace API Discussion: https://lists.freedesktop.org/archives/dri-devel/2023-June/408128.html From: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-09drm/connector: Allow drivers to pass list of supported colorspacesHarry Wentland1-2/+5
Drivers might not support all colorspaces defined in dp_colorspaces and hdmi_colorspaces. This results in undefined behavior when userspace is setting an unsupported colorspace. Allow drivers to pass the list of supported colorspaces when creating the colorspace property. v2: - Use 0 to indicate support for all colorspaces (Jani) - Print drm_dbg_kms message when drivers pass 0 to signal that drivers should specify supported colorspaecs explicity (Jani) v3: - Move changes to create a common colorspace_names array to separate patch v6: - Avoid magic when passing 0 for supported_colorspaces; be explicit in treating it as "all DP/HDMI" Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Sebastian Wick <[email protected]> Reviewed-by: Joshua Ashton <[email protected]> Reviewed-by: Simon Ser <[email protected]> Cc: Pekka Paalanen <[email protected]> Cc: Sebastian Wick <[email protected]> Cc: [email protected] Cc: Uma Shankar <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Joshua Ashton <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Simon Ser <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/connector: Print connector colorspace in state debugfsHarry Wentland1-0/+1
v3: Fix kerneldocs (kernel test robot) v4: Avoid returning NULL from drm_get_colorspace_name Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Sebastian Wick <[email protected]> Reviewed-by: Joshua Ashton <[email protected]> Reviewed-by: Simon Ser <[email protected]> Cc: Pekka Paalanen <[email protected]> Cc: Sebastian Wick <[email protected]> Cc: [email protected] Cc: Uma Shankar <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Joshua Ashton <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Simon Ser <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/connector: Use common colorspace_names arrayHarry Wentland1-0/+2
We an use bitfields to track the support ones for HDMI and DP. This allows us to print colorspaces in a consistent manner without needing to know whether we're dealing with DP or HDMI. v4: - Rename _MAX to _COUNT and leave comment to indicate it's not a valid value - Fix misplaced function doc v6: - Drop magic in drm_mode_create_colorspace_property for dealing with "0" supported_colorspaces. Expect the caller to always provide a non-zero supported_colorspaces. - Improve error checking and logging Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Sebastian Wick <[email protected]> Reviewed-by: Joshua Ashton <[email protected]> Reviewed-by: Simon Ser <[email protected]> Cc: Pekka Paalanen <[email protected]> Cc: Sebastian Wick <[email protected]> Cc: [email protected] Cc: Uma Shankar <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Joshua Ashton <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Simon Ser <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/connector: Add enum documentation to drm_colorspaceJoshua Ashton1-2/+68
To match the other enums, and add more information about these values. v2: - Specify where an enum entry comes from - Clarify DEFAULT and NO_DATA behavior - BT.2020 CYCC is "constant luminance" - correct type for BT.601 v4: - drop DP/HDMI clarifications that might create more questions than answers v5: - Add note on YCC and RGB variants Signed-off-by: Joshua Ashton <[email protected]> Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Reviewed-by: Sebastian Wick <[email protected]> Acked-by: Pekka Paalanen <[email protected]> Reviewed-by: Simon Ser <[email protected]> Cc: Pekka Paalanen <[email protected]> Cc: Sebastian Wick <[email protected]> Cc: [email protected] Cc: Uma Shankar <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Joshua Ashton <[email protected]> Cc: Simon Ser <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/connector: Convert DRM_MODE_COLORIMETRY to enumHarry Wentland2-25/+26
This allows us to use strongly typed arguments. v2: - Bring NO_DATA back - Provide explicit enum values v3: - Drop unnecessary '&' from kerneldoc (emersion) v4: - Fix Normal Colorimetry comment Signed-off-by: Harry Wentland <[email protected]> Reviewed-by: Simon Ser <[email protected]> Reviewed-by: Sebastian Wick <[email protected]> Reviewed-by: Pekka Paalanen <[email protected]> Reviewed-by: Joshua Ashton <[email protected]> Cc: Pekka Paalanen <[email protected]> Cc: Sebastian Wick <[email protected]> Cc: [email protected] Cc: Uma Shankar <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: Joshua Ashton <[email protected]> Cc: Simon Ser <[email protected]> Cc: Melissa Wen <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/ttm: add NUMA node id to the poolRajneesh Bhardwaj1-1/+3
This allows backing ttm_tt structure with pages from different NUMA pools. Tested-by: Graham Sider <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Christian König <[email protected]> Signed-off-by: Rajneesh Bhardwaj <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-09drm/ttm: Helper function to get TTM mem limitMukul Joshi1-1/+1
Add a helper function to get TTM memory limit. This is needed by KFD to set its own internal memory limits. Signed-off-by: Mukul Joshi <[email protected]> Reviewed-by: Christian König <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-06-09Merge tag 'drm-intel-next-2023-06-05' of ↵Dave Airlie6-10/+29
git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v6.5: Features and functionality: - Meteorlake (MTL) display enabling (Mika, Radhakrishna, José, Ankit, Clint, Gustavo, Imre, Anusha, Juha-Pekka, Matt) - Allow VRR to be toggled during fastsets (Ville) - Allow arbitrary refresh rates with VRR eDP panels (Ville) - Support async flips on linear buffers on display ver 12+ (Arun) - New debugfs for display clock frequencies (Bhanuprakash) - Taint kernel when force probing unsupported devices (Jani) - Expose CRTC CTM property on ILK/SNB/VLV (Ville) DRM subsystem changes: - EDID changes to support further conversion to struct drm_edid (Jani) - Move i915 DSC parameter code to common DRM helpers (Dmitry Baryshkov) Refactoring and cleanups: - CSC color refactoring (Ville) - VRR cleanups (Ville) - Finish i915 conversion to struct drm_edid (Jani) - Start high level display driver file (Jani) - Hotplug refactoring (Ville) - Misc display refactoring and cleanups (Jani, Ville) - Use device based logging for state checker warnings (Jani) - Split out hotplug and display irq handling (Jani) - Move display device info and probe under display/ (Matt) - HDCP cleanups (Suraj) - Use localized warning ignores instead of per file (Jani) - Remove superfluous enum i915_drm_suspend_mode (Maarten) - PSR, pfit, scaler and chicken register definition cleanups (Ville) - Constify pointers to hwmon_channel_info (Krzysztof Kozlowski) - Replace all non-returning strlcpy with strscpy (Azeem Shaikh) - Refactor VBT aux channel and DDC pin mapping (Ville) - Include cleanups (Jani) Fixes: - Fix modeset locking issue in DP MST HDCP (Suraj) - Fix disconnected Type-C/DP-alt disable at probe (Imre) - Fix HDMI PCON DSC usage and color conversions (Ankit) - Fix g4x HDMI infoframe/audio transmission port usage (Ville) - Avoid use-after-free when DP connector init fails (Maarten) - Fix voltage level for 480 MHz CDCLK (Chaitanya) - Check HPD live state during eDP probe (Ville) - Fix active port PLL selection for secondary MST streams (Imre) - Check pipe source size when using SKL+ scalers (Ville) - Fix MIPI DSI sleep sequences (Hans de Goede) - Fix DPCD register write order to match 128b/132b requirement (Arun) - Increase AUX timeout for Type-C (Suraj) - Communicate display power demands to pcode (Stan) - Fix potential division by zero in DSC compute config (Nikita Zhandarovich) - Fix fast wake AUX sync length (Jouni) - Fix potential oops on intel_get_crtc_new_encoder() (Ville) Merges: - drm-next backmerges (Rodrigo, Jani) Signed-off-by: Dave Airlie <[email protected]> From: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-02drm/i915_drm.h: fix a typoSui Jingfeng1-1/+1
'rbiter' -> 'arbiter' Signed-off-by: Sui Jingfeng <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-06-02drm/display/dp_mst: convert to struct drm_edidJani Nikula1-2/+7
Convert the topology manager to use struct drm_edid, add drm_dp_mst_edid_read() that returns drm_edid, and rewrite the old drm_dp_mst_get_edid() to use it. Note that the old drm_get_edid() ended up calling drm_connector_update_edid_property(). This responsibility is now deferred to drivers, which all do it anyway after calling drm_dp_mst_edid_read() or drm_dp_mst_get_edid(). Reviewed-by: Ankit Nautiyal <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/9c32e5c241934093fc4144eed4c01155e1f03af1.1685437501.git.jani.nikula@intel.com
2023-06-02drm/edid: add drm_edid_read_switcheroo()Jani Nikula1-0/+2
Add a switcheroo variant to the struct drm_edid based EDID read functions. Reviewed-by: Ankit Nautiyal <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4ab5ec994670ea50f95c8079c1f1ae915940b00f.1685437501.git.jani.nikula@intel.com
2023-06-02drm/display/dp_mst: drop has_audio from struct drm_dp_mst_portJani Nikula1-5/+0
Caching the has_audio in struct drm_dp_mst_port seems odd, and oddly placed. Defer audio handling to drivers, and use the info from the connector display info. i915 was the only one using it anyway. Reviewed-by: Ankit Nautiyal <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/7d9eefdf150870479c5797f027d4c2b0a19ff583.1685437500.git.jani.nikula@intel.com
2023-06-02drm/edid: parse display info has_audio similar to is_hdmiJani Nikula1-0/+8
Since we already iterate everything that's needed for determining audio, reduce the need to call drm_detect_monitor_audio() by storing has_audio to connector info. Reviewed-by: Ankit Nautiyal <[email protected]> Acked-by: Thomas Zimmermann <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/391a93b25c6bcbb39854aaa2813570cfb1580ed9.1685437500.git.jani.nikula@intel.com
Powered by cgit, Gruvboxed by Blaster4385.