Commen=
t # 64
on bug 75985<=
/a>
from Lukas Wunner
(In reply to Maik Freudenberg from comment #57)
> (In reply to Ilia Mirkin from comment #55)
> > What's the downside for doing this always btw=20
> By 'this', you mean, always turning it on?
> This generates the errors from comment #42 since those devices are not
> configured resource-wise, all zeros.
I would assume the BAR is all zeroes because there was insufficient space to
accommodate the additional 4K for it. AFAIUI, the kernel assigns only the
minimal amount of space to the bridge window that is necessary to accomodate
the devices below. Hence, if a device is added after the fact below the bri=
dge,
there may not be sufficient space available for it. I'd expect the situatio=
n to
be different if the device is already present on enumeration, as is done by=
the
"header" PCI quirk. Then the bridge window can be sized appropria=
tely. Could
you verify that on the machine in question?
It occurred to me that we could at least check presence of the Optimus _DSM=
in
the PCI quirk. That would be sufficiently small for a quirk. That way it wo=
uld
be constrained to Optimus laptops, but sadly we'd still expose an audio
function if the GPU has no outputs at all. However I notice that
drivers/gpu/drm/nouveau/nouveau_acpi.c defines a OPTIMUS_HDA_CODEC_MASK mac=
ro
("hda bios codec supported"). Would that be of any use? Or can we=
query via the
_DSM whether the GPU has any outputs?