linux.git/drivers/gpu, branch v3.10.65

drm/i915: Unlock panel even when LVDS is disabled

2014-12-16T17:09:42+00:00

commit b0616c5306b342ceca07044dbc4f917d95c4f825 upstream.

Otherwise we'll have backtraces in assert_panel_unlocked because the
BIOS locks the register. In the reporter's case this regression was
introduced in

commit c31407a3672aaebb4acddf90944a114fa5c8af7b
Author: Chris Wilson 
Date:   Thu Oct 18 21:07:01 2012 +0100

    drm/i915: Add no-lvds quirk for Supermicro X7SPA-H

Reported-by: Alexey Orishko 
Cc: Alexey Orishko 
Cc: Chris Wilson 
Cc: Francois Tigeot 
Signed-off-by: Daniel Vetter 
Tested-by: Alexey Orishko 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6

2014-12-16T17:09:42+00:00

commit f5475cc43c899e33098d4db44b7c5e710f16589d upstream.

I was unable too boot 3.18.0-rc6 because of the following kernel
panic in drm_calc_vbltimestamp_from_scanoutpos():

    [drm] Initialized drm 1.1.0 20060810
    [drm] radeon kernel modesetting enabled.
    [drm] initializing kernel modesetting (RV100 0x1002:0x515E 0x15D9:0x8080).
    [drm] register mmio base: 0xC8400000
    [drm] register mmio size: 65536
    radeon 0000:0b:01.0: VRAM: 128M 0x00000000D0000000 - 0x00000000D7FFFFFF (16M used)
    radeon 0000:0b:01.0: GTT: 512M 0x00000000B0000000 - 0x00000000CFFFFFFF
    [drm] Detected VRAM RAM=128M, BAR=128M
    [drm] RAM width 16bits DDR
    [TTM] Zone  kernel: Available graphics memory: 3829346 kiB
    [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
    [TTM] Initializing pool allocator
    [TTM] Initializing DMA pool allocator
    [drm] radeon: 16M of VRAM memory ready
    [drm] radeon: 512M of GTT memory ready.
    [drm] GART: num cpu pages 131072, num gpu pages 131072
    [drm] PCI GART of 512M enabled (table at 0x0000000037880000).
    radeon 0000:0b:01.0: WB disabled
    radeon 0000:0b:01.0: fence driver on ring 0 use gpu addr 0x00000000b0000000 and cpu addr 0xffff8800bbbfa000
    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] Driver supports precise vblank timestamp query.
    [drm] radeon: irq initialized.
    [drm] Loading R100 Microcode
    radeon 0000:0b:01.0: Direct firmware load for radeon/R100_cp.bin failed with error -2
    radeon_cp: Failed to load firmware "radeon/R100_cp.bin"
    [drm:r100_cp_init] *ERROR* Failed to load firmware!
    radeon 0000:0b:01.0: failed initializing CP (-2).
    radeon 0000:0b:01.0: Disabling GPU acceleration
    [drm] radeon: cp finalized
    BUG: unable to handle kernel NULL pointer dereference at 000000000000025c
    IP: [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    PGD 0
    Oops: 0000 [#1] SMP
    Modules linked in:
    CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc6-4-default #2649
    Hardware name: Supermicro X7DB8/X7DB8, BIOS 6.00 07/26/2006
    task: ffff880234da2010 ti: ffff880234da4000 task.ti: ffff880234da4000
    RIP: 0010:[]  [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
    RSP: 0000:ffff880234da7918  EFLAGS: 00010086
    RAX: ffffffff81557890 RBX: 0000000000000000 RCX: ffff880234da7a48
    RDX: ffff880234da79f4 RSI: 0000000000000000 RDI: ffff880232e15000
    RBP: ffff880234da79b8 R08: 0000000000000000 R09: 0000000000000000
    R10: 000000000000000a R11: 0000000000000001 R12: ffff880232dda1c0
    R13: ffff880232e1518c R14: 0000000000000292 R15: ffff880232e15000
    FS:  0000000000000000(0000) GS:ffff88023fc40000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 000000000000025c CR3: 0000000002014000 CR4: 00000000000007e0
    Stack:
     ffff880234da79d8 0000000000000286 ffff880232dcbc00 0000000000002480
     ffff880234da7958 0000000000000296 ffff880234da7998 ffffffff8151b51d
     ffff880234da7a48 0000000032dcbeb0 ffff880232dcbc00 ffff880232dcbc58
    Call Trace:
     [] ? drm_vma_offset_remove+0x1d/0x110
     [] radeon_get_vblank_timestamp_kms+0x38/0x60
     [] ? ttm_bo_release_list+0xba/0x180
     [] drm_get_last_vbltimestamp+0x41/0x70
     [] vblank_disable_and_save+0x73/0x1d0
     [] ? try_to_del_timer_sync+0x4f/0x70
     [] drm_vblank_cleanup+0x65/0xa0
     [] radeon_irq_kms_fini+0x1a/0x70
     [] r100_init+0x26e/0x410
     [] radeon_device_init+0x7ae/0xb50
     [] radeon_driver_load_kms+0x8f/0x210
     [] drm_dev_register+0xb5/0x110
     [] drm_get_pci_dev+0x8f/0x200
     [] radeon_pci_probe+0xad/0xe0
     [] local_pci_probe+0x45/0xa0
     [] pci_device_probe+0xd1/0x130
     [] driver_probe_device+0x12d/0x3e0
     [] __driver_attach+0x9b/0xa0
     [] ? __device_attach+0x40/0x40
     [] bus_for_each_dev+0x63/0xa0
     [] driver_attach+0x1e/0x20
     [] bus_add_driver+0x180/0x240
     [] driver_register+0x64/0xf0
     [] __pci_register_driver+0x4c/0x50
     [] drm_pci_init+0xf5/0x120
     [] ? ttm_init+0x6a/0x6a
     [] radeon_init+0x97/0xb5
     [] do_one_initcall+0xbc/0x1f0
     [] ? __wake_up+0x48/0x60
     [] kernel_init_freeable+0x18a/0x215
     [] ? initcall_blacklist+0xc0/0xc0
     [] ? rest_init+0x80/0x80
     [] kernel_init+0xe/0xf0
     [] ret_from_fork+0x7c/0xb0
     [] ? rest_init+0x80/0x80
    Code: 45 ac 0f 88 a8 01 00 00 3b b7 d0 01 00 00 49 89 ff 0f 83 99 01 00 00 48 8b 47 20 48 8b 80 88 00 00 00 48 85 c0 0f 84 cd 01 00 00 <41> 8b b1 5c 02 00 00 41 8b 89 58 02 00 00 89 75 98 41 8b b1 60
    RIP  [] drm_calc_vbltimestamp_from_scanoutpos+0x4b/0x320
     RSP 
    CR2: 000000000000025c
    ---[ end trace ad2c0aadf48e2032 ]---
    Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

It has helped me to add a NULL pointer check that was suggested at
http://lists.freedesktop.org/archives/dri-devel/2014-October/070663.html

I am not familiar with the code. But the change looks sane
and we need something fast at this stage of 3.18 development.

Suggested-by: Helge Deller 
Signed-off-by: Petr Mladek 
Tested-by: Petr Mladek 
Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add missing crtc unlock when setting up the MC

2014-11-21T17:22:53+00:00

commit f0d7bfb9407fccb6499ec01c33afe43512a439a2 upstream.

Need to unlock the crtc after updating the blanking state.

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/bios: memset dcb struct to zero before parsing

2014-11-14T16:47:56+00:00

commit 595d373f1e9c9ce0fc946457fdb488e8a58972cd upstream.

Fixes type/mask calculation being based on uninitialised data for VGA
outputs.

Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

drm/tilcdc: Fix the error path in tilcdc_load()

2014-11-14T16:47:56+00:00

commit b478e336b3e75505707a11e78ef8b964ef0a03af upstream.

The current error path calls tilcdc_unload() in case of an error to release
the resources. However, this is wrong because not all resources have been
allocated by the time an error occurs in tilcdc_load().

To fix it, this commit adds proper labels to bail out at the different
stages in the load function, and release only the resources actually allocated.

Tested-by: Darren Etheridge 
Tested-by: Johannes Pointner 
Signed-off-by: Ezequiel Garcia 
Signed-off-by: Dave Airlie 
Fixes: 3a49012224ca ("drm/tilcdc: panel: fix leak when unloading the module")
Signed-off-by: Matwey V. Kornilov 
Signed-off-by: Greg Kroah-Hartman

drm/ast: Fix HW cursor image

2014-11-14T16:47:56+00:00

commit 1e99cfa8de0f0879091e33cd65fd60418d006ad9 upstream.

The translation from the X driver to the KMS one typo'ed a couple
of array indices, causing the HW cursor to look weird (blocky with
leaking edge colors). This fixes it.

Signed-off-by: Benjamin Herrenschmidt 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/radeon: add connector quirk for fujitsu board

2014-10-05T21:54:08+00:00

commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream.

Vbios connector table lists non-existent VGA port.

Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=83184

Signed-off-by: Alex Deucher 
Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Fix a potential infinite spin waiting for fifo idle

2014-10-05T21:54:08+00:00

commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream.

The code waiting for fifo idle was incorrect and could possibly spin
forever under certain circumstances.

Signed-off-by: Thomas Hellstrom 
Reported-by: Mark Sheldon 
Reviewed-by: Jakob Bornecrantz 
Reivewed-by: Mark Sheldon 
Signed-off-by: Greg Kroah-Hartman

drm/ast: AST2000 cannot be detected correctly

2014-10-05T21:54:08+00:00

commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream.

Type error and cause AST2000 cannot be detected correctly

Signed-off-by: Y.C. Chen 
Reviewed-by: Egbert Eich 
Signed-off-by: Dave Airlie 
Signed-off-by: Greg Kroah-Hartman

drm/i915: Wait for vblank before enabling the TV encoder

2014-10-05T21:54:08+00:00

commit 7a98948f3b536ca9a077e84966ddc0e9f53726df upstream.

The vblank waits in intel_tv_detect_type() are timing out for some
reason. This is a regression caused removing seemingly useless vblank
waits from the modeset seqeuence in:

 commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f
 Author: Ville Syrjälä 
 Date:   Thu May 8 19:23:15 2014 +0300

    drm/i915: Kill vblank waits after pipe enable on gmch platforms

So it turns out they weren't all entirely useless. Apparently the pipe
has to go through one full frame before we enable the TV port. Add a
vblank wait to intel_enable_tv() to make sure that happens.

Another approach was attempted by placing the vblank wait just after
enabling the port. The theory behind that attempt was that we need to
let the port stay enabled for one full frame before disabling it again
during load detection. But that didn't work, and we definitely must
have the vblank wait before enabling the port.

Cc: Alan Bartlett 
Tested-by: Alan Bartlett 
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311
Signed-off-by: Ville Syrjälä 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Greg Kroah-Hartman