dri-devel Archive on 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox