dri-devel March 2014

dri-devel@lists.freedesktop.org

144 participants
926 discussions

[PATCH] drm/nouveau: fail runtime pm properly.
by Dave Airlie 26 Mar '14

26 Mar '14

From: Dave Airlie <airlied(a)redhat.com> If we were on a non-optimus device, we'd return -EINVAL, this would lead to the over engineered runtime pm system to go into an error state, subsequent get_sync's would fail, so we'd never be able to open the device again. (like really get_sync shouldn't fail if the device isn't powered down). Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 89c484d..4ee702a 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -866,13 +866,16 @@ static int nouveau_pmops_runtime_suspend(struct device *dev) struct drm_device *drm_dev = pci_get_drvdata(pdev); int ret; - if (nouveau_runtime_pm == 0) - return -EINVAL; + if (nouveau_runtime_pm == 0) { + pm_runtime_forbid(dev); + return -EBUSY; + } /* are we optimus enabled? */ if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { DRM_DEBUG_DRIVER("failing to power off - not optimus\n"); - return -EINVAL; + pm_runtime_forbid(dev); + return -EBUSY; } nv_debug_level(SILENT); @@ -923,12 +926,15 @@ static int nouveau_pmops_runtime_idle(struct device *dev) struct nouveau_drm *drm = nouveau_drm(drm_dev); struct drm_crtc *crtc; - if (nouveau_runtime_pm == 0) + if (nouveau_runtime_pm == 0) { + pm_runtime_forbid(dev); return -EBUSY; + } /* are we optimus enabled? */ if (nouveau_runtime_pm == -1 && !nouveau_is_optimus() && !nouveau_is_v1_dsm()) { DRM_DEBUG_DRIVER("failing to power off - not optimus\n"); + pm_runtime_forbid(dev); return -EBUSY; } -- 1.8.3.1

2 1

[PATCH] drm: Try to acquire modeset lock on panic or sysrq
by Thierry Reding 26 Mar '14

26 Mar '14

From: Thierry Reding <treding(a)nvidia.com> Commit 62ff94a54921 "drm/crtc-helper: remove LOCKING from kerneldoc" causes drm_helper_crtc_in_use() and drm_helper_encoder_in_use() to complain loudly during a kernel panic or sysrq processing. This is caused by nobody acquiring the modeset lock in these code paths. This patch fixes this by trying to acquire the modeset lock for each FB helper that's forced to kernel mode. If the lock can't be acquired, it's likely that somebody else is performing a modeset. However, doing another modeset concurrently might make things even worse, so the safe option is to simply bail out in that case. Signed-off-by: Thierry Reding <treding(a)nvidia.com> --- drivers/gpu/drm/drm_fb_helper.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 9580393628a0..afce7cbd5149 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -325,12 +325,21 @@ static bool drm_fb_helper_force_kernel_mode(void) return false; list_for_each_entry(helper, &kernel_fb_helper_list, kernel_fb_list) { - if (helper->dev->switch_power_state == DRM_SWITCH_POWER_OFF) + struct drm_device *dev = helper->dev; + + if (dev->switch_power_state == DRM_SWITCH_POWER_OFF) + continue; + + if (!mutex_trylock(&dev->mode_config.mutex)) { + error = true; continue; + } ret = drm_fb_helper_restore_fbdev_mode(helper); if (ret) error = true; + + mutex_unlock(&dev->mode_config.mutex); } return error; } -- 1.9.1

3 2

[PATCH 0/3] DRM: Add LD9040 panel support
by Andrzej Hajda 26 Mar '14

26 Mar '14

Hi, This patchset adds LD9040 panel support with DT bindings. It also adds support for this panel to Exynos4210-universal_c210 board. Regards Andrzej Andrzej Hajda (3): panel/ld9040: add DT bindings drm/panel: add ld9040 driver ARM: dts: exynos4210-universal_c210: add proper panel node .../devicetree/bindings/panel/samsung,ld9040.txt | 66 ++++ arch/arm/boot/dts/exynos4210-universal_c210.dts | 71 +++- drivers/gpu/drm/panel/Kconfig | 6 + drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-ld9040.c | 377 +++++++++++++++++++++ 5 files changed, 504 insertions(+), 17 deletions(-) create mode 100644 Documentation/devicetree/bindings/panel/samsung,ld9040.txt create mode 100644 drivers/gpu/drm/panel/panel-ld9040.c -- 1.8.3.2

1 5

[PATCH] a crash in mga_driver_irq_uninstall
by Mikulas Patocka 26 Mar '14

26 Mar '14

Hi I'm getting a reproducible crash in kernel MGA DRM driver. The crash happens in the following way: drm_release is called drm_release calls drm_master_put(&file_priv->master); drm_master_put drops a reference and calls drm_master_destroy drm_master_destroy calls drm_rmmap_locked to unmap the card's mmio space drm_release continues to execute drm_release calls drm_lastclose drm_lastclose calls drm_irq_uninstall drm_irq_uninstall calls dev->driver->irq_uninstall (mga_driver_irq_uninstall) mga_driver_irq_uninstall performs MGA_WRITE(MGA_IEN, 0), it crashes because the mmio range was unmapped The result are these two crashes - one in mga_driver_irq_uninstall and the other in mga_driver_irq_handler: [44272.019284] BUG: unable to handle kernel paging request at e4831e1c [44272.021000] IP: [<e481e8d8>] mga_driver_irq_uninstall+0x18/0x28 [mga] [44272.021000] *pde = 1e7ba067 *pte = 00000000 [44272.021000] Oops: 0002 [#1] [44272.021000] Modules linked in: mga drm hid_generic usbhid hid ipv6 cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_ondemand cpufreq_userspace plip spadfs hpfs nls_cp852 msdos fat matroxfb_base matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea matroxfb_DAC1064 g450_pll matroxfb_misc floppy dm_crypt snd_usb_audio snd_usbmidi_lib snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd soundcore powernow_k6 pcspkr evdev ehci_pci via686a i2c_viapro e1000 i2c_core uhci_hcd ehci_hcd via_agp usbcore usb_common parport_pc agpgart parport dm_mod ext4 crc16 jbd2 mbcache sata_promise unix [44272.021000] CPU: 0 PID: 3140 Comm: Xorg Not tainted 3.13.5 #5 [44272.021000] Hardware name: System Manufacturer Product Name/VA-503A, BIOS 4.51 PG 08/02/00 [44272.021000] task: c043ce80 ti: de662000 task.ti: de662000 [44272.021000] EIP: 0060:[<e481e8d8>] EFLAGS: 00213286 CPU: 0 [44272.021000] EIP is at mga_driver_irq_uninstall+0x18/0x28 [mga] [44272.021000] EAX: de87fc00 EBX: de87fc00 ECX: e4830000 EDX: 00000000 [44272.021000] ESI: 00000001 EDI: 00000001 EBP: 00203202 ESP: de663e58 [44272.021000] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [44272.021000] CR0: 8005003b CR2: e4831e1c CR3: 1e666000 CR4: 00000090 [44272.021000] Stack: [44272.021000] e47d17ae 00000000 e47f0064 e47e6ca2 e47f0079 0000000f 0187fc00 c0096e40 [44272.021000] de87fc00 00000001 de87fc00 e481a277 00000001 e481ee1f e481eaa7 e481ee1d [44272.021000] de7a6880 00150012 e47d6b2d 00017915 e47d6b2d df401d00 c0096e40 de87fc00 [44272.021000] Call Trace: [44272.021000] [<e47d17ae>] ? drm_irq_uninstall+0xae/0x180 [drm] [44272.021000] [<e481a277>] ? mga_do_cleanup_dma+0x237/0x300 [mga] [44272.021000] [<e47d6b2d>] ? drm_ht_remove+0x2d/0x40 [drm] [44272.021000] [<e47d6b2d>] ? drm_ht_remove+0x2d/0x40 [drm] [44272.021000] [<e47cf03e>] ? drm_lastclose+0x3e/0x180 [drm] [44272.021000] [<e47cf4fb>] ? drm_release+0x37b/0x520 [drm] [44272.021000] [<c10a61b2>] ? __fput+0x72/0x1c0 [44272.021000] [<c1039499>] ? task_work_run+0x79/0xa0 [44272.021000] [<c102722f>] ? do_exit+0x18f/0x740 [44272.021000] [<c10a5bec>] ? vfs_writev+0x2c/0x60 [44272.021000] [<c10a5d8a>] ? SyS_writev+0x4a/0xc0 [44272.021000] [<c10278a6>] ? do_group_exit+0x26/0x60 [44272.021000] [<c10278f1>] ? SyS_exit_group+0x11/0x20 [44272.021000] [<c125cbf8>] ? syscall_call+0x7/0xb [44272.021000] Code: 1e 00 00 b0 00 5b c3 8d b6 00 00 00 00 8d bf 00 00 00 00 8b 90 d8 00 00 00 85 d2 74 1b 8b 92 dc 00 00 00 8b 4a 10 ba 00 00 00 00 <89> 91 1c 1e 00 00 c6 80 80 00 00 00 00 c3 00 00 ba 00 f9 81 e4 [44272.021000] EIP: [<e481e8d8>] mga_driver_irq_uninstall+0x18/0x28 [mga] SS:ESP 0068:de663e58 [44272.021000] CR2: 00000000e4831e1c [44272.021000] ---[ end trace 68cd6cc5ef884eb2 ]--- [44272.021000] Fixing recursive fault but reboot is needed! [44272.651150] BUG: unable to handle kernel paging request at e4831e14 [44272.654217] IP: [<e481e5f4>] mga_driver_irq_handler+0x14/0xe0 [mga] [44272.654217] *pde = 1e7ba067 *pte = 00000000 [44272.654217] Oops: 0000 [#2] [44272.654217] Modules linked in: mga drm hid_generic usbhid hid ipv6 cpufreq_stats cpufreq_conservative cpufreq_powersave cpufreq_ondemand cpufreq_userspace plip spadfs hpfs nls_cp852 msdos fat matroxfb_base matroxfb_g450 matroxfb_accel cfbfillrect cfbimgblt cfbcopyarea matroxfb_DAC1064 g450_pll matroxfb_misc floppy dm_crypt snd_usb_audio snd_usbmidi_lib snd_hwdep snd_seq_midi snd_seq_midi_event snd_rawmidi snd_pcm snd_page_alloc snd_seq snd_seq_device snd_timer snd soundcore powernow_k6 pcspkr evdev ehci_pci via686a i2c_viapro e1000 i2c_core uhci_hcd ehci_hcd via_agp usbcore usb_common parport_pc agpgart parport dm_mod ext4 crc16 jbd2 mbcache sata_promise unix [44272.654217] CPU: 0 PID: 0 Comm: swapper Tainted: G D 3.13.5 #5 [44272.654217] Hardware name: System Manufacturer Product Name/VA-503A, BIOS 4.51 PG 08/02/00 [44272.654217] task: c132f500 ti: df406000 task.ti: c1324000 [44272.654217] EIP: 0060:[<e481e5f4>] EFLAGS: 00210082 CPU: 0 [44272.654217] EIP is at mga_driver_irq_handler+0x14/0xe0 [mga] [44272.654217] EAX: de87fc00 EBX: df640a00 ECX: e0860803 EDX: e4830000 [44272.654217] ESI: 00000080 EDI: 0000000f EBP: de585340 ESP: df407fb0 [44272.654217] DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 [44272.654217] CR0: 8005003b CR2: e4831e14 CR3: 1f7ca000 CR4: 00000090 [44272.654217] Stack: [44272.654217] 0000000f 00000001 00000080 c104aaf6 00000000 00000000 00000000 00000000 [44272.654217] 00000000 00000000 df405780 df405780 df405780 c104c9a0 0000000f c104ac19 [44272.654217] df405780 c104c9ec c1325f68 c10036b2 [44272.654217] Call Trace: [44272.654217] [<c104aaf6>] ? handle_irq_event_percpu+0x36/0x140 [44272.654217] [<c104c9a0>] ? cond_unmask_irq+0x40/0x40 [44272.654217] [<c104ac19>] ? handle_irq_event+0x19/0x40 [44272.654217] [<c104c9ec>] ? handle_level_irq+0x4c/0x80 [44272.654217] <IRQ> [44272.654217] [<c100340e>] ? do_IRQ+0x2e/0xa0 [44272.654217] [<c125d5ec>] ? common_interrupt+0x2c/0x31 [44272.654217] [<c104a3a8>] ? cpu_startup_entry+0xa8/0x120 [44272.654217] [<c135f989>] ? start_kernel+0x2d1/0x2d6 [44272.654217] [<c135f502>] ? repair_env_string+0x4d/0x4d [44272.654217] Code: 0e 8b 80 9c 00 00 00 c3 8d b4 26 00 00 00 00 b8 00 00 00 00 c3 66 90 56 53 50 89 d0 8b 9a d8 00 00 00 8b 93 dc 00 00 00 8b 52 10 <8b> b2 14 1e 00 00 f7 c6 20 00 00 00 0f 85 8a 00 00 00 b8 00 00 [44272.654217] EIP: [<e481e5f4>] mga_driver_irq_handler+0x14/0xe0 [mga] SS:ESP 0068:df407fb0 [44272.654217] CR2: 00000000e4831e14 [44272.654217] ---[ end trace 68cd6cc5ef884eb3 ]--- [44272.654217] Kernel panic - not syncing: Fatal exception in interrupt The crash can be fixed with this patch - it calls drm_irq_uninstall before unmapping the registers, so that further calls to drm_irq_uninstall do not try to touch the mmio space. Removing the lock is not correct, but the lock is already held when calling drm_master_destroy - you know the drm locking rules better than me, so you could come up with a better patch for this problem. Mikulas --- drivers/gpu/drm/drm_irq.c | 2 -- drivers/gpu/drm/drm_stub.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) Index: linux-3.13.5/drivers/gpu/drm/drm_irq.c =================================================================== --- linux-3.13.5.orig/drivers/gpu/drm/drm_irq.c 2014-01-24 19:36:33.529945530 +0100 +++ linux-3.13.5/drivers/gpu/drm/drm_irq.c 2014-02-26 16:40:41.379534715 +0100 @@ -357,10 +357,8 @@ int drm_irq_uninstall(struct drm_device if (!drm_core_check_feature(dev, DRIVER_HAVE_IRQ)) return -EINVAL; - mutex_lock(&dev->struct_mutex); irq_enabled = dev->irq_enabled; dev->irq_enabled = false; - mutex_unlock(&dev->struct_mutex); /* * Wake up any waiters so they don't hang. Index: linux-3.13.5/drivers/gpu/drm/drm_stub.c =================================================================== --- linux-3.13.5.orig/drivers/gpu/drm/drm_stub.c 2014-02-26 16:31:36.158862071 +0100 +++ linux-3.13.5/drivers/gpu/drm/drm_stub.c 2014-02-26 16:40:52.031317277 +0100 @@ -167,6 +167,8 @@ static void drm_master_destroy(struct kr list_del(&master->head); + drm_irq_uninstall(dev); + if (dev->driver->master_destroy) dev->driver->master_destroy(dev, master);

5 14

[PATCH] nouveau: safen up nouveau_device list usage against concurrent access
by Ilia Mirkin 26 Mar '14

26 Mar '14

Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> --- nouveau/nouveau.c | 29 ++++++++++++++++++++++++++++- nouveau/private.h | 3 ++- 2 files changed, 30 insertions(+), 2 deletions(-) diff --git a/nouveau/nouveau.c b/nouveau/nouveau.c index ee7893b..72c31cf 100644 --- a/nouveau/nouveau.c +++ b/nouveau/nouveau.c @@ -85,6 +85,12 @@ nouveau_device_wrap(int fd, int close, struct nouveau_device **pdev) if (!nvdev) return -ENOMEM; + ret = pthread_mutex_init(&nvdev->lock, NULL); + if (ret) { + free(nvdev); + return ret; + } + nvdev->base.fd = fd; ver = drmGetVersion(fd); @@ -161,6 +167,7 @@ nouveau_device_del(struct nouveau_device **pdev) if (nvdev->close) drmClose(nvdev->base.fd); free(nvdev->client); + pthread_mutex_destroy(&nvdev->lock); free(nvdev); *pdev = NULL; } @@ -191,6 +198,8 @@ nouveau_client_new(struct nouveau_device *dev, struct nouveau_client **pclient) int id = 0, i, ret = -ENOMEM; uint32_t *clients; + pthread_mutex_lock(&nvdev->lock); + for (i = 0; i < nvdev->nr_client; i++) { id = ffs(nvdev->client[i]) - 1; if (id >= 0) @@ -199,7 +208,7 @@ nouveau_client_new(struct nouveau_device *dev, struct nouveau_client **pclient) clients = realloc(nvdev->client, sizeof(uint32_t) * (i + 1)); if (!clients) - return ret; + goto unlock; nvdev->client = clients; nvdev->client[i] = 0; nvdev->nr_client++; @@ -214,6 +223,9 @@ out: } *pclient = &pcli->base; + +unlock: + pthread_mutex_unlock(&nvdev->lock); return ret; } @@ -225,7 +237,9 @@ nouveau_client_del(struct nouveau_client **pclient) if (pcli) { int id = pcli->base.id; nvdev = nouveau_device(pcli->base.device); + pthread_mutex_lock(&nvdev->lock); nvdev->client[id / 32] &= ~(1 << (id % 32)); + pthread_mutex_unlock(&nvdev->lock); free(pcli->kref); free(pcli); } @@ -331,9 +345,12 @@ nouveau_object_find(struct nouveau_object *obj, uint32_t pclass) static void nouveau_bo_del(struct nouveau_bo *bo) { + struct nouveau_device_priv *nvdev = nouveau_device(bo->device); struct nouveau_bo_priv *nvbo = nouveau_bo(bo); struct drm_gem_close req = { bo->handle }; + pthread_mutex_lock(&nvdev->lock); DRMLISTDEL(&nvbo->head); + pthread_mutex_unlock(&nvdev->lock); if (bo->map) munmap(bo->map, bo->size); drmIoctl(bo->device->fd, DRM_IOCTL_GEM_CLOSE, &req); @@ -363,7 +380,9 @@ nouveau_bo_new(struct nouveau_device *dev, uint32_t flags, uint32_t align, return ret; } + pthread_mutex_lock(&nvdev->lock); DRMLISTADD(&nvbo->head, &nvdev->bo_list); + pthread_mutex_unlock(&nvdev->lock); *pbo = bo; return 0; @@ -378,13 +397,16 @@ nouveau_bo_wrap(struct nouveau_device *dev, uint32_t handle, struct nouveau_bo_priv *nvbo; int ret; + pthread_mutex_lock(&nvdev->lock); DRMLISTFOREACHENTRY(nvbo, &nvdev->bo_list, head) { if (nvbo->base.handle == handle) { + pthread_mutex_unlock(&nvdev->lock); *pbo = NULL; nouveau_bo_ref(&nvbo->base, pbo); return 0; } } + pthread_mutex_unlock(&nvdev->lock); ret = drmCommandWriteRead(dev->fd, DRM_NOUVEAU_GEM_INFO, &req, sizeof(req)); @@ -396,7 +418,9 @@ nouveau_bo_wrap(struct nouveau_device *dev, uint32_t handle, atomic_set(&nvbo->refcnt, 1); nvbo->base.device = dev; abi16_bo_info(&nvbo->base, &req); + pthread_mutex_lock(&nvdev->lock); DRMLISTADD(&nvbo->head, &nvdev->bo_list); + pthread_mutex_unlock(&nvdev->lock); *pbo = &nvbo->base; return 0; } @@ -413,13 +437,16 @@ nouveau_bo_name_ref(struct nouveau_device *dev, uint32_t name, struct drm_gem_open req = { .name = name }; int ret; + pthread_mutex_lock(&nvdev->lock); DRMLISTFOREACHENTRY(nvbo, &nvdev->bo_list, head) { if (nvbo->name == name) { + pthread_mutex_unlock(&nvdev->lock); *pbo = NULL; nouveau_bo_ref(&nvbo->base, pbo); return 0; } } + pthread_mutex_unlock(&nvdev->lock); ret = drmIoctl(dev->fd, DRM_IOCTL_GEM_OPEN, &req); if (ret == 0) { diff --git a/nouveau/private.h b/nouveau/private.h index 60714b8..4f337ad 100644 --- a/nouveau/private.h +++ b/nouveau/private.h @@ -3,6 +3,7 @@ #include <xf86drm.h> #include <xf86atomic.h> +#include <pthread.h> #include "nouveau_drm.h" #include "nouveau.h" @@ -94,7 +95,7 @@ nouveau_bo(struct nouveau_bo *bo) struct nouveau_device_priv { struct nouveau_device base; int close; - atomic_t lock; + pthread_mutex_t lock; struct nouveau_list bo_list; uint32_t *client; int nr_client; -- 1.8.3.2

2 2

[PATCH] drm/nouveau: don't suspend/resume display on runtime s/r
by Dave Airlie 26 Mar '14

26 Mar '14

From: Dave Airlie <airlied(a)redhat.com> This should ensure we don't hit a locking problem when someone wakes us up via a connector, we should never go into suspend while the display is on anyways. Signed-off-by: Dave Airlie <airlied(a)redhat.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index 89c484d..d936e88 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -486,13 +486,13 @@ nouveau_drm_remove(struct pci_dev *pdev) } static int -nouveau_do_suspend(struct drm_device *dev) +nouveau_do_suspend(struct drm_device *dev, bool runtime) { struct nouveau_drm *drm = nouveau_drm(dev); struct nouveau_cli *cli; int ret; - if (dev->mode_config.num_crtc) { + if (dev->mode_config.num_crtc && !runtime) { NV_INFO(drm, "suspending display...\n"); ret = nouveau_display_suspend(dev); if (ret) @@ -566,7 +566,7 @@ int nouveau_pmops_suspend(struct device *dev) if (drm_dev->mode_config.num_crtc) nouveau_fbcon_set_suspend(drm_dev, 1); - ret = nouveau_do_suspend(drm_dev); + ret = nouveau_do_suspend(drm_dev, false); if (ret) return ret; @@ -646,7 +646,7 @@ static int nouveau_pmops_freeze(struct device *dev) if (drm_dev->mode_config.num_crtc) nouveau_fbcon_set_suspend(drm_dev, 1); - ret = nouveau_do_suspend(drm_dev); + ret = nouveau_do_suspend(drm_dev, false); return ret; } @@ -879,7 +879,7 @@ static int nouveau_pmops_runtime_suspend(struct device *dev) drm_kms_helper_poll_disable(drm_dev); vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_OFF); nouveau_switcheroo_optimus_dsm(); - ret = nouveau_do_suspend(drm_dev); + ret = nouveau_do_suspend(drm_dev, true); pci_save_state(pdev); pci_disable_device(pdev); pci_set_power_state(pdev, PCI_D3cold); @@ -905,8 +905,6 @@ static int nouveau_pmops_runtime_resume(struct device *dev) pci_set_master(pdev); ret = nouveau_do_resume(drm_dev); - if (drm_dev->mode_config.num_crtc) - nouveau_display_resume(drm_dev); drm_kms_helper_poll_enable(drm_dev); /* do magic */ nv_mask(device, 0x88488, (1 << 25), (1 << 25)); -- 1.8.3.1

1 0

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents
by bugzilla-daemon＠bugzilla.kernel.org 26 Mar '14

26 Mar '14

https://bugzilla.kernel.org/show_bug.cgi?id=22312 --- Comment #10 from Alex Deucher <alexdeucher(a)gmail.com> --- If you are running a 3.13 or newer kernel, try appending radeon.runpm=0 to the kernel command line in grub. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents
by bugzilla-daemon＠bugzilla.kernel.org 26 Mar '14

26 Mar '14

https://bugzilla.kernel.org/show_bug.cgi?id=22312 --- Comment #9 from Alex Deucher <alexdeucher(a)gmail.com> --- (In reply to Chris Nystrom from comment #8) > Yes. I am having this exact error message with a live Fedora 20 DVD on a > Dell OptiPlex 780 with a PCIe ASUS Radeon R7 240 video card. The desktop > never comes up. Please attach your dmesg output. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 22312] radeon 0000:01:00.0: Invalid ROM contents
by bugzilla-daemon＠bugzilla.kernel.org 25 Mar '14

25 Mar '14

https://bugzilla.kernel.org/show_bug.cgi?id=22312 Chris Nystrom <cnystrom(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cnystrom(a)gmail.com --- Comment #8 from Chris Nystrom <cnystrom(a)gmail.com> --- (In reply to Alex Deucher from comment #3) > Is this still an issue with a newer version of the driver? Yes. I am having this exact error message with a live Fedora 20 DVD on a Dell OptiPlex 780 with a PCIe ASUS Radeon R7 240 video card. The desktop never comes up. I am unable to provide further information as I have been unable to install linux due to this issue. There does not seem to be a way to disable the onboard video in the BIOS on the OptiPlex 780. The only options are "Auto" and "Onboard/Card". There error happens no matter which option is selected. -- You are receiving this mail because: You are watching the assignee of the bug.

1 0

[Bug 76082] New: Metro Last Light fail to start
by bugzilla-daemon＠freedesktop.org 25 Mar '14

25 Mar '14

https://bugs.freedesktop.org/show_bug.cgi?id=76082 Priority: medium Bug ID: 76082 Assignee: dri-devel(a)lists.freedesktop.org Summary: Metro Last Light fail to start Severity: normal Classification: Unclassified OS: All Reporter: lordheavym(a)gmail.com Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa No segfault, it just refuse to start * glxinfo OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.2.0-devel (git-6e627b4) * llvm-3.5svn * mesa-git Bisecting gives me: [lordh@archMain tst]$ git bisect bad d9b983519c63b9072677364a6e399d213a1855e5 is the first bad commit commit d9b983519c63b9072677364a6e399d213a1855e5 Author: Ilia Mirkin <imirkin(a)alum.mit.edu> Date: Mon Feb 24 12:43:17 2014 -0500 build: llvm libs may not be in system search path, add rpath On my gentoo system, llvm libs are in /usr/lib64/llvm, and llvm-config --ldflags does not provide the rpath (it does, of course, provide a -L). This adds the llvm dir to the rpath. It should be harmless if the path is a system path, and should make things work when it's not. Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> Reviewed-by: Tom Stellard <thomas.stellard(a)amd.com> Tested-by: Emil Velikov <emil.l.velikov(a)gmail.com> :100644 100644 b8e3161e116521771eb08a84b6c4e70f357ced52 0e0fd1820f415f5298be947c1598a38b91d37340 M configure.ac -- You are receiving this mail because: You are the assignee for the bug.

1 8

← Newer
1
...
66
67
68
69
70
71
72
...
93
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2014