RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
-Original Message- From: Dan Carpenter [mailto:dan.carpen...@oracle.com] Sent: Wednesday, September 26, 2012 9:00 AM To: Deucher, Alexander Cc: Andres Freund; LKML; David Airlie; dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL This is fixed now? It should be. The patch was reverted for 3.6. Alex regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
-Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Wednesday, September 26, 2012 9:41 AM To: Dan Carpenter Cc: Deucher, Alexander; LKML; David Airlie; dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote: This is fixed now? Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in rc6. On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote: Sorry, I somehow accidentally marked your email as read and thus didn't notice it. I think I see the problem. I think it's a limitation of the current current modesetting API. The current API sets up each display independently which doesn't work so well if there are resource restrictions. There shouldn't be any contention on your board since you are only using 2 non-DP displays. It looks like X is mapping different crtcs to displays than the kernel fb. Initially the kernel set up the follow: [2.134901] [drm] crtc 0 using pll 0x2 [2.362257] [drm] crtc 1 using pll 0x1 [2.386709] [drm] crtc 2 using pll 0x0 Crtc 0 - DCPLL - DP Crtc 1 - PPLL2 - DVI Crtc 2 - PPLL1 - DVI When X loads, it tried to set a different crtc to display mapping: [ 60.679310] [drm] crtc 0 using pll 0xff [ 60.789183] [drm] crtc 1 using pll 0x2 [ 60.819594] [drm] crtc 2 using pll 0x1 Crtc 0 - INVALID - DVI 0 Crtc 1 - DCPLL - DP Crtc 2 - PPLL2 - DVI 1 Crtc 0 should have used PPLL1 or PPLL2, but they were already in use by crtc 1 and crtc 2 from the previous modeset. Since the modeset API is not atomic, it doesn't have the whole picture. I'm not sure of a good solution right now prior to the new atomic modeset API that is under discussion. I guess we can revert the patch for 3.6. For 3.7 I guess we need to validate the actual connector to make sure we aren't trying to set a different configuration relating to the same connector without first tearing down the first one. In the interim, you should be able to work around it by disabling the non-DP outputs and then bringing than back up. Thanks! That explanation makes sense. I can work around it just fine, starting X multiple times works which coincides nicely with your explanation. The code in the 3.7 branch doesn't do that extended validation yet, rigth? If you want/need you can CC for testing once thats ready. It should handle it now. If you could test it that would be great. Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
-Original Message- From: Josh Boyer [mailto:jwbo...@gmail.com] Sent: Monday, December 03, 2012 10:25 AM To: Ben Hutchings; Greg KH Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; akpm@linux- foundation.org; a...@lxorguk.ukuu.org.uk; Deucher, Alexander Subject: Re: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop() On Mon, Dec 3, 2012 at 9:32 AM, Ben Hutchings b...@decadent.org.uk wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Alex Deucher alexander.deuc...@amd.com commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream. The save struct is not initialized previously so explicitly mark the crtcs as not used when they are not in use. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Hm. If this is needed in 3.2, presumably it's needed in 3.6 as well. I don't see it queued for 3.6.9, and the Cc: tag is there. Greg, Alex, was this just something that was missed, or am I wrong about it needing to go into 3.6? The original patches should go into 3.6 kernels as well: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4a15903db02026728d0cf2755c6fabae16b8db6a http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=62444b7462a2b98bc78d68736c03a7c4e66ba7e2 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=804cc4a0ad3a896ca295f771a28c6eb36ced7903 I've been meaning to follow up on it, but I haven't had the time. Do I need to send explicit patches to stable@vger or can I just ask the above commits be cherrypicked to 3.6? Alex josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()
-Original Message- From: Josh Boyer [mailto:jwbo...@gmail.com] Sent: Monday, December 03, 2012 6:26 PM To: Deucher, Alexander Cc: Ben Hutchings; Greg KH; linux-kernel@vger.kernel.org; sta...@vger.kernel.org; a...@linux-foundation.org; a...@lxorguk.ukuu.org.uk Subject: Re: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop() On Mon, Dec 3, 2012 at 10:35 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Josh Boyer [mailto:jwbo...@gmail.com] Sent: Monday, December 03, 2012 10:25 AM To: Ben Hutchings; Greg KH Cc: linux-kernel@vger.kernel.org; sta...@vger.kernel.org; akpm@linux- foundation.org; a...@lxorguk.ukuu.org.uk; Deucher, Alexander Subject: Re: [ 67/89] drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop() On Mon, Dec 3, 2012 at 9:32 AM, Ben Hutchings b...@decadent.org.uk wrote: 3.2-stable review patch. If anyone has any objections, please let me know. -- From: Alex Deucher alexander.deuc...@amd.com commit 804cc4a0ad3a896ca295f771a28c6eb36ced7903 upstream. The save struct is not initialized previously so explicitly mark the crtcs as not used when they are not in use. Signed-off-by: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Ben Hutchings b...@decadent.org.uk Hm. If this is needed in 3.2, presumably it's needed in 3.6 as well. I don't see it queued for 3.6.9, and the Cc: tag is there. Greg, Alex, was this just something that was missed, or am I wrong about it needing to go into 3.6? The original patches should go into 3.6 kernels as well: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=4 a15903db02026728d0cf2755c6fabae16b8db6a http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=6 2444b7462a2b98bc78d68736c03a7c4e66ba7e2 http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=8 04cc4a0ad3a896ca295f771a28c6eb36ced7903 I've been meaning to follow up on it, but I haven't had the time. Do I need to send explicit patches to stable@vger or can I just ask the above commits be cherrypicked to 3.6? Normally the CC tag works. Not entirely sure why it didn't for the one patch I asked about. The other two commits you've highlighted here are lacking any sort of stable tag, so you'd have to pipe up here about them. The patches were not initially a bug fix per se, so I didn't cc stable. It was only later that I got reports of the patches fixing issues for some people. Normally I add the stable cc if the patch is a bug fix. I went ahead and tried the cherry-pick myself on top of 3.6.9, in the order you specified above. The 62444b7462a has a trivial conflict coming back. I've attached an mbox with these three patches. If you want to give them a glance over and OK them, that would be great. They look good to me. Thanks! Reviewed-by: Alex Deucher alexander.deuc...@amd.com (Apologies for the attachment. Gmail is going to mess it up otherwise.) I have them building locally at the moment on top of 3.6.9 and don't expect many issues, but I can't personally test the fixes myself. josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Monday, January 28, 2013 10:20 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 23, 2013 at 11:44 AM, Shuah Khan shuahk...@gmail.com wrote: On Wed, Jan 23, 2013 at 6:40 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 22, 2013 6:57 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 22, 2013 at 11:55 AM, Shuah Khan shuahk...@gmail.com wrote: init: Does the attached patch stop them? It basically skips all initialization of the DMA ring on your system. What I don't understand is why you still get them with the previous patch, but not with 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb reverted. 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb only affects the use of the DMA ring for buffer migration and the patch I previously attached disables the use of the DMA ring for buffer migration. Does the latest batch of drm- fixes from Dave that Linus just merged help? Alex Will try your latest patch. Will also try the latest git - I am currently on Jan 17th. However, in the meantime, I found that these messages might not be new and getting printed now with the eaaa6983ab2ccdf826c90838eb584211e0cadb76 [PATCH] drm/radeon: print dma status reg on lockup (v2) commit that introduced debug messages in r600_gpu_soft_reset(). I couldn't revert this commit, but doing a compile with these messages commented out. Will update you on the results and then test the new git -- Shuah Here is what I tried: 1. Applied your latest disable_dma_ring_on_6xx-2.diff and still see messages. If that is the case, I'm beginning to think the bug is elsewhere. Support for the DMA ring was the only major feature we added in this cycle. If you are still getting errors even with the ring completely disabled, it's probably not the DMA ring. Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=2 0707874fd4fd37e09513f508e642fa8bd06365a That's the only thing I can think of that may cause the DMAR errors if the DMA ring is disabled. I verified I have this commit. ok maybe the bug is elsewhere. So far all my bisects are on drivers/gpu/drm/radeon - I am going go one more level up and start at drivers/gpu/drm and see what I can isolate it that way. I do know that I don't see this problem on 3.7.4 -- Shuah Alex, I was out sick for a few days and finally picked this bisect backup again. I started at 3.7 tag instead of 3.8-rc1 that I did in the past and also did bisect at drivers/gpu/drm/radeon instead. Here are the results: 6253e4c75d96006c06b9ac8f417eba873de2497b is the first bad commit commit 6253e4c75d96006c06b9ac8f417eba873de2497b Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Dec 12 14:30:32 2012 -0500 drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx Along the same lines of what was done for evergreen+ in the last kernel. Signed-off-by: Alex Deucher alexander.deuc...@amd.com git bisect log attached. Try the attached patch. I think it should fix the issue. I just applied a similar patch for newer asics. Alex 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx.patch Description: 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx.patch
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 2:11 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 6:05 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- I was out sick for a few days and finally picked this bisect backup again. I started at 3.7 tag instead of 3.8-rc1 that I did in the past and also did bisect at drivers/gpu/drm/radeon instead. Here are the results: 6253e4c75d96006c06b9ac8f417eba873de2497b is the first bad commit commit 6253e4c75d96006c06b9ac8f417eba873de2497b Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Dec 12 14:30:32 2012 -0500 drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx Along the same lines of what was done for evergreen+ in the last kernel. Signed-off-by: Alex Deucher alexander.deuc...@amd.com git bisect log attached. Try the attached patch. I think it should fix the issue. I just applied a similar patch for newer asics. Alex I reverted 6253e4c75d96006c06b9ac8f417eba873de2497b and DMAR faults went away. Undid the revert and applied your new patch. DMAR faults are back again. [ 25.158653] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 25.158715] radeon :01:00.0: WB enabled [ 25.158719] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x08000c00 and cpu addr 0x88002f143c00 [ 25.158721] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x08000c0c and cpu addr 0x88002f143c0c A few observations and questions about r600_startup() code sequence: I notice DMAR faults right after [drm] Loading RV620 Microcode message which is from r600_init_microcode(). This routine does a series of request_firmware() calls. btw. don't see release_firmware() calls in regular code path, only from error legs in r600_init_microcode(). However, this routine doesn't do any loading yet. When this routine returns, I am assuming request_firmware() step isn't complete yet based on my reading request_firmware() interface. At this point r600_startup() keeps chugging along, and does r600_mc_program() which in turn calls rv515_mc_stop() which was changed with the 6253e4c75d96006c06b9ac8f417eba873de2497b commit. I am thinking the changes somehow eliminated a wait or delay that used be there for request_firmware() step to complete (?) I can see from dmesg that the faults occur right after: r600_init_microcode(rdev); and stop before r600_pcie_gart_enable() r600_init_microcode() doesn't actually touch the hardware it just calls request_firmware() to fetch the microcode images from disk. The microcode doesn't get loaded onto the hardware until r600_cp_load_microcode() much later in the function. I don't think the microcode has anything to do with this. rv515_mc_stop() stops GPU memory clients (e.g., the displays) and blacks out the GPU memory controller so that we can change the location of VRAM within the GPU's address space. If one of the display controllers memory request stop requests takes too long to go through for some reason, it's possible that the display hardware may attempt to read from a GPU memory location no-longer backed by vram (since we changed the location of vram in r600_mc_program()) momentarily until the stop request goes through. Does the attached updated version of the patch help? Alternatively, you can try adding delays to the end of rv515_mc_stop() and see if that helps. Alex 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx-v2.patch Description: 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx-v2.patch
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 4:40 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 1:13 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 2:11 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 6:05 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- I was out sick for a few days and finally picked this bisect backup again. I started at 3.7 tag instead of 3.8-rc1 that I did in the past and also did bisect at drivers/gpu/drm/radeon instead. Here are the results: 6253e4c75d96006c06b9ac8f417eba873de2497b is the first bad commit commit 6253e4c75d96006c06b9ac8f417eba873de2497b Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Dec 12 14:30:32 2012 -0500 drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx Along the same lines of what was done for evergreen+ in the last kernel. Signed-off-by: Alex Deucher alexander.deuc...@amd.com git bisect log attached. Try the attached patch. I think it should fix the issue. I just applied a similar patch for newer asics. Alex I reverted 6253e4c75d96006c06b9ac8f417eba873de2497b and DMAR faults went away. Undid the revert and applied your new patch. DMAR faults are back again. [ 25.158653] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 25.158715] radeon :01:00.0: WB enabled [ 25.158719] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x08000c00 and cpu addr 0x88002f143c00 [ 25.158721] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x08000c0c and cpu addr 0x88002f143c0c A few observations and questions about r600_startup() code sequence: I notice DMAR faults right after [drm] Loading RV620 Microcode message which is from r600_init_microcode(). This routine does a series of request_firmware() calls. btw. don't see release_firmware() calls in regular code path, only from error legs in r600_init_microcode(). However, this routine doesn't do any loading yet. When this routine returns, I am assuming request_firmware() step isn't complete yet based on my reading request_firmware() interface. At this point r600_startup() keeps chugging along, and does r600_mc_program() which in turn calls rv515_mc_stop() which was changed with the 6253e4c75d96006c06b9ac8f417eba873de2497b commit. I am thinking the changes somehow eliminated a wait or delay that used be there for request_firmware() step to complete (?) I can see from dmesg that the faults occur right after: r600_init_microcode(rdev); and stop before r600_pcie_gart_enable() r600_init_microcode() doesn't actually touch the hardware it just calls request_firmware() to fetch the microcode images from disk. The microcode doesn't get loaded onto the hardware until r600_cp_load_microcode() much later in the function. I don't think the microcode has anything to do with this. rv515_mc_stop() stops GPU memory clients (e.g., the displays) and blacks out the GPU memory controller so that we can change the location of VRAM within the GPU's address space. If one of the display controllers memory request stop requests takes too long to go through for some reason, it's possible that the display hardware may attempt to read from a GPU memory location no-longer backed by vram (since we changed the location of vram in r600_mc_program()) momentarily until the stop request goes through. Does the attached updated version of the patch help? Alternatively, you can try adding delays to the end of rv515_mc_stop() and see if that helps. Alex This v2 patch didn't help. I added mdelay(15); at the end of rv515_mc_stop() on top of this v2 patch and that fixed the problem. mdelay(15) is a bit much I am sure. Shouldn't rv515_mc_wait_for_idle() take care of the delay? It waits for idle usec_timeout? It only waits that long if the MC never goes idle. If the MC happens to be idle at the time, it will return immediately. Does the attached patch fix the issue? It waits for the update pending bit to clear in addition to waiting for the next frame. Alex 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx-v3.patch Description: 0001-drm-radeon-fix-MC-blackout-on-r5xx-r7xx-v3.patch
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 9:38 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 4:45 PM, Shuah Khan shuahk...@gmail.com wrote: On Tue, Jan 29, 2013 at 3:02 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 4:40 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 1:13 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 29, 2013 2:11 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 29, 2013 at 6:05 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- I was out sick for a few days and finally picked this bisect backup again. I started at 3.7 tag instead of 3.8-rc1 that I did in the past and also did bisect at drivers/gpu/drm/radeon instead. Here are the results: 6253e4c75d96006c06b9ac8f417eba873de2497b is the first bad commit commit 6253e4c75d96006c06b9ac8f417eba873de2497b Author: Alex Deucher alexander.deuc...@amd.com Date: Wed Dec 12 14:30:32 2012 -0500 drm/radeon: improve mc_stop/mc_resume on r5xx-r7xx Along the same lines of what was done for evergreen+ in the last kernel. Signed-off-by: Alex Deucher alexander.deuc...@amd.com git bisect log attached. Try the attached patch. I think it should fix the issue. I just applied a similar patch for newer asics. Alex I reverted 6253e4c75d96006c06b9ac8f417eba873de2497b and DMAR faults went away. Undid the revert and applied your new patch. DMAR faults are back again. [ 25.158653] [drm] PCIE GART of 512M enabled (table at 0x0004). [ 25.158715] radeon :01:00.0: WB enabled [ 25.158719] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x08000c00 and cpu addr 0x88002f143c00 [ 25.158721] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x08000c0c and cpu addr 0x88002f143c0c A few observations and questions about r600_startup() code sequence: I notice DMAR faults right after [drm] Loading RV620 Microcode message which is from r600_init_microcode(). This routine does a series of request_firmware() calls. btw. don't see release_firmware() calls in regular code path, only from error legs in r600_init_microcode(). However, this routine doesn't do any loading yet. When this routine returns, I am assuming request_firmware() step isn't complete yet based on my reading request_firmware() interface. At this point r600_startup() keeps chugging along, and does r600_mc_program() which in turn calls rv515_mc_stop() which was changed with the 6253e4c75d96006c06b9ac8f417eba873de2497b commit. I am thinking the changes somehow eliminated a wait or delay that used be there for request_firmware() step to complete (?) I can see from dmesg that the faults occur right after: r600_init_microcode(rdev); and stop before r600_pcie_gart_enable() r600_init_microcode() doesn't actually touch the hardware it just calls request_firmware() to fetch the microcode images from disk. The microcode doesn't get loaded onto the hardware until r600_cp_load_microcode() much later in the function. I don't think the microcode has anything to do with this. rv515_mc_stop() stops GPU memory clients (e.g., the displays) and blacks out the GPU memory controller so that we can change the location of VRAM within the GPU's address space. If one of the display controllers memory request stop requests takes too long to go through for some reason, it's possible that the display hardware may attempt to read from a GPU memory location no-longer backed by vram (since we changed the location of vram in r600_mc_program()) momentarily until the stop request goes through. Does the attached updated version of the patch help? Alternatively, you can try adding delays to the end of rv515_mc_stop() and see if that helps. Alex This v2 patch didn't help. I added mdelay(15); at the end of rv515_mc_stop() on top of this v2 patch and that fixed the problem. mdelay(15) is a bit much I am sure. Shouldn't rv515_mc_wait_for_idle() take care of the delay? It waits for idle usec_timeout? It only waits that long if the MC never goes idle. If the MC happens to be idle at the time, it will return immediately. Does the attached patch fix the issue? It waits for the update
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Wednesday, January 30, 2013 10:35 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: ok. I did more debugging in rv515_mc_stop() and here is what's happening. It has two display controllers and one of them is enabled and the other is in disabled state when AVIVO_D1CRTC_CONTROL is checked. The current code doesn't blank the disabled crtc. However, it needs to be blanked to avoid DMAR faults it appears. I think that is what the original code prior to 6253e4c75d96006c06b9ac8f417eba873de2497b commit was doing: - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1); - WREG32(R_006080_D1CRTC_CONTROL, 0); - WREG32(R_006880_D2CRTC_CONTROL, 0); - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); - WREG32(R_000330_D1VGA_CONTROL, 0); - WREG32(R_000338_D2VGA_CONTROL, 0); Anyways, here is the diff for the change (by no means a patch) I made that fixed the problem: Unfortunately, that just fixes the problem by causing an additional delay since the wait_for_vblank() and get_frame_count() loops will timeout since the secondary display is disabled. The previous code disabled the displays completely while the new code just disables the memory request interface so that the display timing stays on to avoid additional flicker at startup or GPU reset. For some reason on your system there seems to be a delay in getting the memory request interface to stop. Alex Right. That makes sense and yes the annoying flicker went away. :) Can you think of something that can address systems that would need more time to get the memory request interface to stop such as mine? Does adding an additional radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() help? Can you find out what the minimum delay required for your system is? Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Wednesday, January 30, 2013 4:12 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 30, 2013 at 8:53 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Wednesday, January 30, 2013 10:35 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: ok. I did more debugging in rv515_mc_stop() and here is what's happening. It has two display controllers and one of them is enabled and the other is in disabled state when AVIVO_D1CRTC_CONTROL is checked. The current code doesn't blank the disabled crtc. However, it needs to be blanked to avoid DMAR faults it appears. I think that is what the original code prior to 6253e4c75d96006c06b9ac8f417eba873de2497b commit was doing: - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1); - WREG32(R_006080_D1CRTC_CONTROL, 0); - WREG32(R_006880_D2CRTC_CONTROL, 0); - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); - WREG32(R_000330_D1VGA_CONTROL, 0); - WREG32(R_000338_D2VGA_CONTROL, 0); Anyways, here is the diff for the change (by no means a patch) I made that fixed the problem: Unfortunately, that just fixes the problem by causing an additional delay since the wait_for_vblank() and get_frame_count() loops will timeout since the secondary display is disabled. The previous code disabled the displays completely while the new code just disables the memory request interface so that the display timing stays on to avoid additional flicker at startup or GPU reset. For some reason on your system there seems to be a delay in getting the memory request interface to stop. Alex Right. That makes sense and yes the annoying flicker went away. :) Can you think of something that can address systems that would need more time to get the memory request interface to stop such as mine? Does adding an additional radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() help? Can you find out what the minimum delay required for your system is? Alex Adding radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() - didn't help. I tried with adding udelay() with delay values of 1,10, and 50, and 100 at the end of rv515_mc_stop(). 100 is the minimum that fixed the DMAR faults. I guess we can just add the delay. I've tried all the ways I know of to get proper feedback from the hardware. Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 31, 2013 11:01 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Thu, Jan 31, 2013 at 7:56 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Wednesday, January 30, 2013 4:12 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 30, 2013 at 8:53 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Wednesday, January 30, 2013 10:35 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: ok. I did more debugging in rv515_mc_stop() and here is what's happening. It has two display controllers and one of them is enabled and the other is in disabled state when AVIVO_D1CRTC_CONTROL is checked. The current code doesn't blank the disabled crtc. However, it needs to be blanked to avoid DMAR faults it appears. I think that is what the original code prior to 6253e4c75d96006c06b9ac8f417eba873de2497b commit was doing: - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1); - WREG32(R_006080_D1CRTC_CONTROL, 0); - WREG32(R_006880_D2CRTC_CONTROL, 0); - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0); - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); - WREG32(R_000330_D1VGA_CONTROL, 0); - WREG32(R_000338_D2VGA_CONTROL, 0); Anyways, here is the diff for the change (by no means a patch) I made that fixed the problem: Unfortunately, that just fixes the problem by causing an additional delay since the wait_for_vblank() and get_frame_count() loops will timeout since the secondary display is disabled. The previous code disabled the displays completely while the new code just disables the memory request interface so that the display timing stays on to avoid additional flicker at startup or GPU reset. For some reason on your system there seems to be a delay in getting the memory request interface to stop. Alex Right. That makes sense and yes the annoying flicker went away. :) Can you think of something that can address systems that would need more time to get the memory request interface to stop such as mine? Does adding an additional radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() help? Can you find out what the minimum delay required for your system is? Alex Adding radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() - didn't help. I tried with adding udelay() with delay values of 1,10, and 50, and 100 at the end of rv515_mc_stop(). 100 is the minimum that fixed the DMAR faults. I guess we can just add the delay. I've tried all the ways I know of to get proper feedback from the hardware. Alex Do you want me to send a patch with delay()? Would you like to see the delay specific to this chipset which is RV620? That said if you think of other ideas to try instead of delay, I can continue the debug and testing effort. I'm planning to merge the attached patch. I'll let you know if I found out any other things to try. Alex 0001-drm-radeon-r5xx-r7xx-wait-for-the-MC-to-settle-after.patch Description: 0001-drm-radeon-r5xx-r7xx-wait-for-the-MC-to-settle-after.patch
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 22, 2013 11:15 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Sat, Jan 19, 2013 at 9:44 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Friday, January 18, 2013 7:40 PM To: Linus Torvalds; Deucher, Alexander Cc: Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Fri, Jan 18, 2013 at 3:37 PM, Shuah Khan shuahk...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:51 AM, Shuah Khan shuahk...@gmail.com wrote: ok. I bisected the DMAR faults and it points to the following commit: 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb This commit as I recall, fixed the crash problem I was seeing back in 3.8-rc1. Reverting to see if crash problem reappears. Confirming that with this commit reverted crash problem re-appeared. With this commit, DMAR faults show up. I'm not quite sure what's going on with your system. At this point it's probably best to just disable the DMA ring on these cards until we sort out what's going on. The attached patch disables the use of the DMA ring. Let me know if it fixes the issues you are seeing. I applied this patch to 3.8-rc4 and didn't fix the DMAR faults. Are you getting continuous DMAR faults or just when while the module is being loaded? Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 22, 2013 1:06 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 22, 2013 at 9:36 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 22, 2013 11:15 AM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Sat, Jan 19, 2013 at 9:44 AM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Friday, January 18, 2013 7:40 PM To: Linus Torvalds; Deucher, Alexander Cc: Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Fri, Jan 18, 2013 at 3:37 PM, Shuah Khan shuahk...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:51 AM, Shuah Khan shuahk...@gmail.com wrote: ok. I bisected the DMAR faults and it points to the following commit: 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb This commit as I recall, fixed the crash problem I was seeing back in 3.8-rc1. Reverting to see if crash problem reappears. Confirming that with this commit reverted crash problem re-appeared. With this commit, DMAR faults show up. I'm not quite sure what's going on with your system. At this point it's probably best to just disable the DMA ring on these cards until we sort out what's going on. The attached patch disables the use of the DMA ring. Let me know if it fixes the issues you are seeing. I applied this patch to 3.8-rc4 and didn't fix the DMAR faults. Are you getting continuous DMAR faults or just when while the module is being loaded? Alex During module initialization, I think might be actually right after RV620 Microcode loading attempt: dmesg excerpts starting from radeoan init: Does the attached patch stop them? It basically skips all initialization of the DMA ring on your system. What I don't understand is why you still get them with the previous patch, but not with 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb reverted. 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb only affects the use of the DMA ring for buffer migration and the patch I previously attached disables the use of the DMA ring for buffer migration. Does the latest batch of drm-fixes from Dave that Linus just merged help? Alex [ 22.150520] [drm] radeon defaulting to kernel modesetting. [ 22.150524] [drm] radeon kernel modesetting enabled. [ 22.150793] [drm] initializing kernel modesetting (RV620 0x1002:0x95C4 0x103C :0x30DC). [ 22.150815] [drm] register mmio base: 0x9030 [ 22.150817] [drm] register mmio size: 65536 [ 22.150918] ATOM BIOS: HP [ 22.150941] radeon :01:00.0: VRAM: 128M 0x - 0x07 FF (128M used) [ 22.150943] radeon :01:00.0: GTT: 512M 0x0800 - 0x27F F [ 22.153790] [drm] Detected VRAM RAM=128M, BAR=128M [ 22.153793] [drm] RAM width 64bits DDR [ 22.153850] [TTM] Zone kernel: Available graphics memory: 989986 kiB [ 22.153852] [TTM] Initializing pool allocator [ 22.153857] [TTM] Initializing DMA pool allocator [ 22.153884] [drm] radeon: 128M of VRAM memory ready [ 22.153885] [drm] radeon: 512M of GTT memory ready. [ 22.153902] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 22.153903] [drm] Driver supports precise vblank timestamp query. [ 22.153947] radeon :01:00.0: irq 51 for MSI/MSI-X [ 22.153958] radeon :01:00.0: radeon: using MSI. [ 22.153988] [drm] radeon: irq initialized. [ 22.154034] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 22.154796] [drm] probing gen 2 caps for device 8086:2a41 = 1/0 [ 22.154969] [drm] Loading RV620 Microcode [ 22.218044] dmar: DRHD: handling fault status reg 3 [ 22.218054] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 8000 [ 22.218054] DMAR:[fault reason 06] PTE Read access is not set [ 22.218083] dmar: DRHD: handling fault status reg 3 [ 22.218089] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 80002000 [ 22.218089] DMAR:[fault reason 06] PTE Read access is not set [ 22.218123] dmar: DRHD: handling fault status reg 3 [ 22.218128] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 80004000 [ 22.218128] DMAR:[fault reason 06] PTE Read access is not set [ 22.218155] dmar: DRHD: handling fault status reg 3 [ 22.218159] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 80006000 [ 22.218159] DMAR:[fault reason 06] PTE Read access is not set [ 22.218169] dmar: DRHD: handling fault status reg 3 [ 22.218173] dmar: DMAR:[DMA Read] Request device [01:00.0] fault addr 80007000 [ 22.218173] DMAR:[fault reason 06] PTE Read access is not set [ 22.218191] dmar: DRHD
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Tuesday, January 22, 2013 6:57 PM To: Deucher, Alexander Cc: Linus Torvalds; Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Tue, Jan 22, 2013 at 11:55 AM, Shuah Khan shuahk...@gmail.com wrote: init: Does the attached patch stop them? It basically skips all initialization of the DMA ring on your system. What I don't understand is why you still get them with the previous patch, but not with 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb reverted. 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb only affects the use of the DMA ring for buffer migration and the patch I previously attached disables the use of the DMA ring for buffer migration. Does the latest batch of drm- fixes from Dave that Linus just merged help? Alex Will try your latest patch. Will also try the latest git - I am currently on Jan 17th. However, in the meantime, I found that these messages might not be new and getting printed now with the eaaa6983ab2ccdf826c90838eb584211e0cadb76 [PATCH] drm/radeon: print dma status reg on lockup (v2) commit that introduced debug messages in r600_gpu_soft_reset(). I couldn't revert this commit, but doing a compile with these messages commented out. Will update you on the results and then test the new git -- Shuah Here is what I tried: 1. Applied your latest disable_dma_ring_on_6xx-2.diff and still see messages. If that is the case, I'm beginning to think the bug is elsewhere. Support for the DMA ring was the only major feature we added in this cycle. If you are still getting errors even with the ring completely disabled, it's probably not the DMA ring. Make sure your kernel has this patch: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=20707874fd4fd37e09513f508e642fa8bd06365a That's the only thing I can think of that may cause the DMAR errors if the DMA ring is disabled. 2. Tried intel_iommu=igfx_off to see if that changes anything. The reason for trying this option is, I noticed this message: (this is not a new message, I see this all the time) [1.337112] DMAR: Disabling IOMMU for graphics on this chipset No change with or without option - still see the same messages. Next steps: 1. One big difference between 3.7 and 3.8 is in the r600_gpu_soft_reset() - I started with 3.7 to see the differences if any of these differences is causing this to be logged. In 3.7 r600_gpu_soft_reset() is called with no reset_mask. I am going to first verify if softreset happens on 3.7. Does this give you any ideas of whether this could cause a problem? I don't think the problem is related to GPU reset. That's for resetting the GPU when it hangs. It changed slightly in 3.8 to accommodate the new DMA engine that we added support for in 3.8. Previously we just reset the graphics engine. 2. Another angle I am looking at is the newly added dev_info(rdev-dev, R_00D034_DMA_STATUS_REG = 0x%08X\n, RREG32(DMA_STATUS_REG)); messages in r600_gpu_soft_reset_dma(). Could it be that these newly added debug messages are now showing this old condition that always existed on my test system. From what I have observed so far, this is very likely. I'm not following. That just prints the DMA status register when we attempt to reset the GPU. It's purely for debugging. Alex Please let me know if you want to me try anything else or if you don't think these steps won't help. -- Shuah -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux 3.8-rc3 reboot and shutdown
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 2:03 PM To: jgli...@redhat.com; Deucher, Alexander Cc: linux-kernel@vger.kernel.org; Shuah Khan Subject: linux 3.8-rc3 reboot and shutdown Alex, I started seeing hang during shutdown and reboot on my laptop that has ATI radeon VGA. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] (prog-if 00 [VGA controller]) My bisect narrowed it to the following commit. Should be fixed by this commit: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8id=19fc42ed9950d5fe17089c0a928121047c882092 Which should be finding its way upstream any day now. Alex shuah@lorien:~/lkml/linus_git_jan1$ git bisect good 71e3d1578c954cf29f1f4db1c8930d3574025eb0 is the first bad commit commit 71e3d1578c954cf29f1f4db1c8930d3574025eb0 Author: Alex Deucher alexander.deuc...@amd.com Date: Thu Jan 3 12:20:35 2013 -0500 drm/radeon: switch to a finer grained reset for r6xx/7xx No change in functionality as we currently set all the reset flags. Reviewed-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 3fa285e9f06de6bb13d711eb87326e821036b0c6 9a9819551f3c7a893f2bfe7094ff0ca84e0e12d2 Mdrivers bisect log: git bisect start '--' 'drivers/gpu/drm/radeon' # good: [d1c3ed669a2d452cacfb48c2d171a1f364dae2ed] Linux 3.8-rc2 git bisect good d1c3ed669a2d452cacfb48c2d171a1f364dae2ed # bad: [9931faca02c604c22335f5a935a501bb2ace6e20] Linux 3.8-rc3 git bisect bad 9931faca02c604c22335f5a935a501bb2ace6e20 # bad: [71e3d1578c954cf29f1f4db1c8930d3574025eb0] drm/radeon: switch to a finer grained reset for r6xx/7xx git bisect bad 71e3d1578c954cf29f1f4db1c8930d3574025eb0 # good: [eaaa6983ab2ccdf826c90838eb584211e0cadb76] drm/radeon: print dma status reg on lockup (v2) git bisect good eaaa6983ab2ccdf826c90838eb584211e0cadb76 # good: [0a9069d34918659bc8a89e21e69e60b2b83291a3] drm/radeon: Properly handle DDC probe for DP bridges git bisect good 0a9069d34918659bc8a89e21e69e60b2b83291a3 # good: [ec46c76d506e845d28d60d0a9f0e993d517030f5] drm/radeon: add GPU reset flags git bisect good ec46c76d506e845d28d60d0a9f0e993d517030f5 I don't have the dmesg from the bad boot. Will gather it shortly. -- Shuah -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: linux 3.8-rc3 reboot and shutdown
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 6:21 PM To: Deucher, Alexander Cc: jgli...@redhat.com; linux-kernel@vger.kernel.org Subject: Re: linux 3.8-rc3 reboot and shutdown On Thu, Jan 17, 2013 at 12:45 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 2:03 PM To: jgli...@redhat.com; Deucher, Alexander Cc: linux-kernel@vger.kernel.org; Shuah Khan Subject: linux 3.8-rc3 reboot and shutdown Alex, I started seeing hang during shutdown and reboot on my laptop that has ATI radeon VGA. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] (prog-if 00 [VGA controller]) My bisect narrowed it to the following commit. Should be fixed by this commit: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes- 3.8id=19fc42ed9950d5fe17089c0a928121047c882092 Which should be finding its way upstream any day now. Alex Alex, Applied this patch on 3.8-rc3 and tested it. reboot still hung. The only thing that fixes the problem is reverting 71e3d1578c954cf29f1f4db1c8930d3574025eb0 Does the attached patch applied in addition to: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.8id=19fc42ed9950d5fe17089c0a928121047c882092 fix the issue? Alex I am also seeing DMAR errors on this device starting 3.8-rc3 and I am going to start bisecting that soon. Reverting 71e3d1578c954cf29f1f4db1c8930d3574025eb0 doesn't help solve the DMAR errors. -- Shuah 0001-drm-radeon-don-t-attempt-to-soft-reset-DMA-ring-on-r.patch Description: 0001-drm-radeon-don-t-attempt-to-soft-reset-DMA-ring-on-r.patch
RE: linux 3.8-rc3 reboot and shutdown
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 7:26 PM To: Deucher, Alexander Cc: jgli...@redhat.com; linux-kernel@vger.kernel.org Subject: Re: linux 3.8-rc3 reboot and shutdown On Thu, Jan 17, 2013 at 4:48 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 6:21 PM To: Deucher, Alexander Cc: jgli...@redhat.com; linux-kernel@vger.kernel.org Subject: Re: linux 3.8-rc3 reboot and shutdown On Thu, Jan 17, 2013 at 12:45 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Thursday, January 17, 2013 2:03 PM To: jgli...@redhat.com; Deucher, Alexander Cc: linux-kernel@vger.kernel.org; Shuah Khan Subject: linux 3.8-rc3 reboot and shutdown Alex, I started seeing hang during shutdown and reboot on my laptop that has ATI radeon VGA. 01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV620 [Mobility Radeon HD 3400 Series] (prog-if 00 [VGA controller]) My bisect narrowed it to the following commit. Should be fixed by this commit: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes- 3.8id=19fc42ed9950d5fe17089c0a928121047c882092 Which should be finding its way upstream any day now. Alex Alex, Applied this patch on 3.8-rc3 and tested it. reboot still hung. The only thing that fixes the problem is reverting 71e3d1578c954cf29f1f4db1c8930d3574025eb0 Does the attached patch applied in addition to: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes- 3.8id=19fc42ed9950d5fe17089c0a928121047c882092 fix the issue? Alex No reboot still hung after applying 0001-drm-radeon-don-t-attempt-to-soft-reset-DMA-ring-on-r.patch in addition to 19fc42ed9950d5fe17089c0a928121047c882092 Can you send me the dmesg from the failed reboot? Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Linux 3.8-rc4
-Original Message- From: Shuah Khan [mailto:shuahk...@gmail.com] Sent: Friday, January 18, 2013 7:40 PM To: Linus Torvalds; Deucher, Alexander Cc: Linux Kernel Mailing List Subject: Re: Linux 3.8-rc4 On Fri, Jan 18, 2013 at 3:37 PM, Shuah Khan shuahk...@gmail.com wrote: On Fri, Jan 18, 2013 at 10:51 AM, Shuah Khan shuahk...@gmail.com wrote: ok. I bisected the DMAR faults and it points to the following commit: 909d9eb67f1e4e39f2ea88e96bde03d560cde3eb This commit as I recall, fixed the crash problem I was seeing back in 3.8-rc1. Reverting to see if crash problem reappears. Confirming that with this commit reverted crash problem re-appeared. With this commit, DMAR faults show up. I'm not quite sure what's going on with your system. At this point it's probably best to just disable the DMA ring on these cards until we sort out what's going on. The attached patch disables the use of the DMA ring. Let me know if it fixes the issues you are seeing. Alex disable_dma_ring_on_6xx.diff Description: disable_dma_ring_on_6xx.diff
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
-Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Monday, September 17, 2012 7:29 AM To: LKML; Deucher, Alexander; David Airlie; dri-de...@lists.freedesktop.org Subject: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL Hi, While debugging another issue I upgraded from v3.6-rc4 to latest git (which exactly is v3.6-rc6). After X started up one of my three monitors blacked out. A look into the kernel log revealed: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are only 2 PLLs for non-DP monitors, so if you are trying to use more than 2 non-DP monitors, it's not supported right now and if it worked before, it was random luck. If you want to use 3+ monitors, only 2 can be non-DP, the rest need to be DP. If you use a DP to DVI/HDMI adapter, it must be active (looks like DP to the GPU), passive adapters just pass through native DVI/HDMI. That said, I've got a set of patches for 3.7 to allow PLL sharing properly for non-DP displays, but it's too invasive for -fixes. Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
-Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Monday, September 17, 2012 9:56 AM To: Deucher, Alexander Cc: LKML; David Airlie; dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote: -Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Monday, September 17, 2012 7:29 AM To: LKML; Deucher, Alexander; David Airlie; dri-de...@lists.freedesktop.org Subject: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL Hi, While debugging another issue I upgraded from v3.6-rc4 to latest git (which exactly is v3.6-rc6). After X started up one of my three monitors blacked out. A look into the kernel log revealed: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are only 2 PLLs for non-DP monitors, so if you are trying to use more than 2 non-DP monitors, it's not supported right now and if it worked before, it was random luck. If you want to use 3+ monitors, only 2 can be non-DP, the rest need to be DP. If you use a DP to DVI/HDMI adapter, it must be active (looks like DP to the GPU), passive adapters just pass through native DVI/HDMI. That said, I've got a set of patches for 3.7 to allow PLL sharing properly for non-DP displays, but it's too invasive for -fixes. 2DVI, 1DP via an supposedly active converter. I can try a native DP cable, its just too short, so I will have to move the monitor to the ground ;) Can I check its really an active connector? Try the attached debugging patch. It will tell us what PPLLs are getting allocated and what type of sink we detect on the DP port (DP or non-DP) The patchset you referenced is in alexdeucher/drm-next-3.7-wip if I saw that correctly? Will test it with a passive connector I have lying arround. Yes. Note that PLLs can only be shared for non-DP monitors if the clocks are the same. Alex debug_dp.diff Description: debug_dp.diff
RE: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL
-Original Message- From: Andres Freund [mailto:and...@anarazel.de] Sent: Monday, September 17, 2012 1:16 PM To: Deucher, Alexander Cc: LKML; David Airlie; dri-de...@lists.freedesktop.org Subject: Re: radeon: Regression between v3.6-rc4 and v3.6-rc6: unable to allocate a PPLL Hi, On Monday, September 17, 2012 04:24:08 PM Deucher, Alexander wrote: On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote: While debugging another issue I upgraded from v3.6-rc4 to latest git (which exactly is v3.6-rc6). After X started up one of my three monitors blacked out. A look into the kernel log revealed: [drm:radeon_atom_pick_pll] *ERROR* unable to allocate a PPLL What 3 monitors are you using (DVI, HDMI, DP, VGA)? Note that there are only 2 PLLs for non-DP monitors, so if you are trying to use more than 2 non-DP monitors, it's not supported right now and if it worked before, it was random luck. If you want to use 3+ monitors, only 2 can be non-DP, the rest need to be DP. If you use a DP to DVI/HDMI adapter, it must be active (looks like DP to the GPU), passive adapters just pass through native DVI/HDMI. That said, I've got a set of patches for 3.7 to allow PLL sharing properly for non-DP displays, but it's too invasive for -fixes. 2DVI, 1DP via an supposedly active converter. I can try a native DP cable, its just too short, so I will have to move the monitor to the ground ;) Can I check its really an active connector? Try the attached debugging patch. It will tell us what PPLLs are getting allocated and what type of sink we detect on the DP port (DP or non-DP) [1.844382] [drm] Initialized drm 1.1.0 20060810 [1.867560] [drm] radeon defaulting to kernel modesetting. [1.890474] [drm] radeon kernel modesetting enabled. [1.913006] fb: conflicting fb hw usage radeondrmfb vs VGA16 VGA - removing generic driver [1.981793] [drm] initializing kernel modesetting (BARTS 0x1002:0x6738 0x174B:0x174B). [1.982323] [drm] register mmio base: 0xFBEC [1.982522] [drm] register mmio size: 131072 [1.983880] [drm] Detected VRAM RAM=1024M, BAR=256M [1.984072] [drm] RAM width 256bits DDR [1.985141] [drm] radeon: 1024M of VRAM memory ready [1.985345] [drm] radeon: 512M of GTT memory ready. [1.985575] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [1.985779] [drm] Driver supports precise vblank timestamp query. [1.986252] [drm] radeon: irq initialized. [1.986454] [drm] GART: num cpu pages 131072, num gpu pages 131072 [1.987226] [drm] probing gen 2 caps for device 8086:340a = 2/0 [1.987426] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [1.987930] [drm] Loading BARTS Microcode [1.990807] [drm] PCIE GART of 512M enabled (table at 0x0004). [2.008503] [drm] ring test on 0 succeeded in 3 usecs [2.009029] [drm] ib test on ring 0 succeeded in 0 usecs [2.009728] [drm] Radeon Display Connectors [2.009914] [drm] Connector 0: [2.010103] [drm] DP-1 [2.010283] [drm] HPD4 [2.010464] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [2.010734] [drm] Encoders: [2.010921] [drm] DFP1: INTERNAL_UNIPHY2 [2.02] [drm] Connector 1: [2.011295] [drm] HDMI-A-1 [2.011478] [drm] HPD3 [2.011662] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [2.011932] [drm] Encoders: [2.012119] [drm] DFP2: INTERNAL_UNIPHY2 [2.012324] [drm] Connector 2: [2.012512] [drm] DVI-D-1 [2.012695] [drm] HPD1 [2.012881] [drm] DDC: 0x6480 0x6480 0x6484 0x6484 0x6488 0x6488 0x648c 0x648c [2.013152] [drm] Encoders: [2.013340] [drm] DFP3: INTERNAL_UNIPHY1 [2.013528] [drm] Connector 3: [2.013712] [drm] DVI-I-1 [2.013898] [drm] HPD6 [2.014082] [drm] DDC: 0x6470 0x6470 0x6474 0x6474 0x6478 0x6478 0x647c 0x647c [2.014352] [drm] Encoders: [2.014538] [drm] DFP4: INTERNAL_UNIPHY [2.014724] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [2.015014] [drm] Internal thermal controller with fan control [2.016370] [drm] radeon: power management initialized [2.022137] [drm] DP sink type 0x13 [2.133666] [drm] fb mappable at 0xD0142000 [2.133793] [drm] vram apper at 0xD000 [2.133919] [drm] size 16384000 [2.134044] [drm] fb depth is 24 [2.134170] [drm]pitch is 10240 [2.134358] fbcon: radeondrmfb (fb0) is primary device [2.134901] [drm] crtc 0 using pll 0x2 [2.362257] [drm] crtc 1 using pll 0x1 [2.386709] [drm] crtc 2 using pll 0x0 [2.472275] fb0: radeondrmfb frame buffer device [2.472300] drm: registered panic notifier [2.472325] [drm] Initialized radeon 2.22.0 20080528 for :08:00.0 on minor 0 [ 60.056358] [drm] DP sink type 0x13
RE: [PATCH] Add 2-level GPUVM pagetables support to radeon driver.
-Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Friday, September 14, 2012 4:49 AM To: Jerome Glisse Cc: Alex Deucher; Cherkasov, Dmitrii; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org; Deucher, Alexander; Dave Airlie; Dmitry Cherkasov Subject: Re: [PATCH] Add 2-level GPUVM pagetables support to radeon driver. On 13.09.2012 20:42, Jerome Glisse wrote: On Thu, Sep 13, 2012 at 2:37 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Thu, Sep 13, 2012 at 2:17 PM, Jerome Glisse j.gli...@gmail.com wrote: On Thu, Sep 13, 2012 at 10:13 AM, Dmitry Cherkasov dcherkas...@gmail.com wrote: PDE/PTE update code uses CP ring for memory writes. All page table entries are preallocated for now in alloc_pt(). It is made as whole because it's hard to divide it to several patches that compile and doesn't break anything being applied separately. Tested on cayman card. Signed-off-by: Dmitry Cherkasov dmitrii.cherka...@amd.com --- I couldn't test in on SI card, so would be happy if someone could check it there. I wonder how this could have work as you don't set PAGE_TABLE_BLOCK_SIZE field so each page directory entry cover only 1 page. I think PAGE_TABLE_BLOCK_SIZE refers number of 4k pages used for PTE entries per PDE. E.g., 1 4k page contains 512 64 bit PTEs. so if BLOCK_SIZE is set to 1 page, each PDE points to 1 page (4k) or PTE entries. If BLOCK_SIZE is 2, each PDE points to 2 pages (8k) or PTEs, etc. Alex If so then it's ok Yeah, minor nitpick: BLOCK_SIZE seems to be number of 4k pages in a page directory entry minus 1. So with a BLOCK_SIZE of 0 you get one 4K page and with a BLOCK_SIZE of 1 you get 8K, etc... It's LOG2: PAGE_TABLE_BLOCK_SIZE 27:24 0x0 log2 number of pages in page table block (default = 1 page) Christian. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH v3 29/32] PCI/radeon: use PCIe capabilities access functions to simplify implementation
-Original Message-
From: Jiang Liu [mailto:liu...@gmail.com]
Sent: Wednesday, August 01, 2012 11:55 AM
To: Bjorn Helgaas; Don Dutile; David Airlie; Dave Airlie; Deucher, Alexander;
Jerome Glisse
Cc: Jiang Liu; Yinghai Lu; Taku Izumi; Rafael J . Wysocki; Kenji Kaneshige;
Yijing
Wang; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; Jiang Liu
Subject: [PATCH v3 29/32] PCI/radeon: use PCIe capabilities access functions
to simplify implementation
From: Jiang Liu jiang@huawei.com
Use PCIe capabilities access functions to simplify radeon driver's
implementation.
Signed-off-by: Jiang Liu liu...@gmail.com
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/evergreen.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 01550d0..8804c80 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -77,13 +77,9 @@ void evergreen_tiling_fields(unsigned tiling_flags,
unsigned *bankw,
void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev)
{
u16 ctl, v;
- int cap, err;
+ int err;
- cap = pci_pcie_cap(rdev-pdev);
- if (!cap)
- return;
-
- err = pci_read_config_word(rdev-pdev, cap + PCI_EXP_DEVCTL,
ctl);
+ err = pci_pcie_capability_read_word(rdev-pdev, PCI_EXP_DEVCTL,
ctl);
if (err)
return;
@@ -95,7 +91,7 @@ void evergreen_fix_pci_max_read_req_size(struct
radeon_device *rdev)
if ((v == 0) || (v == 6) || (v == 7)) {
ctl = ~PCI_EXP_DEVCTL_READRQ;
ctl |= (2 12);
- pci_write_config_word(rdev-pdev, cap + PCI_EXP_DEVCTL,
ctl);
+ pci_pcie_capability_write_word(rdev-pdev,
PCI_EXP_DEVCTL, ctl);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec
-Original Message- From: Boszormenyi Zoltan [mailto:zbos...@pr.hu] Sent: Thursday, January 03, 2013 6:37 AM To: Alex Deucher Cc: Markus Trippelsdorf; lkml; dri-de...@lists.freedesktop.org; Deucher, Alexander; Borislav Petkov; Shuah Khan Subject: Re: radeon :02:00.0: GPU lockup CP stall for more than 1msec 2013-01-03 00:37 keltezéssel, Alex Deucher írta: On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy- on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 1061-1062 in radeon_asic.c is : .copy = r600_copy_dma, .copy_ring_index = R600_RING_TYPE_DMA_INDEX, It fixes the issue for me. Thanks. The count is actually the count, not count - 1. The real fix seems to be that r6xx requires 2 dw aligned transfers. The attached patch fixes the issue for me. Alex I tried this patch over kernel 3.8.0-rc2 but the GDM screen is mostly garbage. Only some text, like Not on the list? below the users and small icons are visible but many user names are not rendered. http://tinypic.com/r/33xihit/6 I am on Fedora 18/x86_64, Radeon HD6570. I don't think the issue you are seeing is related to this one. Looks similar to: https://bugs.freedesktop.org/show_bug.cgi?id=55574 Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Asus F5RL laptop unable to resume from S3 because of radeon module
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Friday, August 23, 2013 1:55 PM
To: Deucher, Alexander
Cc: Kernel development list
Subject: Re: Asus F5RL laptop unable to resume from S3 because of radeon
module
On Friday 23 August 2013 00:08:33 Ondrej Zary wrote:
On Thursday 22 August 2013 22:56:03 Ondrej Zary wrote:
On Thursday 22 August 2013 22:24:17 Deucher, Alexander wrote:
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Thursday, August 22, 2013 4:00 PM
To: Deucher, Alexander
Cc: Kernel development list
Subject: Re: Asus F5RL laptop unable to resume from S3 because of
radeon module
On Thursday 22 August 2013 21:49:41 Deucher, Alexander wrote:
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Thursday, August 22, 2013 2:18 PM
To: Kernel development list
Cc: Deucher, Alexander
Subject: Asus F5RL laptop unable to resume from S3 because of
radeon module
Hello,
resume from suspend-to-RAM (S3) on Asus F5RL laptop does not
work. According to many reports found by Google, it was always
been that and there
is no fix or workaround.
Make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
it /? id=c ef1d00cd56f600121ad121875655ad410a001b8
Just tried latest git (3.11-rc6+) and the problem persists.
You might try adding a quirk for your system in
radeon_combios_asic_init() in radeon_combios.c. You can try
something
like this for testing:
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c index 68ce360..0419a2c
100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3398,6 +3398,8 @@ void radeon_combios_asic_init(struct
drm_device
*dev) rdev-pdev-subsystem_device == 0x30ae)
return;
+ return;
+
/* DYN CLK 1 */
table = combios_get_table_offset(dev,
COMBIOS_DYN_CLK_1_TABLE);
if (table)
If that doesn't work, you'll probably have to track down where it's
hanging during resume, or compare registers before and after resume
to
see if it's some particular state that's causing a problem.
No change.
Inserted return -1; before radeon_device_init() to
radeon_driver_load_kms() - driver fails to load and resume works.
Moved it (and changed to r = -1; goto out;) a bit down before
radeon_modeset_init() - driver fails to load and resume stopped
working.
Going deeper... it works before rs400_startup() and does not work after
that. Will continue later.
Tracked the problem down to rs400_gart_enable(). When this Disable AGP
mode
code is commented out, the machine resumes fine:
if ((rdev-family == CHIP_RS690) || (rdev-family == CHIP_RS740)) {
WREG32_MC(RS480_MC_MISC_CNTL,
(RS480_GART_INDEX_REG_EN | RS690_BLOCK_GFX_D3_EN));
} else {
WREG32_MC(RS480_MC_MISC_CNTL, RS480_GART_INDEX_REG_EN);
}
Does the driver work properly after resume with that part commented out or does
it just avoid the hang?
Alex
Alex
Alex
Did some tests:
radeon module loaded (usual state):
After echo mem/sys/power/state, the laptop suspends
correctly
(power
LED
blinks). When power button is pressed, power LED goes on and
that's all. No more activity, machine is frozen completely.
radeon module not loaded at all:
Laptop resumes correctly (keyboard LED work, network works),
only
the
LCD
is
blank (obviously). Loading radeon module now initializes the card
properly: LCD goes on and console works.
radeon module loaded (but fbcon module not loaded) and then
unloaded:
Machine freezes the same way as when the module is loaded.
So it looks like the radeon module does some initialization that
prevents resume from working.
Hibernation works fine.
Any ideas what to test or how to debug this?
Details:
01:05.0 VGA compatible controller [0300]: Advanced Micro
Devices,
Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M]
[1002:5a62]
(prog-if
00
[VGA controller])
Subsystem: ASUSTeK Computer Inc. Device [1043:1402]
Flags: bus master, 66MHz, medium devsel, latency 64, IRQ
10 Memory at c000 (32-bit, prefetchable) [size=256M] I/O
ports at 9800 [size=256]
Memory at fa8f (32-bit, non-prefetchable) [size=64K]
Expansion ROM at fa8c
RE: Asus F5RL laptop unable to resume from S3 because of radeon module
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Monday, August 26, 2013 5:23 PM
To: Deucher, Alexander
Cc: Kernel development list
Subject: Re: Asus F5RL laptop unable to resume from S3 because of radeon
module
On Monday 26 August 2013 00:01:11 Ondrej Zary wrote:
On Sunday 25 August 2013 19:12:32 Ondrej Zary wrote:
On Sunday 25 August 2013 16:51:06 Deucher, Alexander wrote:
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Friday, August 23, 2013 1:55 PM
To: Deucher, Alexander
Cc: Kernel development list
Subject: Re: Asus F5RL laptop unable to resume from S3 because of
radeon module
On Friday 23 August 2013 00:08:33 Ondrej Zary wrote:
On Thursday 22 August 2013 22:56:03 Ondrej Zary wrote:
On Thursday 22 August 2013 22:24:17 Deucher, Alexander wrote:
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Thursday, August 22, 2013 4:00 PM
To: Deucher, Alexander
Cc: Kernel development list
Subject: Re: Asus F5RL laptop unable to resume from S3
because of radeon module
On Thursday 22 August 2013 21:49:41 Deucher, Alexander
wrote:
-Original Message-
From: Ondrej Zary [mailto:li...@rainbow-software.org]
Sent: Thursday, August 22, 2013 2:18 PM
To: Kernel development list
Cc: Deucher, Alexander
Subject: Asus F5RL laptop unable to resume from S3
because of radeon module
Hello,
resume from suspend-to-RAM (S3) on Asus F5RL laptop
does
not work. According to many reports found by Google, it
was always been that and there
is no fix or workaround.
Make sure your kernel has this patch:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.
gi t/ comm it /? id=c
ef1d00cd56f600121ad121875655ad410a001b8
Just tried latest git (3.11-rc6+) and the problem persists.
You might try adding a quirk for your system in
radeon_combios_asic_init() in radeon_combios.c. You can try
something
like this for testing:
diff --git a/drivers/gpu/drm/radeon/radeon_combios.c
b/drivers/gpu/drm/radeon/radeon_combios.c index
68ce360..0419a2c
100644
--- a/drivers/gpu/drm/radeon/radeon_combios.c
+++ b/drivers/gpu/drm/radeon/radeon_combios.c
@@ -3398,6 +3398,8 @@ void radeon_combios_asic_init(struct
drm_device
*dev) rdev-pdev-subsystem_device == 0x30ae)
return;
+ return;
+
/* DYN CLK 1 */
table = combios_get_table_offset(dev,
COMBIOS_DYN_CLK_1_TABLE);
if (table)
If that doesn't work, you'll probably have to track down where
it's hanging during resume, or compare registers before and
after resume
to
see if it's some particular state that's causing a problem.
No change.
Inserted return -1; before radeon_device_init() to
radeon_driver_load_kms() - driver fails to load and resume works.
Moved it (and changed to r = -1; goto out;) a bit down before
radeon_modeset_init() - driver fails to load and resume stopped
working.
Going deeper... it works before rs400_startup() and does not work
after that. Will continue later.
Tracked the problem down to rs400_gart_enable(). When this
Disable
AGP mode
code is commented out, the machine resumes fine:
if ((rdev-family == CHIP_RS690) || (rdev-family ==
CHIP_RS740)) { WREG32_MC(RS480_MC_MISC_CNTL,
(RS480_GART_INDEX_REG_EN |
RS690_BLOCK_GFX_D3_EN)); } else {
WREG32_MC(RS480_MC_MISC_CNTL,
RS480_GART_INDEX_REG_EN);
}
Does the driver work properly after resume with that part commented
out
or does it just avoid the hang?
Console seems to work fine, haven't tested X, 3D or video.
Testing it right now - everything seems to work. X, accelerated video
(mplayer), 3D (glxgears). Both before and after suspend.
That code does something with GART so maybe I should test something
like
OpenArena (have to download it first).
OpenArena works fine with the code commented out. Both before and after
suspend.
Does the attached patch also work? I suspect we should be RMWing the register
rather than only setting that bit.
Alex
Alex
Alex
Alex
Did some tests:
radeon module loaded (usual state):
After echo mem/sys/power/state, the laptop suspends
RE: Asus F5RL laptop unable to resume from S3 because of radeon module
-Original Message- From: Ondrej Zary [mailto:li...@rainbow-software.org] Sent: Thursday, August 22, 2013 2:18 PM To: Kernel development list Cc: Deucher, Alexander Subject: Asus F5RL laptop unable to resume from S3 because of radeon module Hello, resume from suspend-to-RAM (S3) on Asus F5RL laptop does not work. According to many reports found by Google, it was always been that and there is no fix or workaround. Make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=cef1d00cd56f600121ad121875655ad410a001b8 Alex Did some tests: radeon module loaded (usual state): After echo mem/sys/power/state, the laptop suspends correctly (power LED blinks). When power button is pressed, power LED goes on and that's all. No more activity, machine is frozen completely. radeon module not loaded at all: Laptop resumes correctly (keyboard LED work, network works), only the LCD is blank (obviously). Loading radeon module now initializes the card properly: LCD goes on and console works. radeon module loaded (but fbcon module not loaded) and then unloaded: Machine freezes the same way as when the module is loaded. So it looks like the radeon module does some initialization that prevents resume from working. Hibernation works fine. Any ideas what to test or how to debug this? Details: 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M] [1002:5a62] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1402] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at 9800 [size=256] Memory at fa8f (32-bit, non-prefetchable) [size=64K] Expansion ROM at fa8c [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit- Kernel driver in use: radeon [4.836009] [drm] radeon kernel modesetting enabled. [4.837169] [drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1402). [4.837251] [drm] register mmio base: 0xFA8F [4.837302] [drm] register mmio size: 65536 [4.837570] [drm] Generation 2 PCI interface, using max accessible memory [4.837653] radeon :01:05.0: VRAM: 128M 0x7800 - 0x7FFF (128M used) [4.837714] radeon :01:05.0: GTT: 512M 0x8000 - 0x9FFF [4.837787] [drm] Detected VRAM RAM=128M, BAR=256M [4.837839] [drm] RAM width 128bits DDR [4.839854] [TTM] Zone kernel: Available graphics memory: 444588 kiB [4.839907] [TTM] Zone highmem: Available graphics memory: 972784 kiB [4.839959] [TTM] Initializing pool allocator [4.840042] [drm] radeon: 128M of VRAM memory ready [4.840094] [drm] radeon: 512M of GTT memory ready. [4.840160] [drm] GART: num cpu pages 131072, num gpu pages 131072 [4.866905] [drm] radeon: 2 quad pipes, 1 z pipes initialized. [4.872945] [drm] PCIE GART of 512M enabled (table at 0x35A0). [4.873213] radeon :01:05.0: WB enabled [4.873301] radeon :01:05.0: fence driver on ring 0 use gpu addr 0x8000 and cpu addr 0xf592c000 [4.874929] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.874988] [drm] Driver supports precise vblank timestamp query. [4.875055] [drm] radeon: irq initialized. [4.875119] [drm] Loading R300 Microcode [4.962083] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [5.088150] ohci-pci: OHCI PCI platform driver [5.141799] [drm] radeon: ring at 0x80001000 [5.141883] [drm] ring test succeeded in 2 usecs [5.142064] spurious 8259A interrupt: IRQ7. [5.142073] [drm] ib test succeeded in 0 usecs [5.142317] [drm] Panel ID String: LPL [5.142370] [drm] Panel Size 1280x800 [5.166305] [drm] radeon legacy LVDS backlight initialized [5.166358] [drm] Radeon Display Connectors [5.166408] [drm] Connector 0: [5.166458] [drm] VGA-1 [5.166509] [drm] DDC: 0x68 0x68 0x68 0x68 0x68 0x68 0x68 0x68 [5.166560] [drm] Encoders: [5.166610] [drm] CRT1: INTERNAL_DAC2 [5.10] [drm] Connector 1: [5.166710] [drm] LVDS-1 [5.166760] [drm] DDC: 0x198 0x198 0x19c 0x19c 0x1a0 0x1a0 0x1a4 0x1a4 [5.166812] [drm] Encoders: [5.166862] [drm] LCD1: INTERNAL_LVDS [5.426968] [drm] fb mappable at 0xC004 [5.427026] [drm] vram apper at 0xC000 [5.427076] [drm] size 4096000 [5.427126] [drm] fb depth is 24 [5.427176] [drm]pitch is 5120 [5.427388] radeon :01:05.0: fb0: radeondrmfb frame buffer device [5.427442] radeon :01:05.0: registered panic notifier [5.427501] [drm] Initialized radeon 2.34.0 20080528 for
RE: Asus F5RL laptop unable to resume from S3 because of radeon module
-Original Message- From: Ondrej Zary [mailto:li...@rainbow-software.org] Sent: Thursday, August 22, 2013 4:00 PM To: Deucher, Alexander Cc: Kernel development list Subject: Re: Asus F5RL laptop unable to resume from S3 because of radeon module On Thursday 22 August 2013 21:49:41 Deucher, Alexander wrote: -Original Message- From: Ondrej Zary [mailto:li...@rainbow-software.org] Sent: Thursday, August 22, 2013 2:18 PM To: Kernel development list Cc: Deucher, Alexander Subject: Asus F5RL laptop unable to resume from S3 because of radeon module Hello, resume from suspend-to-RAM (S3) on Asus F5RL laptop does not work. According to many reports found by Google, it was always been that and there is no fix or workaround. Make sure your kernel has this patch: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c ef1d00cd56f600121ad121875655ad410a001b8 Just tried latest git (3.11-rc6+) and the problem persists. You might try adding a quirk for your system in radeon_combios_asic_init() in radeon_combios.c. You can try something like this for testing: diff --git a/drivers/gpu/drm/radeon/radeon_combios.c b/drivers/gpu/drm/radeon/radeon_combios.c index 68ce360..0419a2c 100644 --- a/drivers/gpu/drm/radeon/radeon_combios.c +++ b/drivers/gpu/drm/radeon/radeon_combios.c @@ -3398,6 +3398,8 @@ void radeon_combios_asic_init(struct drm_device *dev) rdev-pdev-subsystem_device == 0x30ae) return; + return; + /* DYN CLK 1 */ table = combios_get_table_offset(dev, COMBIOS_DYN_CLK_1_TABLE); if (table) If that doesn't work, you'll probably have to track down where it's hanging during resume, or compare registers before and after resume to see if it's some particular state that's causing a problem. Alex Alex Did some tests: radeon module loaded (usual state): After echo mem/sys/power/state, the laptop suspends correctly (power LED blinks). When power button is pressed, power LED goes on and that's all. No more activity, machine is frozen completely. radeon module not loaded at all: Laptop resumes correctly (keyboard LED work, network works), only the LCD is blank (obviously). Loading radeon module now initializes the card properly: LCD goes on and console works. radeon module loaded (but fbcon module not loaded) and then unloaded: Machine freezes the same way as when the module is loaded. So it looks like the radeon module does some initialization that prevents resume from working. Hibernation works fine. Any ideas what to test or how to debug this? Details: 01:05.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] RC410M [Mobility Radeon Xpress 200M] [1002:5a62] (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. Device [1043:1402] Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 10 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at 9800 [size=256] Memory at fa8f (32-bit, non-prefetchable) [size=64K] Expansion ROM at fa8c [disabled] [size=128K] Capabilities: [50] Power Management version 2 Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit- Kernel driver in use: radeon [4.836009] [drm] radeon kernel modesetting enabled. [4.837169] [drm] initializing kernel modesetting (RS400 0x1002:0x5A62 0x1043:0x1402). [4.837251] [drm] register mmio base: 0xFA8F [4.837302] [drm] register mmio size: 65536 [4.837570] [drm] Generation 2 PCI interface, using max accessible memory [4.837653] radeon :01:05.0: VRAM: 128M 0x7800 - 0x7FFF (128M used) [4.837714] radeon :01:05.0: GTT: 512M 0x8000 - 0x9FFF [4.837787] [drm] Detected VRAM RAM=128M, BAR=256M [4.837839] [drm] RAM width 128bits DDR [4.839854] [TTM] Zone kernel: Available graphics memory: 444588 kiB [4.839907] [TTM] Zone highmem: Available graphics memory: 972784 kiB [4.839959] [TTM] Initializing pool allocator [4.840042] [drm] radeon: 128M of VRAM memory ready [4.840094] [drm] radeon: 512M of GTT memory ready. [4.840160] [drm] GART: num cpu pages 131072, num gpu pages 131072 [4.866905] [drm] radeon: 2 quad pipes, 1 z pipes initialized. [4.872945] [drm] PCIE GART of 512M enabled (table at 0x35A0). [4.873213] radeon :01:05.0: WB enabled [4.873301] radeon :01:05.0: fence driver on ring 0 use gpu addr 0x8000 and cpu addr 0xf592c000 [4.874929] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [4.874988] [drm] Driver supports precise vblank timestamp query. [4.875055] [drm] radeon: irq initialized
RE: [PATCH 3.11-rc3+] radeon: si_dpm: Fix 32 bit __divdi3 modpost failure
I've already got the fix queued in my -fixes branch: http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-fixes-3.11id=1d2867b98372929129c7f2ce2c83a9b446a1b43a -Original Message- From: Tim Gardner [mailto:tim.gard...@canonical.com] Sent: Thursday, August 01, 2013 11:26 AM To: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org Cc: Tim Gardner; David Airlie; Deucher, Alexander Subject: [PATCH 3.11-rc3+] radeon: si_dpm: Fix 32 bit __divdi3 modpost failure ERROR: __divdi3 [drivers/gpu/drm/radeon/radeon.ko] undefined! make[3]: *** [__modpost] Error 1 gcc version 4.8.1 Cc: David Airlie airl...@linux.ie Cc: Alex Deucher alexander.deuc...@amd.com Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/gpu/drm/radeon/si_dpm.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index 7ad22e87..4182557 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -1767,7 +1767,7 @@ static void si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe s64 temperature, t_slope, t_intercept, av, bv, t_ref; s64 tmp; - i_leakage = drm_int2fixp(ileakage) / 100; + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); vddc = div64_s64(drm_int2fixp(v), 1000); temperature = div64_s64(drm_int2fixp(t), 1000); -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Regression: 3.9.0+ .. 3.10-rc5 freezes during boot, Radeon update ??
-Original Message- From: Jim Bos [mailto:jim...@xs4all.nl] Sent: Sunday, June 16, 2013 6:59 AM To: Linux Kernel Mailing List Cc: Koenig, Christian; Jerome Glisse; Deucher, Alexander Subject: Regression: 3.9.0+ .. 3.10-rc5 freezes during boot, Radeon update ?? Was about to test 3.10-rc5 but kernel freezes during boot. With freeze, I mean I've to hit reset button to recover, system is basically dead, last line on the screen is: Does it eventually boot after several minutes? You may be seeing a timeout from the firmware loader as it tries to load the new ucode for the UVD block. Make sure you have the latest REDWOOD_rlc.bin and CYPRESS_uvd.bin files from the Linux firmware tree. Alex -- fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver -- With a *working* boot on plain 3.9.0 I get this: [0.390471] efifb: probing for efifb [0.390835] efifb: framebuffer at 0xc000, mapped to 0xc9001118, using 6144k, total 16384k [0.390837] efifb: mode is 1024x768x32, linelength=4096, pages=1 [0.390839] efifb: scrolling: redraw [0.390840] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0 [0.392203] Console: switching to colour frame buffer device 128x48 [0.393461] fb0: EFI VGA frame buffer device [0.393476] intel_idle: MWAIT substates: 0x1120 [0.393477] intel_idle: v0.4 model 0x2A [0.393478] intel_idle: lapic_timer_reliable_states 0x [0.393524] input: Power Button as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0 [0.393549] ACPI: Power Button [PWRB] [0.393578] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input1 [0.393599] ACPI: Power Button [PWRF] [0.393645] ACPI: Requesting acpi_cpufreq [0.394908] GHES: HEST is not enabled! [0.401581] Serial: 8250/16550 driver, 8 ports, IRQ sharing enabled [0.422148] 00:02: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A [0.422488] [drm] Initialized drm 1.1.0 20060810 [0.422508] [drm] radeon kernel modesetting enabled. [0.422538] checking generic (c000 60) vs hw (c000 1000) [0.422539] fb: conflicting fb hw usage radeondrmfb vs EFI VGA - removing generic driver here it stops for the failing boot [0.422566] Console: switching to colour dummy device 80x25 [0.422680] [drm] initializing kernel modesetting (REDWOOD 0x1002:0x68D8 0x1682:0x3065). [0.422693] [drm] register mmio base: 0xFE62 [0.422695] [drm] register mmio size: 131072 [0.422735] ATOM BIOS: REDWOOD [0.422764] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [0.422766] radeon :01:00.0: GTT: 512M 0x4000 - 0x5FFF This is the last step in git-bisect: # git bisect good f2ba57b5eab8817d86d0f108fdf1878e51dc0a37 is the first bad commit commit f2ba57b5eab8817d86d0f108fdf1878e51dc0a37 Author: Christian König deathsim...@vodafone.de Date: Mon Apr 8 12:41:29 2013 +0200 drm/radeon: UVD bringup v8 Just everything needed to decode videos using UVD. v6: just all the bugfixes and support for R7xx-SI merged in one patch v7: UVD_CGC_GATE is a write only register, lockup detection fix v8: split out VRAM fallback changes, remove support for RV770, add support for HEMLOCK, add buffer sizes checks Signed-off-by: Christian König christian.koe...@amd.com Reviewed-by: Jerome Glisse jgli...@redhat.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 1bfd368f291a2cfd7d0ebeb70c9109dfd6ebb97d e4307ff6aa51cf9831815528b7dcf802dd045022 M drivers :04 04 1e16513d7c6ac3bde842a2ef9e9993ddfeb3faab 8a79c88d63cce4341a3885effcb69024d6d36917 M include I have these firmware files: # ls -l firmware/radeon/REDWOOD_*bin -rw-r--r-- 1 root root 5504 Jul 22 2012 firmware/radeon/REDWOOD_me.bin -rw-r--r-- 1 root root 4480 Jul 22 2012 firmware/radeon/REDWOOD_pfp.bin -rw-r--r-- 1 root root 3072 Apr 6 11:58 firmware/radeon/REDWOOD_rlc.bin and they are builtin into the kernel: # egrep RADEON|EXTRA_FIRMWARE|KMS|^CONFIG_FB_ .config CONFIG_EXTRA_FIRMWARE=radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin CONFIG_EXTRA_FIRMWARE_DIR=firmware CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_RADEON=y # CONFIG_DRM_RADEON_UMS is not set CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y CONFIG_FB_VESA=y CONFIG_FB_EFI=y # CONFIG_FB_RADEON is not set Anything else I can provide ? _ Jim -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 6/6] radeon: Use pcie_get_readrq() and pcie_set_readrq() to simplify code
-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: Friday, October 04, 2013 4:45 PM
To: Yijing Wang
Cc: David Airlie; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org;
Hanjun Guo; Deucher, Alexander; Koenig, Christian
Subject: Re: [PATCH 6/6] radeon: Use pcie_get_readrq() and
pcie_set_readrq() to simplify code
[-cc unrelated folks, +cc Alex, Christian]
On Mon, Sep 9, 2013 at 7:13 AM, Yijing Wang wangyij...@huawei.com
wrote:
Use pcie_get_readrq() and pcie_set_readrq() functions to simplify code.
Signed-off-by: Yijing Wang wangyij...@huawei.com
I believe the following patch is correct, and I'd be happy to merge it
via the PCI tree along with the rest of this series.
But it'd be better to have an ack from Alex, and he might prefer to
merge it directly.
Patch looks correct to me. Feel free to merge it via the pci tree.
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Bjorn
---
drivers/gpu/drm/radeon/evergreen.c | 19 ++-
1 files changed, 6 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index d5b49e3..b191f92 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1169,23 +1169,16 @@ int evergreen_set_uvd_clocks(struct
radeon_device *rdev, u32 vclk, u32 dclk)
void evergreen_fix_pci_max_read_req_size(struct radeon_device *rdev)
{
- u16 ctl, v;
- int err;
-
- err = pcie_capability_read_word(rdev-pdev, PCI_EXP_DEVCTL, ctl);
- if (err)
- return;
-
- v = (ctl PCI_EXP_DEVCTL_READRQ) 12;
+ int readrq;
+ u16 v;
+ readrq = pcie_get_readrq(rdev-pdev);
+ v = ffs(readrq) - 8;
/* if bios or OS sets MAX_READ_REQUEST_SIZE to an invalid value,
fix it
* to avoid hangs or perfomance issues
*/
- if ((v == 0) || (v == 6) || (v == 7)) {
- ctl = ~PCI_EXP_DEVCTL_READRQ;
- ctl |= (2 12);
- pcie_capability_write_word(rdev-pdev, PCI_EXP_DEVCTL, ctl);
- }
+ if ((v == 0) || (v == 6) || (v == 7))
+ pcie_set_readrq(rdev-pdev, 512);
}
static bool dce4_is_in_vblank(struct radeon_device *rdev, int crtc)
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: build failure after merge of the final tree (drm tree related)
-Original Message-
From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
Sent: Monday, September 02, 2013 5:01 AM
To: Dave Airlie
Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher,
Alexander
Subject: linux-next: build failure after merge of the final tree (drm tree
related)
Hi all,
After merging the final tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/gpu/drm/radeon/ci_dpm.c: In function
'ci_request_link_speed_change_before_state_change':
drivers/gpu/drm/radeon/ci_dpm.c:4212:4: error: implicit declaration of
function 'radeon_acpi_pcie_performance_request' [-Werror=implicit-
function-declaration]
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN3, false) == 0)
^
Caused by commit cc8dbbb4f62a (drm/radeon: add dpm support for CI
dGPUs
(v2)). These calls need protecting with CONFIG_ACPI (like is done in
cypress_dpm.c, I guess).
I tried reverting commit 9c725e5bcdae (Merge branch 'drm-next-3.12' of
git://people.freedesktop.org/~agd5f/linux into drm-next) but that failed
because that branch is based on v3.11-rc7 (!) which is later than the
base of the drm tree (v3.11-rc3). :-(
I added this fix up patch for today (it may be wrong, butfixes the build
failure).
From: Stephen Rothwell s...@canb.auug.org.au
Date: Mon, 2 Sep 2013 18:57:41 +1000
Subject: [PATCH] drm/radeon: protect ACPI calls with CONFIG_ACPI
Signed-off-by: Stephen Rothwell s...@canb.auug.org.au
The patch looks fine.
Thanks,
Alex
---
drivers/gpu/drm/radeon/ci_dpm.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
b/drivers/gpu/drm/radeon/ci_dpm.c
index 916630f..3cce533 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -4208,6 +4208,7 @@ static void
ci_request_link_speed_change_before_state_change(struct radeon_devic
pi-pspp_notify_required = false;
if (target_link_speed current_link_speed) {
switch (target_link_speed) {
+#ifdef CONFIG_ACPI
case RADEON_PCIE_GEN3:
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN3, false) == 0)
break;
@@ -4217,6 +4218,7 @@ static void
ci_request_link_speed_change_before_state_change(struct radeon_devic
case RADEON_PCIE_GEN2:
if (radeon_acpi_pcie_performance_request(rdev,
PCIE_PERF_REQ_PECI_GEN2, false) == 0)
break;
+#endif
default:
pi-force_pcie_gen =
ci_get_current_pcie_speed(rdev);
break;
@@ -4248,7 +4250,9 @@ static void
ci_notify_link_speed_change_after_state_change(struct radeon_device
(ci_get_current_pcie_speed(rdev) 0))
return;
+#ifdef CONFIG_ACPI
radeon_acpi_pcie_performance_request(rdev, request,
false);
+#endif
}
}
--
1.8.4.rc3
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH -next] drm/radeon/dpm: Add missing #include linux/seq_file.h
-Original Message- From: Geert Uytterhoeven [mailto:ge...@linux-m68k.org] Sent: Friday, July 05, 2013 7:25 AM To: Deucher, Alexander; David Airlie Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; linux- n...@vger.kernel.org; Geert Uytterhoeven Subject: [PATCH -next] drm/radeon/dpm: Add missing #include linux/seq_file.h ia64_defconfig: drivers/gpu/drm/radeon/rv6xx_dpm.c: In function 'rv6xx_dpm_debugfs_print_current_performance_level': drivers/gpu/drm/radeon/rv6xx_dpm.c:2041:3: error: implicit declaration of function 'seq_printf' [-Werror=implicit-function-declaration] Already fixed in: http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-nextid=bf0936e196ec21b604106578043d4c14831f99e7 Alex Signed-off-by: Geert Uytterhoeven ge...@linux-m68k.org --- http://kisskb.ellerman.id.au/kisskb/buildresult/9068726/ drivers/gpu/drm/radeon/rv6xx_dpm.c |1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/rv6xx_dpm.c b/drivers/gpu/drm/radeon/rv6xx_dpm.c index 33705c5..0d09677 100644 --- a/drivers/gpu/drm/radeon/rv6xx_dpm.c +++ b/drivers/gpu/drm/radeon/rv6xx_dpm.c @@ -22,6 +22,7 @@ * Authors: Alex Deucher */ +#include linux/seq_file.h #include drmP.h #include radeon.h #include rv6xxd.h -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 32/85] drivers: gpu: Move prototype declarations to header file atombios.h
-Original Message-
From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
Sent: Monday, January 06, 2014 10:38 AM
To: linux-kernel@vger.kernel.org
Cc: David Airlie; Deucher, Alexander; Rashika Kheria; Daenzer, Michel;
Koenig, Christian; Dave Airlie; Rafał Miłecki; Damien Lespiau; dri-
de...@lists.freedesktop.org; j...@joshtriplett.org
Subject: [PATCH 32/85] drivers: gpu: Move prototype declarations to header
file atombios.h
Move prototype declarations of functions radeon_atom_get_tv_timings()
and radeon_atombios_connected_scratch_regs() to header file
drm/radeon/atombios.h because they are used by more than one file.
Include the header file in atombios_encoders.c, radeon_atombios.c and
radeon_connectors.c because they use the function whose prototype
declarations are present in it.
It would be better to add these to radeon_mode.h for consistency with combios.
Alex
This eliminates the following warnings in drm/radeon/radeon_atombios.c:
drivers/gpu/drm/radeon/radeon_atombios.c:1766:6: warning: no previous
prototype for ‘radeon_atom_get_tv_timings’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/radeon_atombios.c:4012:1: warning: no previous
prototype for ‘radeon_atombios_connected_scratch_regs’ [-Wmissing-
prototypes]
Signed-off-by: Rashika Kheria rashika.khe...@gmail.com
Reviewed-by: Josh Triplett j...@joshtriplett.org
---
drivers/gpu/drm/radeon/atombios.h |8
drivers/gpu/drm/radeon/atombios_encoders.c |6 +-
drivers/gpu/drm/radeon/radeon_atombios.c |1 +
drivers/gpu/drm/radeon/radeon_connectors.c |5 +
4 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios.h
b/drivers/gpu/drm/radeon/atombios.h
index 92be50c..72a3aa7c 100644
--- a/drivers/gpu/drm/radeon/atombios.h
+++ b/drivers/gpu/drm/radeon/atombios.h
@@ -193,6 +193,14 @@
#define OFFSET_TO_GET_ATOMBIOS_STRINGS_NUMBER
0x002f
#define OFFSET_TO_GET_ATOMBIOS_STRINGS_START
0x006e
+bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
+ struct drm_display_mode *mode);
+void
+radeon_atombios_connected_scratch_regs(struct drm_connector
*connector,
+struct drm_encoder *encoder,
+bool connected);
+
+
/* Common header for all ROM Data tables.
Every table pointed _ATOM_MASTER_DATA_TABLE has this common
header.
And the pointer actually points to this header. */
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c
b/drivers/gpu/drm/radeon/atombios_encoders.c
index a42d615..641298d 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -28,6 +28,7 @@
#include drm/radeon_drm.h
#include radeon.h
#include atom.h
+#include atombios.h
#include linux/backlight.h
extern int atom_debug;
@@ -283,11 +284,6 @@ static void radeon_atom_backlight_exit(struct
radeon_encoder *encoder)
#endif
-/* evil but including atombios.h is much worse */
-bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index,
- struct drm_display_mode *mode);
-
-
static inline bool radeon_encoder_is_digital(struct drm_encoder *encoder)
{
struct radeon_encoder *radeon_encoder =
to_radeon_encoder(encoder);
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 5c39bf7..39f1fd6 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -28,6 +28,7 @@
#include radeon.h
#include atom.h
+#include atombios.h
#include atom-bits.h
/* from radeon_encoder.c */
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 20a768a..9070487 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -30,6 +30,7 @@
#include drm/radeon_drm.h
#include radeon.h
#include atom.h
+#include atombios.h
#include linux/pm_runtime.h
@@ -37,10 +38,6 @@ extern void
radeon_combios_connected_scratch_regs(struct drm_connector
*connector,
struct drm_encoder *encoder,
bool connected);
-extern void
-radeon_atombios_connected_scratch_regs(struct drm_connector
*connector,
-struct drm_encoder *encoder,
-bool connected);
void radeon_connector_hotplug(struct drm_connector *connector)
{
--
1.7.9.5
RE: drm/radeon/dpm: fix uninitialized read from stack in kv_dpm_late_enable
-Original Message-
From: Dave Jones [mailto:da...@redhat.com]
Sent: Thursday, January 30, 2014 9:18 PM
To: Linux Kernel Mailing List
Cc: Deucher, Alexander
Subject: drm/radeon/dpm: fix uninitialized read from stack in
kv_dpm_late_enable
If we take the false branch of the if quoted in the diff below, we
end up doing a return ret, without ever having initialized it.
Picked up by coverity.
Signed-off-by: Dave Jones da...@fedoraproject.org
Applied. Thanks!
Alex
diff --git a/drivers/gpu/drm/radeon/kv_dpm.c
b/drivers/gpu/drm/radeon/kv_dpm.c
index b6e01d5d2cce..351db361239d 100644
--- a/drivers/gpu/drm/radeon/kv_dpm.c
+++ b/drivers/gpu/drm/radeon/kv_dpm.c
@@ -1223,7 +1223,7 @@ int kv_dpm_enable(struct radeon_device *rdev)
int kv_dpm_late_enable(struct radeon_device *rdev)
{
- int ret;
+ int ret = 0;
if (rdev-irq.installed
r600_is_internal_thermal_sensor(rdev-pm.int_thermal_type)) {
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: Radeon crash with v3.13-rc3-157-g17b2112
-Original Message- From: jwbo...@gmail.com [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer Sent: Tuesday, December 10, 2013 5:04 PM To: Deucher, Alexander; Guenter Roeck; Dave Airlie Cc: Linux-Kernel@Vger. Kernel. Org; DRI mailing list; Linus Torvalds Subject: Radeon crash with v3.13-rc3-157-g17b2112 Hi All, Booting today's rawhide kernel fails on my Dell XPS 8300 machine. I added nomodeset to the command line because it seemed to glitch out when doing the handoff to the radeon driver and that let me boot far enough to start networking. I then loaded the radeon driver with: modprobe radeon modeset=1 and was greeted with the backtrace below. I haven't done a bisect yet, but I can if needs be. I was hoping this would trigger someone's memory. Plain 3.13-rc3 works, so it's something in the DRM merge that Linus did after -rc3. Given the backtrace, this one might be suspect: commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d Author: Guenter Roeck li...@roeck-us.net Date: Fri Nov 22 21:52:00 2013 -0800 drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups Should be fixed by the patch in: https://bugs.freedesktop.org/show_bug.cgi?id=72457 Alex josh [ 105.179966] [drm] radeon kernel modesetting enabled. [ 105.202044] checking generic (d000 5b) vs hw (d000 1000) [ 105.202046] fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver [ 105.224345] Console: switching to colour dummy device 80x25 [ 105.237823] [drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1B0A:0x909D). [ 105.237931] [drm] register mmio base: 0xFE62 [ 105.237934] [drm] register mmio size: 131072 [ 105.238185] ATOM BIOS: DeLL [ 105.238929] radeon :01:00.0: VRAM: 1024M 0x - 0x3FFF (1024M used) [ 105.238935] radeon :01:00.0: GTT: 1024M 0x4000 - 0x7FFF [ 105.238939] [drm] Detected VRAM RAM=1024M, BAR=256M [ 105.238944] [drm] RAM width 64bits DDR [ 105.241655] [TTM] Zone kernel: Available graphics memory: 6130458 kiB [ 105.241659] [TTM] Zone dma32: Available graphics memory: 2097152 kiB [ 105.241662] [TTM] Initializing pool allocator [ 105.242085] [TTM] Initializing DMA pool allocator [ 105.243633] [drm] radeon: 1024M of VRAM memory ready [ 105.243678] [drm] radeon: 1024M of GTT memory ready. [ 105.287598] [drm] GART: num cpu pages 262144, num gpu pages 262144 [ 105.289406] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 [ 105.297354] [drm] Loading CAICOS Microcode [ 105.332526] [drm] PCIE GART of 1024M enabled (table at 0x00273000). [ 105.334094] radeon :01:00.0: WB enabled [ 105.334100] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x4c00 and cpu addr 0x8803001ebc00 [ 105.334105] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x4c0c and cpu addr 0x8803001ebc0c [ 105.345578] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x00072118 and cpu addr 0xc90012d32118 [ 105.345640] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 105.345643] [drm] Driver supports precise vblank timestamp query. [ 105.345942] radeon :01:00.0: irq 48 for MSI/MSI-X [ 105.346091] radeon :01:00.0: radeon: using MSI. [ 105.346782] [drm] radeon: irq initialized. [ 105.401411] [drm] ring test on 0 succeeded in 2 usecs [ 105.401478] [drm] ring test on 3 succeeded in 1 usecs [ 105.589796] [drm] ring test on 5 succeeded in 2 usecs [ 105.589806] [drm] UVD initialized successfully. [ 105.622555] [drm] Enabling audio 0 support [ 105.622899] [drm] ib test on ring 0 succeeded in 0 usecs [ 105.622954] ALSA sound/pci/hda/hda_eld.c:684 HDMI ATI/AMD: no speaker allocation for ELD [ 105.623115] [drm] ib test on ring 3 succeeded in 0 usecs [ 105.776249] [drm] ib test on ring 5 succeeded [ 105.839096] [drm] Radeon Display Connectors [ 105.839100] [drm] Connector 0: [ 105.839102] [drm] HDMI-A-1 [ 105.839104] [drm] HPD2 [ 105.839106] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 105.839109] [drm] Encoders: [ 105.839111] [drm] DFP1: INTERNAL_UNIPHY1 [ 105.839113] [drm] Connector 1: [ 105.839114] [drm] DVI-D-1 [ 105.839116] [drm] HPD4 [ 105.839118] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 105.839121] [drm] Encoders: [ 105.839123] [drm] DFP2: INTERNAL_UNIPHY [ 105.839124] [drm] Connector 2: [ 105.839126] [drm] VGA-1 [ 105.839128] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c [ 105.839131] [drm] Encoders: [ 105.839133] [drm] CRT1: INTERNAL_KLDSCP_DAC1 [ 105.839439] [drm] Internal thermal controller with fan control [ 105.840309] BUG: unable to handle kernel paging request at 0001211f [ 105.840316] IP: [a075afdd] hwmon_attributes_visible+0x1d
RE: Radeon crash with v3.13-rc3-157-g17b2112
-Original Message- From: jwbo...@gmail.com [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer Sent: Tuesday, December 10, 2013 6:28 PM To: Deucher, Alexander Cc: Guenter Roeck; Dave Airlie; Linux-Kernel@Vger. Kernel. Org; DRI mailing list; Linus Torvalds Subject: Re: Radeon crash with v3.13-rc3-157-g17b2112 On Tue, Dec 10, 2013 at 5:24 PM, Josh Boyer jwbo...@fedoraproject.org wrote: On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: jwbo...@gmail.com [mailto:jwbo...@gmail.com] On Behalf Of Josh Boyer Sent: Tuesday, December 10, 2013 5:04 PM To: Deucher, Alexander; Guenter Roeck; Dave Airlie Cc: Linux-Kernel@Vger. Kernel. Org; DRI mailing list; Linus Torvalds Subject: Radeon crash with v3.13-rc3-157-g17b2112 Hi All, Booting today's rawhide kernel fails on my Dell XPS 8300 machine. I added nomodeset to the command line because it seemed to glitch out when doing the handoff to the radeon driver and that let me boot far enough to start networking. I then loaded the radeon driver with: modprobe radeon modeset=1 and was greeted with the backtrace below. I haven't done a bisect yet, but I can if needs be. I was hoping this would trigger someone's memory. Plain 3.13-rc3 works, so it's something in the DRM merge that Linus did after -rc3. Given the backtrace, this one might be suspect: commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d Author: Guenter Roeck li...@roeck-us.net Date: Fri Nov 22 21:52:00 2013 -0800 drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups Should be fixed by the patch in: https://bugs.freedesktop.org/show_bug.cgi?id=72457 OK. I'll give that a spin soon. Thanks for the quick reply! Yep, that seems to have fixed the crash. I've added it to rawhide. Thanks! It'll also be in my next -fixes pull. Alex josh -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] radeon_pm: fix oops in hwmon_attributes_visible() and radeon_hwmon_show_temp_thresh()
Fix is already queued in my next -fixes pull. Thanks!
Alex
-Original Message-
From: Sergey Senozhatsky [mailto:sergey.senozhat...@gmail.com]
Sent: Thursday, December 12, 2013 6:26 PM
To: Deucher, Alexander
Cc: David Airlie; Jerome Glisse; dri-de...@lists.freedesktop.org; linux-
ker...@vger.kernel.org
Subject: [PATCH] radeon_pm: fix oops in hwmon_attributes_visible() and
radeon_hwmon_show_temp_thresh()
Since ec39f64bba radeon_hwmon_init() is using
hwmon_device_register_with_groups(), which sets `rdev' as a device
private driver_data, while hwmon_attributes_visible() and
radeon_hwmon_show_temp_thresh() are still waiting for `drm_device'.
fix them by using dev_get_drvdata():
BUG: unable to handle kernel paging request at 1e28
IP: [a02ae8b4] hwmon_attributes_visible+0x18/0x3d [radeon]
PGD 15057e067 PUD 151a8e067 PMD 0
Oops: [#1] PREEMPT SMP
Call Trace:
[81163ba7] internal_create_group+0x114/0x1d9
[81163c7a] sysfs_create_group+0xe/0x10
[81163ec7] sysfs_create_groups+0x22/0x5f
[812ceed8] device_add+0x34f/0x501
[812cf09f] device_register+0x15/0x18
[81317e5e] hwmon_device_register_with_groups+0xb5/0xed
[a02aec00] radeon_hwmon_init+0x56/0x7c [radeon]
[a02b020b] radeon_pm_init+0x134/0x7e5 [radeon]
[810f5c7c] ? kmem_cache_alloc+0x63/0xe3
[a0284ed1] radeon_modeset_init+0x75f/0x8ed [radeon]
[a02671b6] radeon_driver_load_kms+0xc6/0x187 [radeon]
[a021cb33] drm_dev_register+0xf9/0x1b4 [drm]
[a021ddf2] drm_get_pci_dev+0x98/0x129 [drm]
[810f602e] ? kfree+0x10a/0x166
[a0264345] ? radeon_pci_probe+0x91/0xac [radeon]
[a0264357] radeon_pci_probe+0xa3/0xac [radeon]
[8125b90c] pci_device_probe+0x6e/0xcf
[812d13e4] driver_probe_device+0x98/0x1c4
[812d15a4] __driver_attach+0x5c/0x7e
[812d1548] ? __device_attach+0x38/0x38
[812cfac9] bus_for_each_dev+0x7b/0x85
[812d0f69] driver_attach+0x19/0x1b
[812d0c27] bus_add_driver+0x104/0x1ce
[812d1b23] driver_register+0x89/0xc5
[8125b033] __pci_register_driver+0x58/0x5b
[a037f000] ? 0xa037efff
[a021df09] drm_pci_init+0x86/0xea [drm]
[a037f000] ? 0xa037efff
[a037f097] radeon_init+0x97/0x1000 [radeon]
[81000290] do_one_initcall+0x7f/0x117
[810323bc] ? set_memory_nx+0x3b/0x3d
[810a002a] load_module+0x1583/0x1bb4
[8109d602] ? store_uevent+0x35/0x35
[8106121a] ? finish_task_switch+0x3b/0x10c
[813e818b] ? preempt_schedule_irq+0x5d/0x99
[813ecdf7] ? retint_restore_args+0x13/0x13
[810a06fb] SyS_init_module+0xa0/0xaf
[813ed7e6] tracesys+0xd4/0xd9
Signed-off-by: Sergey Senozhatsky sergey.senozhat...@gmail.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index dc75bb6..984097b 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -552,8 +552,7 @@ static ssize_t
radeon_hwmon_show_temp_thresh(struct device *dev,
struct device_attribute *attr,
char *buf)
{
- struct drm_device *ddev = dev_get_drvdata(dev);
- struct radeon_device *rdev = ddev-dev_private;
+ struct radeon_device *rdev = dev_get_drvdata(dev);
int hyst = to_sensor_dev_attr(attr)-index;
int temp;
@@ -580,8 +579,7 @@ static umode_t hwmon_attributes_visible(struct
kobject *kobj,
struct attribute *attr, int index)
{
struct device *dev = container_of(kobj, struct device, kobj);
- struct drm_device *ddev = dev_get_drvdata(dev);
- struct radeon_device *rdev = ddev-dev_private;
+ struct radeon_device *rdev = dev_get_drvdata(dev);
/* Skip limit attributes if DPM is not enabled */
if (rdev-pm.pm_method != PM_METHOD_DPM
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] radeon: Use Linux division macro in si_calculate_leakage_for_v_and_t_formula
Fix is already merged: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=adfb8e51332153016857194b85309150ac560286 -Original Message- From: Andi Kleen [mailto:a...@firstfloor.org] Sent: Friday, August 09, 2013 11:58 AM To: linux-kernel@vger.kernel.org Cc: Andi Kleen; airl...@linux.ie; Deucher, Alexander Subject: [PATCH] radeon: Use Linux division macro in si_calculate_leakage_for_v_and_t_formula From: Andi Kleen a...@linux.intel.com This fixes my 32bit build which failed with: drivers/built-in.o: In function `si_calculate_leakage_for_v_and_t_formula': /home/ak/lsrc/git/linux-2.6/drivers/gpu/drm/radeon/si_dpm.c:1770: undefined reference to `__divdi3' Cc: airl...@linux.ie Cc: alexander.deuc...@amd.com Signed-off-by: Andi Kleen a...@linux.intel.com --- drivers/gpu/drm/radeon/si_dpm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/si_dpm.c b/drivers/gpu/drm/radeon/si_dpm.c index 7ad22e8..4182557 100644 --- a/drivers/gpu/drm/radeon/si_dpm.c +++ b/drivers/gpu/drm/radeon/si_dpm.c @@ -1767,7 +1767,7 @@ static void si_calculate_leakage_for_v_and_t_formula(const struct ni_leakage_coe s64 temperature, t_slope, t_intercept, av, bv, t_ref; s64 tmp; - i_leakage = drm_int2fixp(ileakage) / 100; + i_leakage = div64_s64(drm_int2fixp(ileakage), 100); vddc = div64_s64(drm_int2fixp(v), 1000); temperature = div64_s64(drm_int2fixp(t), 1000); -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy
-Original Message- From: Koenig, Christian Sent: Monday, April 28, 2014 3:30 AM To: Jerome Glisse; Thomas Schwinge Cc: Bjorn Helgaas; linux-...@vger.kernel.org; Johannes Weiner; Mel Gorman; Rik van Riel; Andrea Arcangeli; Zlatko Calusic; Minchan Kim; linux- m...@kvack.org; linux-kernel@vger.kernel.org; Andrew Morton; Deucher, Alexander; dri-de...@lists.freedesktop.org Subject: Re: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy + /* We are living in a monstruous world in which you can have the pci +* root complex behind an hypertransport link which can not address +* anything above 32bit (well hypertransport specification says 40bits +* but hardware such as SIS761 only support 32bits). That looks more like a problem with this specific chipset rather than something that needs a general solution like this. Maybe we should rather add the PCI-ID(s) of the thing to some kind of quirks table for now so that the patch isn't so invasive and we can CC stable as well? IIRC, there was someone on IRC with a similar problem with a similar SiS chipset a while back. These SiS chipsets seem to be generally problematic. Alex Just a thought, Christian. Am 27.04.2014 21:55, schrieb Jerome Glisse: On Sat, Apr 26, 2014 at 11:31:11PM -0400, Jerome Glisse wrote: On Thu, Apr 24, 2014 at 09:37:22AM -0400, Johannes Weiner wrote: Hi Thomas, On Wed, Apr 02, 2014 at 04:26:08PM +0200, Thomas Schwinge wrote: Hi! On Fri, 2 Aug 2013 11:37:26 -0400, Johannes Weiner han...@cmpxchg.org wrote: Each zone that holds userspace pages of one workload must be aged at a speed proportional to the zone size. [...] Fix this with a very simple round robin allocator. [...] This patch, adding NR_ALLOC_BATCH, eventually landed in mainline as commit 81c0a2bb515fd4daae8cab64352877480792b515 (2013-09-11). I recently upgraded a Debian testing system from a 3.11 kernel to 3.12, and it started to exhibit strange issues, which I then bisected to this patch. I'm not saying that the patch is faulty, as it seems to be working fine for everyone else, so I rather assume that something in a (vastly?) different corner of the kernel (or my hardware?) is broken. ;-) The issue is that when X.org/lightdm starts up, there are garbled section on the screen, for example, rectangular boxes that are just black or otherwise distorted, and/or sets of glyphs (corresponding to a set of characters; but not all characters) are displayed as rectangular gray or black boxes, and/or icons in a GNOME session are not displayed properly, and so on. (Can take a snapshot if that helps?) Switching to a Linux console, I can use that one fine. Switching back to X, in the majority of all cases, the screen will be completely black, but with the mouse cursor still rendered properly (done in hardware, I assume). Reverting commit 81c0a2bb515fd4daae8cab64352877480792b515, for example on top of v3.12, and everything is back to normal. The problem also persists with a v3.14 kernel that I just built. I will try to figure out what's going on, but will gladly take any pointers, or suggestions about how to tackle such a problem. The hardware is a Fujitsu Siemens Esprimo E5600, mainboard D2264-A1, CPU AMD Sempron 3000+. There is a on-board graphics thingy, but I'm not using that; instead I put in a Sapphire Radeon HD 4350 card. I went over this code change repeatedly but I could not see anything directly that would explain it. However, this patch DOES change the way allocations are placed (while still respecting zone specifiers like __GFP_DMA etc.) and so it's possible that they unearthed a corruption, or a wrongly set dma mask in the drivers. Ccing the radeon driver guys. Full quote follows. $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Sempron(tm) Processor 3000+ stepping: 2 cpu MHz : 1000.000 cache size : 128 KB physical id : 0 siblings: 1 core id : 0 cpu cores : 1 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt lm 3dnowext 3dnow rep_good nopl pni lahf_lm bogomips: 2000.20 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: ts fid vid ttp tm stc $ sudo lspci -nn -k -vv 00:00.0 Host bridge [0600]: Silicon Integrated
RE: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy
-Original Message- From: Deucher, Alexander Sent: Monday, April 28, 2014 8:50 AM To: Koenig, Christian; Jerome Glisse; Thomas Schwinge Cc: Bjorn Helgaas; linux-...@vger.kernel.org; Johannes Weiner; Mel Gorman; Rik van Riel; Andrea Arcangeli; Zlatko Calusic; Minchan Kim; linux- m...@kvack.org; linux-kernel@vger.kernel.org; Andrew Morton; dri- de...@lists.freedesktop.org Subject: RE: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy -Original Message- From: Koenig, Christian Sent: Monday, April 28, 2014 3:30 AM To: Jerome Glisse; Thomas Schwinge Cc: Bjorn Helgaas; linux-...@vger.kernel.org; Johannes Weiner; Mel Gorman; Rik van Riel; Andrea Arcangeli; Zlatko Calusic; Minchan Kim; linux- m...@kvack.org; linux-kernel@vger.kernel.org; Andrew Morton; Deucher, Alexander; dri-de...@lists.freedesktop.org Subject: Re: radeon: screen garbled after page allocator change, was: Re: [patch v2 3/3] mm: page_alloc: fair zone allocator policy + /* We are living in a monstruous world in which you can have the pci + * root complex behind an hypertransport link which can not address + * anything above 32bit (well hypertransport specification says 40bits + * but hardware such as SIS761 only support 32bits). That looks more like a problem with this specific chipset rather than something that needs a general solution like this. Maybe we should rather add the PCI-ID(s) of the thing to some kind of quirks table for now so that the patch isn't so invasive and we can CC stable as well? IIRC, there was someone on IRC with a similar problem with a similar SiS chipset a while back. These SiS chipsets seem to be generally problematic. IIRC, in the IRC case, the fix was to limit the about of physical memory in the system. Alex Alex Just a thought, Christian. Am 27.04.2014 21:55, schrieb Jerome Glisse: On Sat, Apr 26, 2014 at 11:31:11PM -0400, Jerome Glisse wrote: On Thu, Apr 24, 2014 at 09:37:22AM -0400, Johannes Weiner wrote: Hi Thomas, On Wed, Apr 02, 2014 at 04:26:08PM +0200, Thomas Schwinge wrote: Hi! On Fri, 2 Aug 2013 11:37:26 -0400, Johannes Weiner han...@cmpxchg.org wrote: Each zone that holds userspace pages of one workload must be aged at a speed proportional to the zone size. [...] Fix this with a very simple round robin allocator. [...] This patch, adding NR_ALLOC_BATCH, eventually landed in mainline as commit 81c0a2bb515fd4daae8cab64352877480792b515 (2013-09-11). I recently upgraded a Debian testing system from a 3.11 kernel to 3.12, and it started to exhibit strange issues, which I then bisected to this patch. I'm not saying that the patch is faulty, as it seems to be working fine for everyone else, so I rather assume that something in a (vastly?) different corner of the kernel (or my hardware?) is broken. ;-) The issue is that when X.org/lightdm starts up, there are garbled section on the screen, for example, rectangular boxes that are just black or otherwise distorted, and/or sets of glyphs (corresponding to a set of characters; but not all characters) are displayed as rectangular gray or black boxes, and/or icons in a GNOME session are not displayed properly, and so on. (Can take a snapshot if that helps?) Switching to a Linux console, I can use that one fine. Switching back to X, in the majority of all cases, the screen will be completely black, but with the mouse cursor still rendered properly (done in hardware, I assume). Reverting commit 81c0a2bb515fd4daae8cab64352877480792b515, for example on top of v3.12, and everything is back to normal. The problem also persists with a v3.14 kernel that I just built. I will try to figure out what's going on, but will gladly take any pointers, or suggestions about how to tackle such a problem. The hardware is a Fujitsu Siemens Esprimo E5600, mainboard D2264- A1, CPU AMD Sempron 3000+. There is a on-board graphics thingy, but I'm not using that; instead I put in a Sapphire Radeon HD 4350 card. I went over this code change repeatedly but I could not see anything directly that would explain it. However, this patch DOES change the way allocations are placed (while still respecting zone specifiers like __GFP_DMA etc.) and so it's possible that they unearthed a corruption, or a wrongly set dma mask in the drivers. Ccing the radeon driver guys. Full quote follows. $ cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 15 model : 47 model name : AMD Sempron(tm) Processor 3000+ stepping: 2 cpu MHz : 1000.000 cache size : 128 KB physical id : 0 siblings: 1 core
RE: PROBLEM: Fatal Machine Check = 3.13.5-101.fc19.x86_64
-Original Message- From: Matthias Graf [mailto:matthias.g...@st.ovgu.de] Sent: Friday, April 18, 2014 7:46 AM To: Borislav Petkov Cc: linux-kernel@vger.kernel.org; Tony Luck; Deucher, Alexander Subject: Re: PROBLEM: Fatal Machine Check = 3.13.5-101.fc19.x86_64 I applied your patch to linus' current master (3.15.0-rc1+) and indeed it does solve the issue for me! Thanks for your help. I would appreciated if you keep me posted on updates. You can try some testing patches here: https://bugs.freedesktop.org/show_bug.cgi?id=76286 but for now, I'm just going to disable dpm on rv770 asics. Alex Best, Matthias Am 18.04.2014 11:45, schrieb Borislav Petkov: On Fri, Apr 18, 2014 at 11:17:34AM +0200, Matthias Graf wrote: Fine-grained bisection result: ab70b1dde73ff4525c3cd51090c233482c50f217 is the first bad commit commit ab70b1dde73ff4525c3cd51090c233482c50f217 Author: Alex Deucher alexander.deuc...@amd.com Date: Fri Nov 1 15:16:02 2013 -0400 drm/radeon: enable DPM by default on r7xx asics Seems to be stable on them. Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 f3262029b868df4d882f64b4deba6b9230e307ea 1f1dfca42763703a56e3cc82bb103608a24be94e M drivers Result is reasonable: I have a RV770 chip. Yes it is. (Additional) Bug Report for Reference: https://bugzilla.redhat.com/show_bug.cgi?id=1085785 Thanks for the instructions Borislav! At first, I was not completely sure what you expected me to do (this is my first kernel bug report :)). And you're doing good so far! :-) If there is anymore more I can help you with, let me know. Ok, now we want to confirm that this patch is *actually* the culprit by reverting it. Simply pull Linus' master branch to have the latest tree, and then do: $ git checkout -b radeon-revert master so that you land on a throwaway branch where we can play. Then normally you would do $ git revert ab70b1dde73ff4525c3cd51090c233482c50f217 but that causes conflicts so I did it for you, see below. Simply apply this patch ontop *without* doing the revert with git. Then build, boot and test. We want to see whether it still generates those ROB timeout machine checks. If all looks ok, then we're pretty sure we need to talk about DPM with your GPU on your platform with Alex. :-) Feel free to ask any questions should something be not clear. Thanks. --- From 0790e872f6d3c986d9ed36b850fd9d799dc422f9 Mon Sep 17 00:00:00 2001 From: Borislav Petkov b...@suse.de Date: Fri, 18 Apr 2014 11:43:12 +0200 Subject: [PATCH] Revert drm/radeon: enable DPM by default on r7xx asics This reverts commit ab70b1dde73ff4525c3cd51090c233482c50f217. Conflicts: drivers/gpu/drm/radeon/radeon_pm.c --- drivers/gpu/drm/radeon/radeon_pm.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index ee738a524639..af693c4746da 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -1257,6 +1257,10 @@ int radeon_pm_init(struct radeon_device *rdev) case CHIP_RV670: case CHIP_RS780: case CHIP_RS880: + case CHIP_RV770: + case CHIP_RV730: + case CHIP_RV710: + case CHIP_RV740: case CHIP_BARTS: case CHIP_TURKS: case CHIP_CAICOS: @@ -1273,10 +1277,6 @@ int radeon_pm_init(struct radeon_device *rdev) else rdev-pm.pm_method = PM_METHOD_PROFILE; break; - case CHIP_RV770: - case CHIP_RV730: - case CHIP_RV710: - case CHIP_RV740: case CHIP_CEDAR: case CHIP_REDWOOD: case CHIP_JUNIPER:
RE: [PATCH] drm/radeon: memory leak on bo reservation failure.
-Original Message-
From: Quentin Casasnovas [mailto:quentin.casasno...@oracle.com]
Sent: Tuesday, March 18, 2014 12:17 PM
To: David Airlie
Cc: linux-kernel@vger.kernel.org; Quentin Casasnovas;
sta...@vger.kernel.org; Koenig, Christian; Deucher, Alexander
Subject: [PATCH] drm/radeon: memory leak on bo reservation failure.
On bo reservation failure, we end up leaking fpriv.
Fixes: 5e386b574cf7e1 (drm/radeon: fix missing bo reservation)
Cc: sta...@vger.kernel.org
Cc: Christian König christian.koe...@amd.com
Cc: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Quentin Casasnovas quentin.casasno...@oracle.com
Sorry I missed this. It looks like we probably want an updated version for
newer kernels where radeon_vm_init() can fail as well.
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
Alex
---
drivers/gpu/drm/radeon/radeon_kms.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_kms.c
b/drivers/gpu/drm/radeon/radeon_kms.c
index 66ed3ea..51cda80 100644
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -546,8 +546,11 @@ int radeon_driver_open_kms(struct drm_device
*dev, struct drm_file *file_priv)
radeon_vm_init(rdev, fpriv-vm);
r = radeon_bo_reserve(rdev-ring_tmp_bo.bo, false);
- if (r)
+ if (r) {
+ radeon_vm_fini(rdev, fpriv-vm);
+ kfree(fpriv);
return r;
+ }
/* map the ib pool buffer read only into
* virtual address space */
--
1.8.3.2
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH] drm/radeon: fix VCE fence command
-Original Message-
From: Christoph Jaeger [mailto:christophjae...@linux.com]
Sent: Monday, April 14, 2014 6:10 PM
To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie
Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Christoph
Jaeger
Subject: [PATCH] drm/radeon: fix VCE fence command
Due to a type mismatch that causes an implicit type conversion, the
upper 32 bits of the GPU address have been zeroed out when adding to the
command buffer.
Picked up by Coverity - CID 1198624.
Signed-off-by: Christoph Jaeger christophjae...@linux.com
Good catch!
Reviewed-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/gpu/drm/radeon/radeon_vce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_vce.c
b/drivers/gpu/drm/radeon/radeon_vce.c
index 76e9904..ced53dd 100644
--- a/drivers/gpu/drm/radeon/radeon_vce.c
+++ b/drivers/gpu/drm/radeon/radeon_vce.c
@@ -613,7 +613,7 @@ void radeon_vce_fence_emit(struct radeon_device
*rdev,
struct radeon_fence *fence)
{
struct radeon_ring *ring = rdev-ring[fence-ring];
- uint32_t addr = rdev-fence_drv[fence-ring].gpu_addr;
+ uint64_t addr = rdev-fence_drv[fence-ring].gpu_addr;
radeon_ring_write(ring, VCE_CMD_FENCE);
radeon_ring_write(ring, addr);
--
1.9.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 15-rc1: radeon modesetting fails
-Original Message-
From: Kertesz Laszlo [mailto:laszlo.kert...@gmail.com]
Sent: Tuesday, April 15, 2014 5:50 PM
To: Borislav Petkov
Cc: Alex Deucher; Deucher, Alexander; Koenig, Christian; Maling list - DRI
developers; lkml
Subject: Re: 15-rc1: radeon modesetting fails
Borislav Petkov wrote:
On Tue, Apr 15, 2014 at 09:02:35PM +0300, Kertesz Laszlo wrote:
Honestly didnt try that but i assume yes, since the screens go black
when it should change resolution.
Pls try it and let us know whether you see the machine booting further,
albeit without modesetting.
Thanks.
Yes, it is working that way. But no X, i assume this is expected.
Turning off modesetting basically disables the driver.
Alex
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [REGRESSION] Radeon (Evergreen) Crash with pin failed in Kernel 3.10-rc7
-Original Message- From: Brian Gitonga Marete [mailto:mar...@toshnix.com] Sent: Friday, June 28, 2013 1:08 AM To: LKML Cc: David Airlie; Jerome Glisse; Deucher, Alexander Subject: [REGRESSION] Radeon (Evergreen) Crash with pin failed in Kernel 3.10-rc7 Hello all, 3.10-rc7,(at revision 98b6ed0f2) breaks evergreen on my system. I get a crash soon after Ubuntu's Unity is loaded: [ 564.186733] radeon :01:00.0: 88021f7f8400 pin failed [ 566.421933] radeon :01:00.0: 880221163c00 pin failed [ 568.822258] radeon :01:00.0: 88022c045800 pin failed [ 571.202550] radeon :01:00.0: 88020e0d4000 pin failed [ 573.601286] radeon :01:00.0: 88020bc3bc00 pin failed [ 576.129650] radeon :01:00.0: 88022c045c00 pin failed [ 578.287459] radeon :01:00.0: 88022bfcb400 pin failed [ 580.497160] radeon :01:00.0: 88020dcd6000 pin failed [ 582.765835] radeon :01:00.0: 88022bfcb400 pin failed [ 585.834068] radeon :01:00.0: 88020cade800 pin failed [ 588.109227] radeon :01:00.0: 88022e742000 pin failed [ 590.441445] radeon :01:00.0: 88020c638c00 pin failed [ 592.550131] radeon :01:00.0: 88022d01ac00 pin failed [ 595.008882] radeon :01:00.0: 88020cadc800 pin failed [ 597.367337] radeon :01:00.0: 88020dcd5000 pin failed [ 599.762514] radeon :01:00.0: 88022e74 pin failed [ 602.001337] radeon :01:00.0: 88022c047400 pin failed [ 604.213469] radeon :01:00.0: 880225d45800 pin failed [ 606.433591] radeon :01:00.0: 88022b65bc00 pin failed [ 608.660915] radeon :01:00.0: 88022d259000 pin failed [ 610.929554] radeon :01:00.0: 88022afa1000 pin failed [ 613.179613] radeon :01:00.0: 88020cac0800 pin failed [ 615.408515] radeon :01:00.0: 88022b6e1000 pin failed [ 617.625670] radeon :01:00.0: 88020cadc000 pin failed [ 617.880137] SysRq : Emergency Sync [ 618.607569] SysRq : Emergency Sync [ 619.854431] radeon :01:00.0: 88022da24000 pin failed [ 621.674929] Emergency Sync complete [ 622.299598] radeon :01:00.0: 88022ac40800 pin failed [ 622.331170] Emergency Sync complete [ 622.532771] SysRq : Emergency Sync [ 624.513321] radeon :01:00.0: 88022afa1c00 pin failed [ 624.845937] Emergency Sync complete [ 625.532319] SysRq : Emergency Sync [ 626.929447] radeon :01:00.0: 88022da26400 pin failed [ 627.102452] SysRq : Emergency Sync [ 627.776821] Emergency Sync complete [ 628.683279] SysRq : Emergency Sync [ 629.329036] radeon :01:00.0: 88020dc1d800 pin failed [ 629.457062] Emergency Sync complete [ 631.483387] Emergency Sync complete [ 632.006185] SysRq : Dump ftrace buffer [ 632.006247] Dumping ftrace buffer: [ 632.006253](ftrace buffer empty) [ 632.068838] radeon :01:00.0: 88022ddc0400 pin failed [ 632.266509] SysRq : Dump ftrace buffer [ 632.266563] Dumping ftrace buffer: [ 632.266569](ftrace buffer empty) [ 633.026429] SysRq : Emergency Remount R/O The full dmesg output for that session is attached in dmesg.txt. In the crash, X crashes and I am dropped onto the console tty. Only a reboot works after this (although sysrq does work, so it is not a full freeze). My card is a Radeon HD 5000M Series. Specifically, it has PCI ID: 1002:68c1 I am running Ubuntu 12.04, but with upgraded libdrm, mesa and xf86-video-ati packages, close to the GIT tip. Specifically: libdrm: a0178c00c7 (June 5) mesa: bbd2d575e (June 20) xf86-video-ati: 3626ab147b67 (June 14) *An important note:* In this 3.10-rc7, I have enabled UVD by installing the correct firmware (indeed, I specifically wanted to test UVD video decoding). But this crash occurred without my having tried to use UVD. Kernel 3.9.7 works fine on this card and with the DRM stack outlined above. Let me know if I should provide further information. I am able and happy to do all manner of debugging and testing, at your suggestion :) Can you bisect? Thanks, Alex Many thanks, -- Brian Gitonga Marete CEO/CTO Toshnix Systems http://toshnix.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [REGRESSION] Radeon (Evergreen) Crash with pin failed in Kernel 3.10-rc7
-Original Message- From: Brian Gitonga Marete [mailto:mar...@toshnix.com] Sent: Saturday, June 29, 2013 3:41 PM To: Deucher, Alexander Cc: LKML; David Airlie; Jerome Glisse Subject: Re: [REGRESSION] Radeon (Evergreen) Crash with pin failed in Kernel 3.10-rc7 On Fri, Jun 28, 2013 at 6:45 PM, Brian Gitonga Marete mar...@toshnix.com wrote: On Fri, Jun 28, 2013 at 3:55 PM, Deucher, Alexander alexander.deuc...@amd.com wrote: Can you bisect? Hello Alexander, So, it turns out that it is not so easy to reproduce this issue. I have been trying to reproduce it with the exact revision of 3.10-rc7 where I first encountered the problem but with no luck. This of course has hampered my bisection since I cannot be sure which revisions to mark good/bad. Do you have any suggestions in this regard? I however have a UVD-related lockup that I can always reproduce on 3.10-rc7: Trying to use UVD with the command: mplayer -vo vdpau -vc ffh264vdpau test.mp4 _always_locks up the same system (same kernel, same DRI stack) hard. I will report this in a separate email, though nothing at all shows up in the logs for this latter problem due to the hard lockup. Suggestions about how to help debug this are also welcome. Please open a bug (https://bugs.freedesktop.org) and attach your xorg log and dmesg output. Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 09/17] drm/radeon: use common fence implementation for fences
-Original Message-
From: Maarten Lankhorst [mailto:maarten.lankho...@canonical.com]
Sent: Wednesday, July 09, 2014 8:30 AM
To: airl...@linux.ie
Cc: thellst...@vmware.com; nouv...@lists.freedesktop.org; linux-
ker...@vger.kernel.org; dri-de...@lists.freedesktop.org;
bske...@redhat.com; Deucher, Alexander; Koenig, Christian
Subject: [PATCH 09/17] drm/radeon: use common fence implementation for
fences
Signed-off-by: Maarten Lankhorst maarten.lankho...@canonical.com
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223
++--
3 files changed, 248 insertions(+), 50 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h
b/drivers/gpu/drm/radeon/radeon.h
index 29d9cc04c04e..03a5567f2c2f 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -64,6 +64,7 @@
#include linux/wait.h
#include linux/list.h
#include linux/kref.h
+#include linux/fence.h
#include ttm/ttm_bo_api.h
#include ttm/ttm_bo_driver.h
@@ -116,9 +117,6 @@ extern int radeon_deep_color;
#define RADEONFB_CONN_LIMIT 4
#define RADEON_BIOS_NUM_SCRATCH 8
-/* fence seq are set to this number when signaled */
-#define RADEON_FENCE_SIGNALED_SEQ0LL
-
/* internal ring indices */
/* r1xx+ has gfx CP ring */
#define RADEON_RING_TYPE_GFX_INDEX 0
@@ -350,12 +348,15 @@ struct radeon_fence_driver {
};
struct radeon_fence {
+ struct fence base;
+
struct radeon_device*rdev;
- struct kref kref;
/* protected by radeon_fence.lock */
uint64_tseq;
/* RB, DMA, etc. */
unsignedring;
+
+ wait_queue_t fence_wake;
};
int radeon_fence_driver_start_ring(struct radeon_device *rdev, int ring);
@@ -2268,6 +2269,7 @@ struct radeon_device {
struct radeon_mman mman;
struct radeon_fence_driver fence_drv[RADEON_NUM_RINGS];
wait_queue_head_t fence_queue;
+ unsignedfence_context;
struct mutexring_lock;
struct radeon_ring ring[RADEON_NUM_RINGS];
boolib_pool_ready;
@@ -2358,11 +2360,6 @@ u32 cik_mm_rdoorbell(struct radeon_device
*rdev, u32 index);
void cik_mm_wdoorbell(struct radeon_device *rdev, u32 index, u32 v);
/*
- * Cast helper
- */
-#define to_radeon_fence(p) ((struct radeon_fence *)(p))
-
-/*
* Registers read write functions.
*/
#define RREG8(reg) readb((rdev-rmmio) + (reg))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 03686fab842d..86699df7c8f3 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1213,6 +1213,7 @@ int radeon_device_init(struct radeon_device
*rdev,
for (i = 0; i RADEON_NUM_RINGS; i++) {
rdev-ring[i].idx = i;
}
+ rdev-fence_context =
fence_context_alloc(RADEON_NUM_RINGS);
DRM_INFO(initializing kernel modesetting (%s 0x%04X:0x%04X
0x%04X:0x%04X).\n,
radeon_family_name[rdev-family], pdev-vendor, pdev-
device,
@@ -1607,6 +1608,54 @@ int radeon_resume_kms(struct drm_device *dev,
bool resume, bool fbcon)
return 0;
}
+static uint32_t radeon_gpu_mask_sw_irq(struct radeon_device *rdev)
+{
+ uint32_t mask = 0;
+ int i;
+
+ if (!rdev-ddev-irq_enabled)
+ return mask;
+
+ /*
+ * increase refcount on sw interrupts for all rings to stop
+ * enabling interrupts in radeon_fence_enable_signaling during
+ * gpu reset.
+ */
+
+ for (i = 0; i RADEON_NUM_RINGS; ++i) {
+ if (!rdev-ring[i].ready)
+ continue;
+
+ atomic_inc(rdev-irq.ring_int[i]);
+ mask |= 1 i;
+ }
+ return mask;
+}
+
+static void radeon_gpu_unmask_sw_irq(struct radeon_device *rdev,
uint32_t mask)
+{
+ unsigned long irqflags;
+ int i;
+
+ if (!mask)
+ return;
+
+ /*
+ * undo refcount increase, and reset irqs to correct value.
+ */
+
+ for (i = 0; i RADEON_NUM_RINGS; ++i) {
+ if (!(mask (1 i)))
+ continue;
+
+ atomic_dec(rdev-irq.ring_int[i]);
+ }
+
+ spin_lock_irqsave(rdev-irq.lock, irqflags);
+ radeon_irq_set(rdev);
+ spin_unlock_irqrestore(rdev-irq.lock, irqflags);
+}
+
/**
* radeon_gpu_reset - reset the asic
*
@@ -1624,6 +1673,7 @@ int radeon_gpu_reset(struct radeon_device *rdev)
int i, r;
int resched;
+ uint32_t sw_mask;
down_write(rdev-exclusive_lock);
@@ -1637,6 +1687,7 @@ int radeon_gpu_reset(struct radeon_device *rdev
RE: Standard VGA console with DRI/DRM under X?
-Original Message-
From: Bjorn Helgaas [mailto:bhelg...@google.com]
Sent: Tuesday, October 28, 2014 11:48 AM
To: Michael Shell
Cc: linux-kernel@vger.kernel.org; David Airlie; DRI mailing list; Deucher,
Alexander; Koenig, Christian
Subject: Re: Standard VGA console with DRI/DRM under X?
[+cc David, Alex, Christian, dri-devel]
On Tue, Oct 28, 2014 at 12:32 AM, Michael Shell li...@michaelshell.org
wrote:
Greetings,
Well, I want to be able to have my cake and eat it too. I want to be able to
have the standard VGA/hardware classic console (not the framebuffer)
but
I still want the /dev/dri/cardX devices so that I can use DRI under Xorg.
Is this possible and if not, why not?
It's not currently possible. When the driver loads it needs to reprogram the
GPU memory controller which requires disabling (or at least blanking the
displays). Additionally there is currently no code in the driver to setup the
vga text mode emulation. Moreover, there is no legacy vga text mode on UEFI
systems when the GPU has a GOP driver.
(I do hope I'm not bring up an issue with an obvious fix, but my searching
has not yielded an answer yet. For the record, I'm running modern kernel
(3.16.3) with much older x86 hardware [r100 Radeon video card].)
If I boot with the kernel nomodeset option I can get the classic
VGA/hardware console, but then I lose support for DRI/DRM:
Oct 27 15:11:09 X kernel: [drm] Initialized drm 1.1.0 20060810
Oct 27 15:11:09 X kernel: [drm] VGACON disable radeon kernel
modesetting.
Oct 27 15:11:09 X kernel: [drm:radeon_init] *ERROR* No UMS support in
radeon module
and glxgears et al. turns slow. In more modern Xorg releases, DRI is
required for all hardware acceleration, so having /dev/dri/cardX is very
important:
http://askubuntu.com/questions/463142/why-x-is-relying-on-software-
instead-of-hardware-with-nomodeset-kernel-paramet
UMS is deprecated in the kernel and support for UMS has been dropped from the X
ddx and the mesa drivers. Moreover, UMS had a lot of limitations that make it
much less useful for modern desktops (no DRI2 support, no display hotplug
support, etc.).
One reason I do not wish to use the framebuffer console is because of the
small font. 160 columns makes it difficult to tell which [OK] belongs with
which service. The selection of console fonts should always include a
set that gives us an 80 column screen and the docs should point this out.
And I dislike any blanking or video mode changes during boot.
Can't the kernel just declare that it is capable of setting the video mode,
provide the /dev/dri/cardX devices and leave the console alone, but still
allow Xorg to call for a new mode and use /dev/dri/cardX if/when it sees
fit?
In an ideal world, there would be some kernel option such as fbcon=no.
In the kernel Documentation fbcon.txt it mentions fbcon=map:1 tells
fbcon not
to take over the console. But, IIRC, from my tests I wasn't able to use
this
to get a VGA/hardware console and still be able to have /dev/dri/cardX
devices.
The driver disables the legacy vga text mode hardware when it loads. I think
configuring a different mode or font for the fb console would probably get you
what you want. See the Forcing Modes section of this page
(http://nouveau.freedesktop.org/wiki/KernelModeSetting/) for how to select a
custom mode for your display with KMS
Alex
Cheers and thank you,
Mike Shell
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 2/4] PCI: quirk AMD/ATI VGA cards to avoid PM reset
-Original Message-
From: Alex Williamson [mailto:alex.william...@redhat.com]
Sent: Friday, November 21, 2014 1:24 PM
To: bhelg...@google.com
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Alex
Williamson; Deucher, Alexander
Subject: [PATCH 2/4] PCI: quirk AMD/ATI VGA cards to avoid PM reset
Some AMD/ATI GPUs report that they support PM reset (NoSoftRst-) but
initiating such a reset has no apparent affect on the device. The
monitor remains sync'd, the framebuffer contents are retained, etc.
Callers of pci_reset_function() don't necessarily have a way to
validate whether a reset was effective, so we really want to avoid
making use of a known non-effective reset. Returning an error in
such cases appears to be the better option. For users like vfio-pci,
this allows the driver to escalate to the bus reset interfaces.
If a device lives on the root bus, there's really no further
escalation path, so we exempt PM reset as potentially better than
nothing.
Signed-off-by: Alex Williamson alex.william...@redhat.com
Cc: Alex Deucher alexander.deuc...@amd.com
Acked-by: Alex Deucher alexander.deuc...@amd.com
---
drivers/pci/quirks.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 90acb32..561e10d 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3008,6 +3008,27 @@
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_REALTEK, 0x8169,
DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, PCI_ANY_ID,
quirk_broken_intx_masking);
+static void quirk_no_pm_reset(struct pci_dev *dev)
+{
+ /*
+ * A non-effective PM reset may be better than nothing
+ * if we can't do a bus reset
+ */
+ if (!pci_is_root_bus(dev-bus))
+ dev-dev_flags |= PCI_DEV_FLAGS_NO_PM_RESET;
+}
+
+/*
+ * Some AMD/ATI GPUS (HD8570 - Oland) report supporting PM reset via
D3-D0
+ * transition (NoSoftRst-). This reset mechanims seems to have no effect
+ * whatsoever on the device, even retaining the framebuffer contents and
+ * monitor sync. Advertising this support makes other layers, like VFIO
+ * assume pci_reset_function() is viable for this device. Mark it as
+ * unavailable to skip it when testing reset methods.
+ */
+DECLARE_PCI_FIXUP_CLASS_HEADER(PCI_VENDOR_ID_ATI, PCI_ANY_ID,
+PCI_CLASS_DISPLAY_VGA, 8,
quirk_no_pm_reset);
+
#ifdef CONFIG_ACPI
/*
* Apple: Shutdown Cactus Ridge Thunderbolt controller.
RE: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head
-Original Message- From: Andrey Utkin [mailto:andrey.krieger.ut...@gmail.com] Sent: Thursday, November 13, 2014 8:10 PM To: linux-...@vger.kernel.org; linux-kbu...@vger.kernel.org; linux- me...@vger.kernel.org; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org; kernel-janit...@vger.kernel.org; gre...@linuxfoundation.org; mgor...@suse.de; ddstr...@ieee.org; jeffrey.t.kirs...@intel.com; yamad...@jp.panasonic.com; kenhel...@firemail.de; o...@redhat.com; a...@linux-foundation.org; shuah...@samsung.com; valentina.mane...@gmail.com; yann.morin.1...@free.fr; la...@cn.fujitsu.com; mathieu.desnoy...@efficios.com; rost...@goodmis.org; j...@joshtriplett.org; paul...@linux.vnet.ibm.com; m.che...@samsung.com; awa...@md.metrocast.net; airl...@linux.ie; Koenig, Christian; Deucher, Alexander; triv...@kernel.org Cc: Andrey Utkin Subject: [RESUBMIT] [PATCH] Replace mentions of list_struct to list_head There's no such thing as list_struct. Signed-off-by: Andrey Utkin andrey.krieger.ut...@gmail.com Acked-by: Alex Deucher alexander.deuc...@amd.com --- drivers/gpu/drm/radeon/mkregtable.c | 24 drivers/media/pci/cx18/cx18-driver.h | 2 +- include/linux/list.h | 34 +- include/linux/plist.h| 10 +- include/linux/rculist.h | 8 scripts/kconfig/list.h | 6 +++--- tools/usb/usbip/libsrc/list.h| 2 +- 7 files changed, 43 insertions(+), 43 deletions(-) diff --git a/drivers/gpu/drm/radeon/mkregtable.c b/drivers/gpu/drm/radeon/mkregtable.c index 4a85bb6..b928c17 100644 --- a/drivers/gpu/drm/radeon/mkregtable.c +++ b/drivers/gpu/drm/radeon/mkregtable.c @@ -347,7 +347,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_entry - get the struct for this entry * @ptr: the struct list_head pointer. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_entry(ptr, type, member) \ container_of(ptr, type, member) @@ -356,7 +356,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_first_entry - get the first element from a list * @ptr: the list head to take the element from. * @type:the type of the struct this is embedded in. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Note, that list is expected to be not empty. */ @@ -406,7 +406,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry - iterate over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry(pos, head, member) \ for (pos = list_entry((head)-next, typeof(*pos), member); \ @@ -417,7 +417,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_reverse - iterate backwards over list of given type. * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. */ #define list_for_each_entry_reverse(pos, head, member) \ for (pos = list_entry((head)-prev, typeof(*pos), member); \ @@ -428,7 +428,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_prepare_entry - prepare a pos entry for use in list_for_each_entry_continue() * @pos: the type * to use as a start point * @head:the head of the list - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Prepares a pos entry for use as a start point in list_for_each_entry_continue(). */ @@ -439,7 +439,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue - continue iteration over list of given type * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head within the struct. * * Continue to iterate over list of given type, continuing after * the current position. @@ -453,7 +453,7 @@ static inline void list_splice_tail_init(struct list_head *list, * list_for_each_entry_continue_reverse - iterate backwards from the given point * @pos: the type * to use as a loop cursor. * @head:the head for your list. - * @member: the name of the list_struct within the struct. + * @member: the name of the list_head
RE: [PATCH] radeon: add updated firmware for kaveri (radeon GPU)
-Original Message-
From: Gabbay, Oded
Sent: Monday, December 22, 2014 6:27 AM
To: linux-firmw...@kernel.org; Kyle McMartin
Cc: linux-kernel@vger.kernel.org; Bridgman, John; Deucher, Alexander;
Elifaz, Dana
Subject: [PATCH] radeon: add updated firmware for kaveri (radeon GPU)
This firmware update is required for the correct functionality of AMD's HSA
Linux kernel driver, called amdkfd.
amdkfd is a new driver that was merged by Linus last week and is present in
3.19-rc1.
Signed-off-by: Oded Gabbay oded.gab...@amd.com
Acked-by: Alex Deucher alexander.deuc...@amd.com
---
radeon/kaveri_ce.bin | Bin 8832 - 8832 bytes
radeon/kaveri_me.bin | Bin 8832 - 8832 bytes
radeon/kaveri_mec.bin | Bin 17024 - 17024 bytes
radeon/kaveri_mec2.bin | Bin 17024 - 17024 bytes
radeon/kaveri_pfp.bin | Bin 8832 - 8832 bytes
radeon/kaveri_rlc.bin | Bin 10496 - 10496 bytes
radeon/kaveri_sdma.bin | Bin 4456 - 4456 bytes
7 files changed, 0 insertions(+), 0 deletions(-)
diff --git a/radeon/kaveri_ce.bin b/radeon/kaveri_ce.bin
index
d86d86e1cd712539fb1940cb58d91281e8554eea..95163d49ae6d4b75bd39da37
f740dc5a508ce9cd 100644
GIT binary patch
delta 769
zc${^SO-
NKx6vzMPy*Klk5%UAb=ILVQnUaKoUlcM?ZKuu#}btS`cj_8lhUuj8~E}
ziWXfzFs(pZ2oV`W(AQ$3oTbJl$bF0wTV6gPhK#i41D-
d*^@8`QLlqxmQF)#1UR
z9ROlXXozwY_OHaJ?!l+lZTl7#ZboXj2Ysalr==G6lMuFUR@b*lot_)bh(Cd8;4
zb!iQ$5kFF+grJv1YfPc?gj)AEnz0P77jwM;J=rd9v}pZ;YBlMEFG9o9$BaPtqegZ
z9F(SfK(+u*w!NO_56T1DhQg_wGwMNE+6{mDnjFwV;RI@31a9cG#yr3XA9`k
v_pjw5
z{^(-
tFY%0;e#^|^ezhdL)%0rWR2cN)AFbub%QtH6GA7YvN1wL!2@_2=sIM}o
!
zVKU5f|VVhykbXNL2Pma$;W^?KH=O3M{Ju%#s@CYJJ!t$D2+O?lmr!rR|
6Xa-#
zXEs#cD=(}gG4w+sc@{6A3{y`8GldqA-
@jdO=ktJ#_?N=D{ppI50JavYz5b9)}
z#vs11{ITYLF04$h7?s-hRax$8r*_%vI%#zfF7(4$%g+_d%Z86A3$?-j3u)mrgV!
zzq)tPaoJ*q!s_{yRh4hj5kqyj$GNpUU^O0$IPs}WA353B}QUU$Tw18)RULiq
VJ?
z9D;=qn$Sf8y)=NsbQ*owhH-4iG8_bGH;ODqBMkIier)zuD~?=zMao-
9WO(Hhuy}
CmEV2
delta 813
zc${sKTSydP6vzL^ncZoD=MxLJ7ZfJXr%=`tmv#41S8T23wkjy^i_PQhrNs#U9bZ
C
zyrgEB)Jw3X2wg;I9@?ddRTCffp@bd+pL!~7pL#Kt?_M=KRl@^PQRh`K(r})v
zjo
zY5G$U;9y%h)Nr+}=D=wqQJ`ya4Rc0(1lwl+^Z$lHF^;IY2~rO`$_@Ox36B2;;
Q
z(!5`VJ(dT1JO|yGb{^$}p5d^P4}H}ObLs@=g_uoi_8M%mkE}{M6q28WO86;+
K*BC
zJRizM@GYS`yBxVZ-
yS6^97#ClxDO@Xlo#cxry`LR3J;*lLuiVS*%a{sV|?u%_Da+
zgg?3v=ZdmX7Au9B1}$3i^Iwx8Wf#M8_kGGCDfVVZfOpvOKSKYT)V$hd`X
mH*!Z
znptMvFiGYe^Fg{~3aq{H4#%2UW1Y|XwAA88mMV;tm!qkBkXF~(ctQO2NN
L(`07F
zWZbKfZ}ARhlL{94Y1nNM~F4+u2t)*YT;d0uQ4;A(3os=%BC=903;@%JGl=
Q$H
zBi#1@Pm(%%Q{=H?3di4`zu}i%0)iqmPld1o4}cZd$XOXeOGn*oQQYxd
@i!B0
z$6;=)Z)574GLUlES2mAqUfkzZh@!KnkgbKYoV~bec38srzQ$O+Mq=ZswU6
|KSz0
zB)({;RQY#{wR={}N6eaghT1kuDki89btu9G_z}W!w2_4_8pK5!LLW}zF6yxk6D8
Dw
d9=e8Jx`|s9#R$bvMwN)s@ZuSxmPEIq{st=3=F$KF
diff --git a/radeon/kaveri_me.bin b/radeon/kaveri_me.bin
index
f65c1c86c417b3ed53c235c5e8fbe00756fd931e..4920e2ed5619e51c687d96c244
16f0d465d6b327 100644
GIT binary patch
delta 1147
zc$~G8O-K}B9LE3u*_n6Sa@(E#aCdgI-
Em!0(zc~oofdP~kh17QMd;(8hrkT1q+_m)
zg+?f8y;!Ia5?z8h6ibKZWFJrmDWrl9MTh9%p-zGkfxYi2waEruIy~gJkS4~cjh;v
zH|x!+UJg(L0LWwq0rJdsbtSm7OMI?8Q0oNQZHH0ZmYoxrY)rmk1#@iv;u%
0d($*
zd2}=ia`b7hD^OE0nF{+KKN=W-
@4%haq=4gTb#jjyFO2NRItZW_hwun9T4*@f0LA
zJZbS9MmL@GgwaPIdR{xMc4iN2u6rACFP-;pspU@+h4-
x?xSi{eKuvQ1^2+J2UlI;
zPUF4^cF;D9b0q0SgIE?6A1BVQ8?Kag319tSyE{v{V+TAqufY(nZr6GDKoEP?qW
V3
zqc45CaUWIvUbOMG+QzmKyP*oeuIsT2mrTuHWV{7JywvWRUOa^LzcgKj$
~J)BeJK
zFu2mlDMNFm3Y*8P=hP+EtUN99B=ja-?v2-
a1DvO~;Q(RTApiew@wrvoAf|$uLG
zU17S(beHK2?JMoXYjnOeftM%-(s-UW1QOUydjpZp{{W-Qf?--
P%px$%A}~w~hRI=A
zd)B^~Sp-
20WymKGC3ftSqsDDFeKh|(uLqw^isdF1HaN1Wg464XQdkt(SxBh_Ry=L
z12{t8hQ`XK*k831GVc(w{b{ICRPZSd$V?)*6U$x9KhprGTe?=$G(EZHY~PC#
OV?
zm)QB+|6O(_C(}kI7nRB)4!+w`zP9YC?S?AiH!7)T9m`S{!lVf*Xig2wX!yVjFA{
v+o6ISg#mg`OWu$IT$AcFhPc3iVVXiG6IXlWyy)HP=RB=uK$Co|9SW)xjHf~
delta 1134
zc$~G8PeF|9LImZ*`2peuIFmvzxf%wx(pROQ9~yTa?cBplUim(nDWd(Kd
V7N9
zN}yreD?^2_Zo(YOrGYLX*r9_EQA9x@9Xfc^tRO1ry-
8|?MY?qOzAy9r{@$CJy1Q;
zGm2UZFs?WB~zYnXAh0U~*}`-
uqB#6zLzjAB!IL0~d5*^9lx2q~opjrh`xi1${
zJS_!%93zwV6eLh0f;7sU4t%A=%;9{_OWJ%kRva?{6-
@ZVPCrhQtG*4t_Nz%xZ
zz0Un;r4!B|+UXbOUY=bceAG8c9+r;o7LKSDQWdm?GpA$iiLg*QH-
tc^T;@(A
z?i$R|jJuVsd3U(!ETnEDM4pDArz-$;gM89jr^Q?_H~FJhi#eDg%-0hudkr5-R-!C
zuJ~MteDxq3Cl)OZmIp}_8xa8RAkBJspZ2Nc;6h;;?Y=1$0_1Eq=yRy62w9mE?
`1
zMT^^7)=ys#Yw^+W`mBwe+ERKdT`}(Z!OvIOn}{3|qS)412~r+U|)E+o9*gn8e
+P|
zbf4)Q?e`wX8}zL=idU)ROJE(_@dZL`+POt4ImsdAm|1Jy$l51fS_{-NxcjNz051
zWx(hhOoLtqj9vzeZa~mE1d;dM^qYSh+Gs@HfuHCRc?#R7x@%+((XV4Ptu9
NJ{+ST
z17p?W@V60sW%Aefdn+l3btnQWFUFNDnOpee8{Af;oIbe+C!ht8Dr!Ic?@x
1q-Mf
z$;2cvZDOjVp6VKj?1CSR?nLXDf;ujGw8foR_|fY4DL5Tbb{=pf_(5OWu7Hs
Hj
s4#Pz{qeL%VBY7AlgHRwtFiwVHkM7Hu^FnuENsECKiB_34gWm+3!Zf_Eu=
k
diff --git a/radeon/kaveri_mec.bin b/radeon/kaveri_mec.bin
index
96bc1c9f77e19b318d412c6af047bf8eb583dd5f..96322d60199a472d61c9b9b20
9ebb8e9b4a7c8dd 100644
GIT binary patch
delta 8620
zc$}?SeRP!NmA~h-;+r)Lng^5;Bu8lbL)Fh9N-
sFnNQ*7V8R92o?g0MYQ%~xv)S
zP3C6)v_*C^vMTFC`T!J`oTwRSm{?Y{I(+1O4Jq|`=@E?U
RE: [PATCH] drm/radeon: remove code that can never get executed
-Original Message- From: Henning Schild [mailto:henn...@hennsch.de] Sent: Monday, October 13, 2014 12:44 PM To: Deucher, Alexander; linux-kernel@vger.kernel.org Cc: Rafał Miłecki Subject: RE: [PATCH] drm/radeon: remove code that can never get executed Well i am not sure what the code actually is supposed to do. That is up to you because you know the hardware. I just wanted to point out that right now some code can never be reached. I ran into the whole thing because the pointer (sadp) that gets kfreed was never initialized (in one of the three cases). My first fix was to initialize it to NULL, that way the kfree did not fail even if the allocation did not do anything. Then i found the other two copies and decided to follow their scheme. In your patch you have to make kfree depend on (sad_count 0) or sadp needs to be initialized with NULL. Otherwise you will get the dangling pointer kfree that lead me to read this code. Ah, ok. The attached patches should do the trick then. Alex Henning On October 13, 2014 at 6:08 PM Deucher, Alexander alexander.deuc...@amd.com wrote: -Original Message- From: Henning Schild [mailto:henn...@hennsch.de] Sent: Saturday, October 11, 2014 8:51 AM To: linux-kernel@vger.kernel.org Cc: Henning Schild; Deucher, Alexander; Rafał Miłecki Subject: [PATCH] drm/radeon: remove code that can never get executed Removing a code-path that can never be executed ... and its copies. If drm_edid_to_speaker_allocation returns 0 the callers return. There is no need to check that condition again. I think we actually want to set the speaker allocation setup to stereo if the speaker allocation block is not present so I think the attached patch is probably the proper fix. Alex Signed-off-by: Henning Schild henn...@hennsch.de --- drivers/gpu/drm/radeon/dce3_1_afmt.c | 5 + drivers/gpu/drm/radeon/dce6_afmt.c | 5 + drivers/gpu/drm/radeon/evergreen_hdmi.c | 5 + 3 files changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c b/drivers/gpu/drm/radeon/dce3_1_afmt.c index cb76074..6d31ed8 100644 --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c @@ -58,10 +58,7 @@ static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c b/drivers/gpu/drm/radeon/dce6_afmt.c index ab29f95..e6b2750 100644 --- a/drivers/gpu/drm/radeon/dce6_afmt.c +++ b/drivers/gpu/drm/radeon/dce6_afmt.c @@ -186,10 +186,7 @@ void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index 278c7a1..11a6b65 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -128,10 +128,7 @@ static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); -- 2.0.4 0001-drm-radeon-initialize-sadb-to-NULL-in-the-audio-code.patch Description: 0001-drm-radeon-initialize-sadb-to-NULL-in-the-audio-code.patch 0002-drm-radeon-fix-speaker-allocation-setup.patch Description: 0002-drm-radeon-fix-speaker-allocation-setup.patch
RE: [PATCH] drm/radeon: remove code that can never get executed
-Original Message- From: Henning Schild [mailto:henn...@hennsch.de] Sent: Saturday, October 11, 2014 8:51 AM To: linux-kernel@vger.kernel.org Cc: Henning Schild; Deucher, Alexander; Rafał Miłecki Subject: [PATCH] drm/radeon: remove code that can never get executed Removing a code-path that can never be executed ... and its copies. If drm_edid_to_speaker_allocation returns 0 the callers return. There is no need to check that condition again. I think we actually want to set the speaker allocation setup to stereo if the speaker allocation block is not present so I think the attached patch is probably the proper fix. Alex Signed-off-by: Henning Schild henn...@hennsch.de --- drivers/gpu/drm/radeon/dce3_1_afmt.c| 5 + drivers/gpu/drm/radeon/dce6_afmt.c | 5 + drivers/gpu/drm/radeon/evergreen_hdmi.c | 5 + 3 files changed, 3 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c b/drivers/gpu/drm/radeon/dce3_1_afmt.c index cb76074..6d31ed8 100644 --- a/drivers/gpu/drm/radeon/dce3_1_afmt.c +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c @@ -58,10 +58,7 @@ static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); diff --git a/drivers/gpu/drm/radeon/dce6_afmt.c b/drivers/gpu/drm/radeon/dce6_afmt.c index ab29f95..e6b2750 100644 --- a/drivers/gpu/drm/radeon/dce6_afmt.c +++ b/drivers/gpu/drm/radeon/dce6_afmt.c @@ -186,10 +186,7 @@ void dce6_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32_ENDPOINT(offset, AZ_F0_CODEC_PIN_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); diff --git a/drivers/gpu/drm/radeon/evergreen_hdmi.c b/drivers/gpu/drm/radeon/evergreen_hdmi.c index 278c7a1..11a6b65 100644 --- a/drivers/gpu/drm/radeon/evergreen_hdmi.c +++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c @@ -128,10 +128,7 @@ static void dce4_afmt_write_speaker_allocation(struct drm_encoder *encoder) tmp = ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); /* set HDMI mode */ tmp |= HDMI_CONNECTION; - if (sad_count) - tmp |= SPEAKER_ALLOCATION(sadb[0]); - else - tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + tmp |= SPEAKER_ALLOCATION(sadb[0]); WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); kfree(sadb); -- 2.0.4 0001-drm-radeon-fix-speaker-allocation-setup.patch Description: 0001-drm-radeon-fix-speaker-allocation-setup.patch
RE: [PATCH] drm/radeon: remove unreachable code
-Original Message-
From: Nicholas Mc Guire [mailto:der.h...@hofr.at]
Sent: Monday, January 19, 2015 8:11 AM
To: Deucher, Alexander
Cc: Koenig, Christian; David Airlie; dri-de...@lists.freedesktop.org; linux-
ker...@vger.kernel.org; Nicholas Mc Guire
Subject: [PATCH] drm/radeon: remove unreachable code
Signed-off-by: Nicholas Mc Guire der.h...@hofr.at
NACK. I want to leave this in place for the future. When we support
dynamically adjusting the disp clock we'll need to update the sclk for ds mode.
Alex
---
As the if (CISLAND_MINIMUM_ENGINE_CLOCK !=
CISLAND_MINIMUM_ENGINE_CLOCK) is never
satisfied - the entire else branch is never going to be executed and could be
removed - provided this is not simply a bug and needs to be fixed...
Patch is against 3.19.0-rc5 -next-20150119
Patch was only compile tested with x86_64_defconfig + CONFIG_DRM=m,
CONFIG_DRM_RADEON=m
drivers/gpu/drm/radeon/ci_dpm.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/ci_dpm.c
b/drivers/gpu/drm/radeon/ci_dpm.c
index f373a81..28db529 100644
--- a/drivers/gpu/drm/radeon/ci_dpm.c
+++ b/drivers/gpu/drm/radeon/ci_dpm.c
@@ -3805,13 +3805,8 @@ static void
ci_find_dpm_states_clocks_in_dpm_table(struct radeon_device *rdev,
break;
}
- if (i = sclk_table-count) {
+ if (i = sclk_table-count)
pi-need_update_smu7_dpm_table |=
DPMTABLE_OD_UPDATE_SCLK;
- } else {
- /* XXX check display min clock requirements */
- if (CISLAND_MINIMUM_ENGINE_CLOCK !=
CISLAND_MINIMUM_ENGINE_CLOCK)
- pi-need_update_smu7_dpm_table |=
DPMTABLE_UPDATE_SCLK;
- }
for (i = 0; i mclk_table-count; i++) {
if (mclk == mclk_table-dpm_levels[i].value)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] drm/radeon: Fix regression with suspend/resume
-Original Message- From: Christian König [mailto:deathsim...@vodafone.de] Sent: Wednesday, February 18, 2015 7:02 AM To: Ross Zwisler; Deucher, Alexander Cc: Michel Dänzer; linux-kernel@vger.kernel.org; dri- de...@lists.freedesktop.org; Dave Airlie; Lauri Kasanen; Koenig, Christian Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume On 17.02.2015 18:49, Ross Zwisler wrote: On Sat, 2015-02-14 at 06:25 +, Deucher, Alexander wrote: -Original Message- From: Ross Zwisler [mailto:ross.zwis...@linux.intel.com] Sent: Friday, February 13, 2015 10:55 PM To: Michel Dänzer Cc: linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; Deucher, Alexander; Dave Airlie; Lauri Kasanen; Koenig, Christian Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume On Fri, 2015-02-13 at 11:41 +0900, Michel Dänzer wrote: On 13.02.2015 05:30, Ross Zwisler wrote: This patch reverts the changes made in this commit: deadcb36f49b (drm/radeon: Use two-ended allocation by size, v2) That patch caused a regression on my system where the bottom of the screen flickers after my laptop goes thorough a suspend and resume. What kind of flicker is it? E.g. does it only affect X or also console, does it flicker all the time or only when there is activity, what does it look like, ... It's kind of hard to describe it precisely, so I made a video. :) http://youtu.be/ESm9SMnr0do It only affects X, not the console, and it seems to go away if you log out back to the login manager (I'm using GDM on Fedora 20) and back into your window manager. Does a VT switch or forcing a dpms cycle (sleep 5; xset dpms force off) also fix it? It doesn't look related to the patch in question at all. Is the flickering 100% reproducible or does it only happen periodically? From kernels 3.14 or so (when the deadcb36f49b patch was introduced) till 3.18 it happened 100% of the time. With 3.19 it only seems to happen maybe 50% of the time, but is still very easily reproducible. Well, what the patch does is just changing where buffers are placed in memory. E.g. now we place the buffer at the end of memory as well. So I can imagine at least three possible causes for the issues you see: 1. We haven't implemented all buffer placement restrictions correctly and without the patch everything just works fine by coincident. 2. Something is overwriting the buffer at it's new location. @AlexMichel: Didn't we had a similar problem internally recently? Or was that just for APUs? I think that was just two engines trying to use the same memory location for writeback since we had not properly allocated a writeback slot. What's odd to me is that the region is actively flickering, it looks almost like a display timing issue. I would expect static corruption unless something else is actively writing to the region. Alex 3. One of the memory chips on your hardware is faulty and without the patch the we just don't use the affected region (rather unlikely). For testing could you try to limit the amount of VRAM used? E.g. give radeon.vramlimit=256 as kernel commandline to limit the VRAM to the first 256MB. Regards, Christian. It's entirely possible that the patch isn't the root cause, but it just brought out a bug somewhere else. All I know is that I did a bisect, and with the commit before this the issue never happens, and after this commit it happens 100% of the time. :) Also, reverting that commit with 3.19 makes the issue go away. Nope, xset dpms force off doesn't fix it. After the screen goes black and comes back, the flicker is still there. - Ross ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC
-Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Thursday, January 08, 2015 4:58 PM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri-devel Subject: Re: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC On 01/08/2015 12:48 PM, Deucher, Alexander wrote: -Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Thursday, January 08, 2015 11:26 AM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri-devel Subject: Re: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC On 01/07/2015 09:51 PM, Deucher, Alexander wrote: -Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Wednesday, January 07, 2015 5:51 PM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri- devel Subject: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC Hi Alexander, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 Author: Alex Deucher alexander.deuc...@amd.com Date: Mon Jul 14 12:01:40 2014 -0400 drm/radeon: re-enable dpm by default on BTC The regression was introduced as of v3.17-rc1 and still exists in current mainline. It has also made it's way into the stable releases. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Does revering b2dccf24e77 help? I'd hate to revert this patch because it disables power management for a whole family of chips. If it doesn't help I'd prefer to just add a quirk to disable it for the specific problematic board. Commit b2dccf24e77 was added to mainline as of v3.18-rc1 and was not cc'd to stable. We are also seeing this issue in the 3.13.y stable kernel, which does not have commit b2dccf24e77 applied. However, we can test reverting it in mainline? Nope. Won't make a difference. The attached patch adds a quirk list for dpm which will fix the issue for the affected boards. Alex Thanks again for the patch, Alex. The bug reporter has tested a 3.16 kernel with the patch and says it fixes the bug. I'll queue it up for 3.19-fixes and cc stable. Thanks, Alex Alex Thanks, Joe [0] http://pad.lv/1386534
RE: [PATCH] drm/radeon: Fix regression with suspend/resume
-Original Message- From: Ross Zwisler [mailto:ross.zwis...@linux.intel.com] Sent: Friday, February 13, 2015 10:55 PM To: Michel Dänzer Cc: linux-kernel@vger.kernel.org; dri-de...@lists.freedesktop.org; Deucher, Alexander; Dave Airlie; Lauri Kasanen; Koenig, Christian Subject: Re: [PATCH] drm/radeon: Fix regression with suspend/resume On Fri, 2015-02-13 at 11:41 +0900, Michel Dänzer wrote: On 13.02.2015 05:30, Ross Zwisler wrote: This patch reverts the changes made in this commit: deadcb36f49b (drm/radeon: Use two-ended allocation by size, v2) That patch caused a regression on my system where the bottom of the screen flickers after my laptop goes thorough a suspend and resume. What kind of flicker is it? E.g. does it only affect X or also console, does it flicker all the time or only when there is activity, what does it look like, ... It's kind of hard to describe it precisely, so I made a video. :) http://youtu.be/ESm9SMnr0do It only affects X, not the console, and it seems to go away if you log out back to the login manager (I'm using GDM on Fedora 20) and back into your window manager. Does a VT switch or forcing a dpms cycle (sleep 5; xset dpms force off) also fix it? It doesn't look related to the patch in question at all. Is the flickering 100% reproducible or does it only happen periodically? Alex I've tested with OpenBox, Gnome and KDE, and it happens in all three, so it doesn't appear to be related to the window manager. It does appear to flicker more if you move the mouse, but it still does flicker occasionally if you aren't doing anything.
RE: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC
-Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Wednesday, January 07, 2015 5:51 PM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri-devel Subject: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC Hi Alexander, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 Author: Alex Deucher alexander.deuc...@amd.com Date: Mon Jul 14 12:01:40 2014 -0400 drm/radeon: re-enable dpm by default on BTC The regression was introduced as of v3.17-rc1 and still exists in current mainline. It has also made it's way into the stable releases. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Does revering b2dccf24e77 help? I'd hate to revert this patch because it disables power management for a whole family of chips. If it doesn't help I'd prefer to just add a quirk to disable it for the specific problematic board. Alex Thanks, Joe [0] http://pad.lv/1386534
RE: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC
-Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Thursday, January 08, 2015 11:26 AM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri-devel Subject: Re: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC On 01/07/2015 09:51 PM, Deucher, Alexander wrote: -Original Message- From: Joseph Salisbury [mailto:joseph.salisb...@canonical.com] Sent: Wednesday, January 07, 2015 5:51 PM To: Deucher, Alexander Cc: sta...@vger.kernel.org; LKML; Koenig, Christian; David Airlie; dri-devel Subject: [Regression][v3.17][3.18][3.19-rc3] drm/radeon: re-enable dpm by default on BTC Hi Alexander, A kernel bug report was opened against Ubuntu [0]. After a kernel bisect, it was found that reverting the following commit resolved this bug: commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 Author: Alex Deucher alexander.deuc...@amd.com Date: Mon Jul 14 12:01:40 2014 -0400 drm/radeon: re-enable dpm by default on BTC The regression was introduced as of v3.17-rc1 and still exists in current mainline. It has also made it's way into the stable releases. I was hoping to get your feedback, since you are the patch author. Do you think gathering any additional data will help diagnose this issue, or would it be best to submit a revert request? Does revering b2dccf24e77 help? I'd hate to revert this patch because it disables power management for a whole family of chips. If it doesn't help I'd prefer to just add a quirk to disable it for the specific problematic board. Commit b2dccf24e77 was added to mainline as of v3.18-rc1 and was not cc'd to stable. We are also seeing this issue in the 3.13.y stable kernel, which does not have commit b2dccf24e77 applied. However, we can test reverting it in mainline? Nope. Won't make a difference. The attached patch adds a quirk list for dpm which will fix the issue for the affected boards. Alex Alex Thanks, Joe [0] http://pad.lv/1386534 0001-drm-radeon-add-a-dpm-quirk-list.patch Description: 0001-drm-radeon-add-a-dpm-quirk-list.patch
RE: [PATCH] radeon: Do not directly dereference pointers to BIOS area.
-Original Message- From: David Miller [mailto:da...@davemloft.net] Sent: Friday, March 20, 2015 1:24 PM To: Koenig, Christian Cc: Deucher, Alexander; dri-de...@lists.freedesktop.org; linux- ker...@vger.kernel.org Subject: Re: [PATCH] radeon: Do not directly dereference pointers to BIOS area. From: Christian König christian.koe...@amd.com Date: Fri, 20 Mar 2015 10:38:32 +0100 On 19.03.2015 17:29, David Miller wrote: From: Christian König christian.koe...@amd.com Date: Thu, 19 Mar 2015 09:50:58 +0100 In general I would say yes, but for this particular hardware it's a bit questionable to do so. For radeon hardware to work correctly the CPU access to the PCIE BARs should work even without using the specialized IO macros/functions, otherwise mapping VRAM CPU accessible isn't really possible. What's the background of the change? Some problems on a certain CPU platform? or just general cleanups? It's an _iomem_ pointer, it's not a virtual address. Therefore it is illegal to dereference the pointer. The value is opaque and has values that only make sense when used with the readb() et al. interfaces. This code is relying upon the fact that on x86 it happens to be a virtual address, but this won't work on many other architectures. In this case I'm perfectly fine with it and the patch is Reviewed-by: Christian König christian.koe...@amd.com Just wanted to make sure that you're not trying to get Radeon working on a platform which will never really support the necessary hardware features. I would like this to get merged via the Radeon DRM maintainer, thanks. Already added to my tree. Thanks! Alex -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Bisected regression 4.0.0-rc1 No image with RADEON
-Original Message- From: Jim Bos [mailto:jim...@xs4all.nl] Sent: Monday, February 23, 2015 4:08 PM To: linux-kernel@vger.kernel.org Cc: Deucher, Alexander Subject: Bisected regression 4.0.0-rc1 No image with RADEON Hello, Booting 4.0-rc1 gives me black screen with monitor displaying an OSD message that input signal is not supported. Video card is ATI Radeon HD 5670, monitor 1920x1200 Dell U2412M connected via DisplayPort. Git bisect gives this $ git bisect good e55bca26188e45f209597abf986c87cc5a49894a is the first bad commit commit e55bca26188e45f209597abf986c87cc5a49894a Author: Slava Grigorev slava.grigo...@amd.com Date: Fri Dec 12 17:01:42 2014 -0500 radeon/audio: enable DP audio Reviewed-by: Christian König christian.koe...@amd.com Signed-off-by: Slava Grigorev slava.grigo...@amd.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 25da4481f28d249ec827fe72c0b14c0a50265887 2eb7eb3728a5b811b0f954cbce486841c90ef938 M drivers Comparing dmesg with bad/good kernel doesn't show any interesting differences. I've firmware build into the kernel $ grep EXTRA_FIRMWARE .config CONFIG_EXTRA_FIRMWARE=radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin radeon/REDWOOD_smc.bin radeon/CYPRESS_uvd.bin CONFIG_EXTRA_FIRMWARE_DIR=firmware Any ideas ? Can you attach your xorg log and dmesg output? Alex Thanks, Jim *** $ git bisect log git bisect start # bad: [c517d838eb7d07bbe9507871fab3931deccff539] Linux 4.0-rc1 git bisect bad c517d838eb7d07bbe9507871fab3931deccff539 # good: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19 git bisect good bfa76d49576599a4b9f9b7a71f23d73d6dcff735 # good: [02f1f2170d2831b3233e91091c60a66622f29e82] kernel.h: remove ancient __FUNCTION__ hack git bisect good 02f1f2170d2831b3233e91091c60a66622f29e82 # bad: [796e1c55717e9a6ff5c81b12289ffa1ffd919b6f] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad 796e1c55717e9a6ff5c81b12289ffa1ffd919b6f # good: [9682ec9692e5ac11c6caebd079324e727b19e7ce] Merge tag 'driver-core-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good 9682ec9692e5ac11c6caebd079324e727b19e7ce # good: [a9724125ad014decf008d782e60447c811391326] Merge tag 'tty-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect good a9724125ad014decf008d782e60447c811391326 # good: [f43dff0ee00a259f524ce17ba4f8030553c66590] Merge tag 'drm-amdkfd-next-fixes-2015-01-25' of git://people.freedesktop.org/~gabbayo/linux into drm-next git bisect good f43dff0ee00a259f524ce17ba4f8030553c66590 # bad: [cffe1e89dc9bf541a39d9287ced7c5addff07084] drm: sti: HDMI add audio infoframe git bisect bad cffe1e89dc9bf541a39d9287ced7c5addff07084 # bad: [2f5b4ef15c60bc5292a3f006c018acb3da53737b] Merge tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next git bisect bad 2f5b4ef15c60bc5292a3f006c018acb3da53737b # bad: [cc0cc1aa279067207085b75a674453e021879801] Merge branch 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux into drm-next git bisect bad cc0cc1aa279067207085b75a674453e021879801 # good: [8ffea8570d5a7e9dd3c10349ebc3bd79487ae30b] radeon/audio: removed unnecessary CRC control programing git bisect good 8ffea8570d5a7e9dd3c10349ebc3bd79487ae30b # good: [eb88e422c502a7a1628cc919020e2ebf59450d4d] drm/exynos: remove drm_dev from struct exynos_drm_manager git bisect good eb88e422c502a7a1628cc919020e2ebf59450d4d # bad: [f4c6c08182b3f648b788422f27926f097759b0eb] drm/radeon: whitespace clean up in radeon_audio.c git bisect bad f4c6c08182b3f648b788422f27926f097759b0eb # good: [7f604077ac9cacb9a6b04b977e2cd1f26cb3f667] radeon/audio: removed unnecessary debug settings git bisect good 7f604077ac9cacb9a6b04b977e2cd1f26cb3f667 # good: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: applied audio_dpms() and audio_mode_set() calls git bisect good 6f945693be7eea24b1a8e5ce252a96df98d55a5c # bad: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio git bisect bad e55bca26188e45f209597abf986c87cc5a49894a # good: [ccd4be7eb7ef2aac076b604c716f36aa926651e3] radeon/audio: moved audio caps programming to audio_hotplug() function git bisect good ccd4be7eb7ef2aac076b604c716f36aa926651e3 # first bad commit: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio
RE: Bisected regression 4.0.0-rc1 No image with RADEON
-Original Message- From: Deucher, Alexander Sent: Monday, February 23, 2015 4:32 PM To: 'Jim Bos'; linux-kernel@vger.kernel.org Cc: Grigorev, Slava Subject: RE: Bisected regression 4.0.0-rc1 No image with RADEON -Original Message- From: Jim Bos [mailto:jim...@xs4all.nl] Sent: Monday, February 23, 2015 4:08 PM To: linux-kernel@vger.kernel.org Cc: Deucher, Alexander Subject: Bisected regression 4.0.0-rc1 No image with RADEON Hello, Booting 4.0-rc1 gives me black screen with monitor displaying an OSD message that input signal is not supported. Video card is ATI Radeon HD 5670, monitor 1920x1200 Dell U2412M connected via DisplayPort. Git bisect gives this $ git bisect good e55bca26188e45f209597abf986c87cc5a49894a is the first bad commit commit e55bca26188e45f209597abf986c87cc5a49894a Author: Slava Grigorev slava.grigo...@amd.com Date: Fri Dec 12 17:01:42 2014 -0500 radeon/audio: enable DP audio Reviewed-by: Christian König christian.koe...@amd.com Signed-off-by: Slava Grigorev slava.grigo...@amd.com Signed-off-by: Alex Deucher alexander.deuc...@amd.com :04 04 25da4481f28d249ec827fe72c0b14c0a50265887 2eb7eb3728a5b811b0f954cbce486841c90ef938 M drivers Comparing dmesg with bad/good kernel doesn't show any interesting differences. I've firmware build into the kernel $ grep EXTRA_FIRMWARE .config CONFIG_EXTRA_FIRMWARE=radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin radeon/REDWOOD_smc.bin radeon/CYPRESS_uvd.bin CONFIG_EXTRA_FIRMWARE_DIR=firmware Any ideas ? Does the attached patch help? Alex Can you attach your xorg log and dmesg output? Alex Thanks, Jim *** $ git bisect log git bisect start # bad: [c517d838eb7d07bbe9507871fab3931deccff539] Linux 4.0-rc1 git bisect bad c517d838eb7d07bbe9507871fab3931deccff539 # good: [bfa76d49576599a4b9f9b7a71f23d73d6dcff735] Linux 3.19 git bisect good bfa76d49576599a4b9f9b7a71f23d73d6dcff735 # good: [02f1f2170d2831b3233e91091c60a66622f29e82] kernel.h: remove ancient __FUNCTION__ hack git bisect good 02f1f2170d2831b3233e91091c60a66622f29e82 # bad: [796e1c55717e9a6ff5c81b12289ffa1ffd919b6f] Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux git bisect bad 796e1c55717e9a6ff5c81b12289ffa1ffd919b6f # good: [9682ec9692e5ac11c6caebd079324e727b19e7ce] Merge tag 'driver-core-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core git bisect good 9682ec9692e5ac11c6caebd079324e727b19e7ce # good: [a9724125ad014decf008d782e60447c811391326] Merge tag 'tty-3.20-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty git bisect good a9724125ad014decf008d782e60447c811391326 # good: [f43dff0ee00a259f524ce17ba4f8030553c66590] Merge tag 'drm-amdkfd-next-fixes-2015-01-25' of git://people.freedesktop.org/~gabbayo/linux into drm-next git bisect good f43dff0ee00a259f524ce17ba4f8030553c66590 # bad: [cffe1e89dc9bf541a39d9287ced7c5addff07084] drm: sti: HDMI add audio infoframe git bisect bad cffe1e89dc9bf541a39d9287ced7c5addff07084 # bad: [2f5b4ef15c60bc5292a3f006c018acb3da53737b] Merge tag 'drm/tegra/for-3.20-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next git bisect bad 2f5b4ef15c60bc5292a3f006c018acb3da53737b # bad: [cc0cc1aa279067207085b75a674453e021879801] Merge branch 'drm-next-3.20' of git://people.freedesktop.org/~agd5f/linux into drm- next git bisect bad cc0cc1aa279067207085b75a674453e021879801 # good: [8ffea8570d5a7e9dd3c10349ebc3bd79487ae30b] radeon/audio: removed unnecessary CRC control programing git bisect good 8ffea8570d5a7e9dd3c10349ebc3bd79487ae30b # good: [eb88e422c502a7a1628cc919020e2ebf59450d4d] drm/exynos: remove drm_dev from struct exynos_drm_manager git bisect good eb88e422c502a7a1628cc919020e2ebf59450d4d # bad: [f4c6c08182b3f648b788422f27926f097759b0eb] drm/radeon: whitespace clean up in radeon_audio.c git bisect bad f4c6c08182b3f648b788422f27926f097759b0eb # good: [7f604077ac9cacb9a6b04b977e2cd1f26cb3f667] radeon/audio: removed unnecessary debug settings git bisect good 7f604077ac9cacb9a6b04b977e2cd1f26cb3f667 # good: [6f945693be7eea24b1a8e5ce252a96df98d55a5c] radeon/audio: applied audio_dpms() and audio_mode_set() calls git bisect good 6f945693be7eea24b1a8e5ce252a96df98d55a5c # bad: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio git bisect bad e55bca26188e45f209597abf986c87cc5a49894a # good: [ccd4be7eb7ef2aac076b604c716f36aa926651e3] radeon/audio: moved audio caps programming to audio_hotplug() function git bisect good ccd4be7eb7ef2aac076b604c716f36aa926651e3 # first bad commit: [e55bca26188e45f209597abf986c87cc5a49894a] radeon/audio: enable DP audio 0001-drm-radeon-only-enable-DP-audio-if-the-monitor-suppo.patch
RE: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard
-Original Message- From: Mikael Pettersson [mailto:mikpeli...@gmail.com] Sent: Monday, May 04, 2015 11:53 AM To: linux-kernel@vger.kernel.org Cc: Deucher, Alexander Subject: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses hard, requiring a hard reset: BUG: unable to handle kernel NULL pointer dereference at 0010 IP: [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] PGD 0 Oops: [#1] SMP Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore usb_common ipv6 CPU: 0 PID: 163 Comm: kworker/0:2 Not tainted 4.1.0-rc2 #1 Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 0403 05/08/2012 Workqueue: events output_poll_execute [drm_kms_helper] task: 8806012b1590 ti: 88003796 task.ti: 88003796 RIP: 0010:[a03d0e1b] [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] RSP: 0018:880037963c78 EFLAGS: 00010246 RAX: 880600c92da0 RBX: 880600cbb000 RCX: 0001 RDX: RSI: RDI: 880037a3f600 RBP: 880600c92da0 R08: 0001 R09: 0050 R10: 0001 R11: 880603001a80 R12: 0001 R13: 880600c924e0 R14: 880601f84000 R15: 0001 FS: () GS:88061ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0010 CR3: 01478000 CR4: 001407f0 Stack: 880600cbb000 0001 0001 880601f84000 a03e7d70 a03157ea 880601f84000 0002 880600baa200 880600cbb050 880600cbb000 880600e33800 Call Trace: [a03157ea] ? radeon_dvi_detect+0x35a/0x4d0 [radeon] [a0262b06] ? drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 [drm_kms_helper] [a026bde8] ? drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 [drm_kms_helper] [a026cf55] ? drm_fb_helper_hotplug_event+0x55/0xe0 [drm_kms_helper] [a026267c] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper] [81050680] ? process_one_work+0x130/0x360 [81050cb4] ? worker_thread+0x114/0x460 [8134c02d] ? __schedule+0x20d/0x660 [81050ba0] ? rescuer_thread+0x2f0/0x2f0 [81054e4c] ? kthread+0xbc/0xe0 [81054d90] ? kthread_create_on_node+0x170/0x170 [8134f9e2] ? ret_from_fork+0x42/0x70 [81054d90] ? kthread_create_on_node+0x170/0x170 Code: 8b 45 00 4c 8b ad 58 01 00 00 4c 8b 70 28 49 8b 85 00 01 00 00 48 85 c0 74 30 41 83 fc 01 74 38 48 8b 70 10 49 8b 96 c8 24 00 00 48 8b 4a 10 48 85 c9 74 0e 31 d2 4c 89 f7 ff d1 49 8b 85 00 01 RIP [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] RSP 880037963c78 CR2: 0010 ---[ end trace 5b99e3870bfc7a92 ]--- BUG: unable to handle kernel paging request at ffd8 IP: [810552d7] kthread_data+0x7/0x10 PGD 1479067 PUD 147b067 PMD 0 Oops: [#2] SMP Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore usb_common ipv6 CPU: 0 PID: 163 Comm: kworker/0:2 Tainted: G D 4.1.0-rc2 #1 Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 0403 05/08/2012 task: 8806012b1590 ti: 88003796 task.ti: 88003796 RIP: 0010:[810552d7] [810552d7] kthread_data+0x7/0x10 RSP: 0018:880037963a60 EFLAGS: 00010002 RAX: RBX: RCX: 73c2bc6e RDX: RSI: RDI: 8806012b1590 RBP: 8806012b1590 R08: 0001 R09: 0001 R10: ea001804b800 R11: 001a R12: 8806012b1980 R13: R14: 00014300 R15: FS: () GS:88061ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0028 CR3: 01478000 CR4: 001407f0 Stack: 81051068 88061ec14300 8134c203 880037964000 8806012b1878 880037963af8 880603188000 8806012b1590 8134c4aa 8800379637d8
RE: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard
-Original Message- From: Mikael Pettersson [mailto:mikpeli...@gmail.com] Sent: Monday, May 04, 2015 3:27 PM To: Deucher, Alexander Cc: Mikael Pettersson; linux-kernel@vger.kernel.org Subject: RE: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard Deucher, Alexander writes: -Original Message- From: Mikael Pettersson [mailto:mikpeli...@gmail.com] Sent: Monday, May 04, 2015 11:53 AM To: linux-kernel@vger.kernel.org Cc: Deucher, Alexander Subject: [REGRESSION,BISECTED] 4.1-rc2 radeon audio changes oops the kernel hard On my Ivy Bridge i7 mobo w/ Radeon graphics, the 4.1-rc2 kernel oopses hard, requiring a hard reset: BUG: unable to handle kernel NULL pointer dereference at 0010 IP: [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] PGD 0 Oops: [#1] SMP Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore usb_common ipv6 CPU: 0 PID: 163 Comm: kworker/0:2 Not tainted 4.1.0-rc2 #1 Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 0403 05/08/2012 Workqueue: events output_poll_execute [drm_kms_helper] task: 8806012b1590 ti: 88003796 task.ti: 88003796 RIP: 0010:[a03d0e1b] [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] RSP: 0018:880037963c78 EFLAGS: 00010246 RAX: 880600c92da0 RBX: 880600cbb000 RCX: 0001 RDX: RSI: RDI: 880037a3f600 RBP: 880600c92da0 R08: 0001 R09: 0050 R10: 0001 R11: 880603001a80 R12: 0001 R13: 880600c924e0 R14: 880601f84000 R15: 0001 FS: () GS:88061ec0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 0010 CR3: 01478000 CR4: 001407f0 Stack: 880600cbb000 0001 0001 880601f84000 a03e7d70 a03157ea 880601f84000 0002 880600baa200 880600cbb050 880600cbb000 880600e33800 Call Trace: [a03157ea] ? radeon_dvi_detect+0x35a/0x4d0 [radeon] [a0262b06] ? drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 [drm_kms_helper] [a026bde8] ? drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 [drm_kms_helper] [a026cf55] ? drm_fb_helper_hotplug_event+0x55/0xe0 [drm_kms_helper] [a026267c] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper] [81050680] ? process_one_work+0x130/0x360 [81050cb4] ? worker_thread+0x114/0x460 [8134c02d] ? __schedule+0x20d/0x660 [81050ba0] ? rescuer_thread+0x2f0/0x2f0 [81054e4c] ? kthread+0xbc/0xe0 [81054d90] ? kthread_create_on_node+0x170/0x170 [8134f9e2] ? ret_from_fork+0x42/0x70 [81054d90] ? kthread_create_on_node+0x170/0x170 Code: 8b 45 00 4c 8b ad 58 01 00 00 4c 8b 70 28 49 8b 85 00 01 00 00 48 85 c0 74 30 41 83 fc 01 74 38 48 8b 70 10 49 8b 96 c8 24 00 00 48 8b 4a 10 48 85 c9 74 0e 31 d2 4c 89 f7 ff d1 49 8b 85 00 01 RIP [a03d0e1b] radeon_audio_detect+0x5b/0x150 [radeon] RSP 880037963c78 CR2: 0010 ---[ end trace 5b99e3870bfc7a92 ]--- BUG: unable to handle kernel paging request at ffd8 IP: [810552d7] kthread_data+0x7/0x10 PGD 1479067 PUD 147b067 PMD 0 Oops: [#2] SMP Modules linked in: af_packet snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device snd_pcm radeon cfbfillrect cfbimgblt cfbcopyarea i2c_algo_bit backlight r8169 mii coretemp snd_timer drm_kms_helper ttm snd drm i2c_core xhci_pci xhci_hcd soundcore evdev firmware_class hwmon hid_generic usbhid hid ehci_pci ehci_hcd sr_mod cdrom usbcore usb_common ipv6 CPU: 0 PID: 163 Comm: kworker/0:2 Tainted: G D 4.1.0-rc2 #1 Hardware name: System manufacturer System Product Name/P8Z77-V LE PLUS, BIOS 0403 05/08/2012 task: 8806012b1590 ti: 88003796 task.ti: 88003796 RIP: 0010:[810552d7] [810552d7] kthread_data+0x7/0x10 RSP: 0018:880037963a60 EFLAGS: 00010002 RAX: RBX: RCX: 73c2bc6e RDX: RSI: RDI: 8806012b1590 RBP
RE: [PATCH v2] radeon: Deinline indirect register accessor functions
-Original Message-
From: Denys Vlasenko [mailto:vda.li...@googlemail.com]
Sent: Monday, May 18, 2015 6:50 PM
To: Koenig, Christian
Cc: Denys Vlasenko; Deucher, Alexander; Linux Kernel Mailing List
Subject: Re: [PATCH v2] radeon: Deinline indirect register accessor functions
On Mon, May 18, 2015 at 9:09 PM, Christian König
christian.koe...@amd.com wrote:
r600_uvd_ctx_rreg: 111 bytes, 4 callsites
r600_uvd_ctx_wreg: 113 bytes, 5 callsites
eg_pif_phy0_rreg: 106 bytes, 13 callsites
eg_pif_phy0_wreg: 108 bytes, 13 callsites
eg_pif_phy1_rreg: 107 bytes, 13 callsites
eg_pif_phy1_wreg: 108 bytes, 13 callsites
rv370_pcie_rreg: 111 bytes, 21 callsites
rv370_pcie_wreg: 113 bytes, 24 callsites
r600_rcu_rreg: 111 bytes, 16 callsites
r600_rcu_wreg: 113 bytes, 25 callsites
cik_didt_rreg: 106 bytes, 10 callsites
cik_didt_wreg: 107 bytes, 10 callsites
tn_smc_rreg: 106 bytes, 126 callsites
tn_smc_wreg: 107 bytes, 116 callsites
eg_cg_rreg: 107 bytes, 20 callsites
eg_cg_wreg: 108 bytes, 52 callsites
Sorry haven't noticed that before:
radeon_device.c is most likely not the right place for the non-inlined
functions. Please move them into to the appropriate files for each
generation.
Will do (probably tomorrow, not today).
Is this whole exercise really worthwhile? This will be the 3rd or 4th time
these have been inlined/uninlined.
Can you help me here a bit?
There are LOTS of *.c files in drm/radeon/.
I guess r600_ functions should go into r600.c,
Yes.
rv370_ to rv730_dpm.c (right?),
No. rv370_ should go in r300.c
but some of the function names are less clear (to me).
Where would you like eg_pif_phyN_r/wreg() go? evergreen.c?
Yes.
Should eg_cg_r/wreg() also go to this file?
Yes.
cik_didt_r/wreg() - to cik.c?
Yes.
tn_smc_r/wreg()? Is tn = trinity? so, trinity_smc.c?
ni.c
Alex
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: linux-next: build failure after merge of the drm tree
-Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Tuesday, June 09, 2015 9:43 AM To: Dave Airlie Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Deucher, Alexander Subject: linux-next: build failure after merge of the drm tree Hi Dave, After merging the drm tree, today's linux-next build (powerpc allyesconfig) failed like this: drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function 'gfx_v7_0_cp_gfx_resume': drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: error: 'BUF_SWAP_32BIT' undeclared (first use in this function) tmp |= BUF_SWAP_32BIT; ^ drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:2879:9: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c: In function 'gfx_v7_0_cp_compute_resume': drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3398:41: error: 'BUF_SWAP_32BIT' undeclared (first use in this function) mqd-queue_state.cp_hqd_pq_control |= BUF_SWAP_32BIT; ^ drivers/gpu/drm/amd/amdgpu/cik_sdma.c: In function 'cik_sdma_gfx_resume': drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: error: 'SDMA_RB_SWAP_ENABLE' undeclared (first use in this function) rb_cntl |= SDMA_RB_SWAP_ENABLE | SDMA_RPTR_WRITEBACK_SWAP_ENABLE; ^ drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:14: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/amd/amdgpu/cik_sdma.c:413:36: error: 'SDMA_RPTR_WRITEBACK_SWAP_ENABLE' undeclared (first use in this function) rb_cntl |= SDMA_RB_SWAP_ENABLE | SDMA_RPTR_WRITEBACK_SWAP_ENABLE; ^ Caused by commit a2e73f56fa62 (drm/amdgpu: Add support for CIK parts). Should be fixed with this patch. Sorry for the breakage. Alex I added the following patch to disable this code for today: From: Stephen Rothwell s...@canb.auug.org.au Date: Tue, 9 Jun 2015 23:38:30 +1000 Subject: [PATCH] drm/amdgpu: disable CIK parts for now Signed-off-by: Stephen Rothwell s...@canb.auug.org.au --- drivers/gpu/drm/amd/amdgpu/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/amd/amdgpu/Kconfig b/drivers/gpu/drm/amd/amdgpu/Kconfig index b30fcfa4b1f2..8da6bf7f39c8 100644 --- a/drivers/gpu/drm/amd/amdgpu/Kconfig +++ b/drivers/gpu/drm/amd/amdgpu/Kconfig @@ -1,6 +1,7 @@ config DRM_AMDGPU_CIK bool Enable amdgpu support for CIK parts depends on DRM_AMDGPU + depends on BROKEN help Choose this option if you want to enable experimental support for CIK asics. -- 2.1.4 -- Cheers, Stephen Rothwells...@canb.auug.org.au 0001-drm-amdgpu-fix-the-build-on-big-endian.patch Description: 0001-drm-amdgpu-fix-the-build-on-big-endian.patch
RE: [PATCH v3] radeon: Deinline indirect register accessor functions
-Original Message-
From: Denys Vlasenko [mailto:dvlas...@redhat.com]
Sent: Wednesday, May 20, 2015 7:03 AM
To: Koenig, Christian
Cc: Denys Vlasenko; Deucher, Alexander; linux-kernel@vger.kernel.org
Subject: [PATCH v3] radeon: Deinline indirect register accessor functions
This patch deinlines indirect register accessor functions.
These functions perform two mmio accesses, framed by spin lock/unlock.
Spin lock/unlock by itself takes more than 50 cycles in ideal case
(if lock is exclusively cached on current CPU).
With this .config: http://busybox.net/~vda/kernel_config,
after uninlining these functions have sizes and callsite counts
as follows:
r600_uvd_ctx_rreg: 111 bytes, 4 callsites
r600_uvd_ctx_wreg: 113 bytes, 5 callsites
eg_pif_phy0_rreg: 106 bytes, 13 callsites
eg_pif_phy0_wreg: 108 bytes, 13 callsites
eg_pif_phy1_rreg: 107 bytes, 13 callsites
eg_pif_phy1_wreg: 108 bytes, 13 callsites
rv370_pcie_rreg: 111 bytes, 21 callsites
rv370_pcie_wreg: 113 bytes, 24 callsites
r600_rcu_rreg: 111 bytes, 16 callsites
r600_rcu_wreg: 113 bytes, 25 callsites
cik_didt_rreg: 106 bytes, 10 callsites
cik_didt_wreg: 107 bytes, 10 callsites
tn_smc_rreg: 106 bytes, 126 callsites
tn_smc_wreg: 107 bytes, 116 callsites
eg_cg_rreg: 107 bytes, 20 callsites
eg_cg_wreg: 108 bytes, 52 callsites
Functions r100_mm_rreg() and r100_mm_rreg() have a fast path and
a locked (slow) path. This patch deinlines only slow path.
r100_mm_rreg_slow: 78 bytes, 2083 callsites
r100_mm_wreg_slow: 81 bytes, 3570 callsites
Reduction in code size is more than 65,000 bytes:
text data bss dec hex filename
85740176 22294680 20627456 128662312 7ab3b28 vmlinux.before
85674192 22294776 20627456 128598664 7aa4288 vmlinux
Signed-off-by: Denys Vlasenko dvlas...@redhat.com
Cc: Christian König christian.koe...@amd.com
Cc: Alex Deucher alexander.deuc...@amd.com
Cc: linux-kernel@vger.kernel.org
Applied. Thanks!
Alex
---
Changes in v2: only partially deinline r100_mm_r/wreg
Changes in v3: move deinlined functions into files which correspond to
particular hw. Explain why these functions aren't inlined.
drivers/gpu/drm/radeon/cik.c | 25 +
drivers/gpu/drm/radeon/evergreen.c | 69
drivers/gpu/drm/radeon/ni.c| 25 +
drivers/gpu/drm/radeon/r100.c | 22
drivers/gpu/drm/radeon/r300.c | 25 +
drivers/gpu/drm/radeon/r600.c | 47
drivers/gpu/drm/radeon/radeon.h| 225
+
7 files changed, 241 insertions(+), 197 deletions(-)
diff --git a/drivers/gpu/drm/radeon/cik.c b/drivers/gpu/drm/radeon/cik.c
index 3e670d3..7fe99ce 100644
--- a/drivers/gpu/drm/radeon/cik.c
+++ b/drivers/gpu/drm/radeon/cik.c
@@ -141,6 +141,31 @@ static void cik_fini_cg(struct radeon_device *rdev);
static void cik_enable_gui_idle_interrupt(struct radeon_device *rdev,
bool enable);
+/*
+ * Indirect registers accessor
+ */
+u32 cik_didt_rreg(struct radeon_device *rdev, u32 reg)
+{
+ unsigned long flags;
+ u32 r;
+
+ spin_lock_irqsave(rdev-didt_idx_lock, flags);
+ WREG32(CIK_DIDT_IND_INDEX, (reg));
+ r = RREG32(CIK_DIDT_IND_DATA);
+ spin_unlock_irqrestore(rdev-didt_idx_lock, flags);
+ return r;
+}
+
+void cik_didt_wreg(struct radeon_device *rdev, u32 reg, u32 v)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(rdev-didt_idx_lock, flags);
+ WREG32(CIK_DIDT_IND_INDEX, (reg));
+ WREG32(CIK_DIDT_IND_DATA, (v));
+ spin_unlock_irqrestore(rdev-didt_idx_lock, flags);
+}
+
/* get temperature in millidegrees */
int ci_get_temp(struct radeon_device *rdev)
{
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 973df06..1e78c1f 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -35,6 +35,75 @@
#include evergreen_blit_shaders.h
#include radeon_ucode.h
+/*
+ * Indirect registers accessor
+ */
+u32 eg_cg_rreg(struct radeon_device *rdev, u32 reg)
+{
+ unsigned long flags;
+ u32 r;
+
+ spin_lock_irqsave(rdev-cg_idx_lock, flags);
+ WREG32(EVERGREEN_CG_IND_ADDR, ((reg) 0x));
+ r = RREG32(EVERGREEN_CG_IND_DATA);
+ spin_unlock_irqrestore(rdev-cg_idx_lock, flags);
+ return r;
+}
+
+void eg_cg_wreg(struct radeon_device *rdev, u32 reg, u32 v)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(rdev-cg_idx_lock, flags);
+ WREG32(EVERGREEN_CG_IND_ADDR, ((reg) 0x));
+ WREG32(EVERGREEN_CG_IND_DATA, (v));
+ spin_unlock_irqrestore(rdev-cg_idx_lock, flags);
+}
+
+u32 eg_pif_phy0_rreg(struct radeon_device *rdev, u32 reg)
+{
+ unsigned long flags;
+ u32 r;
+
+ spin_lock_irqsave(rdev-pif_idx_lock, flags);
+ WREG32(EVERGREEN_PIF_PHY0_INDEX, ((reg) 0x));
+ r = RREG32(EVERGREEN_PIF_PHY0_DATA
RE: [PATCH] DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcd
-Original Message-
From: Jerome Glisse [mailto:j.gli...@gmail.com]
Sent: Monday, August 24, 2015 9:48 AM
To: cp...@redhat.com
Cc: Deucher, Alexander; Koenig, Christian; David Airlie; dri-
de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Jerome Glisse;
Benjamin Tissoires; sta...@vger.kernel.org
Subject: Re: [PATCH] DRM - radeon: Don't link train DisplayPort on HPD until
we get the dpcd
On Fri, Aug 21, 2015 at 02:16:12PM -0400, cp...@redhat.com wrote:
From: Stephen Chandler Paul cp...@redhat.com
Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:
- GPU has only one monitor connected. It's connected via
DisplayPort, and does not go through an adaptor of any sort.
- User unplugs DisplayPort connector from GPU.
- Change in HPD is detected by the driver, we probe every
DisplayPort for a possible connection.
- Probe the port the user originally had the monitor connected
on for it's dpcd. This fails, and we clear the first (and only
the first) byte of the dpcd to indicate we no longer have a
dpcd for this port.
- User plugs the previously disconnected monitor back into the
same DisplayPort.
- radeon_connector_hotplug() is called before everyone else,
and tries to handle the link training. Since only the first
byte of the dpcd is zeroed, the driver is able to complete
link training but does so against the wrong dpcd, causing it
to initialize the link with the wrong settings.
- Display stays blank (usually), dpcd is probed after the
initial link training, and the driver prints no obvious
messages to the log.
In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: Stephen Chandler Paul cp...@redhat.com
Reviewed-by: Jerome Glisse jgli...@redhat.com
This should be added to stable
cc: sta...@vger.kernel.org
I already added that when I pulled it into my tree :)
Thanks,
Alex
---
drivers/gpu/drm/radeon/radeon_connectors.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 94b21ae..5a2cafb 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -95,6 +95,11 @@ void radeon_connector_hotplug(struct
drm_connector *connector)
if (!radeon_hpd_sense(rdev, radeon_connector-
hpd.hpd)) {
drm_helper_connector_dpms(connector,
DRM_MODE_DPMS_OFF);
} else if
(radeon_dp_needs_link_train(radeon_connector)) {
+ /* Don't try to start link training before we
+* have the dpcd */
+ if (!radeon_dp_getdpcd(radeon_connector))
+ return;
+
/* set it to OFF so that
drm_helper_connector_dpms()
* won't return immediately since the current
state
* is ON at this point.
--
2.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: drm/radeon: take the mode_config mutex when dealing with hpds (v2) crashes
-Original Message-
From: Joerg Platte [mailto:li...@naasa.net]
Sent: Sunday, August 23, 2015 11:26 PM
To: Deucher, Alexander; linux-kernel@vger.kernel.org
Subject: drm/radeon: take the mode_config mutex when dealing with hpds
(v2) crashes
Dear Alex,
on my old P4 based non-SMP router your patch (commit
32d12fc20e3c726ca858d0e5055fb596fce2f8bc in linux stable) crashes on
Linux 4.1.4 and above. I was only able to take a picture of the whole
trace https://ferdi.naasa.net/url/jplatte/IMG_3116.JPG
Reverting the patch resolves the issue.
This is my old graphics hardware:
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc.
[AMD/ATI] RV100 [Radeon 7000 / Radeon VE]
Just for the reference, here is the full patch:
commit 32d12fc20e3c726ca858d0e5055fb596fce2f8bc
Author: Alex Deucher alexander.deuc...@amd.com
Date: Fri May 15 11:48:52 2015 -0400
drm/radeon: take the mode_config mutex when dealing with hpds (v2)
commit 39fa10f7e21574a70cecf1fed0f9b36535aa68a0 upstream.
Since we are messing with state in the worker.
v2: drop the changes in the mst worker
Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 7162c93..f682e53 100644
--- a/drivers/gpu/drm/radeon/radeon_irq_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_irq_kms.c
@@ -79,10 +79,12 @@ static void radeon_hotplug_work_func(struct
work_struct *work)
struct drm_mode_config *mode_config = dev-mode_config;
struct drm_connector *connector;
+ mutex_lock(mode_config-mutex);
if (mode_config-num_connector) {
list_for_each_entry(connector,
mode_config-connector_list, head)
radeon_connector_hotplug(connector);
}
+ mutex_unlock(mode_config-mutex);
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
}
Is it possible that the mutex is not defined on non-SMP systems? Can you
help to resolve this regression?
Fixed in:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=7f98ca454ad373fc1b76be804fa7138ff68c1d27
Alex
Best regards,
Joerg
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z� �w���?��)ߢf��^jǫy�m��@A�a���
0��h���i
RE: [PATCH 38/38] drm/radeon: simplify boot level calculation
> -Original Message-
> From: Andrzej Hajda [mailto:a.ha...@samsung.com]
> Sent: Monday, September 21, 2015 9:34 AM
> To: linux-kernel@vger.kernel.org
> Cc: Andrzej Hajda; Bartlomiej Zolnierkiewicz; Marek Szyprowski; David Airlie;
> Deucher, Alexander; Koenig, Christian; dri-de...@lists.freedesktop.org
> Subject: [PATCH 38/38] drm/radeon: simplify boot level calculation
>
> The patch simplifies the code without changing behaviour, but most
> problably there is a bug somewhere else.
I'd prefer the leave the code as is in case we ever add ACP support to these
asics.
Thanks,
Alex
>
> The problem has been detected using proposed semantic patch
> scripts/coccinelle/tests/unsigned_lesser_than_zero.cocci [1].
>
> [1]: http://permalink.gmane.org/gmane.linux.kernel/2038576
>
> Signed-off-by: Andrzej Hajda <a.ha...@samsung.com>
> ---
> drivers/gpu/drm/amd/amdgpu/kv_dpm.c | 11 +--
> drivers/gpu/drm/radeon/kv_dpm.c | 11 +--
> 2 files changed, 2 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> index 94ec04a..f9cfc56 100644
> --- a/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/kv_dpm.c
> @@ -1622,19 +1622,10 @@ static int kv_update_samu_dpm(struct
> amdgpu_device *adev, bool gate)
>
> static u8 kv_get_acp_boot_level(struct amdgpu_device *adev)
> {
> - u8 i;
> struct amdgpu_clock_voltage_dependency_table *table =
>
> >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
>
> - for (i = 0; i < table->count; i++) {
> - if (table->entries[i].clk >= 0) /* XXX */
> - break;
> - }
> -
> - if (i >= table->count)
> - i = table->count - 1;
> -
> - return i;
> + return table->count ? 0 : -1;
> }
>
> static void kv_update_acp_boot_level(struct amdgpu_device *adev)
> diff --git a/drivers/gpu/drm/radeon/kv_dpm.c
> b/drivers/gpu/drm/radeon/kv_dpm.c
> index 2d71da4..dc9aab5 100644
> --- a/drivers/gpu/drm/radeon/kv_dpm.c
> +++ b/drivers/gpu/drm/radeon/kv_dpm.c
> @@ -1546,19 +1546,10 @@ static int kv_update_samu_dpm(struct
> radeon_device *rdev, bool gate)
>
> static u8 kv_get_acp_boot_level(struct radeon_device *rdev)
> {
> - u8 i;
> struct radeon_clock_voltage_dependency_table *table =
>
> >pm.dpm.dyn_state.acp_clock_voltage_dependency_table;
>
> - for (i = 0; i < table->count; i++) {
> - if (table->entries[i].clk >= 0) /* XXX */
> - break;
> - }
> -
> - if (i >= table->count)
> - i = table->count - 1;
> -
> - return i;
> + return table->count ? 0 : -1;
> }
>
> static void kv_update_acp_boot_level(struct radeon_device *rdev)
> --
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: similar files amd vs radeon
> -Original Message-
> From: Peter Senna Tschudin [mailto:peter.se...@gmail.com]
> Sent: Monday, September 07, 2015 11:09 AM
> To: David Airlie; Deucher, Alexander; Koenig, Christian; Zhou, Jammy; dri-
> de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: similar files amd vs radeon
>
> I executed a clone detection tool* on drivers source code and I found
> that there are similar files between drivers/gpu/drm/amd/ and
> drivers/gpu/drm/radeon, but also inside each of theses folders.
>
> Some examples:
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu
> /dce_v10_0.c
> drivers/gpu/drm/amd/amdgpu/ci_dpm.c,drivers/gpu/drm/radeon/ci_dpm.c
> drivers/gpu/drm/radeon/kv_dpm.c,drivers/gpu/drm/amd/amdgpu/kv_dpm
> .c
>
> I use meld for seeing the differences and similarities. More results
> from the tool at: http://pastebin.com/iX3fhifG (The number on the
> first field is the number of probable cloned lines of code).
>
> Should these files be consolidated? And if so how?
No, they shouldn't be. Amdgpu was forked from radeon to restructure the driver
and support new asics. However, due to the nature of the restructuring and our
past experience with radeon, there's not much more we'd like to consolidate.
We did the initial prototyping and bring up for amdgpu on CI parts (ci and kv)
which are already supported in radeon since we wanted to use an asic that was
already well supported in radeon so we had a good working base to compare
against as we brought up the new driver. The CI support in amdgpu however can
be conditionally compiled out to avoid duplication of support. The dce files
are for specific versions of the display hw block. Each hardware version is
similar, but there are enough version specific differences that I'd rather not
further consolidate the code to avoid bug fixes in one version regressing
features in another version.
Alex
>
> Thank you,
>
> Peter
>
> * https://github.com/petersenna/ccfinderx-core
>
> --
> Peter
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
RE: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon problem?
> -Original Message- > From: Pavel Machek [mailto:pa...@ucw.cz] > Sent: Wednesday, September 02, 2015 6:03 AM > To: Andreas Mohr; maarten.lankho...@canonical.com; Deucher, Alexander > Cc: linux-kernel@vger.kernel.org > Subject: Re: 4.1-rc7: Xorg broken after resume on thinkpad T40p, radeon > problem? > > > On Wed 2015-06-17 21:01:55, Andreas Mohr wrote: > > Hi, > > > > [unable to set In-Reply-To: since lkml.org "headers" view remains > broken...] > > > > > Hibernation works well here, including X. (Which has small glitch with > > > mouse cursor being corrupted until it is changed by application). > > > > I recently also observed the cursor issue, see > > https://bugzilla.kernel.org/show_bug.cgi?id=99421 > > Yes, and its a regression, console switch actually helps. > Pavel This was fixed in: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=f3cbb17bcf676a2fc6aedebe9fbebd59e550c51a Alex > > commit b9729b17a414f99c61f4db9ac9f9ed987fa0cbfe > Author: Maarten Lankhorst <maarten.lankho...@canonical.com> > Date: Tue Jan 13 09:40:13 2015 +0100 > > drm/radeon: dont switch vt on suspend > > Signed-off-by: Maarten Lankhorst <maarten.lankho...@canonical.com> > Acked-by: Alex Deucher <alexander.deuc...@amd.com> > Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> > > > -- > (english) http://www.livejournal.com/~pavelmachek > (cesky, pictures) > http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: radeon -Wmaybe-uninitialized crap
> -Original Message- > From: Borislav Petkov [mailto:b...@alien8.de] > Sent: Monday, December 07, 2015 3:56 AM > To: Deucher, Alexander; Koenig, Christian > Cc: lkml > Subject: radeon -Wmaybe-uninitialized crap > > Hi guys, > > this just started appearing when building -rc4. Got fixes yet? :-) Odd. Nothing related to these variables has changed in years. Alex > > In file included from drivers/gpu/drm/radeon/radeon_mode.h:37:0, > from drivers/gpu/drm/radeon/radeon.h:80, > from drivers/gpu/drm/radeon/r100.c:33: > drivers/gpu/drm/radeon/r100.c: In function ‘r100_bandwidth_update’: > include/drm/drm_fixed.h:64:13: warning: ‘crit_point_ff.full’ may be used > uninitialized in this function [-Wmaybe-uninitialized] > u64 tmp = ((u64)A.full << 13); > ^ > drivers/gpu/drm/radeon/r100.c:3153:63: note: ‘crit_point_ff.full’ was > declared here > fixed20_12 peak_disp_bw, mem_bw, pix_clk, pix_clk2, temp_ff, > crit_point_ff; >^ > drivers/gpu/drm/radeon/r100.c:3583:42: warning: ‘disp_drain_rate.full’ may > be used uninitialized in this function [-Wmaybe-uninitialized] > temp_ff.full = read_return_rate.full - disp_drain_rate.full; > ^ > -- > Regards/Gruss, > Boris. > > ECO tip #101: Trim your mails when you reply.
RE: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt
> -Original Message- > From: Lyude [mailto:cp...@redhat.com] > Sent: Sunday, November 22, 2015 9:45 PM > To: Koenig, Christian; Daniel Stone > Cc: Deucher, Alexander; David Airlie; dri-devel; Linux Kernel Mailing List; > Jerome Glisse; Benjamin Tissoires > Subject: Re: [PATCH] drm/radeon: Retry DDC probing on DVI on failure if we > got an HPD interrupt > > On Sat, 2015-11-21 at 16:22 +0100, Christian König wrote: > > On 21.11.2015 15:49, Daniel Stone wrote: > > > Hi, > > > > > > On 21 November 2015 at 14:22, Christian König <christian.koenig@amd > > > .com> wrote: > > > > On 20.11.2015 16:52, cp...@redhat.com wrote: > > > > > This is somewhat rare on most cards (depending on what angle > > > > > you plug > > > > > the DVI connector in), but on some cards it happens constantly. > > > > > The > > > > > Radeon R5 on the machine used for testing this patch for > > > > > instance, runs > > > > > into this issue just about every time I try to hotplug a DVI > > > > > monitor and > > > > > as a result hotplugging almost never works. > > > > > > > > > > Rescheduling the hotplug work for a second when we run into an > > > > > HPD > > > > > signal with a failing DDC probe usually gives enough time for > > > > > the rest > > > > > of the connector's pins to make contact, and fixes this issue. > > > > > > > > > > Signed-off-by: Stephen Chandler Paul <cp...@redhat.com> > > > > > > > > Yeah, that's something I always wondered a about bit as well. > > > > > > > > Debouncing is something very common done in electronics, but as > > > > far as I > > > > know the HPD pins don't necessary have an RC circuit so we might > > > > need to > > > > handle this case in software here. > > > > > > > > A delay of something between 10-30ms between the last HPD > > > > interrupt and > > > > further processing of the signal doesn't sounds like such a bad > > > > idea. > Unfortunately the delay needed to make hotplugging work on the system > mentioned in the commit log can actually be over 700ms. > > > > > > > > Retrying on the other hand doesn't necessarily improve the > > > > situation cause > > > > the delay introduced by this might not be enough. > Yeah, but I would think it would make sense to retry here so long as we > back off after a certain time. This would also have the benefit of > skipping this delay on systems that don't need it. > > > > > > > > So I would rather vote for a fixed delay between an HPD interrupt > > > > and > > > > actually starting to process anything. > > > Yes-ish. Debouncing is useful, and ignoring buggy devices (e.g. > > > those > > > on marginal power) which send you HPD storms as well. But DP relies > > > on > > > 'short HPD' pulses which can be as brief as 2ms. So attempting to > > > totally debounce all HPD won't work. > > Well the discussion so far was about HPD on DVI only. > > > > I'm not so deep into DP, but why should it uses HPD pulses of less > > than 2ms? > This is part of the DP spec iirc. This being said though, the issue > here with the HPD signal coming before the connector is ready only > happens on DVI. I haven't ever run into this issue with any HDMI cables > or DP cables, so I'm against imposing this on all connectors. > > One of the solutions I've been thinking about with this: In > radeon_dvi_detect(), if we get a real hotplug signal retry the DDC > probe until at least a second has passed, after which we back off and > assume the port is disconnected. FWIW, there are registers to adjust how long the hpd needs to be asserted before the hpd connection and short pulse interrupts are triggered. See DC_HPDx_CONTROL. Maybe adjusting them would help. We currently just write the default value, but it might be better to RMW the value in case there is a special golden value set by the vbios at init time. Alex > > > > Regards, > > Christian. > > > > > > > > Cheers, > > > Daniel > > > -- > Cheers, > Lyude
RE: linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836: wierd condition ?
> -Original Message- > From: David Binderman [mailto:linuxdev.baldr...@gmail.com] > Sent: Monday, June 13, 2016 4:16 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; dri- > de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; > dcb...@hotmail.com > Subject: linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836: > wierd condition ? > > Hello there, > > linux-4.7-rc3/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4836]: (style) > Boolean result is used in bitwise operation. Clarify expression with > parentheses. > > Source code is > > if ((ring->me == me_id) & (ring->pipe == pipe_id)) > > Maybe better code > > if ((ring->me == me_id) && (ring->pipe == pipe_id)) > Good catch. Fixed in the attached patch. > Also in the same file: > > [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:3866]: (style) Variable 'data' > is assigned a value that is never used. The readback of the register here is needed to wake up the block after disabling powergating. > [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4321]: (style) Variable > 'mc_shared_chmap' is assigned a value that is never used. I think this one can be dropped. > [drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:4657]: (style) Variable 'tmp' > is assigned a value that is never used. > This operation requires a posted write (i.e., a read back of the register to make sure the write has completed). Thanks! Alex > Regards > > David Binderman 0001-drm-amdgpu-gfx7-fix-broken-condition-check.patch Description: 0001-drm-amdgpu-gfx7-fix-broken-condition-check.patch
RE: [PATCH] drm/amd: Do not make DRM_AMD_ACP default to y
> -Original Message- > From: Geert Uytterhoeven [mailto:geert+rene...@glider.be] > Sent: Wednesday, February 24, 2016 3:14 AM > To: David Airlie; Deucher, Alexander; Bayyavarapu, Maruthi > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Geert > Uytterhoeven > Subject: [PATCH] drm/amd: Do not make DRM_AMD_ACP default to y > > By default, not only this driver is enabled on all platforms, but also > generic PM Domains and Multi-Function Devices. > > Drop the "default y" to fix this. > I guess I don't really care per se, but why is this an issue? Alex > Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> > --- > drivers/gpu/drm/amd/acp/Kconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/acp/Kconfig > b/drivers/gpu/drm/amd/acp/Kconfig > index 2b07813bceede66d..0f734ee0527434b0 100644 > --- a/drivers/gpu/drm/amd/acp/Kconfig > +++ b/drivers/gpu/drm/amd/acp/Kconfig > @@ -2,7 +2,6 @@ menu "ACP Configuration" > > config DRM_AMD_ACP > bool "Enable ACP IP support" > - default y > select MFD_CORE > select PM_GENERIC_DOMAINS if PM > help > -- > 1.9.1
RE: [4.5-rc regression] drm radeon Tahiti_vce fails to load
> -Original Message- > From: Woody Suwalski [mailto:terraluna...@gmail.com] > Sent: Thursday, February 18, 2016 7:53 AM > To: LKML > Cc: Deucher, Alexander; Koenig, Christian > Subject: [4.5-rc regression] drm radeon Tahiti_vce fails to load > > Alex, the 4.5-rc 32-bit kernels seem to have a problem initializing VCE. > The drm.debug boot option does not show more info as to what the problem > is. > On 4.4 (tested with 4.4.1 and 4.4.2) kernels it is loading OK. > > I have confirmed the regression on 4.5-rc2 and 4.5-rc4 kernels. [1.051686] radeon :01:00.0: Requesting firmware: radeon/TAHITI_vce.bin [1.051856] radeon :01:00.0: Direct firmware load for radeon/TAHITI_vce.bin failed with error -2 [1.051858] radeon :01:00.0: radeon_vce: Can't load firmware "radeon/TAHITI_vce.bin" You did not include the vce firmware image in your kernel image. Please make sure to include the firmware image in your kernel image if you are building it in or if you are using an initrd, please make sure the firmware image is in your initrd. Alex
RE: Linux 4.4.4 [regression]
> -Original Message- > From: 'Greg KH' [mailto:gre...@linuxfoundation.org] > Sent: Wednesday, March 09, 2016 11:28 AM > To: Deucher, Alexander > Cc: Jean Delvare; linux-kernel@vger.kernel.org; Andrew Morton; > torva...@linux-foundation.org; sta...@vger.kernel.org; l...@lwn.net; Jiri > Slaby; Koenig, Christian; Lazare, Jordan > Subject: Re: Linux 4.4.4 [regression] > > On Wed, Mar 09, 2016 at 02:40:48PM +, Deucher, Alexander wrote: > > > -Original Message- > > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > > Sent: Tuesday, March 08, 2016 11:17 PM > > > To: Jean Delvare > > > Cc: linux-kernel@vger.kernel.org; Andrew Morton; torvalds@linux- > > > foundation.org; sta...@vger.kernel.org; l...@lwn.net; Jiri Slaby; Koenig, > > > Christian; Lazare, Jordan; Deucher, Alexander > > > Subject: Re: Linux 4.4.4 [regression] > > > > > > On Tue, Mar 08, 2016 at 09:48:02AM +0100, Jean Delvare wrote: > > > > On Tue, 8 Mar 2016 09:16:13 +0100, Jean Delvare wrote: > > > > > On Thu, 3 Mar 2016 15:34:15 -0800, Greg KH wrote: > > > > > > I'm announcing the release of the 4.4.4 kernel. > > > > > > > > > > > > All users of the 4.4 kernel series must upgrade. > > > > > > (...) > > > > > > Alex Deucher (13): > > > > > > (...) > > > > > > drm/radeon/pm: adjust display configuration after powerstate > > > > > > > > > > I am getting a regression from 4.4.3 to 4.4.4, and biscection points > > > > > to > > > > > the above commit. > > > > > > > > > > http://git.kernel.org/cgit/linux/kernel/git/stable/linux- > > > stable.git/commit/?h=linux- > > > 4.4.y=a83b349814dee660caff0a40a22ac2f166c94a8b > > > > > > > > > > I have reported it in bugzilla: > > > > > https://bugzilla.kernel.org/show_bug.cgi?id=113891 > > > > > > > > > > Symptoms are a vertically jittering display with horizontal black > > > > > stripes, pretty much all the time on almost every boot. > > > > > > > > > > This is with a Sapphire HD 6670 graphics card: > > > > > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, > Inc. > > > [AMD/ATI] Turks XT [Radeon HD 6670/7670] [1002:6758] > > > > > > > > I just tested v4.5-rc7 and it suffers from the same problem. > > > > > > Wonderful, we are bug-compatible then :) > > > > > > Radeon developers, can you all look into this? > > > > Already reverted in my last pull request to Dave. > > Great, hopefully it's tagged with cc: stable@ ... > Yes, of course. Alex
RE: Linux 4.4.4 [regression]
> -Original Message- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Tuesday, March 08, 2016 11:17 PM > To: Jean Delvare > Cc: linux-kernel@vger.kernel.org; Andrew Morton; torvalds@linux- > foundation.org; sta...@vger.kernel.org; l...@lwn.net; Jiri Slaby; Koenig, > Christian; Lazare, Jordan; Deucher, Alexander > Subject: Re: Linux 4.4.4 [regression] > > On Tue, Mar 08, 2016 at 09:48:02AM +0100, Jean Delvare wrote: > > On Tue, 8 Mar 2016 09:16:13 +0100, Jean Delvare wrote: > > > On Thu, 3 Mar 2016 15:34:15 -0800, Greg KH wrote: > > > > I'm announcing the release of the 4.4.4 kernel. > > > > > > > > All users of the 4.4 kernel series must upgrade. > > > > (...) > > > > Alex Deucher (13): > > > > (...) > > > > drm/radeon/pm: adjust display configuration after powerstate > > > > > > I am getting a regression from 4.4.3 to 4.4.4, and biscection points to > > > the above commit. > > > > > > http://git.kernel.org/cgit/linux/kernel/git/stable/linux- > stable.git/commit/?h=linux- > 4.4.y=a83b349814dee660caff0a40a22ac2f166c94a8b > > > > > > I have reported it in bugzilla: > > > https://bugzilla.kernel.org/show_bug.cgi?id=113891 > > > > > > Symptoms are a vertically jittering display with horizontal black > > > stripes, pretty much all the time on almost every boot. > > > > > > This is with a Sapphire HD 6670 graphics card: > > > 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. > [AMD/ATI] Turks XT [Radeon HD 6670/7670] [1002:6758] > > > > I just tested v4.5-rc7 and it suffers from the same problem. > > Wonderful, we are bug-compatible then :) > > Radeon developers, can you all look into this? Already reverted in my last pull request to Dave. Alex
RE: [drm:radeon_dp_link_train] *ERROR* clock recovery failed -bisected
> -Original Message- > From: Ken Moffat [mailto:zarniwh...@ntlworld.com] > Sent: Thursday, March 03, 2016 6:47 PM > To: Deucher, Alexander; StDenis, Tom > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org > Subject: [drm:radeon_dp_link_train] *ERROR* clock recovery failed - > bisected > > On Thu, Mar 03, 2016 at 02:38:11AM +, Ken Moffat wrote: > > One of my machines is an A10 Kaveri desktop, with a good old VGA > > connection to the monitor. I've only just started trying to boot > > any 4.5 kernel on it, but with 4.5.0-rc6 and now linus's tree from a > > few hours ago (4.5.0-rc6-00018-gf983cd3) I get a blank screen, with > > no video signal, as soon as it tries to switch to a framebuffer. > > > > Comparing the logs, the first bad attempt had a couple of new error > > messages, everything else in the logs looked normal - > > > > Mar 1 19:31:10 deluxe kernel: [2.543163] fbcon: radeondrmfb (fb0) is > primary device > > Mar 1 19:31:10 deluxe kernel: [2.654179] [drm:radeon_dp_link_train] > *ERROR* clock recovery reached max voltage > > Mar 1 19:31:10 deluxe kernel: [2.654181] [drm:radeon_dp_link_train] > *ERROR* clock recovery failed > > Mar 1 19:31:10 deluxe kernel: [2.677142] Console: switching to colour > frame buffer device 200x56 > > Mar 1 19:31:10 deluxe kernel: [2.680435] radeon :00:01.0: fb0: > radeondrmfb frame buffer device > > > Bisection pointed to > > 092c96a8ab9d1bd60ada2ed385cc364ce084180e is the first bad commit > commit 092c96a8ab9d1bd60ada2ed385cc364ce084180e > Author: Alex Deucher <alexander.deuc...@amd.com> > Date: Thu Dec 17 10:23:34 2015 -0500 > > drm/radeon: fix dp link rate selection (v2) > > Need to properly handle the max link rate in the dpcd. > This prevents some cases where 5.4 Ghz is selected when > it shouldn't be. > > v2: simplify logic, add array bounds check > > Reviewed-by: Tom St Denis <tom.stde...@amd.com> > Signed-off-by: Alex Deucher <alexander.deuc...@amd.com> > > I have now reverted that commit from that version of linus's tree and > the machine everything is back to normal. > The attached radeon patch should fix it. I accidently dropped the special handling for NUTMEG DP to VGA bridge chips. > This mobo does not have a DP connector. > The VGA port uses a DP to VGA bridge chip. Alex > lspci reports the graphics part is > > 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. > [AMD/ATI] Kaveri [Radeon R7 Graphics] (prog-if 00 [VGA controller]) > Subsystem: Gigabyte Technology Co., Ltd Kaveri [Radeon R7 Graphics] > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- > DisINTx+ > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- R- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 26 > Region 0: Memory at c000 (64-bit, prefetchable) [size=256M] > Region 2: Memory at d000 (64-bit, prefetchable) [size=8M] > Region 4: I/O ports at f000 [size=256] > Region 5: Memory at feb0 (32-bit, non-prefetchable) [size=256K] > Expansion ROM at feb4 [disabled] [size=128K] > Capabilities: [48] Vendor Specific Information: Len=08 > Capabilities: [50] Power Management version 3 > Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0- > ,D1+,D2+,D3hot+,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [58] Express (v2) Root Complex Integrated Endpoint, MSI > 00 > DevCap: MaxPayload 256 bytes, PhantFunc 0 > ExtTag+ RBE+ > DevCtl: Report errors: Correctable- Non-Fatal- Fatal- > Unsupported- > RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ > MaxPayload 128 bytes, MaxReadReq 512 bytes > DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- > TransPend- > DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, > OBFF Not Supported > DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, > OBFF > Disabled > Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ > Address: fee0f00c Data: 4172 > Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 > Len=010 > Capabilities: [270 v1] #19 > Capabilities: [2b0 v1] Address Translation Service (ATS) > ATSCap: Invalidate Queue Depth: 00 >
RE: Linux 4.4.4 [regression]
> -Original Message- > From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of Linus > Torvalds > Sent: Monday, March 07, 2016 11:21 AM > To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list > Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable; l...@lwn.net; > Jiri Slaby; Deucher, Alexander > Subject: Re: Linux 4.4.4 [regression] > > On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz <jvpe...@web.de> > wrote: > > > > This same problem with X does happen in 4.5-rc7. And removing the line > > introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 makes > X go again on > > my laptop. > > Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline. > > Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with > hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No > suspend/resume in sight, just starting X hangs. > > I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on > that hybrid graphics thing), but we need to do something since this is > a regression. > > Just revert for now? Or do you have other suggestions for Jörg-Volker to > test? Can you attach your dmesg output? > > Maybe that call to drm_helper_hpd_irq_event() should be purely in the > real resume path? > > Or maybe there is something that the switcheroo code does that just > interacts badly with the code in drm_helper_hpd_irq_event()? Deadlock > on mode_config.mutex or something? > > I suspect we just need to revert, but if somebody who knows the code > sees some obvious fix, holler quickly, please. Yes, It's probably something related to switcheroo. Does the attached patch help? Alex 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch Description: 0001-drm-radeon-selectively-call-drm_helper_hpd_irq_event.patch
RE: Linux 4.4.4 [regression]
> -Original Message- > From: Jörg-Volker Peetz [mailto:jvpe...@web.de] > Sent: Monday, March 07, 2016 12:40 PM > To: Deucher, Alexander; 'Linus Torvalds'; Dave Airlie; DRI mailing list > Cc: Greg KH; Linux Kernel Mailing List; stable; l...@lwn.net; Andrew Morton; > Jiri Slaby > Subject: Re: Linux 4.4.4 [regression] > > Deucher, Alexander wrote on 03/07/16 17:44: > >> -Original Message- > >> From: linus...@gmail.com [mailto:linus...@gmail.com] On Behalf Of > Linus > >> Torvalds > >> Sent: Monday, March 07, 2016 11:21 AM > >> To: Jörg-Volker Peetz; Dave Airlie; DRI mailing list > >> Cc: Greg KH; Linux Kernel Mailing List; Andrew Morton; stable; > l...@lwn.net; > >> Jiri Slaby; Deucher, Alexander > >> Subject: Re: Linux 4.4.4 [regression] > >> > >> On Mon, Mar 7, 2016 at 6:20 AM, Jörg-Volker Peetz <jvpe...@web.de> > >> wrote: > >>> > >>> This same problem with X does happen in 4.5-rc7. And removing the line > >>> introduced by patch b36e52c44ce6728824546d8b5f05b844cede96f1 > makes > >> X go again on > >>> my laptop. > >> > >> Ok, so that's dbb17a21c131eca94eb31136eee9a7fe5aff00d9 in mainline. > >> > >> Dave, Alex: that commit makes Jörg-Volker's HP Pavilion dv7 with > >> hybrid graphics (AMD HD 4200 - AMD 5400) unable to run X. No > >> suspend/resume in sight, just starting X hangs. > >> > >> I'd guess it's the "radeon_switcheroo_set_state()" craziness (based on > >> that hybrid graphics thing), but we need to do something since this is > >> a regression. > >> > >> Just revert for now? Or do you have other suggestions for Jörg-Volker to > >> test? > > > > Can you attach your dmesg output? > > > I append the dmesg output from 4.5-rc7 (as vacuous as it is) and from my > running > system with 4.4.4 without the problematic code line. > Will try your attached patch next. Thanks. The patch won't make any difference in the case of your system. It looks like you have a muxed system so I suspect what's happening is that one of the display is being reported as connected for both the IGP and the dGPU and then the desktop environment gets confused or there some sort problem in the detect functions since the mux is not switched to the dGPU. I don't see an easy fix unless Dave has any ideas. I'd say just revert for now. Alex
RE: [PATCH] drm/radeon: refactor CIK tiling table initialization
> -Original Message- > From: Josh Poimboeuf [mailto:jpoim...@redhat.com] > Sent: Monday, March 07, 2016 6:10 PM > To: Deucher, Alexander; Koenig, Christian > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; kbuild > test robot; Ingo Molnar > Subject: [PATCH] drm/radeon: refactor CIK tiling table initialization > > When compiling the radeon driver on x86_64 with > CONFIG_STACK_VALIDATION > enabled, objtool gives the following warnings: > > drivers/gpu/drm/radeon/cik.o: warning: objtool: > cik_tiling_mode_table_init()+0x6ce: call without frame pointer save/setup > drivers/gpu/drm/radeon/cik.o: warning: objtool: > cik_tiling_mode_table_init()+0x72b: call without frame pointer save/setup > drivers/gpu/drm/radeon/cik.o: warning: objtool: > cik_tiling_mode_table_init()+0x464: call without frame pointer save/setup > ... > > These are actually false positive warnings; there are no frame pointer > bugs. Instead objtool gets confused by the jump tables created by all > the switch statements, combined with some other gcc optimizations. It > tries to follows all possible code paths, but it fails to realize that > some of the paths aren't possible. For example: > > 4c97: 31 c0 xor%eax,%eax > ... > 4ca2: 89 c1 mov%eax,%ecx > 4ca4: ff 24 cd 00 00 00 00jmpq *0x0(,%rcx,8) 4ca7: > R_X86_64_32S > .rodata+0x148 > > First eax is cleared to zero with the "xor %eax,%eax" instruction. > Later, it moves the value of eax (zero in this case) to ecx, and uses > that value to jump to the first entry in a jump table in .rodata. > > Because objtool doesn't have an x86 emulator, it doesn't know that rcx > is zero. So instead of following a single code path to the first jump > table entry, it follows all possible jump table entry paths in parallel. > > Usually such overactive analysis isn't a problem. In every other jump > table in the kernel, all the jump targets have the same frame pointer > state. But in this exceedingly rare case, different targets have > different frame pointer states. Objtool notices that and creates the > false positive warnings. > > In theory we could use the STACK_FRAME_NON_STANDARD marker to tell > objtool to skip analysis of the function. However, that's less than > ideal. > > Looking at the cik_tiling_mode_table_init() code, it seems overly > complex with lots of repetition. So let's simplify it. All the switch > statements and conditionals can be replaced with much simpler logic by > generalizing the different behaviors and moving the initialization data > into data structures. > > The change is a win-win: it's easier to parse for both humans and > machines. It also reduces the binary size by about 2%: > > textdata bss dec hex filename >101011 30360 0 131371 2012b cik-before.o > 98699 30200 0 128899 1f783 cik-after.o > > [ Note: Unfortunately I don't know how to test this code, so it's > completely untested. Any help or guidance with ensuring that the > correct initialization is still being written would be greatly > appreciated! ] I think it would be clearer to rework it similarly to how it was reworked in amdgpu (see gfx_v8_0.c and gfx_v7_0.c in drm-next). Also ideally you'd update the similar code in si.c as well for consistency. Alex
RE: [PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of array
> -Original Message-
> From: Muhammad Falak R Wani [mailto:falakre...@gmail.com]
> Sent: Friday, May 13, 2016 1:17 PM
> To: Jani Nikula
> Cc: Koenig, Christian; Nils Wallménius; Zhou, Jammy; linux-
> ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; Deucher,
> Alexander; Zhu, Rex; Dan Carpenter
> Subject: Re: [PATCH] drm/amd/powerplay: use ARRAY_SIZE() for size of
> array
>
> On Thu, May 12, 2016 at 12:53:48PM +0300, Jani Nikula wrote:
> > On Wed, 11 May 2016, Muhammad Falak R Wani <falakre...@gmail.com>
> wrote:
> > > Use ARRAY_SIZE() for the size calculation of the array. Also move the
> > > condition evaulation function out of the for loop.
> > > Although, any respectable c-compiler would optimize this and evaluate
> > > the function only once outside the loop, but the optimzation engine
> > > of gcc is bit brain-dead, and at times needs some hand holding.
> >
> > This just caught my eye. ARRAY_SIZE is a macro that expands to a compile
> > time constant. Arguably adding the the local variable here gives GCC
> > more chances to go wrong than keeping the ARRAY_SIZE in the loop
> > condition.
> >
> > BR,
> > Jani.
> >
> > >
> > > Signed-off-by: Muhammad Falak R Wani <falakre...@gmail.com>
> > > ---
> > > drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > index da18f44..718a551 100644
> > > --- a/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > +++ b/drivers/gpu/drm/amd/powerplay/smumgr/cz_smumgr.c
> > > @@ -636,10 +636,11 @@ static int
> cz_smu_populate_firmware_entries(struct pp_smumgr *smumgr)
> > > int ret;
> > > enum cgs_ucode_id ucode_id;
> > > struct cgs_firmware_info info = {0};
> > > + int n = ARRAY_SIZE(firmware_list);
> > >
> > > cz_smu->driver_buffer_length = 0;
> > >
> > > - for (i = 0; i < sizeof(firmware_list)/sizeof(*firmware_list); i++) {
> > > + for (i = 0; i < n; i++) {
> > >
> > > firmware_type =
> cz_translate_firmware_enum_to_arg(smumgr,
> > > firmware_list[i]);
> >
> > --
> > Jani Nikula, Intel Open Source Technology Center
> Should i send a new patch, with these modifications. Sorry for my
> childish mistake, i got a little too carried away.
Yes, please send an updated patch.
Thanks,
Alex
RE: [PATCH] drm/docs: Move "scaling mode" property.
> -Original Message-
> From: robert.f...@collabora.com [mailto:robert.f...@collabora.com]
> Sent: Monday, May 02, 2016 11:41 AM
> To: daniel.vet...@ffwll.ch; cor...@lwn.net; lu...@wunner.de;
> tred...@nvidia.com; Deucher, Alexander; dh.herrm...@gmail.com;
> graham.wha...@linux.intel.com; jani.nik...@intel.com
> Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Robert Foss
> Subject: [PATCH] drm/docs: Move "scaling mode" property.
>
> From: Robert Foss <robert.f...@collabora.com>
>
> The "scaling mode" property has been moved to the DRM->Generic.
> It has also had a list of supported drivers added to it.
>
> Signed-off-by: Robert Foss <robert.f...@collabora.com>
Reviewed-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
> Documentation/DocBook/gpu.tmpl | 22 ++
> 1 file changed, 10 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/DocBook/gpu.tmpl
> b/Documentation/DocBook/gpu.tmpl
> index 1692c4d..da58702 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1817,7 +1817,7 @@ void intel_crt_init(struct drm_device *dev)
>
>
> DRM
> - Generic
> + Generic
> “rotation”
> BITMASK
> { 0, "rotate-0" },
> @@ -1832,6 +1832,13 @@ void intel_crt_init(struct drm_device *dev)
> image along the specified axis prior to rotation
>
>
> + “scaling mode”
> + ENUM
> + { "None", "Full", "Center", "Full aspect" }
> + Connector
> + Supported by: amdgpu, gma500, i915, nouveau
> and radeon.
> +
> +
> Connector
> “EDID”
> BLOB | IMMUTABLE
> @@ -2068,21 +2075,12 @@ void intel_crt_init(struct drm_device *dev)
> property to suggest an Y offset for a
> connector
>
>
> - Optional
> - “scaling mode”
> - ENUM
> - { "None", "Full", "Center", "Full aspect" }
> - Connector
> - TBD
> -
> -
> + Optional
> "aspect ratio"
> ENUM
> { "None", "4:3", "16:9" }
> Connector
> - DRM property to set aspect ratio from user space
> app.
> - This enum is made generic to allow addition of custom aspect
> - ratios.
> + TDB
>
>
> “dirty”
> --
> 2.5.0
RE: [PATCH -next] drm/amdgpu: use kmemdup rather than duplicating its implementation
> -Original Message- > From: Sean Paul [mailto:seanp...@google.com] > Sent: Friday, July 29, 2016 3:35 PM > To: Wei Yongjun > Cc: Deucher, Alexander; Koenig, Christian; Dave Airlie; Jiang, Sonny; Liu, > Leo; > Nath, Arindam; Zhou, David(ChunMing); Zhou, Jammy; Liu, Monk; dri-devel; > Linux Kernel Mailing List > Subject: Re: [PATCH -next] drm/amdgpu: use kmemdup rather than > duplicating its implementation > > On Thu, Jul 28, 2016 at 12:18 PM, Wei Yongjun <weiyj...@gmail.com> wrote: > > Use kmemdup rather than duplicating its implementation. > > > > Generated by: scripts/coccinelle/api/memdup.cocci > > > > Signed-off-by: Wei Yongjun <weiyj...@gmail.com> > > > Thanks for the patch. I'll apply this to -misc once the merge window is > closed. > > Acked-by: Sean Paul <seanp...@chromium.org> Unless you've already applied this to the misc tree, I'd prefer to take it via the amdgpu tree. Alex > > > > --- > > drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +--- > > 1 file changed, 1 insertion(+), 3 deletions(-) > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > index a46a64c..b779b5f 100644 > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c > > @@ -296,12 +296,10 @@ int amdgpu_uvd_suspend(struct amdgpu_device > *adev) > > size = amdgpu_bo_size(adev->uvd.vcpu_bo); > > ptr = adev->uvd.cpu_addr; > > > > - adev->uvd.saved_bo = kmalloc(size, GFP_KERNEL); > > + adev->uvd.saved_bo = kmemdup(ptr, size, GFP_KERNEL); > > if (!adev->uvd.saved_bo) > > return -ENOMEM; > > > > - memcpy(adev->uvd.saved_bo, ptr, size); > > - > > return 0; > > } > > > > > > > >
RE: [PATCH 0179/1285] Replace numeric parameter like 0444 with macro
> -Original Message- > From: Baole Ni [mailto:baolex...@intel.com] > Sent: Tuesday, August 02, 2016 6:47 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; > tony.l...@intel.com; m...@codeblueprint.co.uk; m.che...@samsung.com; > l...@apm.com; dougthomp...@xmission.com; b...@alien8.de > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; Zhou, > Jammy; Zhou, David(ChunMing); Cui, Flora; chuansheng@intel.com; > baolex...@intel.com > Subject: [PATCH 0179/1285] Replace numeric parameter like 0444 with macro > > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access > permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and that using macro can improve the robustness and readability of the code, > thus, I suggest replacing the numeric parameter with the macro. > > Signed-off-by: Chuansheng Liu <chuansheng@intel.com> > Signed-off-by: Baole Ni <baolex...@intel.com> > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 54 > - > 1 file changed, 27 insertions(+), 27 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index f888c01..f0c9c29 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -86,87 +86,87 @@ unsigned amdgpu_pcie_gen_cap = 0; > unsigned amdgpu_pcie_lane_cap = 0; > > MODULE_PARM_DESC(vramlimit, "Restrict VRAM for testing, in > megabytes"); > -module_param_named(vramlimit, amdgpu_vram_limit, int, 0600); > +module_param_named(vramlimit, amdgpu_vram_limit, int, S_IRUSR | > S_IWUSR); > FWIW, I find it much easier to read and understand the numeric representation. Alex > MODULE_PARM_DESC(gartsize, "Size of PCIE/IGP gart to setup in > megabytes (32, 64, etc., -1 = auto)"); > -module_param_named(gartsize, amdgpu_gart_size, int, 0600); > +module_param_named(gartsize, amdgpu_gart_size, int, S_IRUSR | > S_IWUSR); > > MODULE_PARM_DESC(benchmark, "Run benchmark"); > -module_param_named(benchmark, amdgpu_benchmarking, int, 0444); > +module_param_named(benchmark, amdgpu_benchmarking, int, S_IRUSR > | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(test, "Run tests"); > -module_param_named(test, amdgpu_testing, int, 0444); > +module_param_named(test, amdgpu_testing, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(audio, "Audio enable (-1 = auto, 0 = disable, 1 = > enable)"); > -module_param_named(audio, amdgpu_audio, int, 0444); > +module_param_named(audio, amdgpu_audio, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(disp_priority, "Display Priority (0 = auto, 1 = normal, 2 > = high)"); > -module_param_named(disp_priority, amdgpu_disp_priority, int, 0444); > +module_param_named(disp_priority, amdgpu_disp_priority, int, S_IRUSR | > S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(hw_i2c, "hw i2c engine enable (0 = disable)"); > -module_param_named(hw_i2c, amdgpu_hw_i2c, int, 0444); > +module_param_named(hw_i2c, amdgpu_hw_i2c, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(pcie_gen2, "PCIE Gen2 mode (-1 = auto, 0 = disable, > 1 = enable)"); > -module_param_named(pcie_gen2, amdgpu_pcie_gen2, int, 0444); > +module_param_named(pcie_gen2, amdgpu_pcie_gen2, int, S_IRUSR | > S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(msi, "MSI support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(msi, amdgpu_msi, int, 0444); > +module_param_named(msi, amdgpu_msi, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(lockup_timeout, "GPU lockup timeout in ms (default > 0 = disable)"); > -module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, > 0444); > +module_param_named(lockup_timeout, amdgpu_lockup_timeout, int, > S_IRUSR | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(dpm, "DPM support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(dpm, amdgpu_dpm, int, 0444); > +module_param_named(dpm, amdgpu_dpm, int, S_IRUSR | S_IRGRP | > S_IROTH); > > MODULE_PARM_DESC(smc_load_fw, "SMC firmware loading(1 = enable, 0 = > disable)"); > -module_param_named(smc_load_fw, amdgpu_smc_load_fw, int, 0444); > +module_param_named(smc_load_fw, amdgpu_smc_load_fw, int, S_IRUSR > | S_IRGRP | S_IROTH); > > MODULE_PARM_DESC(aspm, "ASPM support (1 = enable, 0 = disable, -1 = > auto)"); > -module_param_named(aspm, amdgpu_aspm, int, 0444); > +module_param_named(aspm, amdgpu_aspm, int, S_IRUSR | S_I
RE: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk more generic
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Bjorn Helgaas
> Sent: Monday, January 30, 2017 3:41 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: linux...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; amd-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; Maarten Lankhorst
> Subject: [PATCH v1 2/2] drm/radeon: make MacBook Pro d3_delay quirk
> more generic
>
> The PCI Power Management Spec, r1.2, sec 5.6.1, requires a 10 millisecond
> delay when powering on a device, i.e., transitioning from state D3hot to
> D0.
>
> Apparently some devices require more time, and d1f9809ed131
> ("drm/radeon:
> add quirk for d3 delay during switcheroo poweron for apple macbooks")
> added
> an additional delay for the Radeon device in a MacBook Pro. 4807c5a8a0c8
> ("drm/radeon: add a PX quirk list") made the affected device more explicit.
>
> Add a generic PCI quirk to increase the d3_delay. This means we will use
> the additional delay for *all* wakeups from D3, not just those initiated by
> radeon_switcheroo_set_state().
>
> Signed-off-by: Bjorn Helgaas <bhelg...@google.com>
> CC: Maarten Lankhorst <maarten.lankho...@canonical.com>
For the series:
Acked-by: Alex Deucher <alexander.deuc...@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_device.c | 12
> drivers/pci/quirks.c | 13 +
> 2 files changed, 13 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_device.c
> b/drivers/gpu/drm/radeon/radeon_device.c
> index 8a1df2a1afbd..8b8fd981cae5 100644
> --- a/drivers/gpu/drm/radeon/radeon_device.c
> +++ b/drivers/gpu/drm/radeon/radeon_device.c
> @@ -113,7 +113,6 @@ static inline bool radeon_is_atpx_hybrid(void) {
> return false; }
> #endif
>
> #define RADEON_PX_QUIRK_DISABLE_PX (1 << 0)
> -#define RADEON_PX_QUIRK_LONG_WAKEUP (1 << 1)
>
> struct radeon_px_quirk {
> u32 chip_vendor;
> @@ -136,9 +135,6 @@ static struct radeon_px_quirk radeon_px_quirk_list[]
> = {
>* https://bugzilla.kernel.org/show_bug.cgi?id=51381
>*/
> { PCI_VENDOR_ID_ATI, 0x6840, 0x1043, 0x2122,
> RADEON_PX_QUIRK_DISABLE_PX },
> - /* macbook pro 8.2 */
> - { PCI_VENDOR_ID_ATI, 0x6741, PCI_VENDOR_ID_APPLE, 0x00e2,
> RADEON_PX_QUIRK_LONG_WAKEUP },
> - { 0, 0, 0, 0, 0 },
> };
>
> bool radeon_is_px(struct drm_device *dev)
> @@ -1241,25 +1237,17 @@ static void radeon_check_arguments(struct
> radeon_device *rdev)
> static void radeon_switcheroo_set_state(struct pci_dev *pdev, enum
> vga_switcheroo_state state)
> {
> struct drm_device *dev = pci_get_drvdata(pdev);
> - struct radeon_device *rdev = dev->dev_private;
>
> if (radeon_is_px(dev) && state == VGA_SWITCHEROO_OFF)
> return;
>
> if (state == VGA_SWITCHEROO_ON) {
> - unsigned d3_delay = dev->pdev->d3_delay;
> -
> printk(KERN_INFO "radeon: switched on\n");
> /* don't suspend or resume card normally */
> dev->switch_power_state =
> DRM_SWITCH_POWER_CHANGING;
>
> - if (d3_delay < 20 && (rdev->px_quirk_flags &
> RADEON_PX_QUIRK_LONG_WAKEUP))
> - dev->pdev->d3_delay = 20;
> -
> radeon_resume_kms(dev, true, true);
>
> - dev->pdev->d3_delay = d3_delay;
> -
> dev->switch_power_state = DRM_SWITCH_POWER_ON;
> drm_kms_helper_poll_enable(dev);
> } else {
> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
> index 1800befa8b8b..512d7a875d62 100644
> --- a/drivers/pci/quirks.c
> +++ b/drivers/pci/quirks.c
> @@ -1683,6 +1683,19 @@
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x2609,
> quirk_intel_pcie_pm);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260a,
> quirk_intel_pcie_pm);
> DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_INTEL, 0x260b,
> quirk_intel_pcie_pm);
>
> +static void quirk_radeon_pm(struct pci_dev *dev)
> +{
> + if (dev->subsystem_vendor == PCI_VENDOR_ID_APPLE &&
> + dev->subsystem_device == 0x00e2) {
> + if (dev->d3_delay < 20) {
> + dev->d3_delay = 20;
> + dev_info(>dev, "extending delay after power-
> on from D3 to %d msec\n",
> + dev->d3_delay);
> + }
> + }
> +}
> +DECLARE_PCI_FIXUP_FINAL(PCI_VENDOR_ID_ATI, 0x6741,
> quirk_radeon_pm);
> +
> #ifdef CONFIG_X86_IO_APIC
> /*
> * Boot interrupts on some chipsets cannot be turned off. For these
> chipsets,
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
RE: [PATCH] drm: squash lines for simple wrapper functions
> -Original Message-
> From: Masahiro Yamada [mailto:yamada.masah...@socionext.com]
> Sent: Tuesday, September 06, 2016 7:04 PM
> To: David Airlie; dri-de...@lists.freedesktop.org
> Cc: Masahiro Yamada; Gustavo Padovan; Yakir Yang; Huang, Ray; Deucher,
> Alexander; Liu, Monk; Zhou, David(ChunMing); Daniel Vetter; Heiko
> Stuebner; Huang, JinHuiEric; Cui, Flora; Inki Dae; Krzysztof Kozlowski; Dave
> Airlie; Jani Nikula; intel-...@lists.freedesktop.org; Frediano Ziglio; Li,
> Samuel;
> Koenig, Christian; Tomasz Figa; Sumit Semwal; linux-kernel@vger.kernel.org;
> StDenis, Tom; Dan Carpenter
> Subject: [PATCH] drm: squash lines for simple wrapper functions
>
> Remove unneeded variables and assignments.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
Please split these up per driver.
Alex
> ---
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 6 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c| 6 +-
> drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c| 6 +-
> drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c | 20
> drivers/gpu/drm/drm_dp_mst_topology.c | 7 ++-
> drivers/gpu/drm/i915/i915_drv.c | 8 +---
> drivers/gpu/drm/qxl/qxl_draw.c| 7 ++-
> drivers/gpu/drm/qxl/qxl_release.c | 7 ++-
> drivers/gpu/drm/radeon/cik.c | 6 +-
> drivers/gpu/drm/radeon/r100.c | 6 +-
> drivers/gpu/drm/radeon/r600.c | 6 +-
> 11 files changed, 17 insertions(+), 68 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index b818461..0d5307a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5854,11 +5854,7 @@ static int gfx_v8_0_set_clockgating_state(void
> *handle,
>
> static u32 gfx_v8_0_ring_get_rptr_gfx(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> - rptr = ring->adev->wb.wb[ring->rptr_offs];
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs];
> }
>
> static u32 gfx_v8_0_ring_get_wptr_gfx(struct amdgpu_ring *ring)
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> index a64715d..b165c78 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v2_4.c
> @@ -190,12 +190,8 @@ out:
> */
> static uint32_t sdma_v2_4_ring_get_rptr(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> /* XXX check if swapping is necessary on BE */
> - rptr = ring->adev->wb.wb[ring->rptr_offs] >> 2;
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs] >> 2;
> }
>
> /**
> diff --git a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> index 653ce5e..cf253b9 100644
> --- a/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c
> @@ -335,12 +335,8 @@ out:
> */
> static uint32_t sdma_v3_0_ring_get_rptr(struct amdgpu_ring *ring)
> {
> - u32 rptr;
> -
> /* XXX check if swapping is necessary on BE */
> - rptr = ring->adev->wb.wb[ring->rptr_offs] >> 2;
> -
> - return rptr;
> + return ring->adev->wb.wb[ring->rptr_offs] >> 2;
> }
>
> /**
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> index 48030f0..d37d112 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
> @@ -1073,34 +1073,22 @@ void analogix_dp_set_lane3_link_training(struct
> analogix_dp_device *dp,
>
> u32 analogix_dp_get_lane0_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_DP_LN0_LINK_TRAINING_CTL);
> }
>
> u32 analogix_dp_get_lane1_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_DP_LN1_LINK_TRAINING_CTL);
> }
>
> u32 analogix_dp_get_lane2_link_training(struct analogix_dp_device *dp)
> {
> - u32 reg;
> -
> - reg = readl(dp->reg_base +
> ANALOGIX_DP_LN2_LINK_TRAINING_CTL);
> - return reg;
> + return readl(dp->reg_base +
> ANALOGIX_
RE: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference workaround
> -Original Message- > From: Koenig, Christian > Sent: Friday, September 09, 2016 4:16 AM > To: Mark Fortescue; Koenig, Christian; David Airlie > Cc: Deucher, Alexander; linux-kernel@vger.kernel.org; dri- > de...@lists.freedesktop.org > Subject: Re: [PATCH 001/001] drivers/gpu/radeon: NULL pointer deference > workaround > > >> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel > >> interface and DP-2 is a DVI interface (which I can connect to my > >> monitor if testing this is useful). There are no displayport connectors. > > > > Yeah, but from the driver point of view there are only DP connectors on > > the chip. The LVDS and DVI are probably realized with external DP to > > whatever converter ICs. > > > > > > That would explain why some similar boards have 24bit LVDS and others > > only 18bit LVDS. > > It could be that this is actually a configuration we don't support yet > with radeon and/or the display stack. > > E.g. that the connector only uses the displayport LVDS lanes, but not > actual the displayport protocol to train those lanes. > > Instead it rather expects a fixed training which is configured somewhere > in the BIOS. > > Anyway Alex needs to take a look, he knows displayport much better than > I do (and hates it passionately :). Generally these sorts of setups are supported by exposing an LVDS or eDP connector rather than a regular DP. In the case of LVDS and eDP, we have code to fallback to a hardcoded EDID in the vbios if DDC is not available. I'll take a closer look when I'm back. Alex > > Cheers, > Christian. > > Am 08.09.2016 um 13:18 schrieb Mark Fortescue: > > On 08/09/16 11:25, Christian König wrote: > >> Am 08.09.2016 um 11:09 schrieb Mark Fortescue: > >>> Hi Christian, > >>> > >>> Thank you for the feedback. > >>> > >>> On 08/09/16 08:14, Christian König wrote: > >>>> Am 07.09.2016 um 19:38 schrieb Mark Fortescue: > >>>>> > >>>>> On an LV-683 (AMD Dual-core G-T56N) Mini-ITX board, I get a Kernel > >>>>> Oops because Connector 0 (LCD Panel interface) does not have DDC. > >>>> > >>>> I'm not an expert on this, but that is really odd cause even LCD > >>>> Panels > >>>> should have a DDC interface. > >>>> > >>>>> > >>>>> Ubuntu 16.04 LTS Kernel (4.4 series): > >>>>> > >>>>> ... > >>>>> [ 8.262990] [drm] ib test on ring 5 succeeded > >>>>> [ 8.288897] [drm] Radeon Display Connectors > >>>>> [ 8.293175] [drm] Connector 0: > >>>>> [ 8.296252] [drm] DP-1 > >>>> > >>>> Especially since the BIOS claims that this is a displayport connector > >>>> and there is no physical way to have a DP without an DDC as far as I > >>>> know. > >>>> > >>>> Please open a bug report on FDO and attach you BIOS image. > >>> > >>> FDO ? I am not familiar with this. Please can you enlighten me. > >>> > >> > >> See here: http://bugs.freedesktop.org/ > >> > >>> I do not have a BIOS image so will need some assistance in > >>> understanding what is required here and how I extract the BIOS > >>> information you are after. > >>> > >> > >> Sorry my fault. Mullins is an APU, so you don't have a dedicated video > >> BIOS. As usually I didn't got enough sleep :) But please open up a bug > >> report anyway. > > > > Know the problem of being awake too long :). I will raise a bug. > > > >> > >>> On this motherboard, DP-1 is a single channel 18bit LVDS LCD panel > >>> interface and DP-2 is a DVI interface (which I can connect to my > >>> monitor if testing this is useful). There are no displayport > >>> connectors. > >> > >> Yeah, but from the driver point of view there are only DP connectors on > >> the chip. The LVDS and DVI are probably realized with external DP to > >> whatever converter ICs. > >> > > > > That would explain why some similar boards have 24bit LVDS and others > > only 18bit LVDS. > > > >>> > >>> On industrial motherboards, I have noticed that it is not uncommon to > >>> hard code the information for the LCD panel into the BIOS so no DDC is > >>> required. In this case, there is no LCD panel connected to the > >>> interface a
RE: [PATCH] drm/amd/amdgpu: default to zero number of states if not enabled
> -Original Message- > From: Colin Ian King [mailto:colin.k...@canonical.com] > Sent: Thursday, October 06, 2016 3:04 PM > To: Alex Deucher > Cc: Deucher, Alexander; Koenig, Christian; David Airlie; Huang, JinHuiEric; > Zhu, Rex; Zhou, Jammy; StDenis, Tom; Dan Carpenter; Maling list - DRI > developers; LKML > Subject: Re: [PATCH] drm/amd/amdgpu: default to zero number of states if > not enabled > > On 06/10/16 19:32, Alex Deucher wrote: > > On Thu, Oct 6, 2016 at 2:02 PM, Colin King <colin.k...@canonical.com> > wrote: > >> From: Colin Ian King <colin.k...@canonical.com> > >> > >> Currently, if adev->pp_enabled is false then the pp_stats_info data > >> is not read and hence a garbage number of states from the stack > >> is used to dump out the number of states. Given data.nums could be > >> any random value, this could easily lead to read outside the > >> data.states array. Fix this by setting data.nums to zero if > >> adev->pp_enabled is false. > > > > Are you actually seeing a problem? > > Nope. > > > The pp_num_states attribute only > > gets added in the first place if pp_enabled is true. > > Does that mean that the check on adev->pp_enabled is redundant then? Yes, I think so. Alex > > > > > Alex > > > > >> > >> Signed-off-by: Colin Ian King <colin.k...@canonical.com> > >> --- > >> drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c | 2 ++ > >> 1 file changed, 2 insertions(+) > >> > >> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> index accc908..808d788 100644 > >> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c > >> @@ -195,6 +195,8 @@ static ssize_t amdgpu_get_pp_num_states(struct > device *dev, > >> > >> if (adev->pp_enabled) > >> amdgpu_dpm_get_pp_num_states(adev, ); > >> + else > >> + data.nums = 0; > >> > >> buf_len = snprintf(buf, PAGE_SIZE, "states: %d\n", data.nums); > >> for (i = 0; i < data.nums; i++) > >> -- > >> 2.9.3 > >> > >> ___ > >> dri-devel mailing list > >> dri-de...@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH 4/5] drm/amdgpu: Rename a jump label in amdgpu_device_init()
> -Original Message-
> From: SF Markus Elfring [mailto:elfr...@users.sourceforge.net]
> Sent: Sunday, September 18, 2016 12:53 PM
> To: dri-de...@lists.freedesktop.org; Deucher, Alexander; Koenig, Christian;
> Zhou, David(ChunMing); David Airlie; Liu, Monk; StDenis, Tom
> Cc: LKML; kernel-janit...@vger.kernel.org; Julia Lawall
> Subject: [PATCH 4/5] drm/amdgpu: Rename a jump label in
> amdgpu_device_init()
>
> From: Markus Elfring <elfr...@users.sourceforge.net>
> Date: Sun, 18 Sep 2016 17:50:09 +0200
>
> Adjust jump labels according to the current Linux coding style convention.
>
> Signed-off-by: Markus Elfring <elfr...@users.sourceforge.net>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 21 ++--
> -
> 1 file changed, 10 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> index 2b8ba97..fed4854 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
> @@ -1566,18 +1566,18 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> /* Read BIOS */
> if (!amdgpu_get_bios(adev)) {
> r = -EINVAL;
> - goto failed;
> + goto check_runtime;
NACK. Failed is a more appropriate label here. The runtime check is just part
of the failure cleanup.
Alex
> }
> /* Must be an ATOMBIOS */
> if (!adev->is_atom_bios) {
> dev_err(adev->dev, "Expecting atombios for GPU\n");
> r = -EINVAL;
> - goto failed;
> + goto check_runtime;
> }
> r = amdgpu_atombios_init(adev);
> if (r) {
> dev_err(adev->dev, "amdgpu_atombios_init failed\n");
> - goto failed;
> + goto check_runtime;
> }
>
> /* See if the asic supports SR-IOV */
> @@ -1595,7 +1595,7 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> if (!adev->bios) {
> dev_err(adev->dev, "Card not posted and no BIOS -
> ignoring\n");
> r = -EINVAL;
> - goto failed;
> + goto check_runtime;
> }
> DRM_INFO("GPU not posted. posting now...\n");
> amdgpu_atom_asic_init(adev->mode_info.atom_context);
> @@ -1605,7 +1605,7 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> r = amdgpu_atombios_get_clock_info(adev);
> if (r) {
> dev_err(adev->dev, "amdgpu_atombios_get_clock_info
> failed\n");
> - goto failed;
> + goto check_runtime;
> }
> /* init i2c buses */
> amdgpu_atombios_i2c_init(adev);
> @@ -1614,7 +1614,7 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> r = amdgpu_fence_driver_init(adev);
> if (r) {
> dev_err(adev->dev, "amdgpu_fence_driver_init failed\n");
> - goto failed;
> + goto check_runtime;
> }
>
> /* init the mode config */
> @@ -1624,7 +1624,7 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> if (r) {
> dev_err(adev->dev, "amdgpu_init failed\n");
> amdgpu_fini(adev);
> - goto failed;
> + goto check_runtime;
> }
>
> adev->accel_working = true;
> @@ -1634,7 +1634,7 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> r = amdgpu_ib_pool_init(adev);
> if (r) {
> dev_err(adev->dev, "IB initialization failed (%d).\n", r);
> - goto failed;
> + goto check_runtime;
> }
>
> r = amdgpu_ib_ring_tests(adev);
> @@ -1682,12 +1682,11 @@ int amdgpu_device_init(struct amdgpu_device
> *adev,
> r = amdgpu_late_init(adev);
> if (r) {
> dev_err(adev->dev, "amdgpu_late_init failed\n");
> - goto failed;
> + goto check_runtime;
> }
>
> return 0;
> -
> -failed:
> + check_runtime:
> if (runtime)
> vga_switcheroo_fini_domain_pm_ops(adev->dev);
> return r;
> --
> 2.10.0
RE: [PATCH] drm/amdgpu: add function declaration in amdgpu.h
> -Original Message- > From: Baoyou Xie [mailto:baoyou@linaro.org] > Sent: Sunday, September 18, 2016 10:29 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie; Zhou, > David(ChunMing); Liu, Monk; Zhu, Rex; Huang, JinHuiEric; Cui, Flora > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; > a...@arndb.de; baoyou@linaro.org; xie.bao...@zte.com.cn > Subject: [PATCH] drm/amdgpu: add function declaration in amdgpu.h > > We get 2 warnings when building kernel with W=1: > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:502:10: warning: no previous > prototype for 'init_cond_exec' [-Wmissing-prototypes] > drivers/gpu/drm/amd/amdgpu/sdma_v3_0.c:514:6: warning: no previous > prototype for 'patch_cond_exec' [-Wmissing-prototypes] > > In fact, both functions are not declared in any files. > > So this patch declares them in drivers/gpu/drm/amd/amdgpu/amdgpu.h. > > Signed-off-by: Baoyou Xie <baoyou@linaro.org> These functions were unused so they were already dropped. Alex > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 8e3d9b2..7b71cbe 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -396,6 +396,8 @@ int amdgpu_fence_emit(struct amdgpu_ring *ring, > struct fence **fence); > void amdgpu_fence_process(struct amdgpu_ring *ring); > int amdgpu_fence_wait_empty(struct amdgpu_ring *ring); > unsigned amdgpu_fence_count_emitted(struct amdgpu_ring *ring); > +unsigned int init_cond_exec(struct amdgpu_ring *ring); > +void patch_cond_exec(struct amdgpu_ring *ring, unsigned int offset); > > /* > * BO. > -- > 2.7.4
RE: [PATCH linux-firmware 10/12] WHENCE: List new radeon CI and SI smc firmware
> -Original Message- > From: Ben Hutchings [mailto:b...@decadent.org.uk] > Sent: Saturday, September 17, 2016 10:08 PM > To: linux-kernel@vger.kernel.org; linux-firmw...@kernel.org > Cc: Deucher, Alexander > Subject: Re: [PATCH linux-firmware 10/12] WHENCE: List new radeon CI and > SI smc firmware > > On Sun, Sep 18, 2016 at 03:03:43AM +0100, Ben Hutchings wrote: > [...] > > @@ -2957,6 +2964,7 @@ File: qat_c3xxx.bin > > File: qat_c3xxx_mmp.bin > > File: qat_c62x.bin > > File: qat_c62x_mmp.bin > > +Link: qat_mmp.bin -> qat_895xcc_mmp.bin > > > > Licence: Redistributable. See LICENCE.qat_firmware for details > > > > > > Oops, I'll move that last bit to a separate commit. With that fixed: Acked-by: Alex Deucher <alexander.deuc...@amd.com> > > Ben. > > -- > Ben Hutchings > For every action, there is an equal and opposite criticism. - Harrison
RE: linux-next: Tree for Sep 28 (drivers/gpu/drm/amd/amdgpu/amdgpu.ko)
> -Original Message- > From: Randy Dunlap [mailto:rdun...@infradead.org] > Sent: Wednesday, September 28, 2016 1:10 PM > To: Stephen Rothwell; linux-n...@vger.kernel.org > Cc: linux-kernel@vger.kernel.org; dri-devel; Deucher, Alexander; Koenig, > Christian > Subject: Re: linux-next: Tree for Sep 28 > (drivers/gpu/drm/amd/amdgpu/amdgpu.ko) > > On 09/27/16 23:56, Stephen Rothwell wrote: > > Hi all, > > > > Changes since 20160927: > > > > on i386: > > ERROR: "amd_set_clockgating_by_smu" > [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined! > DRM_AMD_POWERPLAY needs to be set. Fixed in the attached patch. Alex > > Full randconfig file is attached. > > -- > ~Randy 0001-drm-amdgpu-remove-DRM_AMD_POWERPLAY.patch Description: 0001-drm-amdgpu-remove-DRM_AMD_POWERPLAY.patch
RE: [PATCH] drm/amdgpu: enable powerplay unconditionally
> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Friday, September 30, 2016 12:21 PM
> To: Deucher, Alexander; Koenig, Christian
> Cc: Arnd Bergmann; David Airlie; Zhou, Jammy; Zhu, Rex; dri-
> de...@lists.freedesktop.org; linux-kernel@vger.kernel.org
> Subject: [PATCH] drm/amdgpu: enable powerplay unconditionally
>
> Using the newly exported amd_set_clockgating_by_smu function in the
> main amdgpu driver
> means that we can no longer build the driver without also enabling the
> powerplay
> component, otherwise we get this link error:
>
> ERROR: "amd_set_clockgating_by_smu"
> [drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
>
> The easiest way to avoid this error is to always enable the Kconfig symbol
> when
> the amdgpu driver is enabled.
>
> Fixes: a8ca34136453 ("drm/amdgpu: set gfx clock gating for tonga/polaris.")
> Fixes: 1bb08f91b0f6 ("drm/amdgpu: set system clock gating for
> tonga/polaris.")
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> ---
> It's quite likely that there is a better way to do this, as the separation
> of the drivers is intentional. If my patch isn't acceptable, please come
> up with a different solution.
I've already removed the kconfig symbol altogether:
https://lists.freedesktop.org/archives/dri-devel/2016-September/119647.html
Alex
> ---
> drivers/gpu/drm/amd/powerplay/Kconfig | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/Kconfig
> b/drivers/gpu/drm/amd/powerplay/Kconfig
> index af380335b425..6d4f155a0453 100644
> --- a/drivers/gpu/drm/amd/powerplay/Kconfig
> +++ b/drivers/gpu/drm/amd/powerplay/Kconfig
> @@ -1,6 +1,4 @@
> config DRM_AMD_POWERPLAY
> - bool "Enable AMD powerplay component"
> - depends on DRM_AMDGPU
> - default n
> + def_bool DRM_AMDGPU
> help
> select this option will enable AMD powerplay component.
> --
> 2.9.0
RE: [PATCH 2/3] drm/radeon: clean function declarations up
> -Original Message- > From: Baoyou Xie [mailto:baoyou@linaro.org] > Sent: Friday, September 30, 2016 4:15 AM > To: Deucher, Alexander; Koenig, Christian; airl...@linux.ie > Cc: dri-de...@lists.freedesktop.org; linux-kernel@vger.kernel.org; > a...@arndb.de; baoyou@linaro.org; xie.bao...@zte.com.cn; > han@zte.com.cn; tang.qiang...@zte.com.cn > Subject: [PATCH 2/3] drm/radeon: clean function declarations up > > We get a few warnings when building kernel with W=1: > drivers/gpu/drm/radeon/radeon_device.c:642:6: warning: no previous > prototype for 'radeon_device_is_virtual' [-Wmissing-prototypes] > drivers/gpu/drm/radeon/radeon_kms.c:56:5: warning: no previous > prototype for 'radeon_driver_unload_kms' [-Wmissing-prototypes] > drivers/gpu/drm/radeon/radeon_kms.c:97:5: warning: no previous > prototype for 'radeon_driver_load_kms' [-Wmissing-prototypes] > drivers/gpu/drm/radeon/radeon_kms.c:612:6: warning: no previous > prototype for 'radeon_driver_lastclose_kms' [-Wmissing-prototypes] > > > In fact, these functions are declared in some source files, > but should be declared in a header file, > thus can be recognized in other file. > > So this patch declares them in drivers/gpu/drm/radeon/radeon.h. NACK. This just shoves a ton of unrelated declarations into radeon.h. I would prefer to refactor these in some sort of more organized way. Alex > > Signed-off-by: Baoyou Xie <baoyou@linaro.org> > --- > drivers/gpu/drm/radeon/atombios_encoders.c | 4 - > drivers/gpu/drm/radeon/btc_dpm.c | 4 - > drivers/gpu/drm/radeon/ci_dpm.c| 10 -- > drivers/gpu/drm/radeon/cik.c | 14 -- > drivers/gpu/drm/radeon/cik_sdma.c | 2 - > drivers/gpu/drm/radeon/cypress_dpm.c | 4 - > drivers/gpu/drm/radeon/evergreen.c | 11 -- > drivers/gpu/drm/radeon/evergreen_cs.c | 2 - > drivers/gpu/drm/radeon/evergreen_dma.c | 2 - > drivers/gpu/drm/radeon/kv_dpm.c| 5 - > drivers/gpu/drm/radeon/ni.c| 11 -- > drivers/gpu/drm/radeon/ni_dma.c| 2 - > drivers/gpu/drm/radeon/ni_dpm.c| 3 - > drivers/gpu/drm/radeon/r600.c | 2 - > drivers/gpu/drm/radeon/r600_dma.c | 2 - > drivers/gpu/drm/radeon/radeon.h| 207 > + > drivers/gpu/drm/radeon/radeon_acpi.c | 2 - > drivers/gpu/drm/radeon/radeon_asic.h | 9 -- > drivers/gpu/drm/radeon/radeon_atombios.c | 9 -- > drivers/gpu/drm/radeon/radeon_audio.c | 63 - > drivers/gpu/drm/radeon/radeon_encoders.c | 8 -- > drivers/gpu/drm/radeon/radeon_i2c.c| 4 - > drivers/gpu/drm/radeon/radeon_kms.c| 6 +- > drivers/gpu/drm/radeon/radeon_object.c | 2 - > drivers/gpu/drm/radeon/rv730_dpm.c | 3 - > drivers/gpu/drm/radeon/rv740_dpm.c | 2 - > drivers/gpu/drm/radeon/si.c| 10 -- > drivers/gpu/drm/radeon/si_dma.c| 2 - > drivers/gpu/drm/radeon/si_dpm.c| 8 -- > drivers/gpu/drm/radeon/sumo_smc.c | 2 - > drivers/gpu/drm/radeon/trinity_dpm.c | 1 - > 31 files changed, 210 insertions(+), 206 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c > b/drivers/gpu/drm/radeon/atombios_encoders.c > index fa4f8f0..2bbb916 100644 > --- a/drivers/gpu/drm/radeon/atombios_encoders.c > +++ b/drivers/gpu/drm/radeon/atombios_encoders.c > @@ -291,10 +291,6 @@ static void radeon_atom_backlight_exit(struct > radeon_encoder *encoder) > > #endif > > -/* evil but including atombios.h is much worse */ > -bool radeon_atom_get_tv_timings(struct radeon_device *rdev, int index, > - struct drm_display_mode *mode); > - > static bool radeon_atom_mode_fixup(struct drm_encoder *encoder, > const struct drm_display_mode *mode, > struct drm_display_mode > *adjusted_mode) > diff --git a/drivers/gpu/drm/radeon/btc_dpm.c > b/drivers/gpu/drm/radeon/btc_dpm.c > index 38e5123..2b08cfd 100644 > --- a/drivers/gpu/drm/radeon/btc_dpm.c > +++ b/drivers/gpu/drm/radeon/btc_dpm.c > @@ -47,10 +47,6 @@ > #ifndef BTC_MGCG_SEQUENCE > #define BTC_MGCG_SEQUENCE 300 > > -struct rv7xx_ps *rv770_get_ps(struct radeon_ps *rps); > -struct rv7xx_power_info *rv770_get_pi(struct radeon_device *rdev); > -struct evergreen_power_info *evergreen_get_pi(struct radeon_device > *rdev); > - > extern int ni_mc_load_microcode(struct radeon_device *rdev); > > //* BARTS **// > diff --git a/drivers/gpu/drm/radeon/ci_dpm.c > b/drivers/gpu/drm/radeon/ci_dpm.c > ind
RE: [PATCH] drm/amd/powerplay: mark symbols static where possible
> -Original Message- > From: Arnd Bergmann [mailto:a...@arndb.de] > Sent: Tuesday, October 25, 2016 4:15 AM > To: Baoyou Xie > Cc: Deucher, Alexander; Dave Airlie; Zhu, Rex; Zhou, Jammy; Huang, > JinHuiEric; StDenis, Tom; Edward O'Callaghan; Prosyak, Vitaly; Yang, Eric; > Yang, Young; Huang, Ray; Dan Carpenter; Cui, Flora; Nils Wallménius; Liu, > Monk; Wang, Ken; Min, Frank; dri-devel; Linux Kernel Mailing List; > xie.bao...@zte.com.cn; han@zte.com.cn; tang.qiang...@zte.com.cn > Subject: Re: [PATCH] drm/amd/powerplay: mark symbols static where > possible > > On Tuesday, October 25, 2016 10:31:21 AM CEST Baoyou Xie wrote: > > On 25 October 2016 at 04:51, Arnd Bergmann <a...@arndb.de> wrote: > > > On Saturday, October 22, 2016 4:56:22 PM CEST Baoyou Xie wrote: > > > The function has no callers, so the easiest way would be to remove it > > > entirely, but it's possible that there are plans to add users soon. > > > > > > It was assumed that this function will be used soon, so this patch remains > > it. > > if it still not be used in 4.10, then we can remove it. > > is it right? > > There is no such rule in general, it's up to the maintainer and > it depends on the specific reason for why the function ended up > being unused in the first place. > > However, we can expect the maintainer to come up with some solution > to address the warning. Possible options include: > > - calling the function from where it was meant to be used > - removing the function > - adding __maybe_unused > - adding an #if 0 > > I have not looked at this specific example and do not know > which of them would be appropriate here. If you look at the > output of 'git log -p > drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c' > you might find it out yourself. This is mostly fallout from a big cleanup/re-org of the powerplay code in the 4.9. Rex said he was going to use these soon. Alex
RE: v4.9-rc3: radeon oops on shutdown
> -Original Message- > From: Pavel Machek [mailto:pa...@ucw.cz] > Sent: Monday, November 07, 2016 1:40 PM > To: Deucher, Alexander; Koenig, Christian; dri-de...@lists.freedesktop.org; > kernel list > Subject: v4.9-rc3: radeon oops on shutdown > > Hi! > > On old thinkpad T40p... with v4.9-rc3+ I'm getting radeon oops on > shutdown. Seems repeatable. > > Unable to handle kernel NULL pointer dereference at 78c. > IP: .. radeon_connector_unregister > ... > trace: > ? drm_connector_unregister.part.5 > drm_connector_unregister_all > Already fixed: https://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-fixes=0a6e21056eaa859353945c4b164f3ef574d84271 Alex
