Nouveau - Apr 2014 - [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
>>

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
>>>
>

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
>>>>