- Apr 24, 2019
-
-
Daniel Vetter authored
We disallow subleasing, so no point checking whether the master holds all the leases - it will. Spotted while typing exhaustive igt coverage for all these corner cases. Cc: Keith Packard <keithp@keithp.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Not exactly sure what's the aim here, but the canonical nil object has id == 0, we don't use negative object ids for anything. Plus all object_id are valided by the object_idr, there's nothing we need to do on top of that ENOENT check a bit further down. Spotted while typing exhaustive igt coverage for all these corner-cases. Cc: Keith Packard <keithp@keithp.com> Reviewed-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190228144910.26488-2-daniel.vetter@ffwll.ch
-
Dave Airlie authored
This code moved in here in master, so revert it the same way. This is the same revert as 9fa24625 ("Revert "drm/i915/fbdev: Actually configure untiled displays"") in drm-fixes. Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
This should help with some of the lifetime issues, and move us away from load/unload. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-4-airlied@gmail.com
-
Dave Airlie authored
This just makes it easier to later embed drm into udl. Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190405031715.5959-3-airlied@gmail.com
-
Inki Dae authored
Print out debug messages with correct device name. As for this, this patch adds device pointer to exynos_drm_ipp structure, and in case of exynos_drm_ipp_task structure, replace drm_device pointer with device one. This will make each ipp driver to print out debug messages with correct device name. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Inki Dae authored
Add device pointer to vidi_context and remove platform_device pointer. It doesn't need for vidi_context to contain platform_device object. Instead, this patch makes this driver more simply by replacing platform_device pointer with device one. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Inki Dae authored
Use DRM_DEV_DEBUG* instead of DRM_DEBUG macro to print out debug messages. This patch just cleans up the use of debug log macro, which changes the log macro to DRM_DEV_DEBUG*. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Inki Dae authored
This patch just cleans up the use of error log macro, which changes the log macro to DRM_DEV_ERROR. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Inki Dae authored
This patch removes unnecessary messages from fimd_clear_channels and decon_clear_channels functions which print out just function name. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Inki Dae authored
This patch makes error messages to be printed out using DRM_ERROR instead of DRM_INFO. Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
Seung-Woo Kim authored
Remove checkpatch error, "foo* bar" should be "foo *bar". Signed-off-by:
Seung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by:
Inki Dae <inki.dae@samsung.com>
-
- Apr 21, 2019
-
-
Jordan Crouse authored
Add CONFIG_DRM_MSM_GPU_STATE to conditionally compile Adreno GPU state code depending on the availability of the dependencies. Reported-by:
Hulk Robot <hulkci@huawei.com> Reported-by:
YueHaibing <yuehaibing@huawei.com> Fixes: 1707add8 ("drm/msm/a6xx: Add a6xx gpu state") Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
The a6xx GPU powers on in secure mode which restricts what memory it can write to. To get out of secure mode the GPU driver can write to REG_A6XX_RBBM_SECVID_TRUST_CNTL but on targets that are "secure" that register region is blocked and writes will cause the system to go down. For those targets we need to execute a special sequence that involves loadinga special shader that clears the GPU registers and use a PM4 sequence to pull the GPU out of secure. Add support for loading the zap shader and executing the secure sequence. For targets that do not support SCM or the specific SCM sequence this should fail and we would fall back to writing the register. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
a5xx and a6xx both share (mostly) the same code to load the zap shader and bring the GPU out of secure mode. Move the formerly 5xx specific code to adreno to make it available for a6xx too. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
- Apr 19, 2019
-
-
Kristian H. Kristensen authored
First loop does copy_from_user() without the table lock held and just stores the handle. Second loop looks up buffer objects with the table_lock held without potentially blocking or faulting. This lets us clean up a bunch of custom, non-faulting copy_from_user() code. Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Kristian H. Kristensen authored
Now that we don't have the mmap_sem lock inversion, we don't need to jump through this particular hoop anymore. Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Kristian H. Kristensen authored
We use a llist and a worker to delay the object cleanup. This avoids taking mmap_sem and struct_mutex in the wrong order when calling drm_gem_object_put_unlocked() from drm_gem_mmap(). Fixes lockdep problem with copy_from_user() in msm_ioctl_gem_submit(). Signed-off-by:
Kristian H. Kristensen <hoegsberg@chromium.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
The HFI tasklet was removed in df0dff13 ("drm/msm/a6xx: Poll for HFI responses") but the tasklet_struct was accidentally left behind. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Currently if the GMU resume function fails all we try to do is clear the BOOT_SLUMBER oob which usually times out and ends up in a cycle of death. If the resume function fails at any point remove any RPMh votes that might have been added and try to shut down the GMU hardware cleanly. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Now that the GX domain is sorted we can wire up a working GMU reset. IF a GMU hang was detected then try to forcefully shut down the GMU in the power down sequence which should ensure that it can recover normally on the next power up. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
99.999% of the time during normal operation the GMU is responsible for power and clock control on the GX domain and the CPU remains blissfully unaware. However, there is one situation where the CPU needs to get involved: The power sequencing rules dictate that the GX needs to be turned off before the CX so that the CX can be turned on before the GX during power up. During normal operation when the CPU is taking down the CX domain a stop command is sent to the GMU which turns off the GX domain and then the CPU handles the CX domain. But if the GMU happened to be unresponsive while the GX domain was left then the CPU will need to step in and turn off the GX domain before resetting the CX and rebooting the GMU. This unfortunately means that the CPU needs to be marginally aware of the GX domain even though it is expected to usually keep its hands off. To support this we create a semi-disabled GX power domain that does nothing to the hardware on power up but tries to shut it down normally on power down. In this method the reference counting is correct and we can step in with the pm_runtime_put() at the right time during the failure path. This patch sets up the connection to the GX power domain and does the magic to "enable" and disable it at the right points. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
The GMU code currently has some misguided code to try to work around a hardware quirk that requires the power domains on the GPU be collapsed in a certain order. Upcoming patches will do this the right way so get rid of the unused and unwanted regulator code. Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jordan Crouse authored
Add the capability to query information from a submit queue. The first available parameter is for querying the number of GPU faults (hangs) that can be attributed to the queue. This is useful for implementing context robustness. A user context can regularly query the number of faults to see if it is responsible for any and if so it can invalidate itself. This is also helpful for testing by confirming to the user driver if a particular command stream caused a fault (or not as the case may be). Signed-off-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Rob Clark authored
For KHR_robustness, userspace wants to know two things, the count of GPU faults globally, and the count of faults attributed to a given context. This patch providees the former, and the next patch provides the latter. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org>
-
Rob Clark authored
For now it always returns '0' (false), but once the iommu work is in place to enable per-process pagetables we can update the value returned. Userspace needs to know this to make an informed decision about exposing KHR_robustness. Signed-off-by:
Rob Clark <robdclark@chromium.org> Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org>
-
- Apr 18, 2019
-
-
Wen Yang authored
The call to of_get_child_by_name returns a node pointer with refcount incremented thus it must be explicitly decremented after the last usage. Detected by coccinelle with the following warnings: drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 47, but without a corresponding object release within this function. drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 47, but without a corresponding object release within this function. drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 47, but without a corresponding object release within this function. drivers/gpu/drm/msm/adreno/a5xx_gpu.c:57:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 51, but without a corresponding object release within this function. drivers/gpu/drm/msm/adreno/a5xx_gpu.c:66:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 51, but without a corresponding object release within this function. drivers/gpu/drm/msm/adreno/a5xx_gpu.c:118:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 51, but without a corresponding object release within this function. Signed-off-by:
Wen Yang <wen.yang99@zte.com.cn> Cc: Rob Clark <robdclark@gmail.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Mamta Shukla <mamtashukla555@gmail.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Sharat Masetty <smasetty@codeaurora.org> Cc: linux-arm-msm@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: freedreno@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org (open list) Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Douglas Anderson authored
The patch ("OPP: Add support for parsing the 'opp-level' property") adds an API enabling a cleaner way to read the opp-level. Let's use the new API. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Reviewed-by:
Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
Removing unwanted access of crtc_state for finding this information. Use split role information to know whether we have slave ctl. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-8-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
Iterate and assign HW intf block to physical encoders in encoder modeset. Moving all the HW block assignments to encoder modeset to allow easy switching to state based resource management. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-7-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
After resource allocation, iterate and populate mixer/ctl hw blocks in encoder modeset thereby centralizing all the resource mapping to the CRTC. This change is made for easy switching to state based allocation using private objects later in this series. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-6-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
encoder->crtc is not really meaningful for atomic path. Use crtc->encoder_mask to identify the crtc attached with an encoder. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-5-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
release resources allocated in mode_set if any of the hw check fails. Most of these checks are not necessary and they will be removed in the follow up patches with state based resource allocations. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-4-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
Not holding any video encoder specific data. Get rid of it. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-3-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Jeykumar Sankaran authored
Both video and command physical encoders will have a hw interface assigned to it. So there is really no need to track the hw block in specific encoder subclass. Signed-off-by:
Jeykumar Sankaran <jsanka@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1550107156-17625-2-git-send-email-jsanka@codeaurora.org Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Sean Paul authored
The frame_busy mask is used in frame_done event handling, which is not invoked for async commits. So an async commit will leave the frame_busy mask populated after it completes and future commits will start with the busy mask incorrect. This showed up on disable after cursor move. I was hitting the "this should not happen" comment in the frame event worker since frame_busy was set, we queued the event, but there were no frames pending (since async also doesn't set that). Reviewed-by:
Fritz Koenig <frkoenig@google.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190130163220.138637-1-sean@poorly.run Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Sean Paul authored
In the case of an async/cursor update, we don't wait for the frame_done event, which means handle_frame_done is never called, and the frame_done watchdog isn't canceled. Currently, this results in a frame_done timeout every time the cursor moves without a synchronous frame following it up before the timeout expires. Since we don't wait for frame_done, and don't handle it, we shouldn't modify the watchdog. Reviewed-by:
Fritz Koenig <frkoenig@google.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-4-sean@poorly.run Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Sean Paul authored
There exists a bunch of confusion as to what the actual units of frame_done is: - The definition states it's in # of frames - CRTC treats it like it's ms - frame_done_timeout comment thinks it's Hz, but it stores ms - frame_done timer is setup such that it _should_ be in frames, but the timeout is super long So this patch tries to interpret what the driver really wants. I've de-centralized the #define since the consumers are expecting different units. For crtc, we just use 60ms since that's what it was doing before. Perhaps we could get fancy and scale with vrefresh, but that's for another time. For encoder, fix the comments and rename frame_done_timeout so it's obvious what the units are. In practice, frame_done_timeout is really just checked against 0 || !0, which I guess is why the units being wrong didn't matter. I've also dropped the timeout from the previous 60 frames to 5. That seems like more than enough time to give up on a frame, and my guess is that no one intended for the timeout to _actually_ be 60 frames. Reviewed-by:
Fritz Koenig <frkoenig@google.com> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-3-sean@poorly.run Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Sean Paul authored
Instead of setting the timeout and then immediately reading it back (along with the hand-rolled msecs_to_jiffies calculation), just calculate it once and set it in both places at the same time. Reviewed-by:
Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-2-sean@poorly.run Signed-off-by:
Rob Clark <robdclark@chromium.org>
-
Sean Paul authored
Use the drm_mode_vrefresh helper where we need refresh rate in case vrefresh is empty. Reviewed-by:
Abhinav Kumar <abhinavk@codeaurora.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190128204306.95076-1-sean@poorly.run Signed-off-by:
Rob Clark <robdclark@chromium.org>
-