summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-02-13drm/stm: Convert to CRTC VBLANK callbacksThomas Zimmermann2-1/+1
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert stm over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Yannick Fertré <yannick.fertre@st.com> Acked-by: Philippe Cornu <philippe.cornu@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-16-tzimmermann@suse.de
2020-02-13drm/stm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann3-42/+39
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert stm over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Philippe Cornu <philippe.cornu@st.com> Tested-by: Yannick Fertré <yannick.fertre@st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-15-tzimmermann@suse.de
2020-02-13drm/msm: Convert to CRTC VBLANK callbacksThomas Zimmermann6-38/+28
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert msm over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Yannick Fertré <yannick.fertre@st.com> Acked-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-14-tzimmermann@suse.de
2020-02-13drm/msm: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann2-61/+67
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert msm over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-13-tzimmermann@suse.de
2020-02-13drm/radeon: Convert to CRTC VBLANK callbacksThomas Zimmermann3-22/+26
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert radeon over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-12-tzimmermann@suse.de
2020-02-13drm/radeon: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann5-12/+22
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert radeon over. v4: * 80-character line fixes Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-11-tzimmermann@suse.de
2020-02-13drm/nouveau: Convert to CRTC VBLANK callbacksThomas Zimmermann5-18/+11
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert nouvean over. v4: * add argument names in function declaration Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-10-tzimmermann@suse.de
2020-02-13drm/nouveau: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann5-15/+9
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert nouveau over. v4: * add argument names in function declaration Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-9-tzimmermann@suse.de
2020-02-13drm/i915: Convert to CRTC VBLANK callbacksThomas Zimmermann4-12/+24
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert i915 over. The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). i915 doesn't use CRTC helpers. Instead pass i915's implementation of get_scanout_position() to DRM core's drm_crtc_vblank_helper_get_vblank_timestamp_internal(). v3: * rename dcrtc to _crtc * use intel_ prefix for i915_crtc_get_vblank_timestamp() * update for drm_crtc_vblank_helper_get_vblank_timestamp_internal() v2: * use DRM's implementation of get_vblank_timestamp() * simplify function names Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-8-tzimmermann@suse.de
2020-02-13drm/gma500: Convert to CRTC VBLANK callbacksThomas Zimmermann6-13/+22
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert gma500 over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-7-tzimmermann@suse.de
2020-02-13drm/amdgpu: Convert to CRTC VBLANK callbacksThomas Zimmermann10-22/+43
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert amdgpu over. v2: * don't wrap existing functions; change signature instead Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-6-tzimmermann@suse.de
2020-02-13drm/amdgpu: Convert to struct drm_crtc_helper_funcs.get_scanout_position()Thomas Zimmermann9-12/+24
The callback struct drm_driver.get_scanout_position() is deprecated in favor of struct drm_crtc_helper_funcs.get_scanout_position(). Convert amdgpu over. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-5-tzimmermann@suse.de
2020-02-13drm: Add get_vblank_timestamp() to struct drm_crtc_funcsThomas Zimmermann4-17/+125
The callback get_vblank_timestamp() is currently located in struct drm_driver, but really belongs into struct drm_crtc_funcs. Add an equivalent there. Driver will be converted in separate patches. The default implementation is drm_calc_vbltimestamp_from_scanoutpos(). The patch adds drm_crtc_vblank_helper_get_vblank_timestamp(), which is an implementation for the CRTC callback. v4: * more readable code for setting high_prec (Ville, Jani) v3: * use refactored timestamp calculation to minimize duplicated code * do more checks for crtc != NULL to support legacy drivers v2: * rename helper to drm_crtc_vblank_helper_get_vblank_timestamp() * replace drm_calc_vbltimestamp_from_scanoutpos() with drm_crtc_vblank_helper_get_vblank_timestamp() in docs Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-4-tzimmermann@suse.de
2020-02-13drm: Add get_scanout_position() to struct drm_crtc_helper_funcsThomas Zimmermann4-23/+157
The new callback get_scanout_position() reads the current location of the scanout process. The operation is currently located in struct drm_driver, but really belongs to the CRTC. Drivers will be converted in separate patches. To help with the conversion, the timestamp calculation has been moved from drm_calc_vbltimestamp_from_scanoutpos() to drm_crtc_vblank_helper_get_vblank_timestamp_internal(). The helper function supports the new and old interface of get_scanout_position(). drm_calc_vbltimestamp_from_scanoutpos() remains as a wrapper around the new function. Callback functions return the scanout position from the CRTC. The legacy version of the interface receives the device and pipe index, the modern version receives a pointer to the CRTC. We keep the legacy version until all drivers have been converted. v4: * 80-character line fixes v3: * refactor drm_calc_vbltimestamp_from_scanoutpos() to minimize code duplication * define types for get_scanout_position() callbacks v2: * fix logical op in drm_calc_vbltimestamp_from_scanoutpos() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Tested-by: Yannick Fertré <yannick.fertre@st.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-3-tzimmermann@suse.de
2020-02-13drm: Remove internal setup of struct drm_device.vblank_disable_immediateThomas Zimmermann1-13/+0
VBLANK interrupts can be disabled immediately or with a delay, where the latter is the default. The former option can be selected by setting get_vblank_timestamp and enabling vblank_disable_immediate in struct drm_device. Simplify the code in preparation of the removal of struct drm_device.get_vblank_timestamp. v3: * remove internal setup of vblank_disable_immediate Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200123135943.24140-2-tzimmermann@suse.de
2020-02-13drm/virtio: fix virtio_gpu_cursor_plane_update().Gerd Hoffmann1-0/+1
Add missing virtio_gpu_array_lock_resv() call. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200211135047.22261-3-kraxel@redhat.com
2020-02-13drm/virtio: fix virtio_gpu_execbuffer_ioctl lockingGerd Hoffmann1-10/+10
Lockdep says we can't call vmemdup() while having objects reserved because it needs the mmap semaphore. So reorder the calls reserve the objects later. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Chia-I Wu <olvaffe@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200211135047.22261-2-kraxel@redhat.com
2020-02-13drm/qxl: replace zero-length array with flexible-array memberGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertenly introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200212193344.GA27929@embeddedor Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2020-02-13drm/hisilicon/hibmc: add gamma_set functionZhihui Chen2-0/+42
Add gamma_set function, and we can also use it to adjust the brightness of the display. Signed-off-by: Zhihui Chen <chenzhihui4@huawei.com> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> Acked-by: Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191223074910.1030-1-chenzhihui4@huawei.com
2020-02-13drm/hisilicon/hibmc: add DPMS on/off functionZhihui Chen2-0/+22
add DPMS function to turn on/off signal of monitor Signed-off-by: Zhihui Chen <chenzhihui4@huawei.com> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> Acked-by: Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191220023112.2728-1-chenzhihui4@huawei.com
2020-02-13drm/hisilicon/hibmc: fix 'xset dpms force off' failZhihui Chen1-0/+3
both crtc_state->adjusted_mode.hdisplay and crtc_state->adjusted_mode.vdisplay are 0 when switch dpms off, return -EINVAL cause switch dpms off fail. Signed-off-by: Zhihui Chen <chenzhihui4@huawei.com> Signed-off-by: Xinliang Liu <xinliang.liu@linaro.org> Acked-by: Xinliang Liu <xinliang.liu@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191220023004.2658-1-chenzhihui4@huawei.com
2020-02-13drm/bridge: ti-sn65dsi86: Avoid invalid ratesDouglas Anderson1-25/+75
Based on work by Bjorn Andersson <bjorn.andersson@linaro.org>, Jeffrey Hugo <jeffrey.l.hugo@gmail.com>, and Rob Clark <robdclark@chromium.org>. Let's read the SUPPORTED_LINK_RATES and/or MAX_LINK_RATE (depending on the eDP version of the sink) to figure out what eDP rates are supported and pick the ideal one. NOTE: I have only personally tested this code on eDP panels that are 1.3 or older. Code reading SUPPORTED_LINK_RATES for DP 1.4+ was tested by hacking the code to pretend that a table was there. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.9.Ib59207b66db377380d13748752d6fce5596462c5@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Train at faster rates if slower ones failDouglas Anderson1-11/+60
If we fail training at a lower DP link rate let's now keep trying until we run out of rates to try. Basically the algorithm here is to start at the link rate that is the theoretical minimum and then slowly bump up until we run out of rates or hit the max rate of the sink. We query the sink using a DPCD read. This is, in fact, important in practice. Specifically at least one panel hooked up to the bridge (AUO B116XAK01) had a theoretical min rate more than 1.62 GHz (if run at 24 bpp) and fails to train at the next rate (2.16 GHz). It would train at 2.7 GHz, though. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.8.I251add713bc5c97225200894ab110ea9183434fd@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Group DP link training bits in a functionDouglas Anderson1-34/+52
We'll re-organize the ti_sn_bridge_enable() function a bit to group together all the parts relating to link training and split them into a sub-function. This is not intended to have any functional change and is in preparation for trying link training several times at different rates. One small side effect here is that if link training fails we'll now leave the DP PLL disabled, but that seems like a sane thing to do. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.7.I1fc75ad11db9048ef08cfe1ab7322753d9a219c7@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Use 18-bit DP if we canDouglas Anderson1-9/+18
The current bridge driver always forced us to use 24 bits per pixel over the DP link. This is a waste if you are hooked up to a panel that only supports 6 bits per color or fewer, since in that case you can run at 18 bits per pixel and thus end up at a lower DP clock rate. Let's support this. While at it, let's clean up the math in the function to avoid rounding errors (and round in the correct direction when we have to round). Numbers are sufficiently small (because mode->clock is in kHz) that we don't need to worry about integer overflow. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> [narmstrong: s/ran/can/] Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.6.Iaf8d698f4e5253d658ae283d2fd07268076a7c27@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Read num lanes from the DP sinkDouglas Anderson1-2/+30
At least one panel hooked up to the bridge (AUO B116XAK01) only supports 1 lane of DP. Let's read this information and stop hardcoding 4 DP lanes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.5.Idbd0051d0de53f7e9d18a291ea33011c0854fcc6@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Config number of DP lanes Mo' BettaDouglas Anderson1-1/+1
The driver used to say that the value to program into bridge register 0x93 was dp_lanes - 1. Looking at the datasheet for the bridge, this is wrong. The data sheet says: * 1 = 1 lane * 2 = 2 lanes * 3 = 4 lanes A more proper way to express this encoding is min(dp_lanes, 3). At the moment this change has zero effect because we've hardcoded the number of DP lanes to 4. ...and (4 - 1) == min(4, 3). How fortunate! ...but soon we'll stop hardcoding the number of lanes. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.4.If3e2d0493e7b6e8b510ea90d8724ff760379b3ba@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Don't use MIPI variables for DP linkDouglas Anderson1-6/+12
The ti-sn65dsi86 is a bridge from MIPI to DP and thus has two links: the MIPI link and the DP link. The two links do not need to have the same format or number of lanes. Stop using MIPI variables when talking about the DP link. This has zero functional change because: * currently we are hardcoding the MIPI link as unpacked RGB888 which requires 24 bits and currently we are not changing the DP link rate from the bridge's default of 8 bits per pixel. * currently we are hardcoding both the MIPI and DP as being 4 lanes. This is all in prep for fixing some of the above. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.3.Ia6e05f4961adb0d4a0d32ba769dd7781ee8db431@changeid
2020-02-13drm/bridge: ti-sn65dsi86: zero is never greater than an unsigned intDouglas Anderson1-1/+1
When we iterate over ti_sn_bridge_dp_rate_lut, there's no reason to start at index 0 which always contains the value 0. 0 is not a valid link rate. This change should have no real effect but is a small cleanup. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.2.Id445d0057bedcb0a190009e0706e9254c2fd48eb@changeid
2020-02-13drm/bridge: ti-sn65dsi86: Split the setting of the dp and dsi ratesDouglas Anderson1-10/+23
These two things were in one function. Split into two. This looks like it's duplicating some code, but don't worry. This is is just in preparation for future changes. This is intended to have zero functional change and will just make future patches easier to understand. Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191218143416.v3.1.Icb765d5799e9651e5249c0c27627ba33a9e411cf@changeid
2020-02-12drm/ttm: individualize resv objects before calling release_notifyChristian König1-8/+8
This allows release_notify to add and remove fences from deleted objects. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/352750/
2020-02-12drm/ttm: replace dma_resv object on deleted BOs v3Christian König1-1/+13
When non-imported BOs are resurrected for delayed delete we replace the dma_resv object to allow for easy reclaiming of the resources. v2: move that to ttm_bo_individualize_resv v3: add a comment to explain what's going on Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/352927/
2020-02-12drm/ttm: rework BO delayed delete. v2Christian König3-132/+97
This patch reworks the whole delayed deletion of BOs which aren't idle. Instead of having two counters for the BO structure we resurrect the BO when we find that a deleted BO is not idle yet. This has many advantages, especially that we don't need to increment/decrement the BOs reference counter any more when it moves on the LRUs. v2: remove duplicate ttm_tt_destroy, fix holde lock for LRU move Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/352912/
2020-02-12drm/virtio: add drm_driver.release callback.Gerd Hoffmann5-17/+27
Split virtio_gpu_deinit(), move the drm shutdown and release to virtio_gpu_release(). Drop vqs_ready variable, instead use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200211135805.24436-1-kraxel@redhat.com
2020-02-12drm/cirrus: add drm_driver.release callback.Gerd Hoffmann1-6/+37
Move final cleanups from cirrus_pci_remove() to the new callback. Add drm_atomic_helper_shutdown() call to cirrus_pci_remove(). Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. v4: add changelog. v3: use drm_dev*. v2: stop touching hardware after pci_remove(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200211135522.23654-1-kraxel@redhat.com
2020-02-12drm/bochs: add drm_driver.release callback.Gerd Hoffmann2-4/+26
Call bochs_unload via drm_driver.release to make sure we release stuff when it is safe to do so. Use drm_dev_{enter,exit,unplug} to avoid touching hardware after device removal. Tidy up here and there. v4: add changelog. v3: use drm_dev_*(). v2: move hardware deinit to pci_remove(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200211135218.22871-1-kraxel@redhat.com
2020-02-11drm/irq: remove check on dev->dev_privateJani Nikula1-4/+0
There is no real reason to require drivers to set and use dev->dev_private. Indeed, the current recommendation, as documented in drm_device.h, is to embed struct drm_device in the per-device struct instead of using dev_private. Remove the requirement for dev_private to have been set to indicate driver initialization. For background, quoting Daniel Vetter: Now there might be some hilarious races this papers over, but: - Proper drivers should only call drm_dev_register once everything is set up, including this stuff here. No race possible with anything else really. - Slightly more wobbly drivers, including the legacy ones, all use drm_global_mutex. This was the former BKL, which means that it was impossible for soeone to go through the load/unload/reload (between lastclose and firstopen) paths and also run the ioctl. But the ioctl had to be made unlocked because blocking there killed X: commit 8f4ff2b06afcd6f151868474a432c603057eaf56 Author: Ilija Hadzic <ihadzic@research.bell-labs.com> Date: Mon Oct 31 17:46:18 2011 -0400 drm: do not sleep on vblank while holding a mutex The even more legacy DRM_CONTROL ioctl stayed fully locked. But the file open/close paths are still fully locked, and that's the only place legacy drivers should call drm_irq_install/uninstall, so should all still be fully ordered and protected and happy. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200211144753.3175-1-jani.nikula@intel.com
2020-02-11drm/panel: simple: Add Rocktech RK101II01D-CT panelJyri Sarha1-0/+32
Add support for Rocktech RK101II01D-CT, 10.1" 1280x800 TFT with LVDS interface, LED backlight and integrated Goodix GT928 capacitive touch panel. Signed-off-by: Jyri Sarha <jsarha@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/b543b77d8af7cbbef852d3df4595f11ac1aa0046.1581423249.git.jsarha@ti.com
2020-02-11dt-bindings: panel-simple: Add rocktech,rk101ii01d-ct compatibleJyri Sarha1-0/+2
Add compatible to panel-simple for Rocktech Displays Limited RK101II01D-CT 10.1" TFT 1280x800 Pixels with LVDS interface, LED Backlight, and capacitive touch panel ("goodix,gt928" compatible). Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/2ffedf45e65943a021ed57a0d174900e43663b27.1581423249.git.jsarha@ti.com
2020-02-11drm: Nerf drm_global_mutex BKL for good driversDaniel Vetter3-8/+47
This catches the majority of drivers (unfortunately not if we take users into account, because all the big drivers have at least a lastclose hook). With the prep patches out of the way all drm state is fully protected and either prevents or can deal with the races from dropping the BKL around open/close. The only thing left to audit are the various driver hooks - by keeping the BKL around if any of them are set we have a very simple cop-out! Note that one of the biggest prep pieces to get here was making dev->open_count atomic, which was done in commit 7e13ad896484a0165a68197a2e64091ea28c9602 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Jan 24 13:01:07 2020 +0000 drm: Avoid drm_global_mutex for simple inc/dec of dev->open_count v2: - Rebase and fix locking in drm_open() (Chris) - Indentation fix in drm_release - Typo fix in the commit message (Sam) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-6-daniel.vetter@ffwll.ch
2020-02-11drm: Push drm_global_mutex locking in drm_openDaniel Vetter2-9/+11
We want to only take the BKL on crap drivers, but to know whether we have a crap driver we first need to look it up. Split this shuffle out from the main BKL-disabling patch, for more clarity. Historical aside: When the kernel-wide BKL was removed, it was replaced by drm_global_mutex within the scope of the drm subsystem hence why these two things are (almost) interchangeable as concepts here. Since the minors are refcounted drm_minor_acquire is purely internal and this does not have a driver visible effect. v2: Push the locking even further into drm_open(), suggested by Chris. This gives us more symmetry with drm_release(), and maybe a futuer avenue where we make drm_global_mutex locking (partially) opt-in like with drm_release_noglobal(). v3: - Actually push this stuff correctly, don't unlock twice (Chris) - Fix typo on commit message, plus explain why BKL = drm_global_mutex (Sam) Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-5-daniel.vetter@ffwll.ch
2020-02-11drm/client: Rename _force to _lockedDaniel Vetter3-8/+10
Plus extend the kerneldoc a bit to explain how this should be used. With the previous patch to drop the force restore the main user of this function is not emphasis on the "I hold the internal master lock already" aspect, so rename the function to match. Suggested by Noralf. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-4-daniel.vetter@ffwll.ch
2020-02-11drm/fbdev-helper: don't force restoresDaniel Vetter2-11/+6
Instead check for master status, in case we've raced. This is the last exception to the general rule that we restore fbcon only when there's no master active. Compositors are supposed to drop their master status before they switch to a different console back to text mode (or just switch to text mode directly, without a vt switch). This is known to break some subtests of kms_fbcon_fbt in igt, but they're just wrong - it does a graphics/text mode switch for the vt without updating the master status. Also add a comment to the drm_client->restore hook that this is expected going forward from all clients (there's currently just one). v2: Also drop the force in pan_display v3: Restore the _force to pan_display, this actually means _locked in that path. Spotted by Noralf. Cc: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200204150146.2006481-3-daniel.vetter@ffwll.ch
2020-02-11drm/ttm: use RCU in ttm_bo_flush_all_fencesChristian König1-4/+6
This allows it to call the function without the lock held. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/352742/
2020-02-11drm/ttm: cleanup ttm_buffer_object_transferChristian König1-9/+3
The function is always called with deleted BOs. While at it cleanup the indentation as well. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/352743/
2020-02-11drm/ttm: refine ghost BO resv criteriaChristian König1-1/+1
Ghost BOs need to stick with the resv object only when the origin is imported. This is a low hanging fruit to avoid OOM situations on evictions. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: xinhui pan <xinhui.pan@amd.com> Link: https://patchwork.freedesktop.org/patch/352740/
2020-02-11drm/qxl: add drm_driver.release callback.Gerd Hoffmann1-7/+19
Move final cleanups to qxl_drm_release() callback. Add drm_atomic_helper_shutdown() call to qxl_pci_remove(). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200210113753.5614-3-kraxel@redhat.com
2020-02-11drm/qxl: reorder calls in qxl_device_fini().Gerd Hoffmann1-2/+2
Reorder calls in qxl_device_fini(). Cleaning up gem & ttm might trigger qxl commands, so we should do that before releaseing command rings. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20200210113753.5614-2-kraxel@redhat.com
2020-02-11drm/omap: fix possible object reference leakWen Yang1-1/+3
The call to of_find_matching_node 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/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function. Signed-off-by: Wen Yang <wen.yang99@zte.com.cn> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: Markus Elfring <Markus.Elfring@web.de> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
2020-02-11drm/omap: dmm_tiler: Remove the dma_async_issue_pending() callPeter Ujfalusi1-1/+0
dma_sync_wait() is calling it so no need to call it in the driver. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190731094233.13890-3-peter.ujfalusi@ti.com
generated by cgit v1.2.3 (git 2.39.0) at 2024-12-02 22:42:35 +0300