[Nouveau] [Bug 111642] NV43 GeForce 6600 Nouveau is not stable on legacy hardware
https://bugs.freedesktop.org/show_bug.cgi?id=111642 --- Comment #16 from Vasili Pupkin --- I am using gnome 3.28.2 on xorg 1.20.4, wayland disappeared from the list on gdm login screen after recent upgrades -- You are receiving this mail because: You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH CI 2/2] drm/connector: Allow max possible encoders to attach to a connector
Currently we restrict the number of encoders that can be linked to
a connector to 3, increase it to match the maximum number of encoders
that can be initialized(32).
To more effiently do that lets switch from an array of encoder ids to
bitmask.
v2: Fixing missed return on amdgpu_dm_connector_to_encoder()
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Cc: Alex Deucher
Cc: dri-de...@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
Reviewed-by: Ville Syrjälä
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: José Roberto de Souza
---
.../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 23 +-
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 5 ++-
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 8 -
drivers/gpu/drm/drm_client_modeset.c | 3 +-
drivers/gpu/drm/drm_connector.c | 31 +--
drivers/gpu/drm/drm_crtc_helper.c | 9 --
drivers/gpu/drm/drm_probe_helper.c| 3 +-
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 7 ++---
drivers/gpu/drm/radeon/radeon_connectors.c| 27 ++--
include/drm/drm_connector.h | 18 +--
12 files changed, 55 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index ece55c8fa673..d8729285f731 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -217,11 +217,10 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder;
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
bool connected;
- int i;
best_encoder = connector_funcs->best_encoder(connector);
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if ((encoder == best_encoder) && (status ==
connector_status_connected))
connected = true;
else
@@ -236,9 +235,8 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
int encoder_type)
{
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type == encoder_type)
return encoder;
}
@@ -347,10 +345,9 @@ static struct drm_encoder *
amdgpu_connector_best_single_encoder(struct drm_connector *connector)
{
struct drm_encoder *encoder;
- int i;
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1065,9 +1062,8 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
/* find analog encoder */
if (amdgpu_connector->dac_load_detect) {
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DAC &&
encoder->encoder_type != DRM_MODE_ENCODER_TVDAC)
continue;
@@ -1117,9 +1113,8 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
{
struct amdgpu_connector *amdgpu_connector =
to_amdgpu_connector(connector);
struct drm_encoder *encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
if (amdgpu_connector->use_digital == true) {
if (encoder->encoder_type == DRM_MODE_ENCODER_TMDS)
return encoder;
@@ -1134,7 +1129,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
- drm_connector_for_each_possible_encoder(connector, encoder, i)
+ drm_connector_for_each_possible_encoder(connector, encoder)
return encoder;
return NULL;
@@ -1271,9 +1266,8 @@ u16
amdgpu_connector_encoder_get_dp_bridge_encoder_id(struct drm_connector *conn
{
struct drm_encoder *encoder;
struct amdgpu_encoder *amdgpu_encoder;
- int i;
- drm_connector_for_each_possible_encoder(connector, encoder, i) {
+ drm_connector_for_each_possible_encoder(connector, encoder) {
[Nouveau] [PATCH v2] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored by the atomic modesetting helpers. That being
said, this hook is completely broken anyway - it always returns the
first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to per-connector.
Changes since v1:
* Fix typo in documentation - imirkin
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b46be8a091e9..a3f350fdfa8c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
return >mstm->msto[head->base.index]->encoder;
}
-static struct drm_encoder *
-nv50_mstc_best_encoder(struct drm_connector *connector)
-{
- struct nv50_mstc *mstc = nv50_mstc(connector);
-
- return >mstm->msto[0]->encoder;
-}
-
static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
- .best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
.atomic_check = nv50_mstc_atomic_check,
};
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, 2019-09-13 at 18:20 -0400, Ilia Mirkin wrote:
> On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
> > When drm_connector_helper_funcs->atomic_best_encoder is defined,
> > ->best_encoder is ignored both by the atomic modesetting helpers. That
>
> By both the atomic modesetting helpers and ... (usually "both" implies 2
> things)
good catch, will fix and respin in a moment
>
> > being said, this hook is completely broken anyway - it always returns
> > the first msto for a given mstc, despite the fact it might already be in
> > use.
> >
> > So, just get rid of it. We'll need this in a moment anyway, when we make
> > mstos per-head as opposed to per-connector.
> >
> > Signed-off-by: Lyude Paul
> > ---
> > drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
> > 1 file changed, 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > index b46be8a091e9..a3f350fdfa8c 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
> > *connector,
> > return >mstm->msto[head->base.index]->encoder;
> > }
> >
> > -static struct drm_encoder *
> > -nv50_mstc_best_encoder(struct drm_connector *connector)
> > -{
> > - struct nv50_mstc *mstc = nv50_mstc(connector);
> > -
> > - return >mstm->msto[0]->encoder;
> > -}
> > -
> > static enum drm_mode_status
> > nv50_mstc_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > @@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
> > nv50_mstc_help = {
> > .get_modes = nv50_mstc_get_modes,
> > .mode_valid = nv50_mstc_mode_valid,
> > - .best_encoder = nv50_mstc_best_encoder,
> > .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> > .atomic_check = nv50_mstc_atomic_check,
> > };
> > --
> > 2.21.0
> >
--
Cheers,
Lyude Paul
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
On Fri, Sep 13, 2019 at 6:05 PM Lyude Paul wrote:
>
> When drm_connector_helper_funcs->atomic_best_encoder is defined,
> ->best_encoder is ignored both by the atomic modesetting helpers. That
By both the atomic modesetting helpers and ... (usually "both" implies 2 things)
> being said, this hook is completely broken anyway - it always returns
> the first msto for a given mstc, despite the fact it might already be in
> use.
>
> So, just get rid of it. We'll need this in a moment anyway, when we make
> mstos per-head as opposed to per-connector.
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
> 1 file changed, 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index b46be8a091e9..a3f350fdfa8c 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
> *connector,
> return >mstm->msto[head->base.index]->encoder;
> }
>
> -static struct drm_encoder *
> -nv50_mstc_best_encoder(struct drm_connector *connector)
> -{
> - struct nv50_mstc *mstc = nv50_mstc(connector);
> -
> - return >mstm->msto[0]->encoder;
> -}
> -
> static enum drm_mode_status
> nv50_mstc_mode_valid(struct drm_connector *connector,
> struct drm_display_mode *mode)
> @@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
> nv50_mstc_help = {
> .get_modes = nv50_mstc_get_modes,
> .mode_valid = nv50_mstc_mode_valid,
> - .best_encoder = nv50_mstc_best_encoder,
> .atomic_best_encoder = nv50_mstc_atomic_best_encoder,
> .atomic_check = nv50_mstc_atomic_check,
> };
> --
> 2.21.0
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4/4] drm/nouveau: dispnv50: Report possible_crtcs incorrectly on mstos, for now
This commit is seperate from the previous one to make it easier to revert in the future. Basically, while working on making MSTOs per-head as opposed to per-head-per-connector I discovered these lovely issues: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 https://gitlab.gnome.org/GNOME/mutter/issues/759 Note as well that Intel already has a temporary workaround for this in their kernel driver. So, unfortunately we need to follow suit to avoid causing a regression in userspace. Once these issues get fixed, this commit should be reverted. Signed-off-by: Lyude Paul Cc: Ville Syrjälä --- drivers/gpu/drm/nouveau/dispnv50/disp.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c b/drivers/gpu/drm/nouveau/dispnv50/disp.c index d23ac13763b5..f5ad20af0dd5 100644 --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -2366,6 +2366,18 @@ nv50_display_create(struct drm_device *dev) head->msto = NULL; goto out; } + + /* +* FIXME: This is a hack to workaround the following +* issues: +* +* https://gitlab.gnome.org/GNOME/mutter/issues/759 +* https://gitlab.freedesktop.org/xorg/xserver/merge_requests/277 +* +* Once these issues are closed, this should be +* removed +*/ + head->msto->encoder.possible_crtcs = crtcs; } } -- 2.21.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 3/4] drm/nouveau: dispnv50: Use less encoders by making mstos per-head
Currently, for every single MST capable DRM connector we create a set of
fake encoders, one for each possible head. Unfortunately this ends up
being a huge waste of encoders. While this currently isn't causing us
any problems, it's extremely close to doing so.
The ThinkPad P71 is a good example of this. Originally when trying to
figure out why nouveau was failing to load on this laptop, I discovered
it was because nouveau was creating too many encoders. This ended up
being because we were mistakenly creating MST encoders for the eDP port,
however we are still extremely close to hitting the encoder limit on
this machine as it exposes 1 eDP port and 5 DP ports, resulting in 31
encoders.
So while this fix didn't end up being necessary to fix the P71, we still
need to implement this so that we avoid hitting the encoder limit for
valid display configurations in the event that some machine with more
connectors then this becomes available. Plus, we don't want to let good
code go to waste :)
So, use less encoders by only creating one MSTO per head. Then, attach
each new MSTC to each MSTO which corresponds to a head that it's parent
DP port is capable of using. This brings the number of encoders we
register on the ThinkPad P71 from 31, down to just 15. Yay!
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 92 +++--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 2 +
drivers/gpu/drm/nouveau/dispnv50/head.c | 17 +++--
drivers/gpu/drm/nouveau/dispnv50/head.h | 3 +-
4 files changed, 68 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index a3f350fdfa8c..d23ac13763b5 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -650,7 +650,6 @@ struct nv50_mstm {
struct nouveau_encoder *outp;
struct drm_dp_mst_topology_mgr mgr;
- struct nv50_msto *msto[4];
bool modified;
bool disabled;
@@ -716,7 +715,6 @@ nv50_msto_cleanup(struct nv50_msto *msto)
drm_dp_mst_deallocate_vcpi(>mgr, mstc->port);
msto->mstc = NULL;
- msto->head = NULL;
msto->disabled = false;
}
@@ -846,7 +844,6 @@ nv50_msto_enable(struct drm_encoder *encoder)
mstm->outp->update(mstm->outp, head->base.index, armh, proto, depth);
- msto->head = head;
msto->mstc = mstc;
mstm->modified = true;
}
@@ -887,37 +884,40 @@ nv50_msto = {
.destroy = nv50_msto_destroy,
};
-static int
-nv50_msto_new(struct drm_device *dev, u32 heads, const char *name, int id,
- struct nv50_msto **pmsto)
+static struct nv50_msto *
+nv50_msto_new(struct drm_device *dev, struct nv50_head *head, int id)
{
struct nv50_msto *msto;
int ret;
- if (!(msto = *pmsto = kzalloc(sizeof(*msto), GFP_KERNEL)))
- return -ENOMEM;
+ msto = kzalloc(sizeof(*msto), GFP_KERNEL);
+ if (!msto)
+ return ERR_PTR(-ENOMEM);
ret = drm_encoder_init(dev, >encoder, _msto,
- DRM_MODE_ENCODER_DPMST, "%s-mst-%d", name, id);
+ DRM_MODE_ENCODER_DPMST, "mst-%d", id);
if (ret) {
- kfree(*pmsto);
- *pmsto = NULL;
- return ret;
+ kfree(msto);
+ return ERR_PTR(ret);
}
drm_encoder_helper_add(>encoder, _msto_help);
- msto->encoder.possible_crtcs = heads;
- return 0;
+ msto->encoder.possible_crtcs = drm_crtc_mask(>base.base);
+ msto->head = head;
+ return msto;
}
static struct drm_encoder *
nv50_mstc_atomic_best_encoder(struct drm_connector *connector,
struct drm_connector_state *connector_state)
{
- struct nv50_head *head = nv50_head(connector_state->crtc);
struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct drm_crtc *crtc = connector_state->crtc;
- return >mstm->msto[head->base.index]->encoder;
+ if (!(mstc->mstm->outp->dcb->heads & drm_crtc_mask(crtc)))
+ return NULL;
+
+ return _head(crtc)->msto->encoder;
}
static enum drm_mode_status
@@ -1036,8 +1036,9 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
const char *path, struct nv50_mstc **pmstc)
{
struct drm_device *dev = mstm->outp->base.base.dev;
+ struct drm_crtc *crtc;
struct nv50_mstc *mstc;
- int ret, i;
+ int ret;
if (!(mstc = *pmstc = kzalloc(sizeof(*mstc), GFP_KERNEL)))
return -ENOMEM;
@@ -1057,8 +1058,13 @@ nv50_mstc_new(struct nv50_mstm *mstm, struct
drm_dp_mst_port *port,
mstc->connector.funcs->reset(>connector);
nouveau_conn_attach_properties(>connector);
- for (i = 0; i < ARRAY_SIZE(mstm->msto) && mstm->msto[i]; i++)
- drm_connector_attach_encoder(>connector,
>msto[i]->encoder);
+
[Nouveau] [PATCH 1/4] drm/nouveau: dispnv50: Don't create MSTMs for eDP connectors
On the ThinkPad P71, we have one eDP connector exposed along with 5 DP
connectors, resulting in a total of 11 TMDS encoders. Since the GPU on
this system is also capable of MST, we create an additional 4 fake MST
encoders for each DP port. Unfortunately, we also do this for the eDP
port as well, resulting in:
1 eDP port: +1 TMDS encoder
+4 DPMST encoders
5 DP ports: +2 TMDS encoders
+4 DPMST encoders
*5 ports
== 35 encoders
Which breaks things, since DRM has a hard coded limit of 32 encoders.
So, fix this by not creating MSTMs for any eDP connectors. This brings
us down to 31 encoders, although we can do better.
This fixes driver probing for nouveau on the ThinkPad P71.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 307584107d77..b46be8a091e9 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1603,7 +1603,8 @@ nv50_sor_create(struct drm_connector *connector, struct
dcb_output *dcbe)
nv_encoder->aux = aux;
}
- if ((data = nvbios_dp_table(bios, , , , )) &&
+ if (nv_connector->type != DCB_CONNECTOR_eDP &&
+ (data = nvbios_dp_table(bios, , , , )) &&
ver >= 0x40 && (nvbios_rd08(bios, data + 0x08) & 0x04)) {
ret = nv50_mstm_new(nv_encoder, _connector->aux, 16,
nv_connector->base.base.id,
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 2/4] drm/nouveau: dispnv50: Remove nv50_mstc_best_encoder()
When drm_connector_helper_funcs->atomic_best_encoder is defined,
->best_encoder is ignored both by the atomic modesetting helpers. That
being said, this hook is completely broken anyway - it always returns
the first msto for a given mstc, despite the fact it might already be in
use.
So, just get rid of it. We'll need this in a moment anyway, when we make
mstos per-head as opposed to per-connector.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 -
1 file changed, 9 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index b46be8a091e9..a3f350fdfa8c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -920,14 +920,6 @@ nv50_mstc_atomic_best_encoder(struct drm_connector
*connector,
return >mstm->msto[head->base.index]->encoder;
}
-static struct drm_encoder *
-nv50_mstc_best_encoder(struct drm_connector *connector)
-{
- struct nv50_mstc *mstc = nv50_mstc(connector);
-
- return >mstm->msto[0]->encoder;
-}
-
static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -990,7 +982,6 @@ static const struct drm_connector_helper_funcs
nv50_mstc_help = {
.get_modes = nv50_mstc_get_modes,
.mode_valid = nv50_mstc_mode_valid,
- .best_encoder = nv50_mstc_best_encoder,
.atomic_best_encoder = nv50_mstc_atomic_best_encoder,
.atomic_check = nv50_mstc_atomic_check,
};
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH v2 24/27] drm/amdgpu/dm: Resume short HPD IRQs before resuming MST topology
On Tue, Sep 3, 2019 at 4:49 PM Lyude Paul wrote:
>
> Since we're going to be reprobing the entire topology state on resume
> now using sideband transactions, we need to ensure that we actually have
> short HPD irqs enabled before calling drm_dp_mst_topology_mgr_resume().
> So, do that.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
Acked-by: Alex Deucher
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 73630e2940d4..4d3c8bff77da 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -1185,15 +1185,15 @@ static int dm_resume(void *handle)
> /* program HPD filter */
> dc_resume(dm->dc);
>
> - /* On resume we need to rewrite the MSTM control bits to enamble
> MST*/
> - s3_handle_mst(ddev, false);
> -
> /*
> * early enable HPD Rx IRQ, should be done before set mode as short
> * pulse interrupts are used for MST
> */
> amdgpu_dm_irq_resume_early(adev);
>
> + /* On resume we need to rewrite the MSTM control bits to enamble
> MST*/
> + s3_handle_mst(ddev, false);
> +
> /* Do detection*/
> drm_connector_list_iter_begin(ddev, );
> drm_for_each_connector_iter(connector, ) {
> --
> 2.21.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 110500] X-Server crashes - GL error: GL_OUT_OF_MEMORY in glTexSubImage
https://bugs.freedesktop.org/show_bug.cgi?id=110500 Amy Jones changed: What|Removed |Added Version|git |11.1 URL||http://essays-writers.net/w ||rite-my-book-review.html Component|Drivers/DRI/nouveau |Drivers/DRI/v3d Assignee|nouveau@lists.freedesktop.o |e...@anholt.net |rg | QA Contact|nouveau@lists.freedesktop.o | |rg | -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug.___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:09:22AM -0400, Ilia Mirkin wrote: On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: >> > Hi Greg, >> > >> > This feels like it's missing a From: line. >> > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 >> > Author: Lyude Paul >> > Date: Mon Jan 28 16:03:50 2019 -0500 >> > >> >drm/nouveau: Don't WARN_ON VCPI allocation failures >> > >> > Is this an artifact of your notification-of-patches process and I >> > never noticed before, or was the patch ingested incorrectly? >> >> It was always like this for patches that came through me. Greg's script >> generates an explicit "From:" line in the patch, but I never saw the >> value in that since git does the right thing by looking at the "From:" >> line in the mail header. >> >> The right thing is being done in stable-rc and for the releases. For >> your example here, this is how it looks like in the stable-rc tree: >> >> commit bdcc885be68289a37d0d063cd94390da81fd8178 >> Author: Lyude Paul >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 >> Commit: Greg Kroah-Hartman >> CommitDate: Fri Sep 13 14:05:29 2019 +0100 >> >>drm/nouveau: Don't WARN_ON VCPI allocation failures > >Yeah, we should fix your scripts to put the explicit From: line in here >as we are dealing with patches in this format and it causes confusion at >times (like now.) It's not the first time and that's why I added those >lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different? It shouldn't. It's just a mismatch between our two somewhat seperate workflow. Technically it's Greg who needs to be adding that line since the patches I have in stable-queue correctly state the author, and it only goes wrong when they're being formatted into mails sent for the -rc cycles. But yes, thanks for pointing it out, I'll go add it in the scripts. -- Thanks, Sasha ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 04:10:51PM +0100, Greg Kroah-Hartman wrote: On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > Hi Greg, > > > > > > This feels like it's missing a From: line. > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > Author: Lyude Paul > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > Is this an artifact of your notification-of-patches process and I > > > never noticed before, or was the patch ingested incorrectly? > > > > It was always like this for patches that came through me. Greg's script > > generates an explicit "From:" line in the patch, but I never saw the > > value in that since git does the right thing by looking at the "From:" > > line in the mail header. > > > > The right thing is being done in stable-rc and for the releases. For > > your example here, this is how it looks like in the stable-rc tree: > > > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > > Author: Lyude Paul > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > > Commit: Greg Kroah-Hartman > > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > Yeah, we should fix your scripts to put the explicit From: line in here > as we are dealing with patches in this format and it causes confusion at > times (like now.) It's not the first time and that's why I added those > lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch. Right right, I agree this is wrong and I'll fix it. I'm just concerned about what exactly you are doing with the -rc patches to actually care about this :) -- Thanks, Sasha ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01:11AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > > > Hi Greg, > > > > > > > > This feels like it's missing a From: line. > > > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > > Author: Lyude Paul > > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > > > Is this an artifact of your notification-of-patches process and I > > > > never noticed before, or was the patch ingested incorrectly? > > > > > > It was always like this for patches that came through me. Greg's script > > > generates an explicit "From:" line in the patch, but I never saw the > > > value in that since git does the right thing by looking at the "From:" > > > line in the mail header. > > > > > > The right thing is being done in stable-rc and for the releases. For > > > your example here, this is how it looks like in the stable-rc tree: > > > > > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > > > Author: Lyude Paul > > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > > > Commit: Greg Kroah-Hartman > > > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > > > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Yeah, we should fix your scripts to put the explicit From: line in here > > as we are dealing with patches in this format and it causes confusion at > > times (like now.) It's not the first time and that's why I added those > > lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? On the emails we send out, it has inproper author information which can cause confusion that the sender of the email (i.e. me) is somehow saying that they are the author of the patch. thanks, greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: > >On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > >> On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >> > Hi Greg, > >> > > >> > This feels like it's missing a From: line. > >> > > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 > >> > Author: Lyude Paul > >> > Date: Mon Jan 28 16:03:50 2019 -0500 > >> > > >> >drm/nouveau: Don't WARN_ON VCPI allocation failures > >> > > >> > Is this an artifact of your notification-of-patches process and I > >> > never noticed before, or was the patch ingested incorrectly? > >> > >> It was always like this for patches that came through me. Greg's script > >> generates an explicit "From:" line in the patch, but I never saw the > >> value in that since git does the right thing by looking at the "From:" > >> line in the mail header. > >> > >> The right thing is being done in stable-rc and for the releases. For > >> your example here, this is how it looks like in the stable-rc tree: > >> > >> commit bdcc885be68289a37d0d063cd94390da81fd8178 > >> Author: Lyude Paul > >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > >> Commit: Greg Kroah-Hartman > >> CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >> > >>drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Yeah, we should fix your scripts to put the explicit From: line in here > >as we are dealing with patches in this format and it causes confusion at > >times (like now.) It's not the first time and that's why I added those > >lines to the patches. > > Heh, didn't think anyone cared about this scenario for the stable-rc > patches. > > I'll go add it. > > But... why do you actually care? Just a hygiene thing. Everyone else sends patches the normal way, with accurate attribution. Why should stable be different? (I was surprised to see Greg contributing to nouveau when I first saw the patch. But then realized it was the stable ingestion notification.) -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 03:54:56PM +0100, Greg Kroah-Hartman wrote: On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > Hi Greg, > > This feels like it's missing a From: line. > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > Author: Lyude Paul > Date: Mon Jan 28 16:03:50 2019 -0500 > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > Is this an artifact of your notification-of-patches process and I > never noticed before, or was the patch ingested incorrectly? It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header. The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree: commit bdcc885be68289a37d0d063cd94390da81fd8178 Author: Lyude Paul AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman CommitDate: Fri Sep 13 14:05:29 2019 +0100 drm/nouveau: Don't WARN_ON VCPI allocation failures Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches. Heh, didn't think anyone cared about this scenario for the stable-rc patches. I'll go add it. But... why do you actually care? -- Thanks, Sasha ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46:27AM -0400, Sasha Levin wrote: > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > > Hi Greg, > > > > This feels like it's missing a From: line. > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > Author: Lyude Paul > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Is this an artifact of your notification-of-patches process and I > > never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. > > The right thing is being done in stable-rc and for the releases. For > your example here, this is how it looks like in the stable-rc tree: > > commit bdcc885be68289a37d0d063cd94390da81fd8178 > Author: Lyude Paul > AuthorDate: Mon Jan 28 16:03:50 2019 -0500 > Commit: Greg Kroah-Hartman > CommitDate: Fri Sep 13 14:05:29 2019 +0100 > >drm/nouveau: Don't WARN_ON VCPI allocation failures Yeah, we should fix your scripts to put the explicit From: line in here as we are dealing with patches in this format and it causes confusion at times (like now.) It's not the first time and that's why I added those lines to the patches. thanks, greg k-h ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin wrote: > > On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: > >Hi Greg, > > > >This feels like it's missing a From: line. > > > >commit b513a18cf1d705bd04efd91c417e79e4938be093 > >Author: Lyude Paul > >Date: Mon Jan 28 16:03:50 2019 -0500 > > > >drm/nouveau: Don't WARN_ON VCPI allocation failures > > > >Is this an artifact of your notification-of-patches process and I > >never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit "From:" line in the patch, but I never saw the > value in that since git does the right thing by looking at the "From:" > line in the mail header. That's right -- the email's From header gets used in the case of no explicit From in the email body. But Greg is sending the emails From: Greg, so if I were to ingest that email, I would end up with a patch From: Greg, not From: Lyude as it ought to be. Cheers, -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
On Fri, Sep 13, 2019 at 09:33:36AM -0400, Ilia Mirkin wrote: Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch, but I never saw the value in that since git does the right thing by looking at the "From:" line in the mail header. The right thing is being done in stable-rc and for the releases. For your example here, this is how it looks like in the stable-rc tree: commit bdcc885be68289a37d0d063cd94390da81fd8178 Author: Lyude Paul AuthorDate: Mon Jan 28 16:03:50 2019 -0500 Commit: Greg Kroah-Hartman CommitDate: Fri Sep 13 14:05:29 2019 +0100 drm/nouveau: Don't WARN_ON VCPI allocation failures -- Thanks, Sasha ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
Hi Greg,
This feels like it's missing a From: line.
commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul
Date: Mon Jan 28 16:03:50 2019 -0500
drm/nouveau: Don't WARN_ON VCPI allocation failures
Is this an artifact of your notification-of-patches process and I
never noticed before, or was the patch ingested incorrectly?
Cheers,
-ilia
On Fri, Sep 13, 2019 at 9:16 AM Greg Kroah-Hartman
wrote:
>
> [ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
>
> This is much louder then we want. VCPI allocation failures are quite
> normal, since they will happen if any part of the modesetting process is
> interrupted by removing the DP MST topology in question. So just print a
> debugging message on VCPI failures instead.
>
> Signed-off-by: Lyude Paul
> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
> multi-stream")
> Cc: Ben Skeggs
> Cc: dri-de...@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: # v4.10+
> Signed-off-by: Ben Skeggs
> Signed-off-by: Sasha Levin
> ---
> drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> index f889d41a281fa..5e01bfb69d7a3 100644
> --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> @@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
>
> slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
> r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn,
> slots);
> - WARN_ON(!r);
> + if (!r)
> + DRM_DEBUG_KMS("Failed to allocate VCPI\n");
>
> if (!mstm->links++)
> nv50_outp_acquire(mstm->outp);
> --
> 2.20.1
>
>
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH 4.19 125/190] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
[ Upstream commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 ] On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M variant, the BIOS does not always reset the secondary Nvidia GPU during reboot if the laptop is configured in Hybrid Graphics mode. The reason is unknown, but the following steps and possibly a good bit of patience will reproduce the issue: 1. Boot up the laptop normally in Hybrid Graphics mode 2. Make sure nouveau is loaded and that the GPU is awake 3. Allow the Nvidia GPU to runtime suspend itself after being idle 4. Reboot the machine, the more sudden the better (e.g. sysrq-b may help) 5. If nouveau loads up properly, reboot the machine again and go back to step 2 until you reproduce the issue This results in some very strange behavior: the GPU will be left in exactly the same state it was in when the previously booted kernel started the reboot. This has all sorts of bad side effects: for starters, this completely breaks nouveau starting with a mysterious EVO channel failure that happens well before we've actually used the EVO channel for anything: nouveau :01:00.0: disp: chid 0 mthd data 0400 1000 0002 This causes a timeout trying to bring up the GR ctx: nouveau :01:00.0: timeout WARNING: CPU: 0 PID: 12 at drivers/gpu/drm/nouveau/nvkm/engine/gr/ctxgf100.c:1547 gf100_grctx_generate+0x7b2/0x850 [nouveau] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET82W (1.55 ) 12/18/2018 Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] ... nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1) nouveau :01:00.0: fifo: fault 01 [WRITE] at 8000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [00 unknown] The GPU never manages to recover. Booting without loading nouveau causes issues as well, since the GPU starts sending spurious interrupts that cause other device's IRQs to get disabled by the kernel: irq 16: nobody cared (try booting with the "irqpoll" option) ... handlers: [<7faa9e99>] i801_isr [i2c_i801] Disabling IRQ #16 ... serio: RMI4 PS/2 pass-through port at rmi4-00.fn03 i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110). i801_smbus :00:1f.4: Timeout waiting for interrupt! i801_smbus :00:1f.4: Transaction timeout rmi4_physical rmi4-00: rmi_driver_set_irq_bits: Failed to change enabled interrupts! This causes the touchpad and sometimes other things to get disabled. Since this happens without nouveau, we can't fix this problem from nouveau itself. Add a PCI quirk for the specific P50 variant of this GPU. Make sure the GPU is advertising NoReset- so we don't reset the GPU when the machine is in Dedicated graphics mode (where the GPU being initialized by the BIOS is normal and expected). Map the GPU MMIO space and read the magic 0x2240c register, which will have bit 1 set if the device was POSTed during a previous boot. Once we've confirmed all of this, reset the GPU and re-disable it - bringing it back to a healthy state. Link: https://bugzilla.kernel.org/show_bug.cgi?id=203003 Link: https://lore.kernel.org/lkml/20190212220230.1568-1-ly...@redhat.com Signed-off-by: Lyude Paul Signed-off-by: Bjorn Helgaas Cc: nouveau@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: Karol Herbst Cc: Ben Skeggs Cc: sta...@vger.kernel.org Signed-off-by: Sasha Levin --- drivers/pci/quirks.c | 58 1 file changed, 58 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 6cda8b7ecc821..311f8a33e62ff 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5116,3 +5116,61 @@ SWITCHTEC_QUIRK(0x8573); /* PFXI 48XG3 */ SWITCHTEC_QUIRK(0x8574); /* PFXI 64XG3 */ SWITCHTEC_QUIRK(0x8575); /* PFXI 80XG3 */ SWITCHTEC_QUIRK(0x8576); /* PFXI 96XG3 */ + +/* + * On Lenovo Thinkpad P50 SKUs with a Nvidia Quadro M1000M, the BIOS does + * not always reset the secondary Nvidia GPU between reboots if the system + * is configured to use Hybrid Graphics mode. This results in the GPU + * being left in whatever state it was in during the *previous* boot, which + * causes spurious interrupts from the GPU, which in turn causes us to + * disable the wrong IRQ and end up breaking the touchpad. Unsurprisingly, + * this also completely breaks nouveau. + * + * Luckily, it seems a simple reset of the Nvidia GPU brings it back to a + * clean state and fixes all these issues. + * + * When the machine is configured in Dedicated display mode, the issue + * doesn't occur. Fortunately the GPU advertises NoReset+ when in this + * mode, so we can detect that and avoid resetting it. + */ +static void
[Nouveau] [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures
[ Upstream commit b513a18cf1d705bd04efd91c417e79e4938be093 ]
This is much louder then we want. VCPI allocation failures are quite
normal, since they will happen if any part of the modesetting process is
interrupted by removing the DP MST topology in question. So just print a
debugging message on VCPI failures instead.
Signed-off-by: Lyude Paul
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2
multi-stream")
Cc: Ben Skeggs
Cc: dri-de...@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: # v4.10+
Signed-off-by: Ben Skeggs
Signed-off-by: Sasha Levin
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index f889d41a281fa..5e01bfb69d7a3 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder)
slots = drm_dp_find_vcpi_slots(>mgr, mstc->pbn);
r = drm_dp_mst_allocate_vcpi(>mgr, mstc->port, mstc->pbn, slots);
- WARN_ON(!r);
+ if (!r)
+ DRM_DEBUG_KMS("Failed to allocate VCPI\n");
if (!mstm->links++)
nv50_outp_acquire(mstm->outp);
--
2.20.1
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 3/4] pci: set the pcie link speed to 8.0 when suspending
Apperantly things go south if we suspend the device with a PCIe link speed
set to 2.5. Fixes runtime suspend on my gp107.
This all looks like some bug inside the pci subsystem and I would prefer a
fix there instead of nouveau, but maybe there is no real nice way of doing
that outside of drivers?
v2: squashed together patch 4 and 5
v3: only restore pcie speed on machines with runpm
add NvRunpmWorkaround config option to disable the workaround
v4: only run the code on suspend
always put the card into 8.0 mode, not what nouveau detected on load
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul (v2)
---
drm/nouveau/include/nvkm/core/device.h | 2 ++
drm/nouveau/include/nvkm/subdev/pci.h | 3 ++-
drm/nouveau/nouveau_drm.c | 1 +
drm/nouveau/nvkm/subdev/clk/base.c | 2 +-
drm/nouveau/nvkm/subdev/pci/base.c | 2 ++
drm/nouveau/nvkm/subdev/pci/pcie.c | 27 ++
drm/nouveau/nvkm/subdev/pci/priv.h | 1 +
7 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/drm/nouveau/include/nvkm/core/device.h
b/drm/nouveau/include/nvkm/core/device.h
index 6d55cd047..4fb3f972f 100644
--- a/drm/nouveau/include/nvkm/core/device.h
+++ b/drm/nouveau/include/nvkm/core/device.h
@@ -125,6 +125,8 @@ struct nvkm_device {
u8 chiprev;
u32 crystal;
+ bool has_runpm;
+
struct {
struct notifier_block nb;
} acpi;
diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
b/drm/nouveau/include/nvkm/subdev/pci.h
index b29101e48..7245513d9 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -52,6 +52,7 @@ int gk104_pci_new(struct nvkm_device *, int, struct nvkm_pci
**);
int gp100_pci_new(struct nvkm_device *, int, struct nvkm_pci **);
/* pcie functions */
-int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width);
+int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width,
+ bool save);
enum nvkm_pcie_speed nvkm_pcie_get_speed(struct nvkm_pci *);
#endif
diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 3d32afe8a..78d55c525 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -676,6 +676,7 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
if (nouveau_atomic)
driver_pci.driver_features |= DRIVER_ATOMIC;
+ device->has_runpm = nouveau_pmops_runtime();
drm_dev = drm_dev_alloc(_pci, >dev);
if (IS_ERR(drm_dev)) {
diff --git a/drm/nouveau/nvkm/subdev/clk/base.c
b/drm/nouveau/nvkm/subdev/clk/base.c
index ba6a868d4..e30e77453 100644
--- a/drm/nouveau/nvkm/subdev/clk/base.c
+++ b/drm/nouveau/nvkm/subdev/clk/base.c
@@ -277,7 +277,7 @@ nvkm_pstate_prog(struct nvkm_clk *clk, int pstatei)
nvkm_debug(subdev, "setting performance state %d\n", pstatei);
clk->pstate = pstatei;
- nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width);
+ nvkm_pcie_set_link(pci, pstate->pcie_speed, pstate->pcie_width, true);
if (fb && fb->ram && fb->ram->func->calc) {
struct nvkm_ram *ram = fb->ram;
diff --git a/drm/nouveau/nvkm/subdev/pci/base.c
b/drm/nouveau/nvkm/subdev/pci/base.c
index ee2431a78..c9b60ef76 100644
--- a/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drm/nouveau/nvkm/subdev/pci/base.c
@@ -90,6 +90,8 @@ nvkm_pci_fini(struct nvkm_subdev *subdev, bool suspend)
if (pci->agp.bridge)
nvkm_agp_fini(pci);
+ else if (pci_is_pcie(pci->pdev))
+ nvkm_pcie_fini(pci, suspend);
return 0;
}
diff --git a/drm/nouveau/nvkm/subdev/pci/pcie.c
b/drm/nouveau/nvkm/subdev/pci/pcie.c
index b4203ff1a..5cab4a240 100644
--- a/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -23,6 +23,8 @@
*/
#include "priv.h"
+#include
+
static char *nvkm_pcie_speeds[] = {
"2.5GT/s",
"5.0GT/s",
@@ -106,11 +108,25 @@ nvkm_pcie_init(struct nvkm_pci *pci)
pci->func->pcie.init(pci);
if (pci->pcie.speed != -1)
- nvkm_pcie_set_link(pci, pci->pcie.speed, pci->pcie.width);
+ nvkm_pcie_set_link(pci, pci->pcie.speed,
+ pci->pcie.width, false);
return 0;
}
+int
+nvkm_pcie_fini(struct nvkm_pci *pci, bool suspend)
+{
+ struct nvkm_device *device = pci->subdev.device;
+ if (!device->has_runpm || !suspend)
+ return 0;
+
+ if (!nvkm_boolopt(device->cfgopt, "NvRunpmWorkaround", true))
+ return 0;
+
+ return nvkm_pcie_set_link(pci, NVKM_PCIE_SPEED_8_0, 16, false);
+}
+
void
nvkm_pcie_force_aspm_off(struct nvkm_pci *pci, bool status)
{
@@ -120,7 +136,8 @@ nvkm_pcie_force_aspm_off(struct nvkm_pci *pci, bool status)
}
int
-nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
+nvkm_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8
[Nouveau] [PATCH v4 0/4] add PCIe workaround to fix runpm on laptops
not much changed since the last time I sent those patches out, but there are a couple of annoying bug fixes, which users would probably never hit unless they do rmmod/modprobe nouveau cycles. Biggest change is that I force the link to a 8.0 speed rather than the speed the GPU came up with. Also this series depends on the PCIe improvement patches I sent out recently. Karol Herbst (4): pci: enable pcie link changes for pascal pci: add nvkm_pcie_get_speed pci: set the pcie link speed to 8.0 when suspending drm: abort runtime suspend if we hit an error drm/nouveau/include/nvkm/core/device.h | 2 ++ drm/nouveau/include/nvkm/subdev/pci.h | 4 ++- drm/nouveau/nouveau_drm.c | 6 + drm/nouveau/nvkm/subdev/clk/base.c | 2 +- drm/nouveau/nvkm/subdev/pci/base.c | 2 ++ drm/nouveau/nvkm/subdev/pci/gk104.c| 8 +++--- drm/nouveau/nvkm/subdev/pci/gp100.c| 11 drm/nouveau/nvkm/subdev/pci/pcie.c | 35 +++--- drm/nouveau/nvkm/subdev/pci/priv.h | 6 + 9 files changed, 66 insertions(+), 10 deletions(-) -- 2.21.0 ___ Nouveau mailing list Nouveau@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 1/4] pci: enable pcie link changes for pascal
v2: add force disable ASPM func pointer
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul (v1)
---
drm/nouveau/nvkm/subdev/pci/gk104.c | 8
drm/nouveau/nvkm/subdev/pci/gp100.c | 11 +++
drm/nouveau/nvkm/subdev/pci/priv.h | 5 +
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drm/nouveau/nvkm/subdev/pci/gk104.c
b/drm/nouveau/nvkm/subdev/pci/gk104.c
index 804ef017f..61c4e76e8 100644
--- a/drm/nouveau/nvkm/subdev/pci/gk104.c
+++ b/drm/nouveau/nvkm/subdev/pci/gk104.c
@@ -25,7 +25,7 @@
#include
-static int
+int
gk104_pcie_version_supported(struct nvkm_pci *pci)
{
return (nvkm_rd32(pci->subdev.device, 0x8c1c0) & 0x4) == 0x4 ? 2 : 1;
@@ -110,7 +110,7 @@ gk104_pcie_lnkctl_speed(struct nvkm_pci *pci)
return -1;
}
-static enum nvkm_pcie_speed
+enum nvkm_pcie_speed
gk104_pcie_max_speed(struct nvkm_pci *pci)
{
u32 max_speed = nvkm_rd32(pci->subdev.device, 0x8c1c0) & 0x30;
@@ -156,7 +156,7 @@ gk104_pcie_set_link_speed(struct nvkm_pci *pci, enum
nvkm_pcie_speed speed)
return 0;
}
-static int
+int
gk104_pcie_init(struct nvkm_pci * pci)
{
enum nvkm_pcie_speed lnkctl_speed, max_speed, cap_speed;
@@ -188,7 +188,7 @@ gk104_pcie_init(struct nvkm_pci * pci)
return 0;
}
-static int
+int
gk104_pcie_set_link(struct nvkm_pci *pci, enum nvkm_pcie_speed speed, u8 width)
{
struct nvkm_subdev *subdev = >subdev;
diff --git a/drm/nouveau/nvkm/subdev/pci/gp100.c
b/drm/nouveau/nvkm/subdev/pci/gp100.c
index 82c5234a0..163233f16 100644
--- a/drm/nouveau/nvkm/subdev/pci/gp100.c
+++ b/drm/nouveau/nvkm/subdev/pci/gp100.c
@@ -35,6 +35,17 @@ gp100_pci_func = {
.wr08 = nv40_pci_wr08,
.wr32 = nv40_pci_wr32,
.msi_rearm = gp100_pci_msi_rearm,
+
+ .pcie.init = gk104_pcie_init,
+ .pcie.set_link = gk104_pcie_set_link,
+
+ .pcie.max_speed = gk104_pcie_max_speed,
+ .pcie.cur_speed = g84_pcie_cur_speed,
+
+ .pcie.set_version = gf100_pcie_set_version,
+ .pcie.version = gf100_pcie_version,
+ .pcie.version_supported = gk104_pcie_version_supported,
+ .pcie.force_aspm_off = g84_pcie_force_aspm_off,
};
int
diff --git a/drm/nouveau/nvkm/subdev/pci/priv.h
b/drm/nouveau/nvkm/subdev/pci/priv.h
index c6a9ef330..82c78befa 100644
--- a/drm/nouveau/nvkm/subdev/pci/priv.h
+++ b/drm/nouveau/nvkm/subdev/pci/priv.h
@@ -56,6 +56,11 @@ int gf100_pcie_cap_speed(struct nvkm_pci *);
int gf100_pcie_init(struct nvkm_pci *);
int gf100_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8);
+int gk104_pcie_init(struct nvkm_pci *);
+int gk104_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width);
+enum nvkm_pcie_speed gk104_pcie_max_speed(struct nvkm_pci *);
+int gk104_pcie_version_supported(struct nvkm_pci *);
+
int nvkm_pcie_oneinit(struct nvkm_pci *);
int nvkm_pcie_init(struct nvkm_pci *);
#endif
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 4/4] drm: abort runtime suspend if we hit an error
Signed-off-by: Karol Herbst
---
drm/nouveau/nouveau_drm.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drm/nouveau/nouveau_drm.c b/drm/nouveau/nouveau_drm.c
index 78d55c525..6a6819d96 100644
--- a/drm/nouveau/nouveau_drm.c
+++ b/drm/nouveau/nouveau_drm.c
@@ -911,6 +911,7 @@ nouveau_pmops_runtime_suspend(struct device *dev)
{
struct pci_dev *pdev = to_pci_dev(dev);
struct drm_device *drm_dev = pci_get_drvdata(pdev);
+ struct nouveau_drm *drm = nouveau_drm(drm_dev);
int ret;
if (!nouveau_pmops_runtime()) {
@@ -920,6 +921,10 @@ nouveau_pmops_runtime_suspend(struct device *dev)
nouveau_switcheroo_optimus_dsm();
ret = nouveau_do_suspend(drm_dev, true);
+ if (ret) {
+ NV_ERROR(drm, "suspend failed with: %d\n", ret);
+ return ret;
+ }
pci_save_state(pdev);
pci_disable_device(pdev);
pci_ignore_hotplug(pdev);
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH v4 2/4] pci: add nvkm_pcie_get_speed
v2: fixed compilation error
Signed-off-by: Karol Herbst
Reviewed-by: Lyude Paul
---
drm/nouveau/include/nvkm/subdev/pci.h | 1 +
drm/nouveau/nvkm/subdev/pci/pcie.c| 8
2 files changed, 9 insertions(+)
diff --git a/drm/nouveau/include/nvkm/subdev/pci.h
b/drm/nouveau/include/nvkm/subdev/pci.h
index 4803a4fad..b29101e48 100644
--- a/drm/nouveau/include/nvkm/subdev/pci.h
+++ b/drm/nouveau/include/nvkm/subdev/pci.h
@@ -53,4 +53,5 @@ int gp100_pci_new(struct nvkm_device *, int, struct nvkm_pci
**);
/* pcie functions */
int nvkm_pcie_set_link(struct nvkm_pci *, enum nvkm_pcie_speed, u8 width);
+enum nvkm_pcie_speed nvkm_pcie_get_speed(struct nvkm_pci *);
#endif
diff --git a/drm/nouveau/nvkm/subdev/pci/pcie.c
b/drm/nouveau/nvkm/subdev/pci/pcie.c
index 354ac4c85..b4203ff1a 100644
--- a/drm/nouveau/nvkm/subdev/pci/pcie.c
+++ b/drm/nouveau/nvkm/subdev/pci/pcie.c
@@ -177,3 +177,11 @@ nvkm_pcie_set_link(struct nvkm_pci *pci, enum
nvkm_pcie_speed speed, u8 width)
return ret;
}
+
+enum nvkm_pcie_speed
+nvkm_pcie_get_speed(struct nvkm_pci *pci)
+{
+ if (!pci || !pci_is_pcie(pci->pdev) || !pci->func->pcie.cur_speed)
+ return -ENODEV;
+ return pci->func->pcie.cur_speed(pci);
+}
--
2.21.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
