similar to: [PATCH] drm/nouveau: use drm debug levels

It seems it was only locking up in the context of nouveau_hw_save_vga_fonts, when it actually did something (because the console wasn't already in graphics mode). Signed-off-by: Francisco Jerez <currojerez at riseup.net> --- drivers/gpu/drm/nouveau/nouveau_hw.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_hw.c

This patch series adds TV-out modesetting support to the KMS implementation. I've tried to test it on all the hardware I've got at hand (that is nv11, nv17, nv34, nv35, nv40, nv4b) with every possible output combination; I believe it has reached a mergeable state, however it depends on some commits from drm-next that haven't got into Linus' tree yet, if you agree to merge this

Hi, Here is my patch queue I accumulated over quite a long time. Patches 1-6 are bugfixes, and rest is mostly RFC. Comments are welcome. Best regards, Maxim Levitsky

On Fri, Jan 29, 2010 at 12:00:49PM +0300, Dan Carpenter wrote: > These bugs are when code dereferences a variable and then checks that it is not null. > The new thing is that I wrote a shell script to try remove the false positives caused > by macros. There are still some false positives because smatch is bad at handling > loops and knowing when a container got redefined. > >

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support"), the nouveau driver notifies and pokes the HD-audio HPD and ELD via audio component, but this seems broken. The culprit is the naive assumption that crtc->index corresponds to the HDA pin. Actually this rather corresponds to the MST dev_id (alias "pipe" in the audio component framework)

It turns out that I forgot to go through and make sure that I converted all encoder callbacks to use atomic_enable/atomic_disable(), so let's go and actually do that. Signed-off-by: Lyude Paul <lyude at redhat.com> Cc: Kirill A. Shutemov <kirill at shutemov.name> Fixes: 09838c4efe9a ("drm/nouveau/kms: Search for encoders' connectors properly") ---

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of a flexible structure where the size of the flexible-array member is known at compile-time, and refactor the rest of the code, accordingly. So, with this, fix the following warning: drivers/gpu/drm/nouveau/dispnv50/disp.c:779:47: warning: structure containing a flexible array member is not at the end of another structure

Hi all, Friendly ping: who can take this, please? ? Thanks -Gustavo On 21/08/24 22:16, Gustavo A. R. Silva wrote: > Use the `DEFINE_RAW_FLEX()` helper for an on-stack definition of > a flexible structure where the size of the flexible-array member > is known at compile-time, and refactor the rest of the code, > accordingly. > > So, with this, fix the following warning: >

Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM related and MST related fixes, we're missing a lot of nice things that have been added to DRM since this was originally written. Additionally, the code

drivers/gpu/drm/nouveau/dispnv50/disp.c: In function nv50_pior_enable: drivers/gpu/drm/nouveau/dispnv50/disp.c:1672:28: warning: variable nv_connector set but not used [-Wunused-but-set-variable] commit ac2d9275f371 ("drm/nouveau/kms/nv50-: Store the bpc we're using in nv50_head_atom") left behind this. Reported-by: Hulk Robot <hulkci at huawei.com> Signed-off-by: YueHaibing

To start off: this patch series is less work to review then it looks - most (but not all) of the nouveau related work has already been reviewed elsewhere. Most of the reason I'm asking for an RFC here is because this code pulls a lot of code out of i915 and into shared DP helpers. Anyway-nouveau's HPD related code has been collecting dust for a while. Other then the occasional runtime PM

While the way we find the associated connector for an encoder is just fine for legacy modesetting, it's not correct for nv50+ since that uses atomic modesetting. For reference, see the drm_encoder kdocs. Fix this by removing nouveau_encoder_connector_get(), and replacing it with nv04_encoder_get_connector(), nv50_outp_get_old_connector(), and nv50_outp_get_new_connector(). v2: * Don't

This is more or less simplified series of patches that bring power usage on my NV86 close to that of binary blob. Best regards, Maxim Levitsky

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:

This fixes some nasty issues I found in nouveau that were being caused looping through connectors using racy legacy methods, along with some caused by making incorrect assumptions about the drm_connector structs in nouveau's connector list. Most of these memory corruption issues could be reproduced by using an MST hub with nouveau. Cc: Karol Herbst <karolherbst at gmail.com> Cc: stable

This makes debugging with DP tracing a lot harder to interpret, so name each i2c based off the name of the encoder that it's for Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +- drivers/gpu/drm/nouveau/nouveau_connector.c | 12 ++++++++++--

Hi, Here I post these 2 misc patches. Best regards, Maxim Levitsky