1. 26 1月, 2012 1 次提交
    • B
      drm/ttm: fix two regressions since move_notify changes · 9f1feed2
      Ben Skeggs 提交于
      Both changes in dc97b340 cause serious
      regressions in the nouveau driver.
      
      move_notify() was originally able to presume that bo->mem is the old node,
      and new_mem is the new node.  The above commit moves the call to
      move_notify() to after move() has been done, which means that now, sometimes,
      new_mem isn't the new node at all, bo->mem is, and new_mem points at a
      stale, possibly-just-been-killed-by-move node.
      
      This is clearly not a good situation.  This patch reverts this change, and
      replaces it with a cleanup in the move() failure path instead.
      
      The second issue is that the call to move_notify() from cleanup_memtype_use()
      causes the TTM ghost objects to get passed into the driver.  This is clearly
      bad as the driver knows nothing about these "fake" TTM BOs, and ends up
      accessing uninitialised memory.
      
      I worked around this in nouveau's move_notify() hook by ensuring the BO
      destructor was nouveau's.  I don't particularly like this solution, and
      would rather TTM never pass the driver these objects.  However, I don't
      clearly understand the reason why we're calling move_notify() here anyway
      and am happy to work around the problem in nouveau instead of breaking the
      behaviour expected by other drivers.
      Signed-off-by: NBen Skeggs <bskeggs@redhat.com>
      Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
      Cc: Jerome Glisse <j.glisse@gmail.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9f1feed2
  2. 25 1月, 2012 11 次提交
    • J
      drm/radeon: avoid deadlock if GPU lockup is detected in ib_pool_get · 9fc04b50
      Jerome Glisse 提交于
      If GPU lockup is detected in ib_pool get we are holding the ib_pool
      mutex that will be needed by the GPU reset code. As ib_pool code is
      safe to be reentrant from GPU reset code we should not block if we
      are trying to get the ib pool lock on the behalf of the same userspace
      caller, thus use the radeon_mutex_lock helper.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9fc04b50
    • J
      drm/radeon: silence out possible lock dependency warning · d54fbd49
      Jerome Glisse 提交于
      Silence out the lock dependency warning by moving bo allocation out
      of ib mutex protected section. Might lead to useless temporary
      allocation but it's not harmful as such things only happen at
      initialization.
      Signed-off-by: NJerome Glisse <jglisse@redhat.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      d54fbd49
    • T
      drm: Fix authentication kernel crash · 598781d7
      Thomas Hellstrom 提交于
      If the master tries to authenticate a client using drm_authmagic and
      that client has already closed its drm file descriptor,
      either wilfully or because it was terminated, the
      call to drm_authmagic will dereference a stale pointer into kmalloc'ed memory
      and corrupt it.
      
      Typically this results in a hard system hang.
      
      This patch fixes that problem by removing any authentication tokens
      (struct drm_magic_entry) open for a file descriptor when that file
      descriptor is closed.
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      598781d7
    • A
      gma500: Fix shmem mapping · 15b63d35
      Alan Cox 提交于
      GMA500 did it the old way and it's been on the TODO list to fix. Current kernels
      now blow up if we use the old way so we'd better do the work !
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      15b63d35
    • A
      drm/radeon/kms: refine TMDS dual link checks · 9aa59993
      Alex Deucher 提交于
      HDMI 1.3 defines single link clocks up to 340 Mhz.
      Refine the current dual link checks to only enable
      dual link for DVI > 165 Mhz or HDMI > 340 Mhz if the
      hw supports HDMI 1.3 (DCE3+).
      
      Fixes:
      https://bugs.freedesktop.org/show_bug.cgi?id=44755Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      9aa59993
    • A
      drm/radeon/kms: use drm_detect_hdmi_monitor for picking encoder mode · 27d9cc84
      Alex Deucher 提交于
      We were previously just checking for audio.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      27d9cc84
    • A
      drm/radeon/kms: rework modeset sequence for DCE41 and DCE5 · 3a47824d
      Alex Deucher 提交于
      dig transmitter control table only has ENABLE/DISABLE actions
      on DCE4.1/DCE5.
      
      Fixes:
      https://bugs.freedesktop.org/show_bug.cgi?id=44955Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3a47824d
    • A
      drm/radeon/kms: move panel mode setup into encoder mode set · 386d4d75
      Alex Deucher 提交于
      Needs to happen earlier in the mode set.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      386d4d75
    • A
      drm/radeon/kms: move disp eng pll setup to init path · 3fa47d9e
      Alex Deucher 提交于
      We really only need to set it up once on init or resume
      rather than on every mode set.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      3fa47d9e
    • I
      drm/radeon: finish getting bios earlier · 211fa4fc
      Igor Murzov 提交于
      Return a number of bytes read in radeon_atrm_get_bios_chunk() and
      properly check this value in radeon_atrm_get_bios().
      If radeon_atrm_get_bios_chunk() read less bytes then were requested,
      it means that it finished reading bios data.
      
      Prior to this patch, condition in radeon_atrm_get_bios() was always
      equivalent to "if (ATRM_BIOS_PAGE <= 0)", so it was always false,
      thus radeon_atrm_get_bios() was trying to read past the bios data
      wasting boot time.
      
      On my lenovo ideapad u455 laptop this patch drops bios reading time
      from ~5.5s to ~1.5s.
      Signed-off-by: NIgor Murzov <e-mail@date.by>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      211fa4fc
    • I
      drm/radeon: fix invalid memory access in radeon_atrm_get_bios() · a3f83ab1
      Igor Murzov 提交于
      At a boot time I observed following bug:
      
       BUG: unable to handle kernel paging request at ffff8800a4244000
       IP: [<ffffffff81275b5b>] memcpy+0xb/0x120
       PGD 1816063 PUD 1fe7d067 PMD 1ff9f067 PTE 80000000a4244160
       Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
       CPU 0
       Modules linked in: btusb bluetooth brcmsmac brcmutil crc8 cordic b43 radeon(+)
        mac80211 cfg80211 ttm ohci_hcd drm_kms_helper rfkill drm ssb agpgart mmc_core
        sp5100_tco video battery ac thermal processor rtc_cmos thermal_sys snd_hda_codec_hdmi
        joydev snd_hda_codec_conexant button bcma pcmcia snd_hda_intel snd_hda_codec
        snd_hwdep snd_pcm shpchp pcmcia_core k8temp snd_timer atl1c snd psmouse hwmon
        i2c_piix4 i2c_algo_bit soundcore evdev i2c_core ehci_hcd sg serio_raw snd_page_alloc
        loop btrfs
      
       Pid: 1008, comm: modprobe Not tainted 3.3.0-rc1 #21 LENOVO 20046                           /AMD CRB
       RIP: 0010:[<ffffffff81275b5b>]  [<ffffffff81275b5b>] memcpy+0xb/0x120
       RSP: 0018:ffff8800aa72db00  EFLAGS: 00010246
       RAX: ffff8800a4150000 RBX: 0000000000001000 RCX: 0000000000000087
       RDX: 0000000000000000 RSI: ffff8800a4244000 RDI: ffff8800a4150bc8
       RBP: ffff8800aa72db78 R08: 0000000000000010 R09: ffffffff8174bbec
       R10: ffffffff812ee010 R11: 0000000000000001 R12: 0000000000001000
       R13: 0000000000010000 R14: ffff8800a4140000 R15: ffff8800aaba1800
       FS:  00007ff9a3bd4720(0000) GS:ffff8800afa00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffff8800a4244000 CR3: 00000000a9c18000 CR4: 00000000000006f0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
       Process modprobe (pid: 1008, threadinfo ffff8800aa72c000, task ffff8800aa0e4000)
       Stack:
        ffffffffa04e7c7b 0000000000000001 0000000000010000 ffff8800aa72db28
        ffffffff00000001 0000000000001000 ffffffff8113cbef 0000000000000020
        ffff8800a4243420 ffff880000000002 ffff8800aa72db08 ffff8800a9d42000
       Call Trace:
        [<ffffffffa04e7c7b>] ? radeon_atrm_get_bios_chunk+0x8b/0xd0 [radeon]
        [<ffffffff8113cbef>] ? kmalloc_order_trace+0x3f/0xb0
        [<ffffffffa04a9298>] radeon_get_bios+0x68/0x2f0 [radeon]
        [<ffffffffa04c7a30>] rv770_init+0x40/0x280 [radeon]
        [<ffffffffa047d740>] radeon_device_init+0x560/0x600 [radeon]
        [<ffffffffa047ef4f>] radeon_driver_load_kms+0xaf/0x170 [radeon]
        [<ffffffffa043cdde>] drm_get_pci_dev+0x18e/0x2c0 [drm]
        [<ffffffffa04e7e95>] radeon_pci_probe+0xad/0xb5 [radeon]
        [<ffffffff81296c5f>] local_pci_probe+0x5f/0xd0
        [<ffffffff81297418>] pci_device_probe+0x88/0xb0
        [<ffffffff813417aa>] ? driver_sysfs_add+0x7a/0xb0
        [<ffffffff813418d8>] really_probe+0x68/0x180
        [<ffffffff81341be5>] driver_probe_device+0x45/0x70
        [<ffffffff81341cb3>] __driver_attach+0xa3/0xb0
        [<ffffffff81341c10>] ? driver_probe_device+0x70/0x70
        [<ffffffff813400ce>] bus_for_each_dev+0x5e/0x90
        [<ffffffff8134172e>] driver_attach+0x1e/0x20
        [<ffffffff81341298>] bus_add_driver+0xc8/0x280
        [<ffffffff813422c6>] driver_register+0x76/0x140
        [<ffffffff812976d6>] __pci_register_driver+0x66/0xe0
        [<ffffffffa043d021>] drm_pci_init+0x111/0x120 [drm]
        [<ffffffff8133c67a>] ? vga_switcheroo_register_handler+0x3a/0x60
        [<ffffffffa0229000>] ? 0xffffffffa0228fff
        [<ffffffffa02290ec>] radeon_init+0xec/0xee [radeon]
        [<ffffffff810002f2>] do_one_initcall+0x42/0x180
        [<ffffffff8109d8d2>] sys_init_module+0x92/0x1e0
        [<ffffffff815407a9>] system_call_fastpath+0x16/0x1b
       Code: 58 2a 43 50 88 43 4e 48 83 c4 08 5b c9 c3 66 90 e8 cb fd ff ff eb
        e6 90 90 90 90 90 90 90 90 90 48 89 f8 89 d1 c1 e9 03 83 e2 07 <f3> 48
        a5 89 d1 f3 a4 c3 20 48 83 ea 20 4c 8b 06 4c 8b 4e 08 4c
       RIP  [<ffffffff81275b5b>] memcpy+0xb/0x120
        RSP <ffff8800aa72db00>
       CR2: ffff8800a4244000
       ---[ end trace fcffa1599cf56382 ]---
      
      Call to acpi_evaluate_object() not always returns 4096 bytes chunks,
      on my system it can return 2048 bytes chunk, so pass the length of
      retrieved chunk to memcpy(), not the length of the recieving buffer.
      Signed-off-by: NIgor Murzov <e-mail@date.by>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      a3f83ab1
  3. 23 1月, 2012 3 次提交
  4. 20 1月, 2012 10 次提交
  5. 19 1月, 2012 15 次提交