Ilia Mirkin
2014-Mar-26 23:37 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
There appear to be a crop of new hardware where the vbios is not available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. The data read from PCIROM almost invariably contains invalid instructions (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> Cc: <stable at vger.kernel.org> # v2.6.35+ --- Not sure if the stable CC is warranted... it's technically not a regression. But it's a simple change that enables hardware to work. Patrick/Claas -- please test this out (if you're applying this to a linux tree, you'll have to do it manually, but it should be fairly obvious where this should apply). drm/nouveau_acpi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c index 83face3..2792069 100644 --- a/drm/nouveau_acpi.c +++ b/drm/nouveau_acpi.c @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) acpi_status status; acpi_handle dhandle, rom_handle; - if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) - return false; - dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) return false; -- 1.8.3.2
Ben Skeggs
2014-Mar-27 00:03 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
On Thu, Mar 27, 2014 at 9:37 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:> There appear to be a crop of new hardware where the vbios is not > available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. > The data read from PCIROM almost invariably contains invalid > instructions (still has the x86 opcodes), which makes this a low-risk > way to try to obtain a valid vbios image. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > Cc: <stable at vger.kernel.org> # v2.6.35+Got it, thanks!> --- > > Not sure if the stable CC is warranted... it's technically not a > regression. But it's a simple change that enables hardware to work. > > Patrick/Claas -- please test this out (if you're applying this to a linux > tree, you'll have to do it manually, but it should be fairly obvious where > this should apply). > > drm/nouveau_acpi.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c > index 83face3..2792069 100644 > --- a/drm/nouveau_acpi.c > +++ b/drm/nouveau_acpi.c > @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) > acpi_status status; > acpi_handle dhandle, rom_handle; > > - if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) > - return false; > - > dhandle = ACPI_HANDLE(&pdev->dev); > if (!dhandle) > return false; > -- > 1.8.3.2 > > _______________________________________________ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
Patrick Clara
2014-Mar-27 10:54 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you 2014-03-27 0:37 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>:> There appear to be a crop of new hardware where the vbios is not > available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. > The data read from PCIROM almost invariably contains invalid > instructions (still has the x86 opcodes), which makes this a low-risk > way to try to obtain a valid vbios image. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 > Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> > Cc: <stable at vger.kernel.org> # v2.6.35+ > --- > > Not sure if the stable CC is warranted... it's technically not a > regression. But it's a simple change that enables hardware to work. > > Patrick/Claas -- please test this out (if you're applying this to a linux > tree, you'll have to do it manually, but it should be fairly obvious where > this should apply). > > drm/nouveau_acpi.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c > index 83face3..2792069 100644 > --- a/drm/nouveau_acpi.c > +++ b/drm/nouveau_acpi.c > @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) > acpi_status status; > acpi_handle dhandle, rom_handle; > > - if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) > - return false; > - > dhandle = ACPI_HANDLE(&pdev->dev); > if (!dhandle) > return false; > -- > 1.8.3.2 >
Claas Lorenz
2014-Apr-05 11:53 UTC
[Nouveau] [PATCH] acpi: allow non-optimus setups to load vbios from acpi
Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On 27.03.2014 11:54, Patrick Clara wrote:> I have tested this patch. I can confirm that now nouveau loads > correctly without errors. > Thank you > > 2014-03-27 0:37 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: >> There appear to be a crop of new hardware where the vbios is not >> available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. >> The data read from PCIROM almost invariably contains invalid >> instructions (still has the x86 opcodes), which makes this a low-risk >> way to try to obtain a valid vbios image. >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 >> Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> >> Cc: <stable at vger.kernel.org> # v2.6.35+ >> --- >> >> Not sure if the stable CC is warranted... it's technically not a >> regression. But it's a simple change that enables hardware to work. >> >> Patrick/Claas -- please test this out (if you're applying this to a linux >> tree, you'll have to do it manually, but it should be fairly obvious where >> this should apply). >> >> drm/nouveau_acpi.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/drm/nouveau_acpi.c b/drm/nouveau_acpi.c >> index 83face3..2792069 100644 >> --- a/drm/nouveau_acpi.c >> +++ b/drm/nouveau_acpi.c >> @@ -389,9 +389,6 @@ bool nouveau_acpi_rom_supported(struct pci_dev *pdev) >> acpi_status status; >> acpi_handle dhandle, rom_handle; >> >> - if (!nouveau_dsm_priv.dsm_detected && !nouveau_dsm_priv.optimus_detected) >> - return false; >> - >> dhandle = ACPI_HANDLE(&pdev->dev); >> if (!dhandle) >> return false; >> -- >> 1.8.3.2 >>
Apparently Analagous Threads
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi
- [PATCH 1/8] acpi: Rename v1 DSM to mux to avoid ambiguity
- [PATCH v2 1/9] acpi: Rename v1 DSM to mux to avoid ambiguity
- [PATCH] acpi: allow non-optimus setups to load vbios from acpi