- 25 Oct, 2019 7 commits
-
-
Christian König authored
The ttm_mem_io_* functions were intended to be internal to TTM and shouldn't have been used in a driver. They were exported in commit afe6804c just for QXL. Instead call the qxl_ttm_io_mem_reserve() function directly and completely drop the free call since that is a dummy on QXL. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/333289/
-
Christian König authored
This way the TTM is destroyed with the correct dma_resv object locked and we can even pipeline imported BO evictions. v2: Limit this to only cases when the parent object uses a separate reservation object as well. This fixes another OOM problem. v3: fix init and try_lock on the wrong object Signed-off-by:Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/337499/
-
Christian König authored
As the name says global memory and bo accounting is global. So it doesn't make to much sense having pointers to global structures all around the code. Signed-off-by:
Thomas Hellström <thellstrom@vmware.com> Link: https://patchwork.freedesktop.org/patch/332879/
-
Christian König authored
This allows blocking for BOs to become available in the memory management. Amdgpu is doing this for quite a while now during CS. Now apply the new behavior to all drivers using TTM. Signed-off-by:
-
Christian König authored
This feature is only used by vmwgfx and superfluous for everybody else. Signed-off-by:
-
Bhanusree authored
-Issue found using checkpatch.pl -Insert comments for memory barrier usage Signed-off-by:
Bhanusree <bhanusreemahesh@gmail.com> Signed-off-by:
-
Bhanusree authored
-Insert a blank line after the declarations. -Issue found using checkpatch.pl Signed-off-by:
-
- 24 Oct, 2019 10 commits
-
-
Geert Uytterhoeven authored
Fix misspellings of "connector" and "connection" Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Thomas Zimmermann authored
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb() of struct drm_plane_helper_funcs. Switch over vboxvideo. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
-
Thomas Zimmermann authored
This patch implements prepare_fb() and cleanup_fb() in hibmc with the GEM VRAM helpers. In the current code, pinning the BO is performed by hibmc_plane_atomic_update(), where the operation does not belong. This patch also fixes a bug where the pinned BO was never unpinned. Pinning multiple BOs would have exhaused the available VRAM and further pin operations would have failed, leaving the display in a corrupt state. Signed-off-by:
-
Thomas Zimmermann authored
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb() of struct drm_simple_display_pipe_funcs. Switch over bochs. v2: * use helpers for struct drm_simple_display_pipe_funcs Signed-off-by:
-
Thomas Zimmermann authored
The new helpers pin and unpin a framebuffer's GEM VRAM objects during plane updates. This should be sufficient for most drivers' implementation of prepare_fb() and cleanup_fb(). v2: * provide helpers for struct drm_simple_display_pipe_funcs * rename plane-helper funcs Signed-off-by:
-
Bhanusree authored
-Add comment for memory barrier -Issue found using checkpatch.pl Signed-off-by:
-
Wambui Karuga authored
Remove unnecessary casts to pointer types passed to kfree. Issue detected by coccinelle: @@ type t1; expression *e; @@ -kfree((t1 *)e); +kfree(e); Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Passing the wrong type feels icky, everywhere else we use the pipe as the first parameter. Spotted while discussing patches with Thomas Zimmermann. v2: Make xen compile correctly Acked-By: Thomas Zimmermann <tzimmermann@suse.de> (v1) Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Eric Anholt <eric@anholt.net> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: virtualization@lists.linux-foundation.org Cc: Linus Walleij <linus.walleij@linaro.org> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191023101256.20509-1-daniel.vetter@ffwll.ch
-
Christian König authored
The attachment list is now protected by the dma_resv object. Stop holding the dma_buf->lock while calling ->attach/->detach, this allows for concurrent attach/detach operations. v2: cleanup commit message and locking in _debug_show() Signed-off-by:
-
Christian König authored
This patch is a stripped down version of the locking changes necessary to support dynamic DMA-buf handling. It adds a dynamic flag for both importers as well as exporters so that drivers can choose if they want the reservation object locked or unlocked during mapping of attachments. For compatibility between drivers we cache the DMA-buf mapping during attaching an importer as soon as exporter/importer disagree on the dynamic handling. Issues and solutions we considered: - We can't change all existing drivers, and existing improters have strong opinions about which locks they're holding while calling dma_buf_attachment_map/unmap. Exporters also have strong opinions about which locks they can acquire in their ->map/unmap callbacks, levaing no room for change. The solution to avoid this was to move the actual map/unmap out from this call, into the attach/detach callbacks, and cache the mapping. This works because drivers don't call attach/detach from deep within their code callchains (like deep in memory management code called from cs/execbuf ioctl), but directly from the fd2handle implementation. - The caching has some troubles on some soc drivers, which set other modes than DMA_BIDIRECTIONAL. We can't have 2 incompatible mappings, and we can't re-create the mapping at _map time due to the above locking fun. We very carefuly step around that by only caching at attach time if the dynamic mode between importer/expoert mismatches. - There's been quite some discussion on dma-buf mappings which need active cache management, which would all break down when caching, plus we don't have explicit flush operations on the attachment side. The solution to this was to shrug and keep the current discrepancy between what the dma-buf docs claim and what implementations do, with the hope that the begin/end_cpu_access hooks are good enough and that all necessary flushing to keep device mappings consistent will be done there. v2: cleanup set_name merge, improve kerneldoc v3: update commit message, kerneldoc and cleanup _debug_show() Signed-off-by:
-
- 23 Oct, 2019 19 commits
-
-
Thierry Reding authored
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. After all other drivers have been converted not to use these helpers anymore, move these helpers into the last remaining user: Tegra DRM. If at some point these helpers are deemed more widely useful, they can be moved out into the DRM DP helpers again. Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Thierry Reding authored
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by:
-
Thierry Reding authored
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. Signed-off-by:
-
Thierry Reding authored
The DP specification uses the term "default framing" instead of "non- enhanced framing". Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Signed-off-by:
-
Thierry Reding authored
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v3: make link rate unsigned int to avoid overflow Signed-off-by:
-
Thierry Reding authored
During the discussion of patches that enhance the drm_dp_link helpers it was concluded that these helpers aren't very useful to begin with. Start pushing the equivalent code into individual drivers to ultimately remove them. v4: use bulk DPCD writes if possible (Daniel Vetter) Signed-off-by:
-
Thierry Reding authored
If the transmitter supports pre-emphasis post cursor2 the sink will request adjustments in a similar way to how it requests adjustments to the voltage swing and pre-emphasis settings. Add a helper to extract these adjustments on a per-lane basis from the DPCD link status. Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Thierry Reding authored
Use microsecond sleeps for the clock recovery and channel equalization delays during link training. The duration of these delays can be from 100 us up to 16 ms. It is rude to busy-loop for that amount of time. While at it, also convert to standard coding style by putting the opening braces in a function definition on a new line. Also switch to using an unsigned int for the AUX read interval to match the data type of the parameters to usleep_range(). v2: use correct multiplier for training delays (Philipp Zabel) v3: clarify data type change in commit message Signed-off-by:
-
Thierry Reding authored
Add a helper to check if the sink supports the eDP alternate scrambler reset value of 0xfffe. Reviewed-by:
-
Thierry Reding authored
Add a helper to check whether the sink supports ANSI 8B/10B channel coding capability as specified in ANSI X3.230-1994, clause 11. Reviewed-by:
-
Thierry Reding authored
Add a helper that checks for the fast training capability given the DPCD receiver capabilities blob. Reviewed-by:
-
Thierry Reding authored
It's idiomatic to check the return value of a function call immediately after the function call, without any blank lines in between, to make it more obvious that the two lines belong together. Reviewed-by:
-
Thierry Reding authored
Keeping the list sorted alphabetically makes it much easier to determine where to add new includes. Reviewed-by:
-
Sean Paul authored
Parroting Daniel's backmerge justification from 2e79e22e: Thierry needs fd70c775 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Signed-off-by:
Sean Paul <seanpaul@chromium.org>
-
Sean Paul authored
This reverts commit 23b48225. This patch does not have an acceptable open source userspace implementation, and as such it does not meet the requirements for adding new UAPI. Discussion is in the Link. Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html Fixes: 23b48225 ("drm/omap: add OMAP_BO flags to affect buffer allocation") Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Jean-Jacques Hiblot <jjhiblot@ti.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Acked-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Acked-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Daniel Vetter authored
Thierry needs fd70c775 ("drm/bridge: tc358767: fix max_tu_symbol value") to be able to merge his dp_link patch series. Some adjacent changes conflicts, plus some clashes in i915 due to cherry-picking and git trying to be helpful and leaving both versions in. Signed-off-by:
-
Daniel Vetter authored
Should help new people pick suitable tasks. Cc: Rodrigo Siqueira <rodrigosiqueiramelo@gmail.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Sean Paul <sean@poorly.run> Reviewed-by:
Sean Paul <sean@poorly.run> Acked-by:
-
Daniel Vetter authored
Done with commit aef9f33b Author: Imre Deak <imre.deak@intel.com> Date: Tue Oct 23 17:43:10 2018 +0300 drm/i915: Ensure proper HDA suspend/resume ordering with a device link Cc: Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Daniel Vetter authored
This is not something we'll fix, because failing to clean up stuff (or doing it in the wrong order) is a driver bug. The offending FIXME goes all the way back to the original modeset merge. We've added a WARN_ON in commit 2b677e8c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 10 21:16:05 2012 +0100 drm: reference framebuffers which are on the idr including a comment blaming drivers on this. Right thing to do is most likely drm_atomic_helper_shutdown plus making sure that drm_mode_config_cleanup is not called too early (i.e. not in driver unload, but only in the final drm_device release callback). Cc: Mihail Atanassov <Mihail.Atanassov@arm.com> Reported-by:
Mihail Atanassov <Mihail.Atanassov@arm.com> Reviewed-by:
-
- 22 Oct, 2019 4 commits
-
-
Ville Syrjälä authored
Use the new drm_hdmi_avi_infoframe_bars() helper instead of hand rolling it. Cc: Eric Anholt <eric@anholt.net> Cc: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191008164814.5894-2-ville.syrjala@linux.intel.comReviewed-by:
Boris Brezillon <boris.brezillon@collabora.com>
-
Ville Syrjälä authored
Add a function to fill the AVI infoframe bar information from the standard tv margin properties. Cc: Eric Anholt <eric@anholt.net> Cc: Boris Brezillon <boris.brezillon@bootlin.com> Signed-off-by:
-
Mihail Atanassov authored
I'll be the main point of contact. Cc: James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Cc: Liviu Dudau <liviu.dudau@arm.com> Acked-by:
James Qian Wang (Arm Technology China) <james.qian.wang@arm.com> Signed-off-by:
-
Andy Shevchenko authored
GCC complains about dubious bitwise OR operand: drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y CC [M] drivers/gpu/drm/drm_mipi_dbi.o As long as buffer is consist of byte (u8) values, we may use simple right shift and satisfy compiler. It also reduces amount of operations needed. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Tested-by:
-
