- 07 Apr, 2022 26 commits
-
-
Daniel Vetter authored
Half of it is protected by console_lock, but the other half is a lot more awkward: Registration/deregistration of fbdev are serialized, but we don't really clear out anything in con2fb_map and so there's potential for use-after free mixups. First step is to encapsulate the lookup. Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Cc: Helge Deller <deller@gmx.de> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Du Cheng <ducheng2@gmail.com> Cc: Claudio Suarez <cssk@net-c.es> Cc: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220405210335.3434130-4-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Avoids two forward declarations, and more importantly, matches what I've done in my fbcon scrolling restore patches - so I need this to avoid a bunch of conflicts in rebasing since we ended up merging Helge's series instead. Acked-by:
Javier Martinez Canillas <javierm@redhat.com> Signed-off-by:
-
Daniel Vetter authored
I didn't bother with any code movement to fix the others, these just got a bit in the way. v2: Rebase on top of Helge's reverts. Acked-by:
-
Javier Martinez Canillas authored
The commit 73511edf ("dma-buf: specify usage while adding fences to dma_resv obj v7") ported all the DRM drivers to use the newer fence API that specifies the usage with the enum dma_resv_usage rather than doing an explicit shared / exclusive distinction. But the commit didn't do it properly in two callers of the vc4 driver, leading to build errors. Fixes: 73511edf ("dma-buf: specify usage while adding fences to dma_resv obj v7") Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220407131950.915091-1-javierm@redhat.com
-
Chen-Yu Tsai authored
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add support for this display driver. The default values for some of the hardware settings are taken from the datasheet. Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Acked-by:
-
Chen-Yu Tsai authored
On the SINO WEALTH SH1106, which is mostly compatible with the SSD1306, only the basic page addressing mode is supported. This addressing mode is not as easy to use compared to the currently supported horizontal addressing mode, as the page address has to be set prior to writing out each page, and each page must be written out separately as a result. Also, there is no way to force the column address to wrap around early, thus the column address must also be reset for each page to be accurate. Add support for this addressing mode, with a flag to choose it. This flag is designed to be set from the device info data structure, but can be extended to be explicitly forced on through a device tree property if such a need arises. Signed-off-by:
-
Chen-Yu Tsai authored
The SINO WEALTH SH1106 is an OLED display driver that is somewhat compatible with the SSD1306. It supports a slightly wider display, at 132 instead of 128 pixels. The basic commands are the same, but the SH1106 doesn't support the horizontal or vertical address modes. Add a compatible string for it. Signed-off-by:
-
Chen-Yu Tsai authored
Add a vendor prefix entry for SINO WEALTH Eletronics Ltd. (http://www.sinowealth.com). Signed-off-by:
-
Christian König authored
This isn't included here any more since the removal of ww_mutex.h from seqlock.h which causes a build break. Signed-off-by:
Shashank Sharma <shashank.sharma@amd.com> Fixes: e84815cb ("seqlock: drop seqcount_ww_mutex_t") Link: https://patchwork.freedesktop.org/patch/msgid/20220407114619.961750-1-christian.koenig@amd.com
-
Christian König authored
Daniel pointed out that this series removes the last user of seqcount_ww_mutex_t, so let's drop this. Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-16-christian.koenig@amd.com
-
Christian König authored
This should be possible now since we don't have the distinction between exclusive and shared fences any more. The only possible pitfall is that a dma_fence would be reused during the RCU grace period, but even that could be handled with a single extra check. Signed-off-by:
-
Christian König authored
This is now handled by the DMA-buf framework in the dma_resv obj. Also remove the workaround inside VMWGFX to update the moving fence. Signed-off-by:
-
Christian König authored
That should now be handled by the common dma_resv framework. Signed-off-by:
-
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:
-
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:
-
