- 23 Jun, 2021 12 commits
-
-
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:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210525132354.297468-10-maxime@cerno.tech
-
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:
Nicolas Saenz Julienne <nsaenz@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210525132354.297468-9-maxime@cerno.tech
-
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:
Christian König <christian.koenig@amd.com> Cc: Christian König <ckoenig.leichtzumerken@gmail.com> Signed-off-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 7 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:
-
Zack Rusin authored
Roland will be focusing on lavapipe over the next few months and won't have time for vmwgfx. vmwgfx is now maintained within drm-misc. Signed-off-by:
Roland Scheidegger <sroland@vmware.com> Acked-by:
-
Maxime Ripard authored
DRM currently polls for the HDMI connector status every 10s, which can be an issue when we connect/disconnect a display quickly or the device on the other end only issues a hotplug pulse (for example on EDID change). Switch the driver to rely on the internal controller logic for the BCM2711/RPi4. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210524132018.264396-1-maxime@cerno.tech
-
Yu Jiahua authored
This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Signed-off-by:
-
- 15 Jun, 2021 2 commits
-
-
Hridya Valsaraju authored
Overview ======== The patch adds DMA-BUF statistics to /sys/kernel/dmabuf/buffers. It allows statistics to be enabled for each DMA-BUF in sysfs by enabling the config CONFIG_DMABUF_SYSFS_STATS. The following stats will be exposed by the interface: /sys/kernel/dmabuf/buffers/<inode_number>/exporter_name /sys/kernel/dmabuf/buffers/<inode_number>/size /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/device /sys/kernel/dmabuf/buffers/<inode_number>/attachments/<attach_uid>/map_counter The inode_number is unique for each DMA-BUF and was added earlier [1] in order to allow userspace to track DMA-BUF usage across different processes. Use Cases ========= The interface provides a way to gather DMA-BUF per-buffer statistics from production devices. These statistics will be used to derive DMA-BUF per-exporter stats and per-device usage stats for Android Bug reports. The corresponding userspace changes can be found at [2]. Telemetry tools will also capture this information(along with other memory metrics) periodically as well as on important events like a foreground app kill (which might have been triggered by Low Memory Killer). It will also contribute to provide a snapshot of the system memory usage on other events such as OOM kills and Application Not Responding events. Background ========== Currently, there are two existing interfaces that provide information about DMA-BUFs. 1) /sys/kernel/debug/dma_buf/bufinfo debugfs is however unsuitable to be mounted in production systems and cannot be considered as an alternative to the sysfs interface being proposed. 2) proc/<pid>/fdinfo/<fd> The proc/<pid>/fdinfo/<fd> files expose information about DMA-BUF fds. However, the existing procfs interfaces can only provide information about the buffers for which processes hold fds or have the buffers mmapped into their address space. Since the procfs interfaces alone cannot provide a full picture of all DMA-BUFs in the system, there is the need for an alternate interface to provide this information on production systems. The patch contains the following major improvements over v1: 1) Each attachment is represented by its own directory to allow creating a symlink to the importing device and to also provide room for future expansion. 2) The number of distinct mappings of each attachment is exposed in a separate file. 3) The per-buffer statistics are now in /sys/kernel/dmabuf/buffers inorder to make the interface expandable in future. All of the improvements above are based on suggestions/feedback from Daniel Vetter and Christian König. A shell script that can be run on a classic Linux environment to read out the DMA-BUF statistics can be found at [3](suggested by John Stultz). [1]: https://lore.kernel.org/patchwork/patch/1088791/ [2]: https://android-review.googlesource.com/q/topic:%22dmabuf-sysfs%22+(status:open%20OR%20status:merged) [3]: https://android-review.googlesource.com/c/platform/system/memory/libmeminfo/+/1549734Reviewed-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Hridya Valsaraju <hridya@google.com> Reported-by:
-
Ainux authored
The existence of the connector cannot be detected, so add the detect function to support. Signed-off-by:
Ainux <ainux.wang@gmail.com> Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210526111515.40015-1-ainux.wang@gmail.com
-
- 14 Jun, 2021 2 commits
-
-
Linus Walleij authored
The SPI access to s6e63m0 is using the DBI protocol, so switch to using the elaborate DBI protocol implementation in the DRM DBI helper library. Acked-by:
Noralf Trønnes <noralf@tronnes.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210614181135.1124445-2-linus.walleij@linaro.org
-
Linus Walleij authored
Implement SPI reads for typec1, for SPI controllers that can support 9bpw in addition to 8bpw (such as GPIO bit-banged SPI). 9bpw emulation is not supported but we have to start with something. This is used by s6e63m0 to read display MTP information which is used by the driver for backlight control. Reviewed-by:
-
