[PATCH] acpi: allow non-optimus setups to load vbios from acpi
Claas Lorenz
cllorenz at uni-potsdam.de
Sun Apr 6 01:12:56 PDT 2014
Yes, it works without the workaround... and thanks for the suspend patch
which works fine as well :-)
On 05.04.2014 18:18, Ilia Mirkin wrote:
> On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz <cllorenz at uni-potsdam.de> wrote:
>> Hi, same for me. The screen does not freeze anymore and the boot
> Great! And that's without the nouveau.config=NvBios= stuff that you
> added as a workaround, right?
>
>> 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.
> New to you, perhaps :) Try
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adbbdbac04f093c0abf946b1e93e4e5291808491.
> Or you can try forcing runpm=1 and seeing what happens. Ideally it'll
> be able to suspend your second GPU, but... who knows. That logic is
> really designed around optimus.
>
>> 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
>>>>
More information about the dri-devel
mailing list