similar to: [PATCH] bios: add 8.1Gbps DP link rate

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nouveau_dp.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c b/drivers/gpu/drm/nouveau/nouveau_dp.c index 8a0f7994e1aeb..ee778ddc95fae 100644 --- a/drivers/gpu/drm/nouveau/nouveau_dp.c +++ b/drivers/gpu/drm/nouveau/nouveau_dp.c @@ -76,10 +76,10 @@

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76319 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- It's unclear to me whether GF11x devices actually support this, but the disp "split" is at nvd0, so I went with that. The marketing docs are fairly unclear. However most of them don't actually have DP in the first place, so it may not be a huge issue. I

- Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (04) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace with NV_DEBUG_KMS Signed-off-by: Maarten Maathuis <madman2003 at gmail.com> --- drivers/gpu/drm/nouveau/nouveau_bios.c | 12 +++++----- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 +++---

Hey, This patch causes a regression on my display-less nvd7. Commenting out the aux, aux_stat and aux_mask members in nvd0_i2c_oclass fixes boot, and makes things work normally again. broken dmesg: [ 40.314470] ACPI Warning: \_SB_.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20140424/nsarguments-95) [ 40.314729] ACPI Warning: \_SB_.PCI0.GFX0._DSM:

This warning seems to pop up mainly in laptop cards. Silence it as it is expected behavior. Signed-off by: Rosen Penev <rosenp at gmail.com> --- drm/nouveau/nouveau_bios.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drm/nouveau/nouveau_bios.c b/drm/nouveau/nouveau_bios.c index b998c33a..dd6fba55 100644 --- a/drm/nouveau/nouveau_bios.c +++

Hi, this is my first help request so please bear with me. I've been running some normality tests using the nortest package. For some of my datasets the Cramer-von Mises normality test generates an extremely high probability (e.g., 1.637e+31) and indicates normality when the other tests do not. Is there something I'm misunderstanding or potentially a bug in the code? Below are the

I believe there to be a bug in the cvm.test module of the nortest package authored by Juergen Gross. I do not know how to contact the author directly. I've been running some normality tests using the nortest package. For some of my datasets the Cramer-von Mises normality test generates an extremely high probability (e.g., 1.637e+31) and indicates normality when the other tests do

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++++++++

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com>

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase v3: renamed a function call Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com>

From: Oleg Vasilev <oleg.vasilev at intel.com> Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. v2: rebase Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org Signed-off-by: Jeevan B <jeevan.b at intel.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com>

This should probably be fixed to account for the scenario where an HDMI connector is plugged directly into the DP++ port. I don't think the dp.subconnector property will be valid in that case. (Unfortunately I don't remember how one detects that particular situation.) On Mon, Aug 26, 2019 at 9:22 AM Oleg Vasilev <oleg.vasilev at intel.com> wrote: > > Since DP-specific

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 DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Reviewed-by: Emil Velikov <emil.velikov at collabora.com> Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: Ben Skeggs <bskeggs at redhat.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13

Right now, we make the mistake of allowing interlacing on all connectors. Nvidia hardware does not always support interlacing with DP though, so we need to make sure that we don't allow interlaced modes to be set in such situations as otherwise we'll end up accidentally hanging the display HW. This fixes some hangs with Turing, which would be caused by attempting to set an interlaced mode

Both Coverity and GCC with -Wstringop-overflow noticed that nvif_outp_acquire_dp() accidentally defined its second argument with 1 additional element: drivers/gpu/drm/nouveau/dispnv50/disp.c: In function 'nv50_pior_atomic_enable': drivers/gpu/drm/nouveau/dispnv50/disp.c:1813:17: error: 'nvif_outp_acquire_dp' accessing 16 bytes in a region of size 15 [-Werror=stringop-overflow=]

Since DP-specific information is stored in driver's structures, every driver needs to implement subconnector property by itself. Signed-off-by: Oleg Vasilev <oleg.vasilev at intel.com> Cc: nouveau at lists.freedesktop.org --- drivers/gpu/drm/nouveau/nouveau_connector.c | 13 +++++++++++++ drivers/gpu/drm/nouveau/nouveau_dp.c | 9 +++++++++