- 23 Jun, 2021 19 commits
-
-
Andrey Grodzovsky authored
With added CPU domain to placement you can have now 3 placemnts at once. CC: stable@kernel.org Signed-off-by:
Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-5-andrey.grodzovsky@amd.com
-
Lang Yu authored
Change mgr->available into mgr->used (invert the value). Makes more sense to do it this way since we don't need the spinlock any more to double check the handling. v3 (chk): separated from the TEMPOARAY FLAG change. Signed-off-by:
Lang Yu <Lang.Yu@amd.com> Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-4-andrey.grodzovsky@amd.com
-
Christian König authored
When we run out of GTT we should still be able to evict VRAM->SYSTEM with a bounce bufferdrm/amdgpu: always allow evicting to SYSTEM domain Signed-off-by:
-
Lang Yu authored
Currently, we have a limitted GTT memory size and need a bounce buffer when doing buffer migration between VRAM and SYSTEM domain. The problem is under GTT memory pressure we can't do buffer migration between VRAM and SYSTEM domain. But in some cases we really need that. Eespecially when validating a VRAM backing store BO which resides in SYSTEM domain. v2: still account temporary GTT allocations v3 (chk): revert to the simpler change for now Signed-off-by:
-
Lang Yu authored
Sometimes drivers need to use bounce buffers to evict BOs. While those reside in some domain they are not necessarily suitable for CS. Add a flag so that drivers can note that a bounce buffers needs to be reallocated during validation. v2: add detailed comments v3 (chk): merge commits and rework commit message Suggested-by:
-
Andrey Grodzovsky authored
Problem: Under memory pressure when GTT domain is almost full multihop assert will come up when trying to evict LRU BO from VRAM to SYSTEM. Fix: Don't assert on multihop error in evict code but rather do a retry as we do in ttm_bo_move_buffer Signed-off-by:
-
Maxime Ripard authored
The hdmi-codec brings a lot of advanced features, including the HDMI channel mapping. Let's use it in our driver instead of our own codec. Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Reviewed-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210525132354.297468-11-maxime@cerno.tech
-
Dom Cobley authored
This was a workaround for bugs in hardware on earlier Pi models and wasn't totally successful. It makes audio quality worse on a Pi4 at the higher sample rates Signed-off-by:
Dom Cobley <popcornmix@gmail.com> Signed-off-by:
-
Dom Cobley authored
Without this bit set, HDMI_MAI_FORMAT doesn't pick up the format and samplerate from DVP_CFG_MAI0_FMT and you can't get HDMI_HDMI_13_AUDIO_STATUS_1 to indicate HBR mode Signed-off-by:
-
Dom Cobley authored
The hardware uses this for generating the right audio data island packets when using formats other than PCM Signed-off-by:
-
Dom Cobley authored
Symptom is random switching of speakers when using multichannel. Repeatedly running speakertest -c8 occasionally starts with channels jumbled. This is fixed with HD_CTL_WHOLSMP. The other bit looks beneficial and apears harmless in testing so I'd suggest adding it too. Documentation says: HD_CTL_WHILSMP_SET Wait for whole sample. When this bit is set MAI transmit will start only when there is at least one whole sample available in the fifo. Documentation says: HD_CTL_CHALIGN_SET Channel Align When Overflow. This bit is used to realign the audio channels in case of an overflow. If this bit is set, after the detection of an overflow, equal amount of dummy words to the missing words will be written to fifo, filling up the broken sample and maintaining alignment. Signed-off-by:
-
Maxime Ripard authored
Merge tag 'asoc-hdmi-codec-improvements-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux into drm-misc-next Improvements to the hdmi-codec driver and ALSA infrastructure around it to support the HDMI Channel Mapping and IEC958 controls Signed-off-by:
-
Maxime Ripard authored
The drm_connector detect, drm_dp_aux transfer and mipi_dsi_host operations typically require to access their underlying device to perform what is expected of them. However, there's no guarantee on the fact that the device has been enabled through atomic_enable or similar that will usually power the device. The access to an unpowered device is then an undefined behaviour ranging from the access being ignored to a hard CPU hang. Let's document that expectation to avoid as much as possible those consequences. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210616141529.630719-3-maxime@cerno.tech
-
Maxime Ripard authored
Drivers that allow concurrent access over multiple DP channels need to provide additional locking, even though the hw_mutex field might indicate otherwise. Clarify it in the documentation. Suggested-by:
-
Maxime Ripard authored
Split the existing documentation to move the comments on particular fields next to them. Suggested-by:
-
Vivek Kasireddy authored
If the framebuffer associated with the plane contains a fence, then it is added to resource_flush and will be waited upon for a max of 50 msecs or until it is signalled by the Host. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210610232456.671905-4-vivek.kasireddy@intel.comSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Vivek Kasireddy authored
A fence will be added to resource_flush for resources that are guest blobs. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Vivek Kasireddy authored
Add prepare and cleanup routines for primary planes as well where a fence is added only if the BO/FB associated with the plane is a guest blob. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
-
Dongwon Kim authored
Default list_limit and size_limit_mb are not big enough to cover all possible use cases. For example, list_limit could be well over its default, 1024 if only one or several pages are chained in all individual list entries when creating dmabuf backed by >4MB buffer. list_limit and size_limit_mb are now defined as module parameters so that those can be optionally configured by root with proper values to remove these constraints. Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210611212107.9876-1-dongwon.kim@intel.comSigned-off-by:
-
- 22 Jun, 2021 8 commits
-
-
Daniel Vetter authored
Christian and me realized we have a pretty massive disconnect about different interpretations of what dma_resv is used for by different drivers. The discussion is much, much bigger than this change here, but this is an important one: Non-dynamic exporters must guarantee that the memory they return is ready for use. They cannot expect importers to wait for the exclusive fence. Only dynamic importers are required to obey the dma_resv fences strictly (and more patches are needed to define exactly what this means). Christian has patches to update nouvea, radeon and amdgpu. The only other driver using both ttm and supporting dma-buf export is qxl, which only uses synchronous ttm_bo_move. v2: To hammer this in document that dynamic importers _must_ wait for the exclusive fence after having called dma_buf_map_attachment. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210621151758.2347474-1-daniel.vetter@ffwll.ch
-
Christian König authored
Drop the workaround and instead implement a better solution. Basically we are now chaining all submissions using a dma_fence_chain container and adding them as exclusive fence to the dma_resv object. This way other drivers can still sync to the single exclusive fence while amdgpu only sync to fences from different processes. v3: add the shared fence first before the exclusive one Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Acked-by:
-
Christian König authored
Unwrap the explicit fence if it is a dma_fence_chain and sync to the first fence not matching the owner rules. Signed-off-by:
-
Laurent Pinchart authored
Instead of storing a copy of the display mode in the sn65dsi83 structure, retrieve it from the atomic state in sn65dsi83_atomic_enable(). This allows the removal of the .mode_set() operation, and completes the transition to the atomic API. Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210621125518.13715-6-laurent.pinchart@ideasonboard.com
-
Laurent Pinchart authored
The driver currently iterates over all connectors to get the bus format, used to configure the LVDS output format. This causes several issues: - If other connectors than the LVDS output are present, the format used by the driver may end up belonging to an entirely different output. - The code can crash if some connectors are not connected, as bus_format may then be NULL. - There's no guarantee that the bus format on the connector at the output of the pipeline matches the output of the sn65dsi83, as there may be other bridges in the pipeline. Solve this by retrieving the format from the bridge state instead, which provides the format corresponding to the output of the bridge. The struct sn65dsi83 lvds_format_24bpp and lvds_format_jeida fields are moved to local variables in sn65dsi83_atomic_enable() as they're now used in that function only. Signed-off-by:
-
Laurent Pinchart authored
Use the atomic version of the enable/disable operations to continue the transition to the atomic API, started with the introduction of .atomic_get_input_bus_fmts(). This will be needed to access the mode from the atomic state. Signed-off-by:
-
Laurent Pinchart authored
Pass the display mode explicitly to the sn65dsi83_get_lvds_range() and sn65dsi83_get_dsi_range() functions to prepare for its removal from the sn65dsi83 structure. This is not meant to bring any functional change. Signed-off-by:
-
Laurent Pinchart authored
The LVDS format is selected based on the bus format reported by the connector. This is currently done in .mode_fixup(), but that's not the right place, as the format should be selected when setting the mode. Move it to .mode_set(). Signed-off-by:
-
- 21 Jun, 2021 4 commits
-
-
Stefan Riedmueller authored
Add corresponding bus_format and bus_flags for the EDT ETM0430G0DH6 display. Signed-off-by:
Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by:
-
Stefan Riedmueller authored
The connector_type for following two EDT displays is missing: - EDT ETM0430G0DH6 - EDT ETM0700G0BDH6 Both are parallel displays thus add the corresponding connector_type. Signed-off-by:
-
Stefan Riedmueller authored
The AUO G104SN02 V2 is an LVDS display which supports 6 and 8 bpc PSWG. Add the corresponding connector type and 8 bpc as default bus_format. Signed-off-by:
-
Marek Vasut authored
Patching the connector format is causing various problematic side effects. Implement .atomic_get_input_bus_fmts callback instead, which sets up the input (DSI-end) format, and that format can then be used in pipeline format negotiation between the DSI-end of this bridge and the other component closer to the scanout engine. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Adam Ford <aford173@gmail.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Valentin Raevsky <valentin@compulab.co.il> Cc: dri-devel@lists.freedesktop.org Reviewed-by:
-
- 18 Jun, 2021 3 commits
-
-
Colin Ian King authored
Currently a loop scans through the connector list checking for connectors that do not match a specific criteria. The use of the continue statement is a little unintuitive and can confuse static analysis checking. Invert the criteria matching logic and use a break to terminate the loop once the first suitable connector has been found. Thanks to Patrik Jakobsson for explaining the original intent of the code and suggesting this change. Addresses-Coverity: ("Continue has no effect") Signed-off-by:Colin Ian King <colin.king@canonical.com> Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210618183524.590186-1-colin.king@canonical.com
-
Dan Carpenter authored
There is a reversed if statement in amdgpu_preempt_mgr_new() so it always returns -ENOMEM. Fixes: 09b020bb ("Merge tag 'drm-misc-next-2021-06-09' of git://anongit.freedesktop.org/drm/drm-misc into drm-next") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Pi-Hsun Shih authored
There were still a race condition between hpd work and suspend, since the workqueue work can still be run after anx7625 had powered off in suspend. Since we never want hpd work to run while suspending, and there's no harm to delay them to be run after resume, mark the workqueue as WQ_FREEZABLE so all works won't run while suspending. Fixes: 409776fa ("drm/bridge: anx7625: add suspend / resume hooks") Signed-off-by:
Pi-Hsun Shih <pihsun@chromium.org> Reviewed-by:
Tzung-Bi Shih <tzungbi@google.com> Signed-off-by:
-
- 17 Jun, 2021 2 commits
-
-
Jason Ekstrand authored
This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC. v2 (Daniel Vetter): - Fix a couple typos - Add commentary about synchronization with other devices - Use item list format for describing flags v3 (Pekka Paalanen): - Clarify stalling requirements. - Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be called before more GPU work happens. Signed-off-by:
Jason Ekstrand <jason@jlekstrand.net> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by:
-
Jiahua Yu authored
spinlock can be initialized automatically with DEFINE_SPINLOCK() rather than explicitly calling spin_lock_init(). Signed-off-by:
Jiahua Yu <yujiahua1@huawei.com> Signed-off-by:
-
- 16 Jun, 2021 4 commits
-
-
Martin Krastev authored
Fixes for ARCH i386 * printk format specifier warnings * inconsistent operand constraints in an ‘asm’ errors arm64 * not targeted by the commit being fixed Reviewed-by:
Zack Rusin <zackr@vmware.com> Fixes: 7a7a933e ("drm/vmwgfx: Introduce VMware mks-guest-stats") Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Martin Krastev <krastevm@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210615182336.995192-5-zackr@vmware.comSigned-off-by:
-
Zack Rusin authored
Change 2ef4fb92 ("drm/vmwgfx: Make sure bo's are unpinned before putting them back") caused a conflict in one of the drm trees and the merge commit 68a32ba1 ("Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm") accidently re-added code that the original change was removing. Fixed by removing the incorrect buffer unpin - it has already been unpinned two lines above. Fixes: 68a32ba1 ("Merge tag 'drm-next-2021-04-28' of git://anongit.freedesktop.org/drm/drm") Signed-off-by:
-
Zack Rusin authored
Register accesses are always 4bytes, accidently this was changed to a void pointer whwqich badly breaks 64bit archs when running on top of svga3. Fixes: 2cd80dbd ("drm/vmwgfx: Add basic support for SVGA3") Signed-off-by:
-
Zack Rusin authored
Historically our device headers have been forked versions of the internal device headers, this has made maintaining them a bit of a burden. To fix the situation, going forward, the device headers will be verbatim copies of the internal headers. To do that the driver code has to be adapted to use pristine device headers. This will make future update to the device headers trivial and automatic. Signed-off-by:
-
