[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Greg Kroah-Hartman]

[ 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 <lyude@redhat.com>
Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: dri-devel@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.10+
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@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 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(&mstm->mgr, mstc->pbn);
 	r = drm_dp_mst_allocate_vcpi(&mstm->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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Ilia Mirkin]

Hi Greg,

This feels like it's missing a From: line.

commit b513a18cf1d705bd04efd91c417e79e4938be093
Author: Lyude Paul <lyude@redhat.com>
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
<gregkh@linuxfoundation.org> 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 <lyude@redhat.com>
> Fixes: f479c0ba4a17 ("drm/nouveau/kms/nv50: initial support for DP 1.2 multi-stream")
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: nouveau@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v4.10+
> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
> Signed-off-by: Sasha Levin <sashal@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 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(&mstm->mgr, mstc->pbn);
>         r = drm_dp_mst_allocate_vcpi(&mstm->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-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Sasha Levin]

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 <lyude@redhat.com>
>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 <lyude@redhat.com>
AuthorDate: Mon Jan 28 16:03:50 2019 -0500
Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CommitDate: Fri Sep 13 14:05:29 2019 +0100

    drm/nouveau: Don't WARN_ON VCPI allocation failures

--
Thanks,
Sasha

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Ilia Mirkin]

On Fri, Sep 13, 2019 at 10:46 AM Sasha Levin <sashal@kernel.org> 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 <lyude@redhat.com>
> >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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Greg Kroah-Hartman]

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 <lyude@redhat.com>
> > 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 <lyude@redhat.com>
> AuthorDate: Mon Jan 28 16:03:50 2019 -0500
> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> 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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Sasha Levin]

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 <lyude@redhat.com>
>> > 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 <lyude@redhat.com>
>> AuthorDate: Mon Jan 28 16:03:50 2019 -0500
>> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> 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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Ilia Mirkin]

On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin <sashal@kernel.org> 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 <lyude@redhat.com>
> >> > 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 <lyude@redhat.com>
> >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500
> >> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >> 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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Sasha Levin]

On Fri, Sep 13, 2019 at 11:09:22AM -0400, Ilia Mirkin wrote:
>On Fri, Sep 13, 2019 at 11:01 AM Sasha Levin <sashal@kernel.org> 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 <lyude@redhat.com>
>> >> > 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 <lyude@redhat.com>
>> >> AuthorDate: Mon Jan 28 16:03:50 2019 -0500
>> >> Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> >> 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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Greg Kroah-Hartman]

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 <lyude@redhat.com>
> > > > 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 <lyude@redhat.com>
> > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500
> > > Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > 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

Re: [PATCH 4.19 092/190] drm/nouveau: Dont WARN_ON VCPI allocation failures

[Sasha Levin]

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 <lyude@redhat.com>
>> > > > 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 <lyude@redhat.com>
>> > > AuthorDate: Mon Jan 28 16:03:50 2019 -0500
>> > > Commit:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> > > 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

[PATCH 4.19 125/190] PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary

[Greg Kroah-Hartman]

[ 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 0000:01:00.0: disp: chid 0 mthd 0000 data 00000400 00001000 00000002

This causes a timeout trying to bring up the GR ctx:

  nouveau 0000: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 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
  nouveau 0000:01:00.0: gr: wait for idle timeout (en: 1, ctxsw: 0, busy: 1)
  nouveau 0000:01:00.0: fifo: fault 01 [WRITE] at 0000000000008000 engine 00 [GR] client 15 [HUB/SCC_NB] reason c4 [] on channel -1 [0000000000 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:
  [<000000007faa9e99>] i801_isr [i2c_i801]
  Disabling IRQ #16
  ...
  serio: RMI4 PS/2 pass-through port at rmi4-00.fn03
  i801_smbus 0000:00:1f.4: Timeout waiting for interrupt!
  i801_smbus 0000:00:1f.4: Transaction timeout
  rmi4_f03 rmi4-00.fn03: rmi_f03_pt_write: Failed to write to F03 TX register (-110).
  i801_smbus 0000:00:1f.4: Timeout waiting for interrupt!
  i801_smbus 0000: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-lyude@redhat.com
Signed-off-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: nouveau@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Cc: Karol Herbst <kherbst@redhat.com>
Cc: Ben Skeggs <skeggsb@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
 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 quirk_reset_lenovo_thinkpad_p50_nvgpu(struct pci_dev *pdev)
+{
+	void __iomem *map;
+	int ret;
+
+	if (pdev->subsystem_vendor != PCI_VENDOR_ID_LENOVO ||
+	    pdev->subsystem_device != 0x222e ||
+	    !pdev->reset_fn)
+		return;
+
+	if (pci_enable_device_mem(pdev))
+		return;
+
+	/*
+	 * Based on nvkm_device_ctor() in
+	 * drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+	 */
+	map = pci_iomap(pdev, 0, 0x23000);
+	if (!map) {
+		pci_err(pdev, "Can't map MMIO space\n");
+		goto out_disable;
+	}
+
+	/*
+	 * Make sure the GPU looks like it's been POSTed before resetting
+	 * it.
+	 */
+	if (ioread32(map + 0x2240c) & 0x2) {
+		pci_info(pdev, FW_BUG "GPU left initialized by EFI, resetting\n");
+		ret = pci_reset_function(pdev);
+		if (ret < 0)
+			pci_err(pdev, "Failed to reset GPU: %d\n", ret);
+	}
+
+	iounmap(map);
+out_disable:
+	pci_disable_device(pdev);
+}
+DECLARE_PCI_FIXUP_CLASS_FINAL(PCI_VENDOR_ID_NVIDIA, 0x13b1,
+			      PCI_CLASS_DISPLAY_VGA, 8,
+			      quirk_reset_lenovo_thinkpad_p50_nvgpu);
-- 
2.20.1



_______________________________________________
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau