- 15 Feb, 2021 4 commits
-
-
Marek Vasut authored
The drm_display_mode_to_videomode() does not populate DISPLAY_FLAGS_DE_LOW or DISPLAY_FLAGS_PIXDATA_NEGEDGE flags in struct videomode. Therefore, no matter what polarity the next bridge or display might require, these flags are never set, and thus the LTDC GCR_DEPOL and GCR_PCPOL bits are never set and the LTDC behaves as if both DISPLAY_FLAGS_PIXDATA_POSEDGE and DISPLAY_FLAGS_DE_HIGH were always set. The fix for this problem is taken almost verbatim from MXSFB driver. In case there is a bridge attached to the LTDC, the bridge might have extra polarity requirements, so extract bus_flags from the bridge and use them for LTDC configuration. Otherwise, extract bus_flags from the connector, which is the display. Fixes: b759012c ("drm/stm: Add STM32 LTDC driver") Signed-off-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Yannick Fertre <yannick.fertre@st.com> Cc: Alexandre Torgue <alexandre.torgue@st.com> Cc: Antonio Borneo <antonio.borneo@st.com> Cc: Benjamin Gaignard <benjamin.gaignard@st.com> Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com> Cc: Philippe Cornu <philippe.cornu@st.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Vincent Abriou <vincent.abriou@st.com> Cc: Yannick Fertre <yannick.fertre@st.com> Cc: linux-arm-kernel@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com To: dri-devel@lists.freedesktop.org Tested-by:
Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127110756.125570-1-marex@denx.de
-
Boris Brezillon authored
Doing a hw-irq -> threaded-irq round-trip is counter-productive, stay in the threaded irq handler as long as we can. v2: * Rework the loop to avoid a goto Signed-off-by:
Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210205111757.585248-4-boris.brezillon@collabora.com
-
Boris Brezillon authored
We allocate 2MB chunks at a time, so it might appear that a page fault has already been handled by a previous page fault when we reach panfrost_mmu_map_fault_addr(). Bail out in that case to avoid mapping the same area twice. Cc: <stable@vger.kernel.org> Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by:
-
Boris Brezillon authored
When a fault is handled it will unblock the GPU which will continue executing its shader and might fault almost immediately on a different page. If we clear interrupts after handling the fault we might miss new faults, so clear them before. Cc: <stable@vger.kernel.org> Fixes: 187d2929 ("drm/panfrost: Add support for GPU heap allocations") Signed-off-by:
-
- 12 Feb, 2021 1 commit
-
-
Christian König authored
Swapping bo->mem was completely unecessary. Cleanup the function which is just a leftover from a TTM cleanup. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Tested-by:
-
- 10 Feb, 2021 9 commits
-
-
Zack Rusin authored
There's no need to check for the presence of the hotplug property just to return because this is the end of the function so we're returning either way. Signed-off-by:
Zack Rusin <zackr@vmware.com> Reviewed-by:
Martin Krastev <krastevm@vmware.com> Reviewed-by:
Roland Scheidegger <sroland@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209161700.335611-2-zackr@vmware.com
-
Zack Rusin authored
Our sysfs "modes" entries were broken because our preffered mode never had its name set correctly. This resulted in the first entry simply being called "preferred" followed by a list of other resolutions. Lets fix it by actually setting the name of mode (which is its resolution). This allows one to quickly validate the modes set by the open-vm-tools. Signed-off-by:
-
Roland Scheidegger authored
The default list was old and in particular lacking all common 16:9 resolutions, as well as some newer 16:10 ones. This makes them selectable in resolution change lists, which can be quite useful (for instance in case auto-fit isn't enabled). Signed-off-by:
-
Julia Lawall authored
Use getter and setter functions, for platform_device structures and a mipi_dsi_device structure. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210209211304.1261740-1-Julia.Lawall@inria.fr
-
Daniel Vetter authored
I got real badly confused when trying to review a fix from Ville for this. Let's try to document better what's required for this, and check the minimal settings at runtime - we can't check ofc that there's indeed no races in the driver callback. Also noticed that the drm_vblank_restore version is unused, so lets unexport that while at it. Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210209101523.2954281-1-daniel.vetter@ffwll.ch
-
Roman Stratiienko authored
DE3.0 VI layers supports plane-global alpha channel. DE2.0 FCC block have GLOBAL_ALPHA register that can be used as alpha source for blender. Add alpha property to the DRM plane and connect it to the corresponding registers in the mixer. Do not add alpha property for V3s SOC that have DE2.0 and 2 VI planes. Signed-off-by:
Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by:
Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210128113940.347013-3-r.stratiienko@gmail.com
-
Roman Stratiienko authored
DE2.0 and DE3.0 UI layers supports plane-global alpha channel. Add alpha property to the DRM plane and connect it to the corresponding registers in mixer. Signed-off-by:
-
Joel Stanley authored
There are minor differences in the values for the threshold value and the scan line size between families of ASPEED SoC. Additionally the SCU registers for the output control and scratch registers differ between families. This adds device tree matching to parameterise these values, allowing us to add support for the AST2400 now, and in the future the AST2600. Reviewed-by:
Jeremy Kerr <jk@ozlabs.org> Signed-off-by:
Joel Stanley <joel@jms.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20210209123734.130483-3-joel@jms.id.au
-
Joel Stanley authored
This scales better to multiple families of SoC. The lookup by compatible can be removed in a future change. The fallback path is for the ast2500 platform only. Other platforms will be added with the new style, so they won't need fallback paths. Signed-off-by:
Andrew Jeffery <andrew@aj.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20210209123734.130483-2-joel@jms.id.au
-
- 09 Feb, 2021 15 commits
-
-
Quanyang Wang authored
When run xrandr to change resolution on Beaglebone Black board, it will print the error information: root@beaglebone:~# xrandr -display :0 --output HDMI-1 --mode 720x400 [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:32:tilcdc crtc] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CONNECTOR:34:HDMI-A-1] commit wait timed out [drm:drm_crtc_commit_wait] *ERROR* flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [PLANE:31:plane-0] commit wait timed out tilcdc 4830e000.lcdc: already pending page flip! This is because there is operation sequence as below: drm_atomic_connector_commit_dpms(mode is DRM_MODE_DPMS_OFF): ... drm_atomic_helper_setup_commit <- init_completion(commit_A->flip_done) drm_atomic_helper_commit_tail tilcdc_crtc_atomic_disable tilcdc_plane_atomic_update <- drm_crtc_send_vblank_event in tilcdc_crtc_irq is skipped since tilcdc_crtc->enabled is 0 tilcdc_crtc_atomic_flush <- drm_crtc_send_vblank_event is skipped since crtc->state->event is set to be NULL in tilcdc_plane_atomic_update drm_mode_setcrtc: ... drm_atomic_helper_setup_commit <- init_completion(commit_B->flip_done) drm_atomic_helper_wait_for_dependencies drm_crtc_commit_wait <- wait for commit_A->flip_done completing Just as shown above, the steps which could complete commit_A->flip_done are all skipped and commit_A->flip_done will never be completed. This will result a time-out ERROR when drm_crtc_commit_wait check the commit_A->flip_done. So add drm_crtc_send_vblank_event in tilcdc_crtc_atomic_disable to complete commit_A->flip_done. Fixes: cb345dec ("drm/tilcdc: Use standard drm_atomic_helper_commit") Signed-off-by:Quanyang Wang <quanyang.wang@windriver.com> Reviewed-by:
Jyri Sarha <jyri.sarha@iki.fi> Tested-by:
-
Christian König authored
Not used any more. Signed-off-by:
-
Christian König authored
This is just another feature which is only used by VMWGFX, so move it into the driver instead. I've tried to add the accounting sysfs file to the kobject of the drm minor, but I'm not 100% sure if this works as expected. v2: fix typo in KFD and avoid 64bit divide v3: fix init order in VMWGFX v4: use pdev sysfs reference instead of drm Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210208133226.36955-2-christian.koenig@amd.com
-
Christian König authored
TTM implements a rather extensive accounting of allocated memory. There are two reasons for this: 1. It tries to block userspace allocating a huge number of very small BOs without accounting for the kmalloced memory. 2. Make sure we don't over allocate and run into an OOM situation during swapout while trying to handle the memory shortage. This is only partially a good idea. First of all it is perfectly valid for an application to use all of system memory, limiting it to 50% is not really acceptable. What we need to take care of is that the application is held accountable for the memory it allocated. This is what control mechanisms like memcg and the normal Linux page accounting already do. Making sure that we don't run into an OOM situation while trying to cope with a memory shortage is still a good idea, but this is also not very well implemented since it means another opportunity of recursion from the driver back into TTM. So start to rework all of this by implementing a shrinker callback which allows for TT object to be swapped out if necessary. v2: Switch from limit to shrinker callback. v3: fix gfp mask handling, use atomic for swapable_pages, add debugfs v4: drop the extra gfp_mask checks Signed-off-by:
-
Christian König authored
Only a zombie leftover from rebasing. Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com> Reviewed-by:
-
Thomas Zimmermann authored
Functions in the atomic commit tail are not allowed to acquire the dmabuf's reservation lock. So we cannot legally call the GEM object's vmap functionality in atomic_update. Instead use struct drm_shadow_plane_state and friends. It vmaps the framebuffer BOs in prepare_fb and vunmaps them in cleanup_fb. The cursor plane state stores the mapping's address. The pinning of the BO is implicitly done by vmap. As an extra benefit, there's no source of runtime errors left in atomic_update. v2: * rebase patch onto struct drm_shadow_plane_state Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Tested-by:
-
Thomas Zimmermann authored
Export the helpers for shadow-buffered planes. These will be used by several drivers. v3: * fix documentation typos and formatting (Daniel) Signed-off-by:
-
Patrik Jakobsson authored
Blits cannot happen anymore since we removed the 2d accel code. Stop checking for a busy blitter and remove the remaining blitter code. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by:
-
Patrik Jakobsson authored
Since everything else in accel_2d.c got removed we can move psb_spank() into psb_drv.c where it is used. Signed-off-by:
-
Patrik Jakobsson authored
CDV crtc helpers are identical to other chips so use gma_ prefix for the crtc helper struct and remove the CDV copy. Signed-off-by:
-
Patrik Jakobsson authored
Afaik tv out is not available on Cedarview and the code isn't doing anything so remove it. Signed-off-by:
-
Patrik Jakobsson authored
DPST never got enabled so remove it. We keep the reg save/restore code just for safety. Signed-off-by:
-
Patrik Jakobsson authored
Clearly never been used so just remove it. Signed-off-by:
-
Thomas Zimmermann authored
With support for the MID-only Medfield chips removed, simply build the complete driver if DRM_GMA500 has been selected. Anyone who wants to enable one of the chips would probably also want the rest. Signed-off-by:
-
Sebastian Andrzej Siewior authored
The driver is using msleep() if it is safe to use based on in_atomic(). This is not needed this macro is only used from i2c_algorithm::master_xfer() which is always invoked from preemptible context. Remove in_atomic() because it is superfluous. Remove wait_for_atomic() because it has no users. Signed-off-by:
Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by:
-
- 08 Feb, 2021 7 commits
-
-
Thomas Zimmermann authored
Vmap operations may acquire the dmabuf reservation lock, which is not allowed within atomic commit-tail functions. Therefore move vmap and vunmap from the damage handler into prepare_fb and cleanup_fb callbacks. The mapping is provided as GEM shadow-buffered plane. The functions in the commit tail use the pre-established mapping for damage handling. Signed-off-by:
-
Thomas Zimmermann authored
Vmap operations may acquire the dmabuf reservation lock, which is not allowed within atomic commit-tail functions. Therefore move vmap and vunmap from the damage handler into prepare_fb and cleanup_fb callbacks. The mapping is provided as GEM shadow-buffered plane. The functions in the commit tail use the pre-established mapping for damage handling. Signed-off-by:
-
Thomas Zimmermann authored
Vmap operations may acquire the dmabuf reservation lock, which is not allowed within atomic commit-tail functions. Therefore move vmap and vunmap from the damage handler into prepare_fb and cleanup_fb callbacks. The mapping is provided as GEM shadow-buffered plane. The functions in the commit tail use the pre-established mapping for damage handling. Signed-off-by:
-
Thomas Zimmermann authored
Vmap operations may acquire the dmabuf reservation lock, which is not allowed within atomic commit-tail functions. Therefore move vmap and vunmap from the damage handler into prepare_fb and cleanup_fb callbacks. The mapping is provided as GEM shadow-buffered plane. The functions in the commit tail use the pre-established mapping for damage handling. Signed-off-by:
-
Thomas Zimmermann authored
Several drivers use GEM buffer objects as shadow buffers for the actual framebuffer memory. Right now, drivers do these vmap operations in their commit tail, which is actually not allowed by the locking rules for the dma-buf reservation lock. The involved BO has to be vmapped in the plane's prepare_fb callback and vunmapped in cleanup_fb. This patch introduces atomic helpers for such shadow planes. Plane functions manage the plane state for shadow planes. The provided implementations for prepare_fb and cleanup_fb vmap and vunmap all BOs of struct drm_plane_state.fb. The mappings are afterwards available in the plane's commit-tail functions. For now, all rsp drivers use the simple KMS helpers, so we add the plane callbacks and wrappers for simple KMS. The internal plane functions can later be exported as needed. v3: * documentation fixes v2: * make duplicate_state interface compatible with struct drm_plane_funcs Signed-off-by:
-
Thomas Zimmermann authored
The symbols will be required by the upcoming helpers for shadow-buffered planes. Signed-off-by:
kernel test robot <lkp@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210208115538.6430-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Just like regular plane-state helpers, drivers can use these new callbacks to create and destroy private plane state. v2: * make duplicate_state interface compatible with struct drm_plane_funcs Signed-off-by:
-
- 07 Feb, 2021 2 commits
-
-
Christian Hewitt authored
This patch adapts the panfrost pre-defined thresholds change [0] to the lima driver to improve real-world performance. The upthreshold value has been set to ramp GPU frequency to max freq faster (compared to panfrost) to compensate for the lower overall performance of utgard devices. [0] https://patchwork.kernel.org/project/dri-devel/patch/20210121170445.19761-1-lukasz.luba@arm.com/Signed-off-by:
Christian Hewitt <christianshewitt@gmail.com> Reviewed-by:
Lukasz Luba <lukasz.luba@arm.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210127194047.21462-1-christianshewitt@gmail.com
-
Lukasz Luba authored
Devfreq framework supports 2 modes for monitoring devices. Use delayed timer as default instead of deferrable timer in order to monitor the GPU status regardless of CPU idle. Signed-off-by:
-
- 05 Feb, 2021 2 commits
-
-
Colin Ian King authored
Don't populate the const array m_div_val on the stack but instead make it static. Makes the object code smaller by 29 bytes: Before: text data bss dec hex filename 34736 4552 0 39288 9978 drivers/gpu/drm/mgag200/mgag200_mode.o After: text data bss dec hex filename 34625 4616 0 39241 9949 drivers/gpu/drm/mgag200/mgag200_mode.o (gcc version 10.2.0) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Christian König authored
Allow multiple schedulers to share the load balancing score. This is useful when one engine has different hw rings. Signed-off-by:
Leo Liu <leo.liu@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210204144405.2737-1-christian.koenig@amd.com
-
