- 07 Apr, 2022 14 commits
-
-
Christian König authored
That should now be handled by the common dma_resv framework. Signed-off-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: intel-gfx@lists.freedesktop.org Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-13-christian.koenig@amd.com
-
Christian König authored
We have previously done that in the individual drivers but it is more defensive to move that into the common code. Dynamic attachments should wait for map operations to complete by themselves. Signed-off-by:
-
Christian König authored
Add an usage for submissions independent of implicit sync but still interesting for memory management. v2: cleanup the kerneldoc a bit v3: separate amdgpu changes from this Signed-off-by:
-
Christian König authored
We only need to wait for kernel submissions here. Signed-off-by:
-
Christian König authored
Always wait for kernel fences before kmap and not only for UVD kmaps. Signed-off-by:
-
Christian König authored
Wait only for kernel fences before kmap or UVD direct submission. This also makes sure that we always wait in amdgpu_bo_kmap() even when returning a cached pointer. Signed-off-by:
-
Christian König authored
Add an usage for kernel submissions. Waiting for those are mandatory for dynamic DMA-bufs. As a precaution this patch also changes all occurrences where fences are added as part of memory management in TTM, VMWGFX and i915 to use the new value because it now becomes possible for drivers to ignore fences with the WRITE usage. v2: use "must" in documentation, fix whitespaces v3: separate out some driver changes and better document why some changes should still be part of this patch. Signed-off-by: -
Christian König authored
Rework the internals of the dma_resv object to allow adding more than one write fence and remember for each fence what purpose it had. This allows removing the workaround from amdgpu which used a container for this instead. Signed-off-by:
-
Christian König authored
Instead of distingting between shared and exclusive fences specify the fence usage while adding fences. Rework all drivers to use this interface instead and deprecate the old one. v2: some kerneldoc comments suggested by Daniel v3: fix a missing case in radeon v4: rebase on nouveau changes, fix lockdep and temporary disable warning v5: more documentation updates v6: separate internal dma_resv changes from this patch, avoids to disable warning temporary, rebase on upstream changes v7: fix missed case in lima driver, minimize changes to i915_gem_busy_ioctl Signed-off-by: -
Christian König authored
This change adds the dma_resv_usage enum and allows us to specify why a dma_resv object is queried for its containing fences. Additional to that a dma_resv_usage_rw() helper function is added to aid retrieving the fences for a read or write userspace submission. This is then deployed to the different query functions of the dma_resv object and all of their users. When the write paratermer was previously true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. v2: add KERNEL/OTHER in separate patch v3: some kerneldoc suggestions by Daniel v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in the rebase pointed out by Bas. Signed-off-by: -
Julia Lawall authored
Various spelling mistakes in comments. Detected with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@inria.fr> Reviewed-by:
Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220314115354.144023-17-Julia.Lawall@inria.fr
-
Colin Ian King authored
In other places of the driver the string hdmi_rejection_pll is used instead of the truncated hdmi_rejec_pll, so use this string instead to be consistent. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Randy Dunlap authored
Don't mark static functions as kernel-doc. Prevents multiple kernel-doc build warnings: drivers/gpu/drm/sti/sti_hdmi.c:187: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * HDMI interrupt handler threaded drivers/gpu/drm/sti/sti_hdmi.c:219: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * HDMI interrupt handler drivers/gpu/drm/sti/sti_hdmi.c:241: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Set hdmi active area depending on the drm display mode selected drivers/gpu/drm/sti/sti_hdmi.c:262: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Overall hdmi configuration drivers/gpu/drm/sti/sti_hdmi.c:340: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Helper to concatenate infoframe in 32 bits word drivers/gpu/drm/sti/sti_hdmi.c:357: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Helper to write info frame drivers/gpu/drm/sti/sti_hdmi.c:427: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Prepare and configure the AVI infoframe drivers/gpu/drm/sti/sti_hdmi.c:470: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Prepare and configure the AUDIO infoframe drivers/gpu/drm/sti/sti_hdmi.c:555: warning: This comment starts with '/**', but isn't a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst * Software reset of the hdmi subsystem Fixes: 5402626c ("drm: sti: add HDMI driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Aditya Srivastava <yashsri421@gmail.com> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Alain Volmat <alain.volmat@foss.st.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Acked-by:
-
Xiaomeng Tong authored
The two bugs are here: if (encoder) { if (bridge && bridge->timings) The list iterator value 'encoder/bridge' will *always* be set and non-NULL by drm_for_each_encoder()/list_for_each_entry(), so it is incorrect to assume that the iterator value will be NULL if the list is empty or no element is found. To fix the bug, use a new variable '*_iter' as the list iterator, while use the old variable 'encoder/bridge' as a dedicated pointer to point to the found element. Cc: stable@vger.kernel.org Fixes: 99e36044 ("drm/stm: Fix bus_flags handling") Signed-off-by:Xiaomeng Tong <xiam0nd.tong@gmail.com> Acked-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by:
-
- 06 Apr, 2022 14 commits
-
-
Christian König authored
Audit all the users of dma_resv_add_excl_fence() and make sure they reserve a shared slot also when only trying to add an exclusive fence. This is the next step towards handling the exclusive fence like a shared one. v2: fix missed case in amdgpu v3: and two more radeon, rename function v4: add one more case to TTM, fix i915 after rebase Signed-off-by:
-
Sui Jingfeng authored
change upate to update Signed-off-by:
Sui Jingfeng <15330273260@189.cn> Signed-off-by:
-
Maxime Ripard authored
Those macros are really about the HVS itself, and thus its associated structure vc4_hvs, rather than the entire (virtual) vc4 device. Let's change those macros to use the hvs pointer directly, and change the calling sites accordingly. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20220331143744.777652-8-maxime@cerno.tech
-
Maxime Ripard authored
atomic_flush will be called for each CRTC even if they aren't enabled. The whole code we have there will thus run without a properly affected channel, which can then result in all sorts of weird behaviour. Fortunately, the DRM_PLANE_COMMIT_ACTIVE_ONLY flag will skip the CRTC atomic_begin and atomic_flush, and the planes atomic_update, if they aren't enabled. Our plane atomic_update is a nop, and atomic_begin will copy the current HVS channel to the vc4_crtc structure for the interrupt handler to consume, but the handler won't run if the CRTC is disabled. So in the end, it will only skip our CRTC atomic_flush, which is what we want. Signed-off-by:
-
Maxime Ripard authored
The vc4_hvs_update_dlist function mostly deals with setting up the vblank events and setting up the dlist entry pointer to our current active one. We'll want to do the former separately from the vblank handling in later patches, so let's move it to a function of its own. Signed-off-by:
-
Maxime Ripard authored
Setting the DISPLISTx register needs to occur in every case, and we don't need to protect the register using the event_lock, so we can just move it after the if branches and simplify a bit the function. Signed-off-by:
-
Maxime Ripard authored
The assigned_channel field of our vc4_crtc_state structure is accessed multiple times in vc4_hvs_atomic_flush, so let's move it to a variable that can be used in all those places. Signed-off-by:
-
Maxime Ripard authored
In order to get the field currently being output, the driver has been using the display FIFO frame count in the HVS, reading a 6-bit field at the offset 12 in the DISPSTATx register. While that field is indeed at that location for the FIFO 1 and 2, the one for the FIFO0 is actually in the DISPSTAT1 register, at the offset 18. Fixes: e538092c ("drm/vc4: Enable precise vblank timestamping for interlaced modes.") Signed-off-by:
-
Maxime Ripard authored
During a commit, the core clock, which feeds the HVS, needs to run at a minimum of 500MHz. While doing that commit, we can also change the mode to one that requires a higher core clock, so we take the core clock rate associated to that new state into account for that boost. However, the old state also needs to be taken into account if it requires a core clock higher that the new one and our 500MHz limit, since it's still live in hardware at the beginning of our commit. Fixes: 16e10105 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by:
-
Maxime Ripard authored
Now that the clock driver makes sure we never end up with a rate of 0, the HDMI driver doesn't need to care anymore. Signed-off-by:
-
Maxime Ripard authored
The HVS core clock isn't really obvious, so let's add a bunch more comments and some logging for easier debugging. Signed-off-by:
-
Marek Vasut authored
The module owner = THIS_MODULE is set by I2C core, drop duplicate assignment. Fixes: 8dde6f74 ("drm: bridge: icn6211: Add I2C configuration support") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220401113317.7033-1-marex@denx.de
-
Xiaomeng Tong authored
Instead of exiting the loop as expected when an entry is found, the list_for_each_entry() continues until the traversal is complete. when found the entry, add a break after the switch statement. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220401115018.9335-1-xiam0nd.tong@gmail.com
-
Marek Vasut authored
Fix copy-paste error, module exit function should be marked with __exit instead of __init. Fixes: 8dde6f74 ("drm: bridge: icn6211: Add I2C configuration support") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220406014250.902187-1-marex@denx.deReviewed-by:
-
- 05 Apr, 2022 8 commits
-
-
Marek Vasut authored
The datasheet for this bridge is not available, the PLL behavior has been inferred from [1] and [2] and by analyzing the DPI pixel clock with scope. After further testing with other displays and different DSI data lane count, it turns out the P-factor is not 1/2^N divider, but rather only 1/N divider. It also turns out the input into the PLL seem to be ByteClock instead of DSI HS clock. Rework the P-factor calculation such that the PLL calculation code handles P-factor from 1..32 with P-factors above 16 must be even. In case P-factor is even, enable built-in 1:2 divider and program P-factor/2 to PLL_REF_DIV, otherwise configure only the P-factor into PLL_REF_DIV register. Switch the PLL factor calculation from kHz to Hz to maintain precision. [1] https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/gpu/drm/bridge/icn6211.c [2] https://github.com/tdjastrzebski/ICN6211-Configurator Fixes: f30cf0ec ("drm: bridge: icn6211: Add generic DSI-to-DPI PLL configuration") Signed-off-by:
-
Christophe Branchereau authored
Following the introduction of bridge_atomic_enable in the ingenic drm driver, the crtc is enabled between .prepare and .enable, if it exists. Add it so the backlight is only enabled after the crtc is, to avoid graphical issues. As we're moving the "sleep out" command out of the init sequence into .enable for the ABT, we need to switch the regmap cache to REGCACHE_FLAT to be able to use regmap_set_bits, given this panel registers are write-ony and read as 0. Signed-off-by:
Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> [pcercuei: Remove empty line after opening brace] Acked-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220321133651.291592-4-cbranchereau@gmail.com
-
Christophe Branchereau authored
This driver supports the NewVision NV3052C based LCDs. Right now, it only supports the LeadTek LTK035C5444T 2.4" 640x480 TFT LCD panel, which can be found in the Anbernic RG-350M handheld console. Signed-off-by:
-
Christophe Branchereau authored
ingenic_drm_bridge_atomic_enable allows the CRTC to be enabled after panels have slept out, and before their display is turned on, solving a graphical bug on the newvision nv3502c. Also add ingenic_drm_bridge_atomic_disable to balance it out. Signed-off-by:
Artur Rojek <contact@artur-rojek.eu> Link: https://patchwork.freedesktop.org/patch/msgid/20220321133651.291592-2-cbranchereau@gmail.com
-
Christian König authored
Use dma_resv_get_singleton() here to eventually get more than one write fence as single fence. Signed-off-by:
-
Maxime Ripard authored
Let's start the 5.19 development cycle. Signed-off-by: -
Christian König authored
Drivers should never touch this directly. v2: fix rebase clash Signed-off-by:
-
Christian König authored
Instead use the new dma_resv_get_singleton function. Signed-off-by:
-
- 04 Apr, 2022 4 commits
-
-
Xiaomeng Tong authored
The bug is here: if (nvkm_cstate_valid(clk, cstate, max_volt, clk->temp)) return cstate; The list iterator value 'cstate' will *always* be set and non-NULL by list_for_each_entry_from_reverse(), so it is incorrect to assume that the iterator value will be unchanged if the list is empty or no element is found (In fact, it will be a bogus pointer to an invalid structure object containing the HEAD). Also it missed a NULL check at callsite and may lead to invalid memory access after that. To fix this bug, just return 'encoder' when found, otherwise return NULL. And add the NULL check. Cc: stable@vger.kernel.org Fixes: 1f7f3d91 ("drm/nouveau/clk: Respect voltage limits in nvkm_cstate_prog") Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Randy Dunlap authored
It looks like the incorrect name of a function parameter was used in the kernel-doc notation, so just change it to the function's parameter name to quell the kernel-doc warning. drivers/gpu/drm/drm_format_helper.c:640: warning: Function parameter or member 'vaddr' not described in 'drm_fb_xrgb8888_to_mono_reversed' drivers/gpu/drm/drm_format_helper.c:640: warning: Excess function parameter 'src' description in 'drm_fb_xrgb8888_to_mono_reversed' Fixes: bcf8b616 ("drm/format-helper: Add drm_fb_xrgb8888_to_mono_reversed()") Signed-off-by:
Simon Ser <contact@emersion.fr> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Randy Dunlap authored
Fix a build warning from 'make htmldocs' by correcting the lock name in the kernel-doc comment. include/drm/drm_file.h:369: warning: Function parameter or member 'master_lookup_lock' not described in 'drm_file' Signed-off-by:
-
Daniel Vetter authored
You really need to hold the reservation here or all kinds of funny things can happen between grabbing the dependencies and inserting the new fences. v2: Fix commit summary (Christian) Acked-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Luben Tuikov <luben.tuikov@amd.com> Cc: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220331204651.2699107-4-daniel.vetter@ffwll.ch
-
