Bug 75401
Summary: | vgaswitcheroo doesn't work for AMD Radeon 8870m (possibly due to "wrong" PCI class) | ||
---|---|---|---|
Product: | Drivers | Reporter: | drill87 |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | RESOLVED PATCH_ALREADY_AVAILABLE | ||
Severity: | low | CC: | alexdeucher, pali |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 3.11.10 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Output of "lspci -nn" command
fix for rom fetching dmesg after applying "fix for rom fetching" patch dmesg before applying "fix for rom fetching" patch preffer current pci device |
Description
drill87
2014-05-03 17:26:49 UTC
Created attachment 134941 [details]
Output of "lspci -nn" command
This log has wring revision number for radeon 8870m (rev ff), because right now I'm shutting it out through acpi_call command. Everything else is right.
Already fixed: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=e9a4099a59cc598a44006059dd775c25e422b772 Yes, it fixes vgaswitcheroo problem. Sorry for misleading bugreport then. However, I would like to mention that radeon module had 2 places with "problematic" PCI class test. The first one is fixed with the aforementioned patch. The second place is in file "radeon_bios.c" in function "static bool radeon_atrm_get_bios(struct radeon_device *rdev)". I don't know if it is a problem, but it's still expected only cards with PCI_CLASS_DISPLAY_VGA class there. Thus, I guess, the bios doesn't get initialized properly for my card with class PCI_CLASS_DISPLAY_OTHER... Anyway, thank you for your time! Created attachment 135221 [details]
fix for rom fetching
Does this patch fix the issue?
I guess it fixes. At least, I can see no errors for radeon module in dmesg. Vgaswitcheroo, as I aforementioned, works too (I can turn off the card, so notebook heats less). However, I cannot say any more, because I fail to actually use my radeon for rendering (with Xorg server 1.15.1) --- even command "glxinfo" with "DRI_PRIME=1" (and configured offload sink) crashes Xserver. And I don't know where the problem might be - in module or in Xorg drivers. Created attachment 135541 [details]
dmesg after applying "fix for rom fetching" patch
@drill87: I had same problem (Xorg server crashing) when I tried to use DRI_PRIME on 8690M. I fixed it with updating libdri, mesa, radeon & intel xorg drivers from git. And then it started working. Also I removed everything in /etc/X11/xorg.conf and /etc/X11/xorg.conf.d/ and called xrandr --setprovideroutputsource 1 0 before running DRI_PRIME=1 glxinfo @Alex Deucher: Why is needed to use acpi "ATRM"? If you still remember https://bugzilla.kernel.org/show_bug.cgi?id=73901#c9 I needed only to patch radeon_atpx_handler.c. So my radeon card working fine without "ATRM". When "ATRM" is used? Or for which functions? ATRM is an acpi method for fetching the rom on certain systems. If your system was able to fetch the rom via another method, it may not use ATRM. I'm not sure if the ATRM method is required in drill87's case either, but he claimed that it wasn't able to find the rom. Drill87, can you attach the dmesg output without the patch? Oh, I'm sorry, it seems I didn't write it clear enough. I mentioned file "radeon_bios.c" only because I saw there too goes PCI class checl only against PCI_CLASS_DISPLAY_VGA, but there wasn't additional test for PCI_CLASS_DISPLAY_OTHER . I guessed that it might possibly cause problems (just as it did for vgaswitcherro). Though I don't know if it really does (and if it does specifically on my computer). I don't even know what ATRM is :) So I'm sorry again for mislead I've done. And thanks for the tip about libdri and xorg drivers update! Created attachment 135561 [details]
dmesg before applying "fix for rom fetching" patch
Looks like it works fine without the patch as well. That said, the ATRM patch shouldn't hurt anything if there ever ends up being a case where the ATRM method is hung off a non-VGA display device. @Alex Deucher: Why is this bug while loop needed? static bool radeon_atrm_get_bios(struct radeon_device *rdev) { ... while ((pdev = pci_get_class(PCI_CLASS_DISPLAY_VGA << 8, pdev)) != NULL) { dhandle = ACPI_HANDLE(&pdev->dev); if (!dhandle) continue; status = acpi_get_handle(dhandle, "ATRM", &atrm_handle); if (!ACPI_FAILURE(status)) { found = true; break; } } ... Is not correct to use ACPI_HANDLE directly, something like this (without while loop)? static bool radeon_atrm_get_bios(struct radeon_device *rdev) { ... if (rdev->pdev) dhandle = ACPI_HANDLE(&rdev->pdev->dev); ... This could also eliminate using PCI_CLASS_DISPLAY_VGA. If I understood correctly, ATRM method is specific for AMD cards so searching for ATRM method in all avalilable pci devices (which match class) is not necessary. (In reply to Pali Rohár from comment #12) > @Alex Deucher: Why is this bug while loop needed? IIRC, sometimes the method is hung off the other GPU. Created attachment 137381 [details]
preffer current pci device
What about this patch? It will preffer to call ATRM method for current pci device.
oups, it should be ACPI_HANDLE(&rdev->pdev->dev) and not ACPI_HANDLE(&pdev->dev). |