search for: nv50_display_fini

...e_work() is the ->work element in drm_dp_mst_topology_mgr() and is queued on HPD. I further notice that the work item is flushed on ->runtime_suspend: nouveau_pmops_runtime_suspend() nouveau_do_suspend() nouveau_display_suspend() nouveau_display_fini() disp->fini() == nv50_display_fini() nv50_mstm_fini() drm_dp_mst_topology_mgr_suspend() flush_work(&mgr->work); And before the work item is flushed, the HPD source is quiesced. So it looks like drm_dp_mst_link_probe_work() can only ever run while the GPU is runtime resumed, it never runs while the GPU is runt...

...0644 --- a/drivers/gpu/drm/nouveau/nv50_display.h +++ b/drivers/gpu/drm/nouveau/nv50_display.h @@ -31,7 +31,5 @@ #include "nouveau_reg.h" int nv50_display_create(struct drm_device *); -void nv50_display_destroy(struct drm_device *); -int nv50_display_init(struct drm_device *); -void nv50_display_fini(struct drm_device *); + #endif /* __NV50_DISPLAY_H__ */ -- 2.39.2

...> if (!suspend) > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c > index 88728a0b2c25..674dc567e179 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -2680,7 +2680,7 @@ nv50_display_fini(struct drm_device *dev, bool runtime, bool suspend) > nv50_mstm_fini(nouveau_encoder(encoder)); > } > > - if (!runtime) > + if (!runtime && !drm->headless) > cancel_work_sync(&drm->hpd_work); > } > > diff --git a/drivers/gpu/drm/nouve...

...b/drm/nouveau/nv50_display.h @@ -31,8 +31,12 @@ #include "nouveau_crtc.h" #include "nouveau_reg.h" +struct nouveau_encoder; + int nv50_display_create(struct drm_device *); void nv50_display_destroy(struct drm_device *); int nv50_display_init(struct drm_device *); void nv50_display_fini(struct drm_device *); +void nv50_outp_release(struct nouveau_encoder *); +int nv50_outp_acquire(struct nouveau_encoder *); #endif /* __NV50_DISPLAY_H__ */ -- 2.14.3

...u/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index 8412119bd9..a9bb656058 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -2174,7 +2174,7 @@ nv50_display_create(struct drm_device *dev) nouveau_display(dev)->fini = nv50_display_fini; disp->disp = &nouveau_display(dev)->disp; dev->mode_config.funcs = &nv50_disp_func; - dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP; + dev->mode_config.quirk_addfb_prefer_xbgr_30bpp = true; /* small shared memory area we use for notifiers and semaphores...

...0644 --- a/drivers/gpu/drm/nouveau/nv50_display.h +++ b/drivers/gpu/drm/nouveau/nv50_display.h @@ -31,7 +31,4 @@ #include "nouveau_reg.h" int nv50_display_create(struct drm_device *); -void nv50_display_destroy(struct drm_device *); -int nv50_display_init(struct drm_device *); -void nv50_display_fini(struct drm_device *); #endif /* __NV50_DISPLAY_H__ */ -- 2.23.0

...> if (!suspend) > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c > index 88728a0b2c25..674dc567e179 100644 > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c > @@ -2680,7 +2680,7 @@ nv50_display_fini(struct drm_device *dev, bool runtime, bool suspend) > nv50_mstm_fini(nouveau_encoder(encoder)); > } > > - if (!runtime) > + if (!runtime && !drm->headless) > cancel_work_sync(&drm->hpd_work); > } > > diff --git a/drivers/gpu/drm/nouve...

We want to be able to guarantee the location of the allocated buffer object if we're going to be able to reliably allocate the existing framebuffer at startup. Add an argument to do so and pass that through to the ttm core. Signed-off-by: Matthew Garrett <mjg at redhat.com> --- drivers/bcma/main.c | 1 - drivers/gpu/drm/nouveau/nouveau_bo.c | 8 +++++++-

The base917c_format isn't exported, so make it static to avoid the following warning: drivers/gpu/drm/nouveau/dispnv50/base917c.c:26:1: warning: symbol 'base917c_format' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks at codethink.co.uk> --- drivers/gpu/drm/nouveau/dispnv50/base917c.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

...e+0x39/0xc0 [nouveau] [ 246.727713] nouveau_connector_aux_xfer+0x5c/0xd0 [nouveau] [ 246.728546] drm_dp_dpcd_access+0x77/0x110 [drm_kms_helper] [ 246.729349] drm_dp_dpcd_write+0x2b/0xb0 [drm_kms_helper] [ 246.730085] drm_dp_mst_topology_mgr_suspend+0x4e/0x90 [drm_kms_helper] [ 246.730828] nv50_display_fini+0xa5/0xc0 [nouveau] [ 246.731606] nouveau_display_fini+0xc8/0x100 [nouveau] [ 246.732375] nouveau_display_suspend+0x62/0x110 [nouveau] [ 246.733106] nouveau_do_suspend+0x5e/0x2d0 [nouveau] [ 246.733839] nouveau_pmops_runtime_suspend+0x4f/0xb0 [nouveau] [ 246.734585] pci_pm_runtime_suspend...

https://bugs.freedesktop.org/show_bug.cgi?id=67878 Priority: medium Bug ID: 67878 Assignee: nouveau at lists.freedesktop.org Summary: Hardware freeze after resume from suspend QA Contact: xorg-team at lists.x.org Severity: critical Classification: Unclassified OS: Linux (All) Reporter: bgamari at gmail.com

[cc += linux-pm] Hi Lyude, First of all, thanks a lot for looking into this. On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote: > In order to fix all of the spots that need to have runtime PM get/puts() > added, we need to ensure that it's possible for us to call > pm_runtime_get/put() in any context, regardless of how deep, since > almost all of the spots that are

Signed-off-by: Lyude Paul <lyude at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++

On Wed, Jul 18, 2018 at 04:56:39PM -0400, Lyude Paul wrote: > When DP MST hubs get confused, they can occasionally stop responding for > a good bit of time up until the point where the DRM driver manages to > do the right DPCD accesses to get it to start responding again. In a > worst case scenario however, this process can take upwards of 10+ > seconds. > > Currently we use

This is mainly for dropping interlaced modes on DP connectors if the GPU would otherwise display garbage or EVO timesout. It also adds experimental detection of the HDMI clock limit we currently hard limit depending on the GPU generation. Starting with GF110 GPUs, we can retrieve the limit directly from the GPU and may make the hdmimhz parameter obsolete. Testing this series with 2560x1440 or

...unc->sor->get_caps(disp, nv_encoder, ffs(dcbe->or) - 1); + nv_encoder->or = ffs(dcbe->or) - 1; + disp->core->func->sor->get_caps(disp, nv_encoder, nv_encoder->or); nv50_outp_dump_caps(drm, nv_encoder); if (dcbe->type == DCB_OUTPUT_DP) { @@ -2473,6 +2474,103 @@ nv50_display_fini(struct drm_device *dev, bool runtime, bool suspend) cancel_work_sync(&drm->hpd_work); } +static inline void +nv50_display_read_hw_or_state(struct drm_device *dev, struct nv50_disp *disp, + struct nouveau_encoder *outp) +{ + struct drm_crtc *crtc; + struct drm_connector_list_ite...

small update to my last version I sent out. Patches 3-6 are optional and should only improve detecting the max clocks for HDMI and DP, but they didn't underwent big testing and I am a bit concerned, that it might break detecting the DP limits on some boards. Karol Herbst (6): kms/nv50: move nv50_mstm out of the dp union in nouveau_encoder kms/nv50: reject interlaced modes if the hardware

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

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

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