similar to: [PATCH] drm/nouveau: fix memory leak in nouveau_conn_reset()

From: Yongxin Liu <yongxin.liu at windriver.com> [ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ] In nouveau_conn_reset(), if connector->state is true, __drm_atomic_helper_connector_destroy_state() will be called, but the memory pointed by asyc isn't freed. Memory leak happens in the following function __drm_atomic_helper_connector_reset(), where newly allocated

From: Yongxin Liu <yongxin.liu at windriver.com> [ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ] In nouveau_conn_reset(), if connector->state is true, __drm_atomic_helper_connector_destroy_state() will be called, but the memory pointed by asyc isn't freed. Memory leak happens in the following function __drm_atomic_helper_connector_reset(), where newly allocated

From: Yongxin Liu <yongxin.liu at windriver.com> [ Upstream commit 09b90e2fe35faeace2488234e2a7728f2ea8ba26 ] In nouveau_conn_reset(), if connector->state is true, __drm_atomic_helper_connector_destroy_state() will be called, but the memory pointed by asyc isn't freed. Memory leak happens in the following function __drm_atomic_helper_connector_reset(), where newly allocated

Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not use atomic modesetting). Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

Place the declaration of struct nouveau_conn_atom above that of struct nouveau_connector. This commit makes no changes to the moved block what so ever, it just moves it up a bit. This is a preparation patch to fix some issues with connector handling on pre nv50 displays (which do not use atomic modesetting). Signed-off-by: Hans de Goede <hdegoede at redhat.com> ---

Hello, 5.1.0-next-20190517 I'm looking at quite a lot of kmemleak reports coming from drm/nouveau/core/memory, all of which are: unreferenced object 0xffff8deec27c4ac0 (size 16): comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) hex dump (first 16 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace:

We do not support atomic modesetting on pre-nv50 hardware, but until now our connector code was setting drm_connector->state on pre-nv50 hardware. This causes the core to enter atomic modesetting paths in at least: 1. drm_connector_get_encoder(), returning connector->state->best_encoder which is always 0, causing us to always report 0 as encoder_id in the drmModeConnector struct

We do not support atomic modesetting on pre-nv50 hardware, but until now our connector code was setting drm_connector->state on pre-nv50 hardware. This causes the core to enter atomic modesetting paths in at least: 1. drm_connector_get_encoder(), returning connector->state->best_encoder which is always 0, causing us to always report 0 as encoder_id in the drmModeConnector struct

From: Hans de Goede <hdegoede at redhat.com> [ Upstream commit 64d17f25dcad518461ccf0c260544e1e379c5b35 ] We do not support atomic modesetting on pre-nv50 hardware, but until now our connector code was setting drm_connector->state on pre-nv50 hardware. This causes the core to enter atomic modesetting paths in at least: 1. drm_connector_get_encoder(), returning

On (05/17/19 15:13), Sergey Senozhatsky wrote: > 5.1.0-next-20190517 > > I'm looking at quite a lot of kmemleak reports coming from > drm/nouveau/core/memory, all of which are: > > unreferenced object 0xffff8deec27c4ac0 (size 16): > comm "Web Content", pid 5309, jiffies 4309675011 (age 68.076s) > hex dump (first 16 bytes): > 00 00

Add null check before dereferencing pointer asyc Addresses-Coverity-ID: 1397932 Signed-off-by: Gustavo A. R. Silva <garsilva at embeddedor.com> --- drivers/gpu/drm/nouveau/nv50_display.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c index a766324..052a60a 100644 ---

Prefer the parsed results for is_hdmi and has_audio in display info over calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(), respectively. Conveniently, this also removes the need to use edid_blob_ptr. Cc: Karol Herbst <kherbst at redhat.com> Cc: Lyude Paul <lyude at redhat.com> Cc: Danilo Krummrich <dakr at redhat.com> Cc: nouveau at lists.freedesktop.org

On Fri, Jan 12, 2024 at 11:50?AM Jani Nikula <jani.nikula at intel.com> wrote: > > Prefer the parsed results for is_hdmi and has_audio in display info over > calling drm_detect_hdmi_monitor() and drm_detect_monitor_audio(), > respectively. > > Conveniently, this also removes the need to use edid_blob_ptr. > > Cc: Karol Herbst <kherbst at redhat.com> > Cc:

It's dead code, the core handles all this directly now. This also allows us to unexport drm_atomic_helper_connector_set_property. The only special case is nouveau which used one function for both pre-nv50 legacy modeset code and post-nv50 atomic world instead of 2 vtables. But amounts to exactly the same. What is rather strange here is how few drivers set this up, I suspect the earlier patch

Hello, This is an attempt at providing generic support for underscan connector props. We already have 3 drivers defining the same underscan, underscan vborder and underscan hborder properties (amd, radeon and nouveau) and I am about to add a new one, hence my proposal to put the prop parsing code in the core and add ->underscan fields to drm_connector_state. In this v2, I also converted the

When resuming from ACPI S3, memory leak happens in nvkm_ram_get(). This is because *pmemory points to newly allocated memory without checking and freeing the old memory. Here is the log showing this issue. unreferenced object 0xffffa3b608c6d5c0 (size 64): comm "kworker/u32:30", pid 934, jiffies 4294823520 (age 5000.217s) hex dump (first 32 bytes): 00 fc 4a c0 ff ff ff ff 00 00

This fixes quite a number of runtime PM bugs I found that have been causing some pretty nasty issues such as: - Deadlocking on boot - Connector probing potentially not working while the GPU is in runtime suspend - i2c char dev not working while the GPU is in runtime suspend - aux char dev not working while the GPU is in runtime suspend There's definitely more parts of nouveau that need

While we expose the ability to turn off hardware dithering for nouveau, we actually make the mistake of turning it on anyway, due to dithering_depth containing a non-zero value if our dithering depth isn't also set to 6 bpc. So, fix it by never enabling dithering when it's disabled. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 24

While we expose the ability to turn off hardware dithering for nouveau, we actually make the mistake of turning it on anyway, due to dithering_depth containing a non-zero value if our dithering depth isn't also set to 6 bpc. So, fix it by never enabling dithering when it's disabled. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 24

While we expose the ability to turn off hardware dithering for nouveau, we actually make the mistake of turning it on anyway, due to dithering_depth containing a non-zero value if our dithering depth isn't also set to 6 bpc. So, fix it by never enabling dithering when it's disabled. Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv50/head.c | 24