search for: nvkm_outp_init_rout

...+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c index 6094805fbd63..06b19883a06b 100644 --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/outp.c @@ -229,10 +229,8 @@ nvkm_outp_init_route(struct nvkm_outp *outp) return; ior = nvkm_ior_find(disp, type, -1); - if (!ior) { - WARN_ON(1); + if (WARN_ON(!ior)) return; - } /* Determine the specific OR, if any, this device is attached to. */ if (ior->func->route.get) { @@ -248,10 +246,8 @@ nvkm_outp_init_route(struct...

...ysical 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. 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? Thanks, Danilo >> >> Thanks, >> Ben. >> >>> >>> Therefore to work around this issue skip crossbar routing for this >>> particular macro li...

...if that proves wrong. */ WARN_ON(hda && !ior->hda); - return nvkm_outp_acquire_ior(outp, user, ior); + return _nvkm_outp_acquire_ior(outp, user, ior); } } @@ -214,30 +214,30 @@ nvkm_outp_fini(struct nvkm_outp *outp) outp->func->fini(outp); } -static void -nvkm_outp_init_route(struct nvkm_outp *outp) +struct nvkm_ior * +nvkm_outp_get_current_ior(struct nvkm_outp *outp) { struct nvkm_disp *disp = outp->disp; + struct nvkm_ior *ior; enum nvkm_ior_proto proto; enum nvkm_ior_type type; - struct nvkm_ior *ior; int id, link; /* Find any OR from the class that...

...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 ;) > > 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, &g...

On 5 February 2018 at 11:22, Danilo Krummrich <danilokrummrich at 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]