- 03 Dec, 2023 2 commits
-
-
Abhinav Kumar authored
drm_bridge_hpd_enable()/drm_bridge_hpd_disable() callbacks call into the respective driver's hpd_enable()/hpd_disable() ops. These ops control the HPD enable/disable logic which in some cases like MSM can be a dedicate hardware block to control the HPD. During probe_defer cases, a connector can be initialized and then later destroyed till the probe is retried. During connector destroy in these cases, the hpd_disable() callback gets called without a corresponding hpd_enable() leading to an unbalanced state potentially causing even a crash. This can be avoided by the respective drivers maintaining their own state logic to ensure that a hpd_disable() without a corresponding hpd_enable() just returns without doing anything. However, to have a generic fix it would be better to avoid the hpd_disable() callback from the connector destroy path and let the hpd_enable() / hpd_disable() balance be maintained by the corresponding drm_bridge_connector_enable_hpd() / drm_bridge_connector_disable_hpd() APIs which should get called by drm_kms_helper_disable_hpd(). changes in v2: - minor change in commit text (Dmitry) Signed-off-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Abhinav Kumar authored
While making the changes in [1], it was noted that the documentation of the enable_hpd() and disable_hpd() does not make it clear that these ops should not try to do hpd state maintenance and should only enable/disable hpd related hardware for the connector. The state management of these calls to make sure these calls are balanced is handled by the DRM core and we should keep it that way to minimize the overhead in the drivers which implement these ops. [1]: https://patchwork.freedesktop.org/patch/558387/Signed-off-by:
-
- 02 Dec, 2023 1 commit
-
-
Alex Bee authored
Rockchip RK312x SoC family has a Mali400 MP2. Add a compatible for it. Signed-off-by:
Alex Bee <knaerzche@gmail.com> Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20231202125144.66052-4-knaerzche@gmail.com
-
- 01 Dec, 2023 37 commits
-
-
Jessica Zhang authored
Loosen the requirements for atomic and legacy commit so that, in cases where pixel_source != FB, the commit can still go through. This includes adding framebuffer NULL checks in other areas to account for FB being NULL when non-FB pixel sources are enabled. To disable a plane, the pixel_source must be NONE or the FB must be NULL if pixel_source == FB. Signed-off-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Reviewed-by:
-
Jessica Zhang authored
Currently framebuffer checks happen directly in drm_atomic_plane_check(). Move these checks into their own helper method. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Sebastian Wick <sebastian@sebastianwick.net> Signed-off-by:
-
Jessica Zhang authored
Add solid_fill property data to the atomic plane state dump. Reviewed-by:
-
Jessica Zhang authored
Add pixel source to the atomic plane state dump Reviewed-by:
-
Jessica Zhang authored
Add "SOLID_FILL" as a valid pixel source. If the pixel_source property is set to "SOLID_FILL", it will display data from the drm_plane "solid_fill" blob property. Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Acked-by:
-
Jessica Zhang authored
Document and add support for solid_fill property to drm_plane. In addition, add support for setting and getting the values for solid_fill. To enable solid fill planes, userspace must assign a property blob to the "solid_fill" plane property containing the following information: struct drm_mode_solid_fill { u32 r, g, b, pad; }; Acked-by: -
Jessica Zhang authored
Add support for pixel_source property to drm_plane and related documentation. In addition, force pixel_source to DRM_PLANE_PIXEL_SOURCE_FB in DRM_IOCTL_MODE_SETPLANE as to not break legacy userspace. This enum property will allow user to specify a pixel source for the plane. Possible pixel sources will be defined in the drm_plane_pixel_source enum. Currently, the only pixel sources are DRM_PLANE_PIXEL_SOURCE_FB (the default value) and DRM_PLANE_PIXEL_SOURCE_NONE. Acked-by:
Simon Ser <contact@emersion.fr> Signed-off-by:
-
Rob Clark authored
This consists of simply storing the most recent deadline, and adding an ioctl to retrieve the deadline. This can be used in conjunction with the SET_DEADLINE ioctl on a fence fd for testing. Ie. create various sw_sync fences, merge them into a fence-array, set deadline on the fence-array and confirm that it is propagated properly to each fence. v2: Switch UABI to express deadline as u64 v3: More verbose UAPI docs, show how to convert from timespec v4: Better comments, track the soonest deadline, as a normal fence implementation would, return an error if no deadline set. Signed-off-by:Rob Clark <robdclark@chromium.org> Reviewed-by:
Christian König <christian.koenig@amd.com> Acked-by:
-
Rob Clark authored
The initial purpose is for igt tests, but this would also be useful for compositors that wait until close to vblank deadline to make decisions about which frame to show. The igt tests can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v2: Clarify the timebase, add link to igt tests v3: Use u64 value in ns to express deadline. v4: More doc Signed-off-by:
-
Rob Clark authored
Add a new flag to let userspace provide a deadline as a hint for syncobj and timeline waits. This gives a hint to the driver signaling the backing fences about how soon userspace needs it to compete work, so it can adjust GPU frequency accordingly. An immediate deadline can be given to provide something equivalent to i915 "wait boost". v2: Use absolute u64 ns value for deadline hint, drop cap and driver feature flag in favor of allowing count_handles==0 as a way for userspace to probe kernel for support of new flag v3: More verbose comments about UAPI v4: Fix negative zero, s/deadline_ns/deadline_nsec/ for consistency with existing ioctl struct fields v5: Comment/description typo fixes Signed-off-by:Tvrtko Ursulin <tvrtko.ursulin@intel.com> [DB: fixed checkpatch warnings] Signed-off-by:
-
Carl Vanderlip authored
Currently the QAIC DRM device registers itself when the MHI QAIC_CONTROL channel becomes available. This is when the device is able to process workloads. However, the DRM driver also provides the debugfs interface bootlog for the device. If the device fails to boot to the QSM (which brings up the MHI QAIC_CONTROL channel), the bootlog won't be available for debugging why it failed to boot. Change when the DRM device registers itself from when QAIC_CONTROL is available to when the card is first probed on the PCI bus. Additionally, make the DRM driver persist through reset/error cases so the driver doesn't have to be reloaded to access the card again. Send KOBJ_ONLINE/OFFLINE uevents so userspace can know when DRM device is ready to handle requests. Signed-off-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231117174337.20174-3-quic_jhugo@quicinc.com
-
Carl Vanderlip authored
'in_reset' holds the state of the device. As part of bringup, the device needs to be queried to check if it's in a valid state. Add a new state that indicates that the device is coming up, but not ready for users yet. Rename to 'dev_state' to better describe the variable. Signed-off-by:
-
Uwe Kleine-König authored
The struct imx_lcdc driver data is allocated using devm_drm_dev_alloc() so it must not be explicitly kfree()d. Also drm_kms_helper_poll_fini() should not be called as there is no matching drm_kms_helper_poll_init(). So drop the release function completely. Fixes: c87e859c ("drm/imx/lcdc: Implement DRM driver for imx25") Signed-off-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by:
Philipp Zabel <philipp.zabel@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230706092731.2630232-1-u.kleine-koenig@pengutronix.de
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. A copy performance query job is a job that copy the complete or partial result of a query to a buffer. In order to copy the result of a performance query to a buffer, we need to get the values from the performance monitors. So, create a user extension for the CPU job that enables the creation of a copy performance query job. This user extension will allow the creation of a CPU job that copy the results of a performance query to a BO with the possibility to indicate the availability with a availability bit. Signed-off-by:
Maíra Canal <mcanal@igalia.com> Reviewed-by:
Iago Toral Quiroga <itoral@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231130164420.932823-19-mcanal@igalia.com
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. A reset performance query job is a job that resets the performance queries by resetting the values of the perfmons. Moreover, we also reset the syncobjs related to the availability of the query. So, create a user extension for the CPU job that enables the creation of a reset performance job. This user extension will allow the creation of a CPU job that resets the perfmons values and resets the availability syncobj. Signed-off-by:
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. A copy timestamp query job is a job that copy the complete or partial result of a query to a buffer. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that needs CPU intervention. So, create a user extension for the CPU job that enables the creation of a copy timestamp query job. This user extension will allow the creation of a CPU job that copy the results of a timestamp query to a BO with the possibility to indicate the timestamp availability with a availability bit. Signed-off-by:
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. A reset timestamp job is a job that resets the timestamp queries based on the value offset of the first query. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that needs CPU intervention. So, create a user extension for the CPU job that enables the creation of a reset timestamp job. This user extension will allow the creation of a CPU job that resets the timestamp value in the timestamp BO and resets the availability syncobj. Signed-off-by:
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. A timestamp query job is a job that calculates the query timestamp and updates the query availability by signaling a syncobj. As V3D doesn't provide any mechanism to obtain a timestamp from the GPU, it is a job that needs CPU intervention. So, create a user extension for the CPU job that enables the creation of a timestamp query job. This user extension will allow the creation of a CPU job that performs the timestamp query calculation and updates the timestamp BO with the proper value. Signed-off-by:
-
Maíra Canal authored
A CPU job is a type of job that performs operations that requires CPU intervention. An indirect CSD job is a job that, when executed in the queue, will map the indirect buffer, read the dispatch parameters, and submit a regular dispatch. Therefore, it is a job that needs CPU intervention. So, create a user extension for the CPU job that enables the creation of an indirect CSD. This user extension will allow the creation of a CSD job linked to a CPU job. The CPU job will wait for the indirect CSD job dependencies and, once they are signaled, it will update the CSD job parameters. Co-developed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Maíra Canal authored
For the indirect CSD CPU job, we will need to access the internal contents of the BO with the dispatch parameters. Therefore, create methods to allow the mapping and unmapping of the BO. Signed-off-by:
-
Melissa Wen authored
Detach CSD job setup from CSD submission ioctl to reuse it in CPU submission ioctl for indirect CSD job. Signed-off-by:
-
Maíra Canal authored
Create tracepoints to track the three major events of a CPU job lifetime: 1. Submission of a `v3d_submit_cpu` IOCTL 2. Beginning of the execution of a CPU job 3. Ending of the execution of a CPU job Signed-off-by:
-
Maíra Canal authored
Currently, v3d_get_extensions() only parses multisync data and assigns it to the `struct v3d_submit_ext`. But, to implement the CPU job with user extensions, we want v3d_get_extensions() to be able to parse CPU job data and assign it to the `struct v3d_cpu_job`. Therefore, allow the function v3d_get_extensions() to use `struct v3d_cpu_job *` as a parameter. If the `struct v3d_cpu_job *` is assigned to NULL, it means that the job is a GPU job and CPU job extensions should be rejected. Signed-off-by:
-
Melissa Wen authored
Create a new type of job, a CPU job. A CPU job is a type of job that performs operations that requires CPU intervention. The overall idea is to use user extensions to enable different types of CPU job, allowing the CPU job to perform different operations according to the type of user extension. The user extension ID identify the type of CPU job that must be dealt. Having a CPU job is interesting for synchronization purposes as a CPU job has a queue like any other V3D job and can be synchoronized by the multisync extension. Signed-off-by:
-
Maíra Canal authored
We want to allow the IOCTLs to allocate the job without initiating it. This will be useful for the CPU job submission IOCTL, as the CPU job has the need to use information from the user extensions. Currently, the user extensions are parsed before the job allocation, making it impossible to fill the CPU job when parsing the user extensions. Therefore, decouple the job allocation from the job initiation. Signed-off-by:
-
Maíra Canal authored
Currently, two multisync extensions can be added to the same job and only the last multisync extension will be used. To avoid this vulnerability, don't allow two multisync extensions in the same job. Signed-off-by:
-
Melissa Wen authored
Instead of checking if the job is NULL every time we call the function, check it inside the function. Signed-off-by:
-
Melissa Wen authored
We will include a new job submission type, the CPU job submission. For readability and maintability, separate the job submission IOCTLs and related operations from v3d_gem.c. Minor fix in the CSD submission kernel doc: CSD (texture formatting) -> CSD (compute shader). Signed-off-by:
-
Melissa Wen authored
IOCTLs related to BO operations reside on the file v3d_bo.c. The wait BO ioctl is the only IOCTL regarding BOs that is placed in a different file. So, move it to the v3d_bo.c file. Signed-off-by:
-
Melissa Wen authored
v3d_mmu_get_offset header was added but the function was never defined. Just remove it. Signed-off-by:
-
Tomi Valkeinen authored
At the moment the driver does not use DRM_PLANE_COMMIT_ACTIVE_ONLY, but still checks for crtc->state->active in tidss_crtc_atomic_flush(), and skips the flush if the crtc is not active. The exact reason why DRM_PLANE_COMMIT_ACTIVE_ONLY is not used has been lost in history. DRM_PLANE_COMMIT_ACTIVE_ONLY does also affect the plane updates, and I think the issue was related to multi-display systems and moving planes between the displays. However, it is possible the issue was only present on the older DSS hardware, handled by the omapdrm driver (on which the tidss driver is loosely based). Reviewing the code related to DRM_PLANE_COMMIT_ACTIVE_ONLY does not show any issues, and testing on J7 EVM with two displays works fine. Change the driver to use DRM_PLANE_COMMIT_ACTIVE_ONLY. Reviewed-by:
Aradhya Bhatia <a-bhatia1@ti.com> Link: https://lore.kernel.org/r/20231109-tidss-probe-v2-11-ac91b5ea35c0@ideasonboard.comSigned-off-by:
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
-
Tomi Valkeinen authored
tidss_crtc_atomic_flush() checks if the crtc is enabled, and if not, returns immediately as there's no reason to do any register changes. However, the code checks for 'crtc->state->enable', which does not reflect the actual HW state. We should instead look at the 'crtc->state->active' flag. This causes the tidss_crtc_atomic_flush() to proceed with the flush even if the active state is false, which then causes us to hit the WARN_ON(!crtc->state->event) check. Fix this by checking the active flag, and while at it, fix the related debug print which had "active" and "needs modeset" wrong way. Cc: <stable@vger.kernel.org> Fixes: 32a1795f ("drm/tidss: New driver for TI Keystone platform Display SubSystem") Reviewed-by:
-
Tomi Valkeinen authored
The IRQ setup code is overly complex. All we really need to do is initialize the related fields in struct tidss_device, and request the IRQ. We can drop all the HW accesses, as they are pointless: the driver will set the IRQs correctly when it needs any of the IRQs, and at probe time we have done a reset, so we know that all the IRQs are masked by default in the hardware. Thus we can combine the tidss_irq_preinstall() and tidss_irq_postinstall() into the tidss_irq_install() function, drop the HW accesses, and drop the use of spinlock, as this is done at init time and there can be no races. We can also drop the HW access from the tidss_irq_uninstall(), as the driver will anyway disable and suspend the hardware at remove time. Reviewed-by:
-
Tomi Valkeinen authored
The probe function calls dispc_softreset() before runtime PM is enabled and without enabling any of the DSS clocks. This happens to work by luck, and we need to make sure the DSS HW is active and the fclk is enabled. To fix the above, add a new function, dispc_init_hw(), which does: - pm_runtime_set_active() - clk_prepare_enable(fclk) - dispc_softreset(). This ensures that the reset can be successfully accomplished. Note that we use pm_runtime_set_active(), not the normal pm_runtime_get(). The reason for this is that at this point we haven't enabled the runtime PM yet and also we don't want the normal resume callback to be called: the dispc resume callback does some initial HW setup, and it expects that the HW was off (no video ports are streaming). If the bootloader has enabled the DSS and has set up a boot time splash-screen, the DSS would be enabled and streaming which might lead to issues with the normal resume callback. Fixes: c9b2d923 ("drm/tidss: Soft Reset DISPC on startup") Reviewed-by:
-
Tomi Valkeinen authored
K2G display controller does not support soft reset, but we can do the most important steps manually: mask the IRQs and disable the VPs. Reviewed-by:
-
Tomi Valkeinen authored
K2G doesn't have softreset feature. Instead of having every caller of dispc_softreset() check for K2G, move the check into dispc_softreset(), and make dispc_softreset() return 0 in case of K2G. Reviewed-by:
-
Tomi Valkeinen authored
Return an error value from dispc_softreset() so that the caller can handle the errors. Reviewed-by:
-
