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 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 > 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�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
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: [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: [] 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:[] [] > > > 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: > > > [] ? radeon_dvi_detect+0x35a/0x4d0 [radeon] > > > [] ? > > > drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 > > > [drm_kms_helper] > > > [] ? > > > drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 > > > [drm_kms_helper] > > > [] ? drm_fb_helper_hotplug_event+0x55/0xe0 > > > [drm_kms_helper] > > > [] ? output_poll_execute+0x7c/0x1a0 > [drm_kms_helper] > > > [] ? process_one_work+0x130/0x360 > > > [] ? worker_thread+0x114/0x460 > > > [] ? __schedule+0x20d/0x660 > > > [] ? rescuer_thread+0x2f0/0x2f0 > > > [] ? kthread+0xbc/0xe0 > > > [] ? kthread_create_on_node+0x170/0x170 > > > [] ? ret_from_fork+0x42/0x70 > > > [] ? 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 [] radeon_audio_detect+0x5b/0x150 [radeon] > > > RSP > > > CR2: 0010 > > > ---[ end trace 5b99e3870bfc7a92 ]--- > > > BUG: unable to handle kernel paging request at ffd8 > > > IP: [] 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 sn
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: [] 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:[] [] > 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: > [] ? radeon_dvi_detect+0x35a/0x4d0 [radeon] > [] ? > drm_helper_probe_single_connector_modes_merge_bits+0x2e6/0x490 > [drm_kms_helper] > [] ? > drm_fb_helper_probe_connector_modes.isra.5+0x48/0x70 > [drm_kms_helper] > [] ? drm_fb_helper_hotplug_event+0x55/0xe0 > [drm_kms_helper] > [] ? output_poll_execute+0x7c/0x1a0 [drm_kms_helper] > [] ? process_one_work+0x130/0x360 > [] ? worker_thread+0x114/0x460 > [] ? __schedule+0x20d/0x660 > [] ? rescuer_thread+0x2f0/0x2f0 > [] ? kthread+0xbc/0xe0 > [] ? kthread_create_on_node+0x170/0x170 > [] ? ret_from_fork+0x42/0x70 > [] ? 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 [] radeon_audio_detect+0x5b/0x150 [radeon] > RSP > CR2: 0010 > ---[ end trace 5b99e3870bfc7a92 ]--- > BUG: unable to handle kernel paging request at ffd8 > IP: [] 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:[] [] 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 880037963af
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] 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 > Date: Fri, 20 Mar 2015 10:38:32 +0100 > > > On 19.03.2015 17:29, David Miller wrote: > >> From: Christian König > >> 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 > > > > 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: [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: 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 > > Date: Fri Dec 12 17:01:42 2014 -0500 > > > > radeon/audio: enable DP audio > > > > Reviewed-by: Christian König > > Signed-off-by: Slava Grigorev > > Signed-off-by: Alex Deucher > > > > :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: [7f604077ac9cacb9a6b04b977e2c
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 > Date: Fri Dec 12 17:01:42 2014 -0500 > > radeon/audio: enable DP audio > > Reviewed-by: Christian König > Signed-off-by: Slava Grigorev > Signed-off-by: Alex Deucher > > :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: 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: [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. > @Alex: 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: [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: [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: [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: [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 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: 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: [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 > >>>> 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: [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 > >> 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: [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: [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: [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 > 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: 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: [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 Acked-by: Alex Deucher > --- > 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?Z>#}btS`cj_8lhUuj8~E} > ziWXfzFs(pZ2oV`W(AQ$3oT d*^@8`QLlqxmQF)#1>UR > z9ROlXXozwY_OHaJ?!l+lZTl7#ZboXj2>Ysalr==UR@b*lot_)bh(Cd8;4 > zb!iQ$5kFF+grJv1YfPc?gj)AEnz0P77jwM;J=rd9 z9F(SfK(+u*w!NO_56T1DhQg_wGwMNE+6{mDnjFwV;RI@31a9cG#yr3XA9`k > v_pjw5 > z{^(- > tFY%&0;e#^|^ezhdL)%0rWR2cN)AFbu>b%QtH6GA7YvN1wL!2@_2=sIM>} > ! > zVKU5f<|VVhykb 6Xa-# > zX#cD=(}gG4w+sc@{6A3{y`8GldqA- > @jdO=ktJ#_?N=D{ z#vs11{ITYLF04$h7?s-hRax$8r*_%vI%#zfF7(4$%+_d%Z86 zzq)tPaoJ*q!s_{yRh4hj5kqyj$GNpUU>^O0$IPs}WA353B&}QUU$Tw18)RULiq > VJ? > z9D;=qn$Sf8y)=NsbQ*owhH-4iG8_bGH;)zu~?=zMao- > 9WO(Hhuy} > CmEV2< > > delta 813 > zc${sKTSydP6vzL^ncZo C > zyrgEB)Jw3X2wg;I9@?ddRTCffp@bd+pL!~&7pL>#Kt?_M=KRl@^PQRh`K(r})v > zjo > zY5>G&$U;9y%h)Nr+}=D=wqQJ`ya4Rc0(1lwl+^Z$^;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|? zgg?3v=ZdmX7Au9B1}<$3i^Iwx8Wf#M8_kGGCDfVVZfOpvOKSKYT) mH&*!Z > znptMvFiGYe^Fg{~3aq{H4#%2UW1Y|XwAA8&8mMV;tm!qkBkXF~(ctQO2NN > L&(`07F > zW<JGl= > Q$H > zBi#1@Pm(%%{=H?3di4`z>u}i%0)iqmPld1o&4}cZd$XOXeO @i!B0 > z$6;=)Z)574GLUlES2mAqUfkzZh@!~bec38s$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)rm 0d($* > zd2}=ia<`b7hD^OE0nF{+KKN=W- > @4%haq=4gT>b#jjyFO2NRItZW_hwun9T4*@f0LA > zJZbS9MmL@GgwaPIdR{xMc4iN2u6rACFP-;pspU@+h4- > x?xSi{eKu zPUF4^cF<;D9b0q0SgIE?6A1BVQ8?Kag319tSyE{v{V+TAqufY(nZr6GDKoEP?qW > V3 > zqc45CaUWIvUbOMG+QzmKyP<*oeuIsT2mrTuHWV{7Jywv>WRUOa^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*Xig2w>!yVjFA{ > v+o6ISg#mg`O > delta 1134 > zc$~G8Pe>F|9LImZ*`2peuI%wx(pROQ9~y>Ta V7N9> > zN}yreD?^2_Zo(YOrGYLX*r9_EQA9x@9Xfc^tRO1ry- > 8|?MY?qOzAy9r{@$CJ > zGm2UZ& uqB#6!IL0~d5*^9lx2~opjrh`xi1${ > z>JS_!%&93zwV6eLh0f;7%A=%;9{_OWJ%kRva?{6- > @ZV*4t_Nz%xZ > zz0Un;r4!B|+UXc9+r;o7>LKS>DQWdm?GpA$iiLg*QH- > z?i$R|jJuVsd3U(!ETnEDM4pDArz-$;gM89jr^Q?_H~FJhi#eD>g%-0hudkr5-R-!C > zuJ~MteDxq3Cl)OZmIp}_8xa8RAkBJspZ2>Nc;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?#R<7x@%+((XV4Ptu9 > NJ{+ST > z17p?W>@V60sW%Aefdn+l3b 1q-Mf > z$;2cvZDOjVp6VKj?>1CSR?nLXDf>;ujGw8foR_|fY4DL<5Tbb{=pf_(5OWu7Hs> > Hj > s4#Pz{qeL%VBY7AlgHRwtFiwVHk^FnuENsECKiB_34gWm+3!Zf_E= > k > > diff --git a/radeon/kaveri_mec.bin b/radeon/kaveri_mec.bin > index > 96bc1c9f77e19b318d41
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 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 > Cc: Alex Deucher Acked-by: Alex Deucher > --- > > 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: [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 Acked-by: Alex Deucher > --- > 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 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 > *
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: 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 > 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�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
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] 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 > --- > 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 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" > > 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 > > > --- > > > 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: 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 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 > --- > 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 > #include > #include > +#include > > #include > #include > @@ -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(>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))) > +
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: 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 > > 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
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 > 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. > >>> > &g
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 > >> 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 > >> > >> :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 > > 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: 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: 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�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
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: [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 Good catch! Reviewed-by: Alex Deucher > --- > 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 = >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: [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 > Cc: Alex Deucher > Signed-off-by: Quentin Casasnovas 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 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, >vm); > > r = radeon_bo_reserve(rdev->ring_tmp_bo.bo, false); > - if (r) > + if (r) { > + radeon_vm_fini(rdev, >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�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a��� 0��h���i
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: 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 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: 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: [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 > Reviewed-by: Josh Triplett > --- > 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 > #include "radeon.h" > #include "atom.h" > +#include "atombios.h" > #include > > 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 > #include "radeon.h" > #include "atom.h" > +#include "atombios.h" > > #include > > @@ -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: [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: [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: [] hwmon_attributes_visible+0x18/0x3d [radeon] > PGD 15057e067 PUD 151a8e067 PMD 0 > Oops: [#1] PREEMPT SMP > Call Trace: > [] internal_create_group+0x114/0x1d9 > [] sysfs_create_group+0xe/0x10 > [] sysfs_create_groups+0x22/0x5f > [] device_add+0x34f/0x501 > [] device_register+0x15/0x18 > [] hwmon_device_register_with_groups+0xb5/0xed > [] radeon_hwmon_init+0x56/0x7c [radeon] > [] radeon_pm_init+0x134/0x7e5 [radeon] > [] ? kmem_cache_alloc+0x63/0xe3 > [] radeon_modeset_init+0x75f/0x8ed [radeon] > [] radeon_driver_load_kms+0xc6/0x187 [radeon] > [] drm_dev_register+0xf9/0x1b4 [drm] > [] drm_get_pci_dev+0x98/0x129 [drm] > [] ? kfree+0x10a/0x166 > [] ? radeon_pci_probe+0x91/0xac [radeon] > [] radeon_pci_probe+0xa3/0xac [radeon] > [] pci_device_probe+0x6e/0xcf > [] driver_probe_device+0x98/0x1c4 > [] __driver_attach+0x5c/0x7e > [] ? __device_attach+0x38/0x38 > [] bus_for_each_dev+0x7b/0x85 > [] driver_attach+0x19/0x1b > [] bus_add_driver+0x104/0x1ce > [] driver_register+0x89/0xc5 > [] __pci_register_driver+0x58/0x5b > [] ? 0xa037efff > [] drm_pci_init+0x86/0xea [drm] > [] ? 0xa037efff > [] radeon_init+0x97/0x1000 [radeon] > [] do_one_initcall+0x7f/0x117 > [] ? set_memory_nx+0x3b/0x3d > [] load_module+0x1583/0x1bb4 > [] ? store_uevent+0x35/0x35 > [] ? finish_task_switch+0x3b/0x10c > [] ? preempt_schedule_irq+0x5d/0x99 > [] ? retint_restore_args+0x13/0x13 > [] SyS_init_module+0xa0/0xaf > [] tracesys+0xd4/0xd9 > > Signed-off-by: Sergey Senozhatsky > > --- > > 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_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: 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 > wrote: > > On Tue, Dec 10, 2013 at 5:07 PM, Deucher, Alexander > > 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 > >>> 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: 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 > 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.83912
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 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 > wrote: > > Use pcie_get_readrq() and pcie_set_readrq() functions to simplify code. > > > > Signed-off-by: Yijing Wang > > 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 > > 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, ); > > - 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: [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 > Date: Mon, 2 Sep 2013 18:57:41 +1000 > Subject: [PATCH] drm/radeon: protect ACPI calls with CONFIG_ACPI > > Signed-off-by: Stephen Rothwell 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: 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: 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; >
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: 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: > > > > > > > > > > > > >
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: 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] [T
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: IN
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] 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 > > 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 > --- > 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: [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: [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.11=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 > Cc: Alex Deucher > Signed-off-by: Tim Gardner > --- > 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: [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: [PATCH -next] drm/radeon/dpm: Add missing #include
> -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 > > > 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-next=bf0936e196ec21b604106578043d4c14831f99e7 Alex > Signed-off-by: Geert Uytterhoeven > --- > 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 > #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 -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: [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 > wrote: > > On Fri, Jun 28, 2013 at 3:55 PM, Deucher, Alexander > > 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: [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: [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: 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: 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 > 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 > Reviewed-by: Jerome Glisse > Signed-off-by: Alex Deucher > > :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: 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: 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 > 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 > >> 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 > >> >> 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: 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 > 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 > >> 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: 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: 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 > 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: 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 > wrote: > > On Tue, Jan 29, 2013 at 3:02 PM, Deucher, Alexander > > 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 > >>> 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 > >>> >> 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 > >>> >> >> 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 > >>> >> >> > >>> >> >> 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 cal
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: 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 > 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 > >> 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 > >> >> 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 > >> >> > >> >> 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 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 > 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 > >> 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 > >> > >> 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: 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 > wrote: > > On Wed, Jan 23, 2013 at 6:40 AM, Deucher, Alexander > > 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 > >>> 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 > 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 > > 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: 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 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 > 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/