summaryrefslogtreecommitdiffstats
path: root/include/drm
AgeCommit message (Collapse)AuthorFilesLines
2019-10-03Merge drm/drm-next into drm-misc-nextMaxime Ripard7-16/+47
We haven't done any backmerge for a while due to the merge window, and it starts to become an issue for komeda. Let's bring 5.4-rc1 in. Signed-off-by: Maxime Ripard <mripard@kernel.org>
2019-10-02drm/print: add drm_debug_enabled()Jani Nikula1-0/+5
Add helper to check if a drm debug category is enabled. Convert drm core to use it. No functional changes. v2: Move unlikely() to drm_debug_enabled() (Eric) v3: Keep unlikely() when combined with other conditions (Eric) Cc: Eric Engestrom <eric@engestrom.ch> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Eric Engestrom <eric@engestrom.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191001140614.26909-1-jani.nikula@intel.com
2019-10-02drm/print: move drm_debug variable to drm_print.[ch]Jani Nikula2-2/+2
Move drm_debug variable declaration and definition to where they are relevant and needed. No functional changes. Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Eric Engestrom <eric@engestrom.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/71a566c68883b6e6c61414cd9f7c36c84015edb1.1569329774.git.jani.nikula@intel.com
2019-10-01drm/rect: Add drm_rect_init()Ville Syrjälä1-0/+17
Add a helper to initialize a rectangle from x/y/w/h information. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190930134214.24702-2-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-10-01drm/rect: Add drm_rect_translate_to()Ville Syrjälä1-0/+14
Add a helper to translate a rectangle to an absolute position. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190930134214.24702-1-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
2019-09-27drm/vram: Support top-down placement flagThomas Zimmermann1-0/+1
Pinning lots of small buffer objects, such as cursors or sprites, to video memory can lead to fragmentation, which is a problem for devices with only a small amount of memory. As a result, framebuffer images might not get pinned, even though there's enough space available overall. The flag DRM_GEM_VRAM_PL_FLAG_TOPDOWN marks buffer objects to be pinned at the high end of video memory. This leaves contiguous space available at the memory's low end. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190923172753.26593-2-tzimmermann@suse.de Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
2019-09-25drm/dp_mst: Remove lies in {up, down}_rep_recv documentationLyude Paul1-6/+2
These are most certainly accessed from far more than the mgr work. In fact, up_req_recv is -only- ever accessed from outside the mgr work. 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: Sean Paul <sean@poorly.run> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-19-lyude@redhat.com
2019-09-24drm: tweak drm_print_bits()Gerd Hoffmann1-3/+2
There is little reason for the from/to logic, printing a subset of the bits can be done by simply shifting/masking value if needed. Also use for_each_set_bit(). Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Sean Paul <sean@poorly.run> Link: http://patchwork.freedesktop.org/patch/msgid/20190923065814.4797-1-kraxel@redhat.com
2019-09-20drm: Add DisplayPort colorspace property creation functionGwan-gyeong Mun1-0/+5
Because between HDMI and DP have different colorspaces, it adds drm_mode_create_dp_colorspace_property() function for creating of DP colorspace property. v3: Addressed review comments from Ville - Add new colorimetry options for DP 1.4a spec. - Separate set of colorimetry enum values for DP. v4: Add additional comments to struct drm_prop_enum_list. Polishing an enum string of struct drm_prop_enum_list v5: Change definitions of DRM_MODE_COLORIMETRYs to follow HDMI prefix and DP abbreviations. Add missed variables on dp_colorspaces. Fix typo. [Uma] v6: Addressed review comments from Ilia and Ville - Split drm_mode_create_colorspace_property() to DP and HDMI connector. v7: Fix typo [Jani Saarinen] Fix white space. v8: Addressed review comments from Ville - Drop colorimetries which have another way to distinguish or which would not be used. v9: Addressed review comments from Ville - Split hunk into renaming and adding of code. Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Reviewed-by: Uma Shankar <uma.shankar@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919195311.13972-5-gwan-gyeong.mun@intel.com
2019-09-20drm: Rename HDMI colorspace property creation functionGwan-gyeong Mun1-1/+1
As between HDMI and DP have different colorspaces, in order to distinguish colorspace of DP and HDMI, it renames drm_mode_create_colorspace_property() function to drm_mode_create_hdmi_colorspace_property() function for HDMI connector. In order to apply changed drm api, i915 driver has channged. It addresses review comments from Ville. - Split hunk into renaming and adding of code. Signed-off-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190919195311.13972-4-gwan-gyeong.mun@intel.com
2019-09-19drm/dp: Add definitons for MSA MISC bitsVille Syrjälä1-0/+42
Add definitions for the MSA (Main Stream Attribute) MISC bits. On some hardware you can program these directly into a register. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718145053.25808-2-ville.syrjala@linux.intel.com Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
2019-09-19drm: Add drm_modeset_lock_assert_held()Ville Syrjälä1-0/+9
Add a small wrapper around lockdep_assert_held() to make it a bit more conventinet to use with modeset locks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190708125325.16576-2-ville.syrjala@linux.intel.com Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
2019-09-19drm: Measure Self Refresh Entry/Exit times to avoid thrashingSean Paul1-3/+3
Currently the self refresh idle timer is a const set by the crtc. This is fine if the self refresh entry/exit times are well-known for all panels used on that crtc. However panels and workloads can vary quite a bit, and a timeout which works well for one doesn't work well for another. In the extreme, if the timeout is too short we could get in a situation where the self refresh exits are taking so long we queue up a self refresh entry before the exit commit is even finished. This patch changes the idle timeout to a moving average of the entry times + a moving average of exit times + the crtc constant. This patch was tested on rockchip, with a kevin CrOS panel the idle delay averages out to about ~235ms (35 entry + 100 exit + 100 const). On the same board, the bob panel idle delay lands around ~340ms (90 entry + 150 exit + 100 const). WRT the dedicated mutex in self_refresh_data, it would be nice if we could rely on drm_crtc.mutex to protect the average times, but there are a few reasons why a separate lock is a better choice: - We can't rely on drm_crtc.mutex being held if we're doing a nonblocking commit - We can't grab drm_crtc.mutex since drm_modeset_lock() doesn't tell us whether the lock was already held in the acquire context (it eats -EALREADY), so we can't tell if we should drop it or not - We don't need such a heavy-handed lock for what we're trying to do, commit ordering doesn't matter, so a point-of-use lock will be less contentious Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-2-sean@poorly.run Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-2-sean@poorly.run Changes in v2: - Migrate locking explanation from comment to commit msg (Daniel) - Turf constant entry delay and multiply the avg times by 2 (Daniel)
2019-09-19drm: Fix kerneldoc and remove unused struct member in self_refresh helperSean Paul1-1/+1
Artifacts of previous revisions. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link to v1: https://patchwork.freedesktop.org/patch/msgid/20190917200443.64481-1-sean@poorly.run Link: https://patchwork.freedesktop.org/patch/msgid/20190918200734.149876-1-sean@poorly.run Changes in v2: - None
2019-09-18drm/atomic: Rename crtc_state->pageflip_flags to async_flipDaniel Vetter1-4/+4
It's the only flag anyone actually cares about. Plus if we're unlucky, the atomic ioctl might need a different flag for async flips. So better to abstract this away from the uapi a bit. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Michel Dänzer <michel@daenzer.net> Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Adam Jackson <ajax@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Leo Li <sunpeng.li@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: David Francis <David.Francis@amd.com> Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20190903190642.32588-3-daniel.vetter@ffwll.ch
2019-09-17drm/encoder: Don't raise voice in drm_encoder_mask() documentationLyude Paul1-1/+1
There's no need to raise our voice when saying encoder, we're all civilized adults here! Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913222704.8241-4-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-09-17drm/encoder: Fix possible_crtcs documentationLyude Paul1-1/+1
Similar to possible_clones, we don't actually use possible_crtcs until the driver is registered with userspace. So, fix the documentation to indicate this. Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913222704.8241-3-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-09-17drm/encoder: Fix possible_clones documentationLyude Paul1-1/+1
We say that all of the bits in possible_clones must be set before calling drm_encoder_init(). This isn't true though, since: * The driver may not even have all of the encoder objects that could be used as clones initialized at that point * possible_crtcs isn't used at all outside of userspace, so it's not actually needed to initialize it until drm_dev_register() So, fix it. Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913222704.8241-2-lyude@redhat.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2019-09-17drm/vram: Provide vmap and vunmap operations for GEM VRAM objectsThomas Zimmermann1-1/+4
The implementation of vmap and vunmap for GEM VRAM helpers is already in PRIME helpers. The patch moves the operations to separate functions and exports them for general use. v3: * remove v2's obsolete note on ref-counting v2: * fix documentation * add cross references to function documentation * document (the lack of) ref-counting for GEM VRAM BO mappings Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911120352.20084-2-tzimmermann@suse.de
2019-09-16drm/connector: Allow max possible encoders to attach to a connectorJosé Roberto de Souza1-11/+7
Currently we restrict the number of encoders that can be linked to a connector to 3, increase it to match the maximum number of encoders that can be initialized(32). To more effiently do that lets switch from an array of encoder ids to bitmask. v2: Fixing missed return on amdgpu_dm_connector_to_encoder() Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-2-jose.souza@intel.com
2019-09-16drm/connector: Share with non-atomic drivers the function to get the single ↵José Roberto de Souza1-4/+3
encoder This 3 non-atomic drivers all have the same function getting the only encoder available in the connector, also atomic drivers have this fallback. So moving it a common place and sharing between atomic and non-atomic drivers. While at it I also removed the mention of drm_atomic_helper_best_encoder() that was renamed in commit 297e30b5d9b6 ("drm/atomic-helper: Unexport drm_atomic_helper_best_encoder"). v3: moving drm_connector_get_single_encoder to drm_kms_helper module Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: dri-devel@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190913232857.389834-1-jose.souza@intel.com
2019-09-16drm/prime: Remove duplicate forward declarationThierry Reding1-2/+0
struct device is forward-declared twice. Remove the second instance. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180111201730.30708-1-thierry.reding@gmail.com
2019-09-13drm/bridge: Fix references to drm_bridge_funcs in documentationLaurent Pinchart1-11/+11
The documentation for most of the bridge atomic operations incorrectly reference the non-atomic version when stating the operations are optional. Fix them, and make sure that all references to bridge operations are correctly marked with @. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190821235502.15475-1-laurent.pinchart+renesas@ideasonboard.com
2019-09-13drm: bridge/dw_hdmi: add audio sample channel status settingYakir Yang1-0/+1
When transmitting IEC60985 linear PCM audio, we configure the Aduio Sample Channel Status information in the IEC60958 frame. The status bit is already available in iec.status of hdmi_codec_params. This fix the issue that audio does not come out on some monitors (e.g. LG 22CV241) Note that these registers are only for interfaces: I2S audio interface, General Purpose Audio (GPA), or AHB audio DMA (AHBAUDDMA). For S/PDIF interface this information comes from the stream. Currently this function dw_hdmi_set_channel_status is only called from dw-hdmi-i2s-audio in I2S setup. Signed-off-by: Yakir Yang <ykk@rock-chips.com> Signed-off-by: Cheng-Yi Chiang <cychiang@chromium.org> Reviewed-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911082646.134347-1-cychiang@chromium.org
2019-09-12drm/vram: Unexport internal functions of VRAM MMThomas Zimmermann1-6/+0
The init, cleanup and mmap functions of VRAM MM are only used internally. Remove them from the public interface. v2: * update for debugfs support Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911110910.30698-4-tzimmermann@suse.de
2019-09-12drm/vram: Have VRAM MM call GEM VRAM functions directlyThomas Zimmermann2-54/+2
VRAM MM and GEM VRAM buffer objects are only used with each other; connected via 3 function pointers. Simplify this code by making the memory manager call the rsp. functions of the BOs directly; and remove the functions from the BO's public interface. v2: * typos in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911110910.30698-3-tzimmermann@suse.de
2019-09-12drm/vram: Move VRAM memory manager to GEM VRAM implementationThomas Zimmermann2-77/+86
The separation between GEM VRAM objects and the memory manager is artificial, as they are only used with each other. Copying both implementations into the same file is a first step to simplifying the code. This patch only moves code without functional changes. v3: * update to use dev->vma_offset_manager v2: * update for debugfs support * typos in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190911110910.30698-2-tzimmermann@suse.de
2019-09-11drm/ttm: remove embedded vma_offset_managerGerd Hoffmann1-3/+1
No users left. Drivers either setup vma_offset_manager themself (vmwgfx) or pass the gem vma_offset_manager to ttm_bo_device_init (all other drivers). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190905070509.22407-9-kraxel@redhat.com
2019-09-11drm/ttm: turn ttm_bo_device.vma_manager into a pointerGerd Hoffmann1-2/+6
Rename the embedded struct vma_offset_manager, new name is _vma_manager. ttm_bo_device.vma_manager changed to a pointer. The ttm_bo_device_init() function gets an additional vma_manager argument which allows to initialize ttm with a different vma manager. When passing NULL the embedded _vma_manager is used. All callers are updated to pass NULL, so the behavior doesn't change. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Christian König <christian.koenig@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/20190905070509.22407-2-kraxel@redhat.com
2019-09-10drm/vram: add vram-mm debugfs fileGerd Hoffmann2-0/+2
Wire up drm_mm_print() for vram helpers, using a new debugfs file, so one can see how vram is used: # cat /sys/kernel/debug/dri/0/vram-mm 0x0000000000000000-0x0000000000000300: 768: used 0x0000000000000300-0x0000000000000600: 768: used 0x0000000000000600-0x0000000000000900: 768: used 0x0000000000000900-0x0000000000000c00: 768: used 0x0000000000000c00-0x0000000000004000: 13312: free total: 16384, used 3072 free 13312 Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190904054740.20817-5-kraxel@redhat.com
2019-09-10drm/ttm: add drm gem ttm helpers, starting with drm_gem_ttm_print_info()Gerd Hoffmann1-0/+19
Now with ttm_buffer_object being a subclass of drm_gem_object we can easily lookup ttm_buffer_object for a given drm_gem_object, which in turn allows to create common helper functions. This patch starts off with a drm_gem_ttm_print_info() helper function which adds some ttm specific lines to the debug output. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190904054740.20817-3-kraxel@redhat.com
2019-09-10drm: add drm_print_bitsGerd Hoffmann1-0/+3
New helper to print named bits of some value (think flags fields). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: http://patchwork.freedesktop.org/patch/msgid/20190904054740.20817-2-kraxel@redhat.com
2019-09-09drm/vram: Implement lazy unmapping for GEM VRAM buffersThomas Zimmermann1-0/+4
Frequent mapping and unmapping a buffer object adds overhead for modifying the page table and creates debug output. Unmapping a buffer is only required when the memory manager evicts the buffer from its current location. v4: * WARN_ON if buffer is still mapped during BO cleanup Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-and-tested-by: Davidlohr Bueso <dbueso@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190906122056.32018-5-tzimmermann@suse.de
2019-09-09drm/vram: Add infrastructure for move_notify()Thomas Zimmermann1-0/+4
This patch prepares VRAM helpers for lazy unmapping of buffer objects. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-and-tested-by: Davidlohr Bueso <dbueso@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20190906122056.32018-4-tzimmermann@suse.de
2019-09-09drm/vram: Add kmap ref-counting to GEM VRAM objectsThomas Zimmermann1-0/+14
The kmap and kunmap operations of GEM VRAM buffers can now be called in interleaving pairs. The first call to drm_gem_vram_kmap() maps the buffer's memory to kernel address space and the final call to drm_gem_vram_kunmap() unmaps the memory. Intermediate calls to these functions increment or decrement a reference counter. This change allows for keeping buffer memory mapped for longer and minimizes the amount of changes to TLB, page tables, etc. v4: * lock in kmap()/kunmap() with ttm_bo_reserve() Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Gerd Hoffmann <kraxel@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reported-and-tested-by: Davidlohr Bueso <dbueso@suse.de> Cc: Davidlohr Bueso <dave@stgolabs.net> Link: https://patchwork.freedesktop.org/patch/msgid/20190906122056.32018-2-tzimmermann@suse.de
2019-09-08drm/bridge: panel: Infer connector type from panel by defaultLaurent Pinchart1-4/+7
The drm panel bridge creates a connector using a connector type explicitly passed by the display controller or bridge driver that instantiates the panel bridge. Now that drm_panel reports its connector type, we can use it to avoid passing an explicit (and often incorrect) connector type to drm_panel_bridge_add() and devm_drm_panel_bridge_add(). Several drivers report incorrect or unknown connector types to userspace. Reporting a different type may result in a breakage. For that reason, rename (devm_)drm_panel_bridge_add() to (devm_)drm_panel_bridge_add_typed(), and add new (devm_)drm_panel_bridge_add() functions that use the panel connector type. Update all callers of (devm_)drm_panel_bridge_add() to the _typed function, they will be converted one by one after testing. The panel drivers have been updated with the following Coccinelle semantic patch, with manual inspection and fixes to indentation. @@ expression bridge; expression dev; expression panel; identifier type; @@ ( -bridge = drm_panel_bridge_add(panel, type); +bridge = drm_panel_bridge_add_typed(panel, type); | -bridge = devm_drm_panel_bridge_add(dev, panel, type); +bridge = devm_drm_panel_bridge_add_typed(dev, panel, type); ) Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190904132804.29680-3-laurent.pinchart@ideasonboard.com
2019-09-08drm/panel: Add and fill drm_panel type fieldLaurent Pinchart1-1/+11
Add a type field to the drm_panel structure to report the panel type, using DRM_MODE_CONNECTOR_* macros (the values that make sense are LVDS, eDP, DSI and DPI). This will be used to initialise the corresponding connector type. Update all panel drivers accordingly. The panel-simple driver only specifies the type for the known to be LVDS panels, while all other panels are left as unknown and will be converted on a case-by-case basis as they all need to be carefully reviewed. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190904132804.29680-2-laurent.pinchart@ideasonboard.com
2019-09-03drm/dp_mst: Add sideband down request tracing + selftestsLyude Paul1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-8-lyude@redhat.com
2019-09-03drm/print: Add drm_err_printer()Lyude Paul1-0/+17
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: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190903204645.25487-6-lyude@redhat.com
2019-09-03drm/vblank: Document and fix vblank count barrier semanticsDaniel Vetter1-2/+13
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: 570e86963a51 ("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: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190723131337.22031-1-daniel.vetter@ffwll.ch
2019-08-29drm: mst: Fix query_payload ack reply structSean Paul1-1/+1
Spec says[1] Allocated_PBN is 16 bits [1]- DisplayPort 1.2 Spec, Section 2.11.9.8, Table 2-98 Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Lyude Paul <lyude@redhat.com> Cc: Todd Previte <tprevite@gmail.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190829165223.129662-1-sean@poorly.run
2019-08-28drm: Stop including drm_bridge.h from drm_crtc.hBoris Brezillon1-1/+0
We are about to add a drm_bridge_state that inherits from drm_private_state which is defined in drm_atomic.h. Problem is, drm_atomic.h includes drm_crtc.h which in turn includes drm_bridge.h, leading to "drm_private_state has incomplete type" error. Let's force all users of the drm_bridge API to explicitly include drm_bridge.h. Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190826152649.13820-2-boris.brezillon@collabora.com
2019-08-28drm/shmem: Use mutex_trylock in drm_gem_shmem_purgeRob Herring1-1/+1
Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. WARNING: possible circular locking dependency detected 5.3.0-rc1+ #100 Tainted: G L ------------------------------------------------------ kswapd0/171 is trying to acquire lock: 000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40 but task is already holding lock: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}: fs_reclaim_acquire.part.18+0x34/0x40 fs_reclaim_acquire+0x20/0x28 __kmalloc_node+0x6c/0x4c0 kvmalloc_node+0x38/0xa8 drm_gem_get_pages+0x80/0x1d0 drm_gem_shmem_get_pages+0x58/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xe8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc -> #0 (&shmem->pages_lock){+.+.}: __lock_acquire+0xa2c/0x1d70 lock_acquire+0xdc/0x228 __mutex_lock+0x8c/0x800 mutex_lock_nested+0x1c/0x28 drm_gem_shmem_purge+0x20/0x40 panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost] do_shrink_slab+0x208/0x500 shrink_slab+0x10c/0x2c0 shrink_node+0x28c/0x4d8 balance_pgdat+0x2c8/0x570 kswapd+0x22c/0x638 kthread+0x128/0x130 ret_from_fork+0x10/0x18 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&shmem->pages_lock); lock(fs_reclaim); lock(&shmem->pages_lock); *** DEADLOCK *** 3 locks held by kswapd0/171: #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0 #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost] Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-6-robh@kernel.org
2019-08-27drm_dp_cec: add connector info support.Dariusz Marcinkiewicz1-9/+8
Pass the connector info to the CEC adapter. This makes it possible to associate the CEC adapter with the corresponding drm connector. Signed-off-by: Dariusz Marcinkiewicz <darekm@google.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Tested-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl> Link: https://patchwork.freedesktop.org/patch/msgid/20190814104520.6001-2-darekm@google.com
2019-08-27Merge tag 'drm-next-5.4-2019-08-23' of ↵Dave Airlie1-0/+1
git://people.freedesktop.org/~agd5f/linux into drm-next drm-next-5.4-2019-08-23: amdgpu: - Enable power features on Navi12 - Enable power features on Arcturus - RAS updates - Initial Renoir APU support - Enable power featyres on Renoir - DC gamma fixes - DCN2 fixes - GPU reset support for Picasso - Misc cleanups and fixes scheduler: - Possible race fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexdeucher@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823202620.3870-1-alexander.deucher@amd.com
2019-08-24drm/panel: Initialise panel dev and funcs through drm_panel_init()Laurent Pinchart1-1/+2
Instead of requiring all drivers to set the dev and funcs fields of drm_panel manually after calling drm_panel_init(), pass the data as arguments to the function. This simplifies the panel drivers, and will help future refactoring when adding new arguments to drm_panel_init(). The panel drivers have been updated with the following Coccinelle semantic patch, with manual inspection to verify that no call to drm_panel_init() with a single argument still exists. @@ expression panel; expression device; identifier ops; @@ drm_panel_init(&panel + , device, &ops ); ... ( -panel.dev = device; -panel.funcs = &ops; | -panel.funcs = &ops; -panel.dev = device; ) Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190823193245.23876-3-laurent.pinchart@ideasonboard.com
2019-08-23drm/shmem: Use mutex_trylock in drm_gem_shmem_purgeRob Herring1-1/+1
Lockdep reports a circular locking dependency with pages_lock taken in the shrinker callback. The deadlock can't actually happen with current users at least as a BO will never be purgeable when pages_lock is held. To be safe, let's use mutex_trylock() instead and bail if a BO is locked already. WARNING: possible circular locking dependency detected 5.3.0-rc1+ #100 Tainted: G L ------------------------------------------------------ kswapd0/171 is trying to acquire lock: 000000009b9823fd (&shmem->pages_lock){+.+.}, at: drm_gem_shmem_purge+0x20/0x40 but task is already holding lock: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (fs_reclaim){+.+.}: fs_reclaim_acquire.part.18+0x34/0x40 fs_reclaim_acquire+0x20/0x28 __kmalloc_node+0x6c/0x4c0 kvmalloc_node+0x38/0xa8 drm_gem_get_pages+0x80/0x1d0 drm_gem_shmem_get_pages+0x58/0xa0 drm_gem_shmem_get_pages_sgt+0x48/0xd0 panfrost_mmu_map+0x38/0xf8 [panfrost] panfrost_gem_open+0xc0/0xe8 [panfrost] drm_gem_handle_create_tail+0xe8/0x198 drm_gem_handle_create+0x3c/0x50 panfrost_gem_create_with_handle+0x70/0xa0 [panfrost] panfrost_ioctl_create_bo+0x48/0x80 [panfrost] drm_ioctl_kernel+0xb8/0x110 drm_ioctl+0x244/0x3f0 do_vfs_ioctl+0xbc/0x910 ksys_ioctl+0x78/0xa8 __arm64_sys_ioctl+0x1c/0x28 el0_svc_common.constprop.0+0x90/0x168 el0_svc_handler+0x28/0x78 el0_svc+0x8/0xc -> #0 (&shmem->pages_lock){+.+.}: __lock_acquire+0xa2c/0x1d70 lock_acquire+0xdc/0x228 __mutex_lock+0x8c/0x800 mutex_lock_nested+0x1c/0x28 drm_gem_shmem_purge+0x20/0x40 panfrost_gem_shrinker_scan+0xc0/0x180 [panfrost] do_shrink_slab+0x208/0x500 shrink_slab+0x10c/0x2c0 shrink_node+0x28c/0x4d8 balance_pgdat+0x2c8/0x570 kswapd+0x22c/0x638 kthread+0x128/0x130 ret_from_fork+0x10/0x18 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(fs_reclaim); lock(&shmem->pages_lock); lock(fs_reclaim); lock(&shmem->pages_lock); *** DEADLOCK *** 3 locks held by kswapd0/171: #0: 00000000f82369b6 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x40 #1: 00000000ceb37808 (shrinker_rwsem){++++}, at: shrink_slab+0xbc/0x2c0 #2: 00000000f31efa81 (&pfdev->shrinker_lock){+.+.}, at: panfrost_gem_shrinker_scan+0x34/0x180 [panfrost] Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <maxime.ripard@bootlin.com> Cc: Sean Paul <sean@poorly.run> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190823021216.5862-6-robh@kernel.org
2019-08-23drm: drop resource_id parameter from ↵Gerd Hoffmann1-3/+1
drm_fb_helper_remove_conflicting_pci_framebuffers Not needed any more for remove_conflicting_pci_framebuffers calls. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190822090645.25410-3-kraxel@redhat.com
2019-08-23fbdev: drop res_id parameter from remove_conflicting_pci_framebuffersGerd Hoffmann1-1/+1
Since commit b0e999c95581 ("fbdev: list all pci memory bars as conflicting apertures") the parameter was used for some sanity checks only, to make sure we detect any issues with the new approach to just list all memory bars as apertures. No issues turned up so far, so continue to cleanup: Drop the res_id parameter, drop the sanity checks. Also downgrade the logging from "info" level to "debug" level and update documentation. Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20190822090645.25410-2-kraxel@redhat.com
2019-08-22Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi28-429/+536
We need the rename of reservation_object to dma_resv. The solution on this merge came from linux-next: From: Stephen Rothwell <sfr@canb.auug.org.au> Date: Wed, 14 Aug 2019 12:48:39 +1000 Subject: [PATCH] drm: fix up fallout from "dma-buf: rename reservation_object to dma_resv" Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au> --- drivers/gpu/drm/i915/gt/intel_engine_pool.c | 8 ++++---- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pool.c b/drivers/gpu/drm/i915/gt/intel_engine_pool.c index 03d90b49584a..4cd54c569911 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_pool.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_pool.c @@ -43,12 +43,12 @@ static int pool_active(struct i915_active *ref) { struct intel_engine_pool_node *node = container_of(ref, typeof(*node), active); - struct reservation_object *resv = node->obj->base.resv; + struct dma_resv *resv = node->obj->base.resv; int err; - if (reservation_object_trylock(resv)) { - reservation_object_add_excl_fence(resv, NULL); - reservation_object_unlock(resv); + if (dma_resv_trylock(resv)) { + dma_resv_add_excl_fence(resv, NULL); + dma_resv_unlock(resv); } err = i915_gem_object_pin_pages(node->obj); which is a simplified version from a previous one which had: Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-07 05:14:07 +0000