- 06 Sep, 2019 3 commits
-
-
Daniel Vetter authored
We forgot that. Proof is the one igt testcase we have: https://gitlab.freedesktop.org/drm/igt-gpu-tools/blob/master/tests/kms_atomic.c#L280 While at it also document that we have immutable zpos properties in some cases. Reported-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Ilia Mirkin <imirkin@alum.mit.edu> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190906144459.16025-1-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
- it's what we recommend in our docs: https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values - it's the overwhelmingly used error code for "operation not supported", at least in drm core (slightly less so in drivers): $ git grep EOPNOTSUPP -- drivers/gpu/drm/*c | wc -l 83 $ git grep ENOTSUPP -- drivers/gpu/drm/*c | wc -l 5 - include/linux/errno.h makes it fairly clear that these are for nfsv3 (plus they also have error codes above 512, which is the block with some special behaviour ...) /* Defined for the NFSv3 protocol */ If the above isn't reflecting current practice, then I guess we should at least update the docs. Noralf commented: Ben Hutchings made this comment[1] in a thread about use of ENOTSUPP in drivers: glibc's strerror() returns these strings for ENOTSUPP and EOPNOTSUPP respectively: "Unknown error 524" "Operation not supported" So at least for errors returned to userspace EOPNOTSUPP makes sense. José asked: > Hopefully this will not break any userspace None of the functions in drm_edid.c affected by this reach userspace, it's all driver internal. Same for the mipi function, that error code should be handled by drivers. Drivers are supposed to remap "the hw is on fire" to EIO when reporting up to userspace, but I think if a driver sees this it would be a driver bug. v2: Augment commit message with comments from Noralf and José Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Sean Paul <sean@poorly.run> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Andres Rodriguez <andresx7@gmail.com> Cc: Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
-
Gerd Hoffmann authored
Only call virtio_gpu_array_add_fence if we actually have a fence. Fixes: da758d51 ("drm/virtio: rework virtio_gpu_execbuffer_ioctl fencing") Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190904074828.32502-1-kraxel@redhat.com
-
- 04 Sep, 2019 19 commits
-
-
Gerd Hoffmann authored
Move object release into a separate worker. Releasing objects requires sending commands to the host. Doing that in the dequeue worker will cause deadlocks in case the command queue gets filled up, because the dequeue worker is also the one which will free up slots in the command queue. Reported-by:
-
Gerd Hoffmann authored
Make sure we don't leak half-initialized fences outside the driver. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
Thin wrapper around virtio_gpu_object_create(), but calling that directly works equally well. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Gerd Hoffmann authored
virtio-gpu basically needs a sg_table for the bo, to tell the host where the backing pages for the object are. So the gem shmem helpers are a perfect fit. Some drm_gem_object_funcs need thin wrappers to update the host state, but otherwise the helpers handle everything just fine. Once the fencing was sorted the switch was surprisingly easy and for the most part just removing the ttm code. v4: fix drm_gem_object_funcs name. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Switch to the virtio_gpu_array_* helper workflow. Signed-off-by:
-
Gerd Hoffmann authored
Rework fencing workflow. Stop using ttm helpers, use the virtio_gpu_array_* helpers instead. Due to using the gem reservation object it is initialized and ready for use before calling ttm_bo_init. So we can simply use the standard fencing workflow and drop the tricky logic which checks whenever the command is in flight still. v6: rewrite most of the patch. Signed-off-by:
-
Gerd Hoffmann authored
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl. Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work on the reservation objects directly) instead. Also store the object array in struct virtio_gpu_vbuffer, so we explicitly keep a reference of all buffers used instead of depending on ttm_bo_put() checking whenever the object is actually idle before releasing it. New workflow: (1) All gem objects needed by a command are added to a virtio_gpu_object_array. (2) All reservation objects will be locked (virtio_gpu_array_lock_resv). (3) virtio_gpu_fence_emit() completes fence initialization. (4) fence gets added to the objects, reservation objects are unlocked (virtio_gpu_array_add_fence, virtio_gpu_array_unlock_resv). (5) virtio command is submitted to the host. (6) The completion callback (virtio_gpu_dequeue_ctrl_func) will drop object references and free virtio_gpu_object_array. v6: rewrite most of the patch. Signed-off-by: -
Gerd Hoffmann authored
Some helper functions to manage an array of gem objects. v9: use dma_resv_lock_interruptible. v6: - add ticket to struct virtio_gpu_object_array. - add virtio_gpu_array_{lock,unlock}_resv helpers. - add virtio_gpu_array_add_fence helper. v5: some small optimizations (Chia-I Wu). v4: make them virtio-private instead of generic helpers. Signed-off-by: -
Gerd Hoffmann authored
Call reservation_object_* directly instead of using ttm_bo_{reserve,unreserve}. v4: check for EINTR only. v3: check for EINTR too. Signed-off-by: -
Gerd Hoffmann authored
All callers pass no_wait = false. Signed-off-by:
-
Gerd Hoffmann authored
No users left. Signed-off-by:
-
Gerd Hoffmann authored
No need to do the reservation dance, we can just wait on the fence directly. Signed-off-by:
-
Gerd Hoffmann authored
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl(). This also makes the ioctl run lockless. v9: fix return value. v5: handle lookup failure. v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT. Signed-off-by:
-
Gerd Hoffmann authored
With this gem and ttm will use the same reservation object, so mixing and matching ttm / gem reservation helpers should work fine. Signed-off-by:
-
- 03 Sep, 2019 17 commits
-
-
Lyude Paul authored
Declare local pointer to the drm_dp_link_address_ack_reply struct instead of constantly dereferencing it through the union in txmsg->reply. Then, invert the order of conditionals so we don't have to do the bulk of the work inside them, and can wrap lines even less. Then finally, rearrange variable declarations a bit. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-16-lyude@redhat.com
-
Lyude Paul authored
* Remove the big ugly have_eomt conditional * Store &mgr->down_rep_recv.initial_hdr in a var to make line wrapping easier * Remove duplicate memset() calls * Actually wrap lines Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
There's a couple of changes here, so to summarize: * Remove the big ugly mgr->up_req_recv.have_eomt conditional to save on indenting * Store &mgr->up_req_recv.initial_hdr in a variable so we don't keep going over 80 character long lines * De-duplicate code for calling drm_dp_send_up_ack_reply() and getting the MSTB via it's GUID * Remove all of the duplicate calls to memset() and just use a goto instead * Actually do line wrapping * Remove the unnecessary if (mstb) check before calling drm_dp_mst_topology_put_mstb() - we are guaranteed to always have mstb != NULL at that point in the function Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
And it's helper, we'll be using this in just a moment. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
Lyude Paul authored
Which reduces indentation and makes this function more legible. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Use more pointers so we don't have to write out txmsg->reply.u.path_resources each time. Also, fix line wrapping + rearrange local variables. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Unfortunately the DP MST helpers do not have much in the way of debugging utilities. So, let's add some! This adds basic debugging output for down sideband requests that we send from the driver, so that we can actually discern what's happening when sideband requests timeout. Since there wasn't really a good way of testing that any of this worked, I ended up writing simple selftests that lightly test sideband message encoding and decoding as well. Enjoy! Changes since v1: * Clean up DO_TEST() and sideband_msg_req_encode_decode() - danvet * Get rid of pr_fmt(), just define a prefix string instead and use drm_printf() * Check highest bit of VCPI in drm_dp_decode_sideband_req() - danvet * Make the switch case order between drm_dp_decode_sideband_req() and drm_dp_encode_sideband_req() the same - danvet * Only check DRM_UT_DP - danvet * Clean up sideband_msg_req_equal() from selftests a bit, and add comments explaining why we can't just use memcmp - danvet Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Noticed this while working on adding a drm_dp_decode_sideband_req(). DP_POWER_DOWN_PHY/DP_POWER_UP_PHY both use the same struct as DP_ENUM_PATH_RESOURCES, so we can just combine their cases. Changes since v2: * Fix commit message Signed-off-by:
-
Lyude Paul authored
A simple convienence function that returns a drm_printer which prints using pr_err() Changes since v1: * Make __drm_printfn_err() more consistent with DRM_ERROR() - danvet Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Yes, apparently we've been testing this for every single driver load for quite a long time now. At least that means our PBN calculation is solid! Anyway, introduce self tests for MST and move this into there. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
This seems to be some leftover detritus from before the port/mstb kref cleanup and doesn't do anything anymore, so get rid of it. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
-
Lyude Paul authored
Makes things easier to read. Cc: Juston Li <juston.li@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harry Wentland <hwentlan@amd.com> Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
We can reduce the critical section in vkms_vblank_simulate under output->lock quite a lot: - hrtimer_forward_now just needs to be ordered correctly wrt drm_crtc_handle_vblank. We already access the hrtimer timestamp without locks. While auditing that I noticed that we don't correctly annotate the read there, so sprinkle a READ_ONCE to make sure the compiler doesn't do anything foolish. - drm_crtc_handle_vblank must stay under the lock to avoid races with drm_crtc_arm_vblank_event. - The access to vkms_ouptut->crc_state also must stay under the lock. - next problem is making sure the output->state structure doesn't get freed too early. First we rely on a given hrtimer being serialized: If we call drm_crtc_handle_vblank, then we are guaranteed that the previous call to vkms_vblank_simulate has completed. The other side of the coin is that the atomic updates waits for the vblank to happen before it releases the old state. Both taken together means that by the time the atomic update releases the old state, the hrtimer won't access it anymore (it might be accessing the new state at the same time, but that's ok). - state is invariant, except the few fields separate protected by state->crc_lock. So no need to hold the lock for that. - finally the queue_work. We need to make sure there's no races with the flush_work, i.e. when we call flush_work we need to guarantee that the hrtimer can't requeue the work again. This is guaranteed by the same vblank/hrtimer ordering guarantees like the reasoning above why state won't be freed too early: flush_work on the old state is called after wait_for_flip_done in the atomic commit code. Therefore we can also move everything after the output->crc_state out of the critical section. Motivated by suggestions from Rodrigo. Signed-off-by:
Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190719152314.7706-3-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
It's the recommended version, wait_for_vblanks is a bit a hacky interim thing that predates all the flip_done tracking. It's unfortunately still the default ... Signed-off-by:
-
Daniel Vetter authored
Noticed while reviewing code. I'm not sure whether this might or might not explain some of the missed vblank hilarity we've been seeing on various drivers (but those got tracked down to driver issues, at least mostly). I think those all go through the vblank completion event, which has unconditional barriers - it always takes the spinlock. Therefore no cc stable. v2: - Barrriers are hard, put them in in the right order (Chris). - Improve the comments a bit. v3: Ville noticed that on 32bit we might be breaking up the load/stores, now that the vblank counter has been switched over to be 64 bit. Fix that up by switching to atomic64_t. This this happens so rarely in practice I figured no need to cc: stable ... Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Keith Packard <keithp@keithp.com> References: 570e8696 ("drm: Widen vblank count to 64-bits [v3]") Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Mihail Atanassov authored
Expose node with the name 'aclk_hz' Signed-off-by:
Mihail Atanassov <mihail.atanassov@arm.com> Reviewed-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by:
Ayan kumar halder <ayan.halder@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190828110342.45936-1-mihail.atanassov@arm.com
-
Heinrich Fink authored
Store the timestamp of the current vblank in the new field 'time' of the vblank trace event. If the timestamp is calculated by a driver that supports high-precision vblank timing, set the field 'high-prec' to 'true'. User space can now access actual hardware vblank times via the tracing infrastructure. Tracing applications (such as GPUVis, see [0] for related discussion), can use the newly added information to conduct a more accurate analysis of display timing. v2 Fix author name (missing last name) [0] https://github.com/mikesart/gpuvis/issues/30Reviewed-by:
Heinrich Fink <heinrich.fink@daqri.com> Signed-off-by:
-
- 02 Sep, 2019 1 commit
-
-
Linus Walleij authored
The sti_hdmi.c file include <linux/of_gpio.h> despite not even using any GPIOs. What it does use is devm_ioremap_nocache() which comes from <linux/io.h> implicitly by including that header. Fix this up by including the right header instead. Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Vincent Abriou <vincent.abriou@st.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Benjamin Gaignard <benjamin.gaignard@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823071428.6155-1-linus.walleij@linaro.org
-
