- 01 Oct, 2021 1 commit
-
-
Christian König authored
Daniel pointed me towards this function and there are multiple obvious problems in the implementation. First of all the retry loop is not working as intended. In general the retry makes only sense if you grab the reference first and then check the sequence values. Then we should always also wait for the exclusive fence. It's also good practice to keep the reference around when installing callbacks to fences you don't own. And last the whole implementation was unnecessary complex and rather hard to understand which could lead to probably unexpected behavior of the IOCTL. Fix all this by reworking the implementation from scratch. Dropping the whole RCU approach and taking the lock instead. Only mildly tested and needs a thoughtful review of the code. Pushing through drm-misc-next to avoid merge conflicts and give the code another round of testing. v2: fix the reference counting as well v3: keep the excl fence handling as is for stable v4: back to testing all fences, drop RCU v5: handle in and out separately v6: add missing clear of events v7: change coding style as suggested by Michel, drop unused variables Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by:
Michel Dänzer <mdaenzer@redhat.com> CC: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20210720131110.88512-1-christian.koenig@amd.com
-
- 30 Sep, 2021 2 commits
-
-
Fangzhi Zuo authored
Include FEC, DSC, Link Training related headers. Change since v2 - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210927192324.5428-1-Jerry.Zuo@amd.com
-
Maxime Ripard authored
If CONFIG_OF is disabled, devm_drm_of_get_bridge won't be compiled in and drivers using that function will fail to build. Add an inline stub so that we can still build-test those cases. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Link: https://patchwork.freedesktop.org/patch/msgid/20210928181333.1176840-1-maxime@cerno.tech
-
- 29 Sep, 2021 19 commits
-
-
Matthew Auld authored
In commit: commit 667a50db Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Fri Jan 3 11:17:18 2014 +0100 drm/ttm: Refuse to fault (prime-) imported pages we introduced the restriction that imported pages should not be directly mappable through TTM(this also extends to userptr). In the next patch we want to introduce a shmem_tt backend, which should follow all the existing rules with TTM_PAGE_FLAG_EXTERNAL, since it will need to handle swapping itself, but with the above mapping restriction lifted. v2(Christian): - Don't OR together EXTERNAL and EXTERNAL_MAPPABLE in the definition of EXTERNAL_MAPPABLE, just leave it the caller to handle this correctly, otherwise we might encounter subtle issues. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Cc: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210929132629.353541-3-matthew.auld@intel.comSigned-off-by:
-
Matthew Auld authored
Move it to inline kernel-doc, otherwise we can't add empty lines it seems. Also drop the kernel-doc for pages_list, which doesn't seem to exist. v2(Christian): - Add a note that FLAG_SWAPPED shouldn't need to be touched by drivers. - Mention what FLAG_POPULATED does. Signed-off-by:
-
Matthew Auld authored
It covers more than just ttm_bo_type_sg usage, like with say dma-buf, since one other user is userptr in amdgpu, and in the future we might have some more. Hence EXTERNAL is likely a more suitable name. v2(Christian): - Rename these to TTM_TT_FLAGS_* - Fix up all the holes in the flag values Suggested-by:
-
Matthew Auld authored
No longer used it seems. Signed-off-by:
-
Matthew Auld authored
Now that setting page->index shouldn't be needed anymore, we are just left with setting page->mapping, and here it looks like amdgpu is the only user, where pointing the page->mapping at the dev_mapping is used to verify that the pages do indeed belong to the device, if userspace later tries to touch them. v2(Christian): - Drop the functions altogether and just inline modifying the page->mapping Signed-off-by: -
Matthew Auld authored
In commit: commit 58aa6622 Author: Thomas Hellstrom <thellstrom@vmware.com> Date: Fri Jan 3 11:47:23 2014 +0100 drm/ttm: Correctly set page mapping and -index members we started setting the page->mapping and page->index to point to the virtual address space, if the pages were faulted with TTM. Apparently this was needed for core-mm to able to reverse lookup the virtual address given the struct page, and potentially unmap it from the page tables. However as pointed out by Thomas, since we are now using PFN_MAP, instead of say PFN_MIXED, this should no longer be the case. There was also apparently some usecase in vmwgfx which needed this for dirty tracking, but that also doesn't appear to be the case anymore, as pointed out by Thomas. We still need keep the page->mapping for now, since that is still needed for different reasons, but we try to address that in the next patch. Signed-off-by:
-
Matthew Auld authored
In commit: commit 09ac4fcb Author: Felix Kuehling <Felix.Kuehling@amd.com> Date: Thu Jul 13 17:01:16 2017 -0400 drm/ttm: Implement vm_operations_struct.access v2 we added the vm_access hook, where we also directly call tt_swapin for some reason. If something is swapped-out then the ttm_tt must also be unpopulated, and since access_kmap should also call tt_populate, if needed, then swapping-in will already be handled there. If anything, calling tt_swapin directly here would likely always fail since the tt->pages won't yet be populated, or worse since the tt->pages array is never actually cleared in unpopulate this might lead to a nasty uaf. Fixes: 09ac4fcb ("drm/ttm: Implement vm_operations_struct.access v2") Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
-
Gurchetan Singh authored
This advertises the context init feature to userspace, along with a mask of supported capabilities. Signed-off-by:
Gurchetan Singh <gurchetansingh@chromium.org> Acked-by:
Lingfeng Yang <lfy@google.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-13-gurchetansingh@chromium.orgSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Gurchetan Singh authored
Similar to DRM_VMW_EVENT_FENCE_SIGNALED. Sends a pollable event to the DRM file descriptor when a fence on a specific ring is signaled. One difference is the event is not exposed via the UAPI -- this is because host responses are on a shared memory buffer of type BLOB_MEM_GUEST [this is the common way to receive responses with virtgpu]. As such, there is no context specific read(..) implementation either -- just a poll(..) implementation. Signed-off-by:
Nicholas Verne <nverne@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20210921232024.817-12-gurchetansingh@chromium.orgSigned-off-by:
-
Gurchetan Singh authored
For the Sommelier guest Wayland proxy, it's desirable for the DRM fd to be pollable in response to an host compositor event. This can also be used by the 3D driver to poll events on a CPU timeline. This enables the DRM fd associated with a particular 3D context to be polled independent of KMS events. The parameter VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK specifies the pollable rings. Signed-off-by:
-
Gurchetan Singh authored
We don't want fences from different 3D contexts (virgl, gfxstream, venus) to be on the same timeline. With explicit context creation, we can specify the number of ring each context wants. Execbuffer can specify which ring to use. Signed-off-by:
-
Gurchetan Singh authored
The plumbing is all here to do this. Since we always use the default fence context when allocating a fence, this makes no functional difference. We can't process just the largest fence id anymore, since it's it's associated with different timelines. It's fine for fence_id 260 to signal before 259. As such, process each fence_id individually. Signed-off-by:
-
Gurchetan Singh authored
These were defined in the previous commit. We'll need these parameters when allocating a dma_fence. The use case for this is multiple synchronizations timelines. The maximum number of timelines per 3D instance will be 32. Usually, only 2 are needed -- one for CPU commands, and another for GPU commands. As such, we'll need to specify these parameters when allocating a dma_fence. vgdev->fence_drv.context is the "default" fence context for 2D mode and old userspace. Signed-off-by:
-
Gurchetan Singh authored
Each fence should be associated with a [fence ID, fence_context, seqno]. The seqno number is just the fence id. To get the fence context, we add the ring_idx to the 3D context's base_fence_ctx. The ring_idx is between 0 and 31, inclusive. Each 3D context will have it's own base_fence_ctx. The ring_idx will be emitted to host userspace, when emit_fence_info is true. Signed-off-by:
-
Anthoine Bourgeois authored
This implements the context initialization ioctl. A list of params is passed in by userspace, and kernel driver validates them. The only currently supported param is VIRTGPU_CONTEXT_PARAM_CAPSET_ID. If the context has already been initialized, -EEXIST is returned. This happens after Linux userspace does dumb_create + followed by opening the Mesa virgl driver with the same virtgpu instance. However, for most applications, 3D contexts will be explicitly initialized when the feature is available. Signed-off-by:
Anthoine Bourgeois <anthoine.bourgeois@gmail.com> Acked-by:
-
Anthoine Bourgeois authored
Let's probe for VIRTIO_GPU_F_CONTEXT_INIT. Create a new DRM_INFO(..) line since the current one is getting too long. Signed-off-by:
-
Gurchetan Singh authored
The valid capability IDs are between 1 to 63, and defined in the virtio gpu spec. This is used for error checking the subsequent patches. We're currently only using 2 capability IDs, so this should be plenty for the immediate future. Signed-off-by:
-
Gurchetan Singh authored
This change allows creating contexts of depending on set of context parameters. The meaning of each of the parameters is listed below: 1) VIRTGPU_CONTEXT_PARAM_CAPSET_ID This determines the type of a context based on the capability set ID. For example, the current capsets: VIRTIO_GPU_CAPSET_VIRGL VIRTIO_GPU_CAPSET_VIRGL2 define a Gallium, TGSI based "virgl" context. We only need 1 capset ID per context type, though virgl has two due a bug that has since been fixed. The use case is the "gfxstream" rendering library and "venus" renderer. gfxstream doesn't do Gallium/TGSI translation and mostly relies on auto-generated API streaming. Certain users prefer gfxstream over virgl for GLES on GLES emulation. {gfxstream vk}/{venus} are also required for Vulkan emulation. The maximum capset ID is 63. The goal is for guest userspace to choose the optimal context type depending on the situation/hardware. 2) VIRTGPU_CONTEXT_PARAM_NUM_RINGS This tells the number of independent command rings that the context will use. This value may be zero and is inferred to be zero if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is not passed in. This is for backwards compatibility for virgl, which has one big giant command ring for all commands. The maxiumum number of rings is 64. In practice, multi-queue or multi-ring submission is used for powerful dGPUs and virtio-gpu may not be the best option in that case (see PCI passthrough or rendernode forwarding). 3) VIRTGPU_CONTEXT_PARAM_POLL_RING_IDX_MASK This is a mask of ring indices for which the DRM fd is pollable. For example, if VIRTGPU_CONTEXT_PARAM_NUM_RINGS is 2, then the mask may be: [ring idx] | [1 << ring_idx] | final mask ------------------------------------------- 0 1 1 1 2 3 The "Sommelier" guest Wayland proxy uses this to poll for events from the host compositor. Signed-off-by: -
Gurchetan Singh authored
This feature allows for each virtio-gpu 3D context to be created with a "context_init" variable. This variable can specify: - the type of protocol used by the context via the capset id. This is useful for differentiating virgl, gfxstream, and venus protocols by host userspace. - other things in the future, such as the version of the context. In addition, each different context needs one or more timelines, so for example a virgl context's waiting can be independent on a gfxstream context's waiting. VIRTIO_GPU_FLAG_INFO_RING_IDX is introduced to specific to tell the host which per-context command ring (or "hardware queue", distinct from the virtio-queue) the fence should be associated with. The new capability sets (gfxstream, venus etc.) are only defined in the virtio-gpu spec and not defined in the header. Signed-off-by:
-
- 28 Sep, 2021 9 commits
-
-
yangcong authored
Support for these two panels fits in nicely with the existing panel-boe-tv101wum-nl6 driver as suggested by Sam [1]. This is an incell IC, TDDI use time division multiplexing. Init code effect touch sensing.The main things we needed to handle were: a) These panels need slightly longer delays in two places. Since these new delays aren't much longer, let's just unconditionally increase them for the driver. b) These panel use video BURST mode [1] https://lore.kernel.org/r/YSPAseE6WD8dDRuz@ravnborg.org/Signed-off-by:
yangcong <yangcong5@huaqin.corp-partner.google.com> Reviewed-by:
Douglas Anderson <dianders@chromium.org> [dianders: fix whitespace issues reported by dim apply-branch] [dianders: inx,=>innolux,] Signed-off-by:
-
yangcong authored
Add bindings documentation for boe tv110c9m-ll3, inx hj110iz-01a panel. Signed-off-by:
Rob Herring <robh@kernel.org> [dianders: inx,=>innolux,] Signed-off-by:
-
yangcong authored
The auo,b101uan08.3 panel (already supported by this driver) has a 3.3V rail that needs to be turned on. For previous users of this panel this voltage was directly output by pmic. On a new user (the not-yet-upstream sc7180-trogdor-mrbland board) we need to turn the 3.3V rail on. Add support in the driver for this. Signed-off-by:
-
yangcong authored
The auo,b101uan08.3 panel (already supported by this driver) has a 3.3V rail that needs to be turned on. For previous users of this panel this voltage was directly output by pmic. On a new user (the not-yet-upstream sc7180-trogdor-mrbland board) we need to turn the 3.3V rail on. Signed-off-by:
-
Maxime Ripard authored
The drm_helper_hpd_irq_event() documentation states that this function is "useful for drivers which can't or don't track hotplug interrupts for each connector." and that "Drivers which support hotplug interrupts for each connector individually and which have a more fine-grained detect logic should bypass this code and directly call drm_kms_helper_hotplug_event()". This is thus what we ended-up doing. However, what this actually means, and is further explained in the drm_kms_helper_hotplug_event() documentation, is that drm_kms_helper_hotplug_event() should be called by drivers that can track the connection status change, and if it has changed we should call that function. This underlying expectation we failed to provide is that the caller of drm_kms_helper_hotplug_event() should call drm_helper_probe_detect() to probe the new status of the connector. Since we didn't do it, it meant that even though we were sending the notification to user-space and the DRM clients that something changed we never probed or updated our internal connector status ourselves. This went mostly unnoticed since the detect callback usually doesn't have any side-effect. Also, if we were using the DRM fbdev emulation (which is a DRM client), or any user-space application that can deal with hotplug events, chances are they would react to the hotplug event by probing the connector status eventually. However, now that we have to enable the scrambler in detect() if it was enabled it has a side effect, and an application such as Kodi or modetest doesn't deal with hotplug events. This resulted with a black screen when Kodi or modetest was running when a screen was disconnected and then reconnected, or switched off and on. Acked-by:
-
Maxime Ripard authored
The drm_helper_hpd_irq_event() function is iterating over all the connectors when an hotplug event is detected. During that iteration, it will call each connector detect function and figure out if its status changed. Finally, if any connector changed, it will notify the user-space and the clients that something changed on the DRM device. This is supposed to be used for drivers that don't have a hotplug interrupt for individual connectors. However, drivers that can use an interrupt for a single connector are left in the dust and can either reimplement the logic used during the iteration for each connector or use that helper and iterate over all connectors all the time. Since both are suboptimal, let's create a helper that will only perform the status detection on a single connector. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210914101724.266570-2-maxime@cerno.tech
-
Maxime Ripard authored
The documentation of the drm_helper_hpd_irq_event() function didn't document the value that function was returning. Add that part as well. Signed-off-by:
-
Christian König authored
MSM is one of the few drivers which won't even compile test on !ARM platforms. Looking into this a bit more it turned out that there is actually not that much missing to at least let the driver compile on x86 as well. So this patch replaces the use of phys_to_page() with the open coded version and provides a dummy for of_drm_find_bridge(). Signed-off-by:
Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210924071759.22659-2-christian.koenig@amd.com
-
Douglas Anderson authored
Due to a simple typo (apparently I can't count. It goes 0, 1, 2 and not 0, 2, 3) we were getting a kernel doc warning that looked like this: include/drm/drm_edid.h:530: warning: Function parameter or member 'vend_chr_1' not described in 'drm_edid_encode_panel_id' include/drm/drm_edid.h:530: warning: Excess function parameter 'vend_chr_3' description in 'drm_edid_encode_panel_id' Fix it. Fixes: 7d1be0a0 ("drm/edid: Fix EDID quirk compile error on older compilers") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 24 Sep, 2021 7 commits
-
-
Douglas Anderson authored
It's hard for someone (like me) who's not following closely to know what the suggested best practices are for error printing in DRM drivers. Add some hints to the header file. In general, my understanding is that: * When possible we should be using a `struct drm_device` for logging and recent patches have tried to make it more possible to access a relevant `struct drm_device` in more places. * For most cases when we don't have a `struct drm_device`, we no longer bother with DRM-specific wrappers on the dev_...() functions or pr_...() functions and just encourage drivers to use the normal functions. * For debug-level functions where we might want filtering based on a category we'll still have DRM-specific wrappers, but we'll only support passing a `struct drm_device`, not a `struct device`. Presumably most of the cases where we want the filtering are messages that happen while the system is in a normal running state (AKA not during probe time) and we should have a `struct drm_device` then. If we absolutely can't get a `struct drm_device` then these functions begrudgingly accept NULL for the `struct drm_device` and hopefully the awkwardness of having to manually pass NULL will keep people from doing this unless absolutely necessary. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210921082757.RFC.1.Ibd82d98145615fa55f604947dc6a696cc82e8e43@changeid
-
Douglas Anderson authored
Apparently some compilers [1] cannot handle doing math on dereferenced string constants at compile time. This has led to reports [2] of compile errors like: In file included from drivers/gpu/drm/drm_edid.c:42:0: ./include/drm/drm_edid.h:525:2: error: initializer element is not constant ((((u32)((vend)[0]) - '@') & 0x1f) << 26 | \ Go back to the syntax I used in v4 of the patch series [3] that added this code instead of what landed (v5). This syntax is slightly uglier but should be much more compatible with varied compilers. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960#c18 [2] https://lore.kernel.org/r/874kaabdt5.fsf@intel.com/ [3] https://lore.kernel.org/r/20210909135838.v4.4.I6103ce2b16e5e5a842b14c7022a034712b434609@changeid/ Fixes: d9f91a10 ("drm/edid: Allow querying/working with the panel ID from the EDID") Reported-by:Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Reported-by:
Srikanth Myakam <smyakam@microsoft.com> Signed-off-by:
-
Yang Yingliang authored
PTR_ERR() should access the value just tested by IS_ERR(), otherwise the wrong error code will be returned. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
Hulk Robot <hulkci@huawei.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210924094040.3631675-1-yangyingliang@huawei.com
-
Maxime Ripard authored
MIPI-DSI devices need to call mipi_dsi_attach() when their probe is done to attach against their host. However, at removal or when an error occurs, that attachment needs to be undone through a call to mipi_dsi_detach(). Let's create a device-managed variant of the attachment function that will automatically detach the device at unbind. Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Maxime Ripard authored
Devices that take their data through the MIPI-DSI bus but are controlled through a secondary bus like I2C have to register a secondary device on the MIPI-DSI bus through the mipi_dsi_device_register_full() function. At removal or when an error occurs, that device needs to be removed through a call to mipi_dsi_device_unregister(). Let's create a device-managed variant of the registration function that will automatically unregister the device at unbind. Reviewed-by:
-
Maxime Ripard authored
Interactions between bridges, panels, MIPI-DSI host and the component framework are not trivial and can lead to probing issues when implementing a display driver. Let's document the various cases we need too consider, and the solution to support all the cases. Signed-off-by:
-
Maxime Ripard authored
The bridge documentation overview is quite packed already, and we'll add some more documentation that isn't part of an overview at all. Let's add some sections to the documentation to separate each bits. Reviewed-by:
-
- 23 Sep, 2021 2 commits
-
-
Philip Chen authored
Implement the first version of AUX support, which will be useful as we expand the driver to support varied use cases. Signed-off-by:
Philip Chen <philipchen@chromium.org> Reviewed-by:
Stephen Boyd <swboyd@chromium.org> [dianders: whitespace fixes reported by dim apply-branch] Signed-off-by:
-
Philip Chen authored
Replace the direct i2c access (i2c_smbus_* functions) with regmap APIs, which will simplify the future update on ps8640 driver. Signed-off-by:
-
