All of lore.kernel.org
 help / color / mirror / Atom feed
From: Danilo Krummrich <danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org>
To: Ben Skeggs <bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: Dave Airlie <airlied-cv59FeDIM0c@public.gmane.org>,
	nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org,
	dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81
Date: Mon, 05 Feb 2018 12:14:47 +0100	[thread overview]
Message-ID: <3fe2d38a8923f2673ee4e0568a6b327d@dk-develop.de> (raw)
In-Reply-To: <CABDvA=kuMrzhQOhhuNAdQ25XNMhk+HVenFLMu3tZQnvGPien1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On 2018-02-05 03:47, Ben Skeggs wrote:
> On Mon, Feb 5, 2018 at 12:19 PM, Danilo Krummrich
> <danilokrummrich@dk-develop.de> wrote:
>> On 2018-02-05 02:39, Ben Skeggs wrote:
>>> 
>>> On 5 February 2018 at 11:37, Ben Skeggs <skeggsb@gmail.com> wrote:
>>>> 
>>>> On 5 February 2018 at 11:22, Danilo Krummrich
>>>> <danilokrummrich@dk-develop.de> wrote:
>>>>> 
>>>>> On Gainward GTX 1070 routing any other SOR than SOR-1 to macro link
>>>>> 'G' (outp index 7) causes failures:
>>>>> 
>>>>> [    6.712111] nouveau 0000:01:00.0: bus: MMIO read of 00000000 
>>>>> FAULT at
>>>>> 61c880 [ IBUS ]
>>>>> [    6.724888] nouveau 0000:01:00.0: disp: intr24 80000000
>>>>> [    8.716668] nouveau 0000:01:00.0: DRM: base-0: timeout
>>>>> [   10.716679] nouveau 0000:01:00.0: DRM: base-1: timeout
>>>>> [   63.511862] nouveau 0000:01:00.0: DRM: EVO timeout
>>>>> 
>>>>> As I'm not able to spot an issue in the driver, I suppose it's
>>>>> firmware related.
>>>> 
>>>> Are you able to mail me /dev/dri/card0/vbios.rom from that, please?
>>>> I'd like to look into this some more and be 100% certain this is
>>>> indeed a quirk, and not some subtle driver bug.
>>> 
>>> Err.. /sys/kernel/debug/dri/0/vbios.rom rather ;)
>>> 
>> Sure, that makes sense definitely, as I have checked 
>> gm200_sor_route_set and
>> gm200_sor_route_get only to conform to the statements in this mail 
>> thread:
>> https://lists.freedesktop.org/archives/nouveau/2014-December/019408.html
>> 
>> BTW, I can reproduce the problem with a two monitor setup only, as (of
>> course) having one
>> monitor only at the physical port macro link 'G' is attached to makes 
>> to
>> vbios pick the
>> working SOR. Therefore the physical port macro link 'G' is attached to 
>> must
>> not be picked
>> as primary monitor.
> Thanks for that.  I've only had a quick look so far, but I'm going to
> guess the is a driver bug already.  The DCB specifies two different
> outputs on pad macro 1 (which, would be SOR1 if identity-mapped) that
First of all, sorry for confusing with the macro link numeration.
Of course, I am talking about pad macro 1, link 2 (which is also called
macro link D). I was wrongly looking at outp->index.
I will send an updated patch series correcting this, just in case.
> can apparently be used together.  If used at the same time though,
> they both can't be driven by the same SOR, and would need routing.
I agree that there's definitely the need of routing here. Anyway, it
can still be it's just buggy in a way that only macro link D cannot be
routed to a different SOR than SOR-1. Probably you know better, if such
a case can be possible.

> I guess it'd be interesting to see if NVIDIA can manage to drive those
> two outputs together, which would be a big hint as to whether the
> board is buggy, or we are.  I'm going to guess the latter ;)
> 
I tested that - even nouveau is able to drive macro link C and D 
together.
Macro link C corresponds to connector 3 (which is HDMI) and macro link D
corresponds to connector 4 (which is DP). And it actually works because 
VBIOS
serves macro link D as primary OR and routes SOR-1 to it already.
Nouveau picks (of course) SOR-0 for macro link C then.
BTW, any other combination works well, as long as macro link D (if used) 
is
not routed to another SOR than SOR-1. E.g. macro link A on SOR-2 and 
macro
link E on either SOR-0 or SOR-3.
>> 
>> Also, may I ask you a related question: I was a bit confused why 
>> 'link' is
>> completely unused
>> in nvkm_outp_init_route() after gm200_sor_route_get() returns. Is this 
>> just
>> obsolete or
>> intended to use in the future somehow?
> I suspect it's a left-over from an earlier revision of that code, or
> perhaps I intended to validate it against what we discovered?  Not
> sure now!
> 
> Thanks,
> Ben.
> 
>> 
>> Thanks,
>> Danilo
>> 
>>>> 
>>>> Thanks,
>>>> Ben.
>>>> 
>>>>> 
>>>>> Therefore to work around this issue skip crossbar routing for this
>>>>> particular macro link and instead use identity mapping.
>>>>> 
>>>>> Signed-off-by: Danilo Krummrich <danilokrummrich@dk-develop.de>
>>>>> ---
>>>>>  drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c | 9 ++++++++-
>>>>>  1 file changed, 8 insertions(+), 1 deletion(-)
>>>>> 
>>>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>>>>> b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>>>>> index d2f9664afcf4..29de270f2232 100644
>>>>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>>>>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/pci.c
>>>>> @@ -797,6 +797,13 @@ nvkm_device_pci_10de_139b[] = {
>>>>>         {}
>>>>>  };
>>>>> 
>>>>> +static const struct nvkm_device_pci_vendor
>>>>> +nvkm_device_pci_10de_1b81[] = {
>>>>> +       /* Gainward GTX 1070 8192 MB */
>>>>> +       { 0x10b0, 0x1b81, "GeForce GTX 1070",{ .outp_links_skip = 
>>>>> BIT(7)
>>>>> } },
>>>>> +       {}
>>>>> +};
>>>>> +
>>>>>  static const struct nvkm_device_pci_device
>>>>>  nvkm_device_pci_10de[] = {
>>>>>         { 0x0020, "RIVA TNT" },
>>>>> @@ -1556,7 +1563,7 @@ nvkm_device_pci_10de[] = {
>>>>>         { 0x1b06, "GeForce GTX 1080 TI" },
>>>>>         { 0x1bb7, "Quadro P6000" },
>>>>>         { 0x1b80, "GeForce GTX 1080" },
>>>>> -       { 0x1b81, "GeForce GTX 1070" },
>>>>> +       { 0x1b81, "GeForce GTX 1070", nvkm_device_pci_10de_1b81 },
>>>>>         { 0x1b82, "GeForce GTX 1070 TI" },
>>>>>         { 0x1b84, "GeForce GTX 1060 3GB" },
>>>>>         { 0x1b87, "P104-100" },
>>>>> --
>>>>> 2.14.1
>>>>> 
>>>>> _______________________________________________
>>>>> Nouveau mailing list
>>>>> Nouveau@lists.freedesktop.org
>>>>> https://lists.freedesktop.org/mailman/listinfo/nouveau
>>> 
>>> _______________________________________________
>>> dri-devel mailing list
>>> dri-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel@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

      parent reply	other threads:[~2018-02-05 11:14 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-05  1:22 [PATCH 1/3] drm/nouveau/pci: PCI IDs for pascal architecture Danilo Krummrich
     [not found] ` <20180205012256.2198-1-danilokrummrich-q2z19idT6fYRctDU1SCqIg@public.gmane.org>
2018-02-05  1:22   ` [PATCH 2/3] drm/nouveau/disp: quirk for SOR crossbar routing Danilo Krummrich
2018-02-05  1:22 ` [PATCH 3/3] drm/nouveau/pci: SOR crossbar quirk for 10b0:1b81 Danilo Krummrich
2018-02-05  1:37   ` [Nouveau] " Ben Skeggs
     [not found]     ` <CACAvsv6svP0jGHsJ09m_fHLR8DddmPf7oWHoLbzMjQi87Sy0cA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05  1:39       ` Ben Skeggs
     [not found]         ` <CACAvsv5uV8CpZ8FT-V80DHefLLXkLoLmcbT+6tjo_0zPTqiF0g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05  2:19           ` Danilo Krummrich
2018-02-05  2:47             ` [Nouveau] " Ben Skeggs
     [not found]               ` <CABDvA=kuMrzhQOhhuNAdQ25XNMhk+HVenFLMu3tZQnvGPien1A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2018-02-05 11:14                 ` Danilo Krummrich [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3fe2d38a8923f2673ee4e0568a6b327d@dk-develop.de \
    --to=danilokrummrich-q2z19idt6fyrctdu1scqig@public.gmane.org \
    --cc=airlied-cv59FeDIM0c@public.gmane.org \
    --cc=bskeggs-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.