1. 01 4月, 2016 1 次提交
  2. 05 12月, 2015 1 次提交
    • L
      drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interrupt · cb5d4166
      Lyude 提交于
      HPD signals on DVI ports can be fired off before the pins required for
      DDC probing actually make contact, due to the pins for HPD making
      contact first. This results in a HPD signal being asserted but DDC
      probing failing, resulting in hotplugging occasionally failing.
      
      This is somewhat rare on most cards (depending on what angle you plug
      the DVI connector in), but on some cards it happens constantly. The
      Radeon R5 on the machine used for testing this patch for instance, runs
      into this issue just about every time I try to hotplug a DVI monitor and
      as a result hotplugging almost never works.
      
      Rescheduling the hotplug work for a second when we run into an HPD
      signal with a failing DDC probe usually gives enough time for the rest
      of the connector's pins to make contact, and fixes this issue.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NLyude <cpaul@redhat.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      cb5d4166
  3. 21 8月, 2015 1 次提交
    • D
      drm/radeon: fix hotplug race at startup · 7f98ca45
      Dave Airlie 提交于
      We apparantly get a hotplug irq before we've initialised
      modesetting,
      
      [drm] Loading R100 Microcode
      BUG: unable to handle kernel NULL pointer dereference at   (null)
      IP: [<c125f56f>] __mutex_lock_slowpath+0x23/0x91
      *pde = 00000000
      Oops: 0002 [#1]
      Modules linked in: radeon(+) drm_kms_helper ttm drm i2c_algo_bit backlight pcspkr psmouse evdev sr_mod input_leds led_class cdrom sg parport_pc parport floppy intel_agp intel_gtt lpc_ich acpi_cpufreq processor button mfd_core agpgart uhci_hcd ehci_hcd rng_core snd_intel8x0 snd_ac97_codec ac97_bus snd_pcm usbcore usb_common i2c_i801 i2c_core snd_timer snd soundcore thermal_sys
      CPU: 0 PID: 15 Comm: kworker/0:1 Not tainted 4.2.0-rc7-00015-gbf674028 #111
      Hardware name: MicroLink                               /D850MV                         , BIOS MV85010A.86A.0067.P24.0304081124 04/08/2003
      Workqueue: events radeon_hotplug_work_func [radeon]
      task: f6ca5900 ti: f6d3e000 task.ti: f6d3e000
      EIP: 0060:[<c125f56f>] EFLAGS: 00010282 CPU: 0
      EIP is at __mutex_lock_slowpath+0x23/0x91
      EAX: 00000000 EBX: f5e900fc ECX: 00000000 EDX: fffffffe
      ESI: f6ca5900 EDI: f5e90100 EBP: f5e90000 ESP: f6d3ff0c
       DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068
      CR0: 8005003b CR2: 00000000 CR3: 36f61000 CR4: 000006d0
      Stack:
       f5e90100 00000000 c103c4c1 f6d2a5a0 f5e900fc f6df394c c125f162 f8b0faca
       f6d2a5a0 c138ca00 f6df394c f7395600 c1034741 00d40000 00000000 f6d2a5a0
       c138ca00 f6d2a5b8 c138ca10 c1034b58 00000001 f6d40000 f6ca5900 f6d0c940
      Call Trace:
       [<c103c4c1>] ? dequeue_task_fair+0xa4/0xb7
       [<c125f162>] ? mutex_lock+0x9/0xa
       [<f8b0faca>] ? radeon_hotplug_work_func+0x17/0x57 [radeon]
       [<c1034741>] ? process_one_work+0xfc/0x194
       [<c1034b58>] ? worker_thread+0x18d/0x218
       [<c10349cb>] ? rescuer_thread+0x1d5/0x1d5
       [<c103742a>] ? kthread+0x7b/0x80
       [<c12601c0>] ? ret_from_kernel_thread+0x20/0x30
       [<c10373af>] ? init_completion+0x18/0x18
      Code: 42 08 e8 8e a6 dd ff c3 57 56 53 83 ec 0c 8b 35 48 f7 37 c1 8b 10 4a 74 1a 89 c3 8d 78 04 8b 40 08 89 63
      Reported-and-Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      7f98ca45
  4. 28 5月, 2015 1 次提交
  5. 26 5月, 2015 1 次提交
  6. 20 3月, 2015 2 次提交
  7. 24 11月, 2014 1 次提交
    • B
      gpu/radeon: Set flag to indicate broken 64-bit MSI · 91ed6fd2
      Benjamin Herrenschmidt 提交于
      Some radeon ASICs don't support all 64 address bits of MSIs despite
      advertising support for 64-bit MSIs in their configuration space.
      
      This breaks on systems such as IBM POWER7/8, where 64-bit MSIs can
      be assigned with some of the high address bits set.
      
      This makes use of the newly introduced "no_64bit_msi" flag in structure
      pci_dev to allow the MSI allocation code to fallback to 32-bit MSIs
      on those adapters.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
      CC: <stable@vger.kernel.org>
      ---
      
      Adding Alex's review tag. Patch to the driver is identical to the
      reviewed one, I dropped the arch/powerpc hunk rewrote the subject
      and cset comment.
      91ed6fd2
  8. 01 9月, 2014 1 次提交
    • M
      drm/radeon: use common fence implementation for fences, v4 · 954605ca
      Maarten Lankhorst 提交于
      Changes since v1:
      - Kill the sw interrupt dance, add and use
        radeon_irq_kms_sw_irq_get_delayed instead.
      - Change custom wait function, lockdep complained about it.
        Holding exclusive_lock in the wait function might cause deadlocks.
        Instead do all the processing in .enable_signaling, and wait
        on the global fence_queue to pick up gpu resets.
      - Process all fences in radeon_gpu_reset after reset to close a race
        with the trylock in enable_signaling.
      Changes since v2:
      - Small changes to work with the rewritten lockup recovery patches.
      Changes since v3:
      - Call radeon_fence_schedule_check when exclusive_lock cannot be
        acquired to always cause a wake up.
      - Reset irqs from hangup check.
      - Drop reading seqno in the callback, use cached value.
      - Fix indentation in radeon_fence_default_wait
      - Add a radeon_test_signaled function, drop a few test_bit calls.
      - Make to_radeon_fence global.
      Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      954605ca
  9. 28 8月, 2014 1 次提交
  10. 23 4月, 2014 1 次提交
  11. 18 12月, 2013 1 次提交
  12. 02 11月, 2013 1 次提交
  13. 31 8月, 2013 1 次提交
    • S
      radeon kms: fix uninitialised hotplug work usage in r100_irq_process() · 27c505ca
      Sergey Senozhatsky 提交于
      Commit a01c34f7 (radeon kms: do not
      flush uninitialized hotplug work) moved work initialisation phase to
      the last step of radeon_irq_kms_init(). Meelis Roos reported that this
      causes problems on his machine because drm_irq_install() uses hotplug
      work on r100.
      
      hotplug work flushed in radeon_irq_kms_fini(), with two possible cases:
      -- radeon_irq_kms_fini() call after successful radeon_irq_kms_init()
      -- radeon_irq_kms_fini() call after unsuccessful (or not called at all)
         radeon_irq_kms_init()
      
      The latter one causes flush work on uninitialised hotplug work. Move
      work initialisation before drm_irq_install(), but keep existing agreement
      to flush hotplug work in radeon_irq_kms_fini() only for `irq.installed'
      (successful radeon_irq_kms_init()) case.
      
      WARNING: CPU: 0 PID: 243 at kernel/workqueue.c:1378 __queue_work+0x132/0x16d()
      Call Trace:
      [<c12319b3>] ? dump_stack+0xa/0x13
      [<c1022600>] ? warn_slowpath_common+0x75/0x8a
      [<c1031010>] ? __queue_work+0x132/0x16d
      [<c1031010>] ? __queue_work+0x132/0x16d
      [<c102269e>] ? warn_slowpath_null+0x1b/0x1f
      [<c1031010>] ? __queue_work+0x132/0x16d
      [<c103107b>] ? queue_work_on+0x30/0x40
      [<f8aed3f3>] ? r100_irq_process+0x16d/0x1e6 [radeon]
      [<f8ae77cf>] ? radeon_driver_irq_preinstall_kms+0xc2/0xc5 [radeon]
      [<f8974d77>] ? drm_irq_install+0xb2/0x1ac [drm]
      [<f897604d>] ? drm_vblank_init+0x196/0x1d2 [drm]
      [<f8ae78d3>] ? radeon_irq_kms_init+0x33/0xc6 [radeon]
      [<f8aef35a>] ? r100_startup+0x1a3/0x1d6 [radeon]
      [<f8ad77c8>] ? radeon_ttm_init+0x26e/0x287 [radeon]
      [<f8aef752>] ? r100_init+0x2b3/0x309 [radeon]
      [<c118082e>] ? vga_client_register+0x39/0x40
      [<f8ac535f>] ? radeon_device_init+0x54b/0x61b [radeon]
      [<f8ac40fd>] ? cail_mc_write+0x13/0x13 [radeon]
      [<f8ac6864>] ? radeon_driver_load_kms+0x82/0xda [radeon]
      [<f8978bbd>] ? drm_get_pci_dev+0x136/0x22d [drm]
      [<f8ac409b>] ? radeon_pci_probe+0x6c/0x86 [radeon]
      [<c112acf6>] ? pci_device_probe+0x4c/0x83
      [<c11846c7>] ? driver_probe_device+0x80/0x184
      [<c112a848>] ? pci_match_id+0x18/0x36
      [<c1184837>] ? __driver_attach+0x44/0x5f
      [<c11833f4>] ? bus_for_each_dev+0x50/0x5a
      [<c118433e>] ? driver_attach+0x14/0x16
      [<c11847f3>] ? __device_attach+0x28/0x28
      [<c1184045>] ? bus_add_driver+0xd6/0x1bf
      [<c1184c22>] ? driver_register+0x78/0xcf
      [<f8ba8000>] ? 0xf8ba7fff
      [<c10003bf>] ? do_one_initcall+0x8b/0x121
      [<c101e668>] ? change_page_attr_clear+0x2e/0x33
      [<f8ba8000>] ? 0xf8ba7fff
      [<c101e689>] ? set_memory_ro+0x1c/0x20
      [<c104de94>] ? set_page_attributes+0x11/0x12
      [<c104f6e1>] ? load_module+0x12fa/0x17e8
      [<c107483b>] ? map_vm_area+0x22/0x31
      [<c104fc36>] ? SyS_init_module+0x67/0x7d
      [<c1234245>] ? sysenter_do_call+0x12/0x26
      Reported-by: NMeelis Roos <mroos@linux.ee>
      Tested-by: NMeelis Roos <mroos@linux.ee>
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      27c505ca
  14. 15 7月, 2013 1 次提交
    • S
      radeon kms: do not flush uninitialized hotplug work · a01c34f7
      Sergey Senozhatsky 提交于
      Fix a warning from lockdep caused by calling flush_work() for
      uninitialized hotplug work. Initialize hotplug_work, audio_work
      and reset_work upon successful radeon_irq_kms_init() completion
      and thus perform hotplug flush_work only when rdev->irq.installed
      is true.
      
      [    4.790019] [drm] Loading CEDAR Microcode
      [    4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
      [    4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
      [    4.791330] radeon 0000:01:00.0: disabling GPU acceleration
      
      [    4.792633] INFO: trying to register non-static key.
      [    4.792792] the code is fine but needs lockdep annotation.
      [    4.792953] turning off the locking correctness validator.
      
      [    4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
      [    4.793314] Hardware name: Acer             Aspire 5741G    /Aspire 5741G    , BIOS V1.20 02/08/2011
      [    4.793507]  ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
      [    4.794155]  ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
      [    4.794789]  ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
      [    4.795418] Call Trace:
      [    4.795573]  [<ffffffff8160434e>] dump_stack+0x4e/0x82
      [    4.795731]  [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
      [    4.795893]  [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
      [    4.796034]  [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
      [    4.796216]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
      [    4.796375]  [<ffffffff8106cdad>] flush_work+0x3d/0x280
      [    4.796520]  [<ffffffff8106cd75>] ? flush_work+0x5/0x280
      [    4.796682]  [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
      [    4.796862]  [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
      [    4.797024]  [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
      [    4.797186]  [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
      [    4.797347]  [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
      [    4.797511]  [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
      [    4.797672]  [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
      [    4.797843]  [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
      [    4.798007]  [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
      [    4.798168]  [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
      [    4.798329]  [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
      [    4.798489]  [<ffffffff81339404>] pci_device_probe+0x84/0xe0
      [    4.798644]  [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
      [    4.798805]  [<ffffffff814aca73>] __driver_attach+0x93/0xa0
      [    4.798948]  [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
      [    4.799126]  [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
      [    4.799272]  [<ffffffff814ac2be>] driver_attach+0x1e/0x20
      [    4.799434]  [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
      [    4.799596]  [<ffffffff814ad0e4>] driver_register+0x74/0x150
      [    4.799758]  [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
      [    4.799936]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
      [    4.800081]  [<ffffffff813ce655>] drm_pci_init+0x115/0x130
      [    4.800243]  [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
      [    4.800405]  [<ffffffff81d16f98>] radeon_init+0x9c/0xba
      [    4.800586]  [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
      [    4.800746]  [<ffffffff81073f60>] ? parse_args+0x120/0x330
      [    4.800909]  [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
      [    4.801052]  [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
      [    4.801233]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
      [    4.801393]  [<ffffffff815fb67e>] kernel_init+0xe/0x180
      [    4.801556]  [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
      [    4.801718]  [<ffffffff815fb670>] ? rest_init+0x140/0x140
      Signed-off-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      a01c34f7
  15. 27 6月, 2013 1 次提交
  16. 26 6月, 2013 1 次提交
    • A
      drm/radeon: add a reset work handler · 8f61b34c
      Alex Deucher 提交于
      New asics support non-privileged IBs.  This allows us
      to skip IB checking in the driver since the hardware
      will check the command buffers for us.  When using
      non-privileged IBs, if the CP encounters an illegal
      register in the command stream, it will halt and generate
      an interrupt.  The CP needs to be reset to continue.  For now
      just do a full GPU reset when this happens.
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      8f61b34c
  17. 18 3月, 2013 1 次提交
  18. 08 3月, 2013 1 次提交
  19. 03 10月, 2012 1 次提交
  20. 27 9月, 2012 2 次提交
  21. 21 9月, 2012 1 次提交
  22. 21 8月, 2012 1 次提交
    • T
      workqueue: deprecate flush[_delayed]_work_sync() · 43829731
      Tejun Heo 提交于
      flush[_delayed]_work_sync() are now spurious.  Mark them deprecated
      and convert all users to flush[_delayed]_work().
      
      If you're cc'd and wondering what's going on: Now all workqueues are
      non-reentrant and the regular flushes guarantee that the work item is
      not pending or running on any CPU on return, so there's no reason to
      use the sync flushes at all and they're going away.
      
      This patch doesn't make any functional difference.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: Ian Campbell <ian.campbell@citrix.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Mattia Dongili <malattia@linux.it>
      Cc: Kent Yoder <key@linux.vnet.ibm.com>
      Cc: David Airlie <airlied@linux.ie>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Karsten Keil <isdn@linux-pingi.de>
      Cc: Bryan Wu <bryan.wu@canonical.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Alasdair Kergon <agk@redhat.com>
      Cc: Mauro Carvalho Chehab <mchehab@infradead.org>
      Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
      Cc: David Woodhouse <dwmw2@infradead.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: linux-wireless@vger.kernel.org
      Cc: Anton Vorontsov <cbou@mail.ru>
      Cc: Sangbeom Kim <sbkim73@samsung.com>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Eric Van Hensbergen <ericvh@gmail.com>
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Steven Whitehouse <swhiteho@redhat.com>
      Cc: Petr Vandrovec <petr@vandrovec.name>
      Cc: Mark Fasheh <mfasheh@suse.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Avi Kivity <avi@redhat.com> 
      43829731
  23. 18 7月, 2012 1 次提交
  24. 21 6月, 2012 2 次提交
  25. 24 4月, 2012 1 次提交
  26. 16 4月, 2012 1 次提交
  27. 23 1月, 2012 1 次提交
  28. 21 12月, 2011 1 次提交
  29. 04 11月, 2011 4 次提交
  30. 02 11月, 2011 1 次提交
  31. 24 1月, 2011 1 次提交
  32. 06 1月, 2011 1 次提交
    • T
      drm/radeon: use system_wq instead of dev_priv->wq · 32c87fca
      Tejun Heo 提交于
      With cmwq, there's no reason for radeon to use a dedicated workqueue.
      Drop dev_priv->wq and use system_wq instead.
      
      Because radeon_driver_irq_uninstall_kms() may be called from
      unsleepable context, the work items can't be flushed from there.
      Instead, init and flush from radeon_irq_kms_init/fini().
      
      While at it, simplify canceling/flushing of rdev->pm.dynpm_idle_work.
      Always initialize and sync cancel instead of being unnecessarily smart
      about it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NAlex Deucher <alexdeucher@gmail.com>
      Cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      32c87fca
  33. 23 11月, 2010 1 次提交
  34. 22 11月, 2010 1 次提交