We regularly get dmesg error reports of:
[ 18.184066] hdmi-audio-codec hdmi-audio-codec.3.auto: ASoC: error at snd_soc_dai_startup on i2s-hifi: -19
[ 18.184098] MAI: soc_pcm_open() failed (-19)
These are generated for any disconnected hdmi interface when pulseaudio
attempts to open the associated ALSA device (numerous times). Each open
generates a kernel error message, generating general log spam.
The error messages all come from _soc_pcm_ret in sound/soc/soc-pcm.c#L39
which suggests returning ENOTSUPP, rather that ENODEV will be quiet.
And indeed it is.
Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240621152055.4180873-5-dave.stevenson@raspberrypi.com
Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
Different approaches have been tried to signal resets and other errors in
vendor specific ways which not only resulted in a wide variety of
implementations but also repeating the same bugs and problems over different
drivers.
Document that drivers should use dma_fence based error signaling which is
vendor agnostic and allows userspace to query submission errors in generic
non-vendor specific code.
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240826122541.85663-3-christian.koenig@amd.com
The current implementation of drm_sched_start uses a hardcoded
-ECANCELED to dispose of a job when the parent/hw fence is NULL.
This results in drm_sched_job_done being called with -ECANCELED for
each job with a NULL parent in the pending list, making it difficult
to distinguish between recovery methods, whether a queue reset or a
full GPU reset was used.
To improve this, we first try a soft recovery for timeout jobs and
use the error code -ENODATA. If soft recovery fails, we proceed with
a queue reset, where the error code remains -ENODATA for the job.
Finally, for a full GPU reset, we use error codes -ECANCELED or
-ETIME. This patch adds an error code parameter to drm_sched_start,
allowing us to differentiate between queue reset and GPU reset
failures. This enables user mode and test applications to validate
the expected correctness of the requested operation. After a
successful queue reset, the only way to continue normal operation is
to call drm_sched_job_done with the specific error code -ENODATA.
v1: Initial implementation by Jesse utilized amdgpu_device_lock_reset_domain
and amdgpu_device_unlock_reset_domain to allow user mode to track
the queue reset status and distinguish between queue reset and
GPU reset.
v2: Christian suggested using the error codes -ENODATA for queue reset
and -ECANCELED or -ETIME for GPU reset, returned to
amdgpu_cs_wait_ioctl.
v3: To meet the requirements, we introduce a new function
drm_sched_start_ex with an additional parameter to set
dma_fence_set_error, allowing us to handle the specific error
codes appropriately and dispose of bad jobs with the selected
error code depending on whether it was a queue reset or GPU reset.
v4: Alex suggested using a new name, drm_sched_start_with_recovery_error,
which more accurately describes the function's purpose.
Additionally, it was recommended to add documentation details
about the new method.
v5: Fixed declaration of new function drm_sched_start_with_recovery_error.(Alex)
v6 (chk): rebase on upstream changes, cleanup the commit message,
drop the new function again and update all callers,
apply the errno also to scheduler fences with hw fences
v7 (chk): rebased
Signed-off-by: Jesse Zhang <Jesse.Zhang@amd.com>
Signed-off-by: Vitaly Prosyak <vitaly.prosyak@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240826122541.85663-1-christian.koenig@amd.com
For each mode, test the required memory against the available video
memory. Filters out modes that do not fit into display memory.
Also remove the old test against the 4 MiB limit. It is now obsolete
and did not necessarily produce correct results.
v2:
- fix __udivdi3 linker error (kernel test robot)
- fix vdisplay and hdisplay usage
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240902105546.792625-10-tzimmermann@suse.de
Replace GEM VRAM with GEM SHMEM in bochs. The new memory manager
stores buffer objects in system memory. Makes the driver's memory
management more reliably.
Most of the changes are hidden in external helpers that allocate
buffers. Replacing DRM_GEM_VRAM_DRIVER with DRM_GEM_SHMEM_DRIVER_OPS
swaps these. With GEM VRAM, the video memory was updated directly by
the DRM client. The biggest change within bochs is in atomic_update,
which now updates video memory via memcpy() from the BO in system
memory. Shadow-plane helpers maintaining the pointers to the buffer's
data, so bochs doesn't have to. The update is triggered by each page
flip's call to the framebuffer's dirty helper. The driver supports
damage clipping to minimize memcpy() overhead.
The advantage of GEM SHMEM is that it makes memory management
more reliable. Given DRM's double buffering during page flips, the
minimum amount of video memory is three times the maximum consumption
in some pathological cases. For example, if the maximum size of a GEM
buffer is 1920x1080-32 (i.e., 32-bit FullHD), the buffer size is
8 MiB. Display hardware has to provide at lease 24 MiB to reliably
page flip such configurations. This cannot always be guaranteed and
bochs already contains code to rule out <4 MiB configurations. With
GEM SHMEM, only 8 MiB of video memory are required for the given
example. Unsupported modes can be sorted out easily.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240902105546.792625-9-tzimmermann@suse.de
Remove the simple display pipeline in favor of the regular atomic
helpers in bochs. The simple-pipe helpers are considered deprecated
in DRM.
This effectivly inlines the simple-pipe code for plane and CRTC
support. Instead of a single update helper, there's now a mode-set
helper for the CRTC and an update helper for the plane. The encoder
changes type from NONE ot VIRTUAL.
Removing simple-pipe helpers from bochs will allow for related
cleanups in GEM VRAM helpers.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240902105546.792625-8-tzimmermann@suse.de
Implement a read function for struct drm_edid and read the EDID data
with drm_edit_read_custom(). Update the connector data accordingly.
The EDID data comes from the emulator itself and the connector stores
a copy in its EDID property. The drm_edid field in struct bochs_device
is therefore not required. Remove it.
If qemu provides no EDID data, install default display modes as before.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240902105546.792625-3-tzimmermann@suse.de
Expose timestamp information supported by the GPU with a new device
query.
Mali uses an external timer as GPU system time. On ARM, this is wired to
the generic arch timer so we wire cntfrq_el0 as device frequency.
This new uAPI will be used in Mesa to implement timestamp queries and
VK_KHR_calibrated_timestamps.
Since this extends the uAPI and because userland needs a way to advertise
those features conditionally, this also bumps the driver minor version.
v2:
- Rewrote to use GPU timestamp register
- Added timestamp_offset to drm_panthor_timestamp_info
- Add missing include for arch_timer_get_cntfrq
- Rework commit message
v3:
- Add panthor_gpu_read_64bit_counter
- Change panthor_gpu_read_timestamp to use
panthor_gpu_read_64bit_counter
v4:
- Fix multiple typos in uAPI documentation
- Mention behavior when the timestamp frequency is unknown
- Use u64 instead of unsigned long long
for panthor_gpu_read_timestamp
- Apply r-b from Mihail
Signed-off-by: Mary Guillemard <mary.guillemard@collabora.com>
Reviewed-by: Mihail Atanassov <mihail.atanassov@arm.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240830080349.24736-2-mary.guillemard@collabora.com
ARCH=arm build fails with:
CC [M] drivers/gpu/drm/bridge/ti-tdp158.o
../drivers/gpu/drm/bridge/ti-tdp158.c: In function ‘tdp158_enable’:
../drivers/gpu/drm/bridge/ti-tdp158.c:31:9: error: implicit declaration of function ‘gpiod_set_value_cansleep’ [-Werror=implicit-function-declaration]
31 | gpiod_set_value_cansleep(tdp158->enable, 1);
| ^~~~~~~~~~~~~~~~~~~~~~~~
../drivers/gpu/drm/bridge/ti-tdp158.c: In function ‘tdp158_probe’:
../drivers/gpu/drm/bridge/ti-tdp158.c:80:26: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_regulator_get_optional’? [-Werror=implicit-function-declaration]
80 | tdp158->enable = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
| ^~~~~~~~~~~~~~~~~~~~~~~
| devm_regulator_get_optional
../drivers/gpu/drm/bridge/ti-tdp158.c:80:65: error: ‘GPIOD_OUT_LOW’ undeclared (first use in this function)
80 | tdp158->enable = devm_gpiod_get_optional(dev, "enable", GPIOD_OUT_LOW);
| ^~~~~~~~~~~~~
../drivers/gpu/drm/bridge/ti-tdp158.c:80:65: note: each undeclared identifier is reported only once for each function it appears in
Add the proper gpio consumer #include to fix this, and juggle the
include order to be a bit more pleasant on the eye while at it.
Fixes: a15710027a ("drm/bridge: add support for TI TDP158")
Cc: Marc Gonzalez <mgonzalez@freebox.fr>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240904085206.3331553-1-jani.nikula@intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
The INTERVAL_TREE_DEFINE() uncoditionally provides a bunch of helper
functions which in some cases may be not used. This, in particular,
prevents kernel builds with clang, `make W=1` and CONFIG_WERROR=y:
.../drm/drm_mm.c:152:1: error: unused function 'drm_mm_interval_tree_insert' [-Werror,-Wunused-function]
152 | INTERVAL_TREE_DEFINE(struct drm_mm_node, rb,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
153 | u64, __subtree_last,
| ~~~~~~~~~~~~~~~~~~~~
154 | START, LAST, static inline, drm_mm_interval_tree)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fix this by marking drm_mm_interval_tree*() functions with __maybe_unused.
See also commit 6863f5643d ("kbuild: allow Clang to find unused static
inline functions for W=1 build").
Fixes: 202b52b7fb ("drm: Track drm_mm nodes with an interval tree")
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240829154640.1120050-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
It supports DVI 1.0, HDMI 1.4b and 2.0b.
It supports 4 TMDS channels, HPD, and a DDC interface.
It supports dual power supply rails (1.1V on VDD, 3.3V on VCC)
for power reduction. Several methods of power management are
implemented to reduce overall power consumption.
It supports fixed receiver EQ gain using I2C or pin strap to
compensate for different lengths input cable or board traces.
Features
- AC-coupled TMDS or DisplayPort dual-mode physical layer input
to HDMI 2.0b TMDS physical layer output supporting up to 6Gbps
data rate, compatible with HDMI 2.0b electrical parameters
- DisplayPort dual-mode standard version 1.1
- Programmable fixed receiver equalizer up to 15.5dB
- Global or independent high speed lane control, pre-emphasis
and transmit swing, and slew rate control
- I2C or pin strap programmable
- Configurable as a DisplayPort redriver through I2C
- Full lane swap on main lanes
- Low power consumption (200 mW at 6Gbps, 8 mW in shutdown)
https://www.ti.com/lit/ds/symlink/tdp158.pdf
On our board, I2C_EN is pulled high.
Thus, this code defines a module_i2c_driver.
The default settings work fine for our use-case.
So this basic driver doesn't need to tweak any I2C registers.
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240812-tdp158-v5-2-78684a84ec23@freebox.fr
TDP158 is an AC-coupled DVI / HDMI to TMDS level shifting Redriver.
It supports DVI 1.0, HDMI 1.4b and 2.0b.
It supports 4 TMDS channels, HPD, and a DDC interface.
It supports dual power supply rails (1.1V on VDD, 3.3V on VCC)
for power reduction. Several methods of power management are
implemented to reduce overall power consumption.
It supports fixed receiver EQ gain using I2C or pin strap to
compensate for different lengths input cable or board traces.
Features
- AC-coupled TMDS or DisplayPort dual-mode physical layer input
to HDMI 2.0b TMDS physical layer output supporting up to 6Gbps
data rate, compatible with HDMI 2.0b electrical parameters
- DisplayPort dual-mode standard version 1.1
- Programmable fixed receiver equalizer up to 15.5dB
- Global or independent high speed lane control, pre-emphasis
and transmit swing, and slew rate control
- I2C or pin strap programmable
- Configurable as a DisplayPort redriver through I2C
- Full lane swap on main lanes
- Low power consumption (200 mW at 6Gbps, 8 mW in shutdown)
https://www.ti.com/lit/ds/symlink/tdp158.pdf
Like the TFP410, the TDP158 can be set up in 2 different ways:
1) hard-coding its configuration settings using pin-strapping resistors
2) placing it on an I2C bus, and defer set-up until run-time
The mode is selected via pin 8 = I2C_EN
I2C_EN high = I2C Control Mode
I2C_EN low = Pin Strap Mode
On our board, I2C_EN is pulled high.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Marc Gonzalez <mgonzalez@freebox.fr>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240812-tdp158-v5-1-78684a84ec23@freebox.fr
