1. 18 7月, 2013 6 次提交
  2. 15 7月, 2013 3 次提交
    • 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
    • A
      drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level · 13f69c2c
      Alex Deucher 提交于
      Need to properly enable/disable boost states when forcing a performance
      level.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      13f69c2c
    • A
      drm/radeon: align VM PTBs (Page Table Blocks) to 32K · 1c01103c
      Alex Deucher 提交于
      Covers requirements of all current asics.
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      1c01103c
  3. 14 7月, 2013 13 次提交
  4. 11 7月, 2013 1 次提交
  5. 10 7月, 2013 4 次提交
    • C
      Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs" · 46a0b638
      Chris Wilson 提交于
      This reverts commit 25ff1195 and the follow on for Valleyview commit 2dc8aae0.
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      commit 2dc8aae0
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Wed May 22 17:08:06 2013 +0100
      
          drm/i915: Workaround incoherence with fence updates on Valleyview
      
      Jon Bloomfield came up with a plausible explanation and cheap fix
      (drm/i915: Fix incoherence with fence updates on Sandybridge+) for the
      race condition, so lets run with it.
      
      This is a candidate for stable as the old workaround incurs a
      significant cost (calling wbinvd on all CPUs before performing the
      register write) for some workloads as noted by Carsten Emde.
      
      Link: http://lists.freedesktop.org/archives/intel-gfx/2013-June/028819.html
      References: https://www.osadl.org/?id=1543#c7602
      References: https://bugs.freedesktop.org/show_bug.cgi?id=63825Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Jon Bloomfield <jon.bloomfield@intel.com>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      46a0b638
    • C
      drm/i915: Fix incoherence with fence updates on Sandybridge+ · d18b9619
      Chris Wilson 提交于
      This hopefully fixes the root cause behind the workaround added in
      
      commit 25ff1195
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Thu Apr 4 21:31:03 2013 +0100
      
          drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
      
      Thanks to further investigation by Jon Bloomfield, he realised that
      the 64-bit register might be broken up by the hardware into two 32-bit
      writes (a problem we have encountered elsewhere). This non-atomicity
      would then cause an issue where a second thread would see an
      intermediate register state (new high dword, old low dword), and this
      register would randomly be used in preference to its own thread register.
      This would cause the second thread to read from and write into a fairly
      random tiled location.  Breaking the operation into 3 explicit 32-bit
      updates (first disable the fence, poke the upper bits, then poke the lower
      bits and enable) ensures that, given proper serialisation between the
      32-bit register write and the memory transfer, that the fence value is
      always consistent.
      
      Armed with this knowledge, we can explain how the previous workaround
      work. The key to the corruption is that a second thread sees an
      erroneous fence register that conflicts and overrides its own. By
      serialising the fence update across all CPUs, we have a small window
      where no GTT access is occurring and so hide the potential corruption.
      This also leads to the conclusion that the earlier workaround was
      incomplete.
      
      v2: Be overly paranoid about the order in which fence updates become
      visible to the GPU to make really sure that we turn the fence off before
      doing the update, and then only switch the fence on afterwards.
      Signed-off-by: NJon Bloomfield <jon.bloomfield@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Carsten Emde <C.Emde@osadl.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d18b9619
    • C
      drm/i915: Fix write-read race with multiple rings · 02978ff5
      Chris Wilson 提交于
      Daniel noticed a problem where is we wrote to an object with ring A in
      the middle of a very long running batch, then executed a quick batch on
      ring B before a batch that reads from the same object, its obj->ring would
      now point to ring B, but its last_write_seqno would be still relative to
      ring A. This would allow for the user to read from the object before the
      GPU had completed the write, as set_domain would only check that ring B
      had passed the last_write_seqno.
      
      To fix this simply (and inelegantly), we bump the last_write_seqno when
      switching rings so that the last_write_seqno is always relative to the
      current obj->ring.
      
      This fixes igt/tests/gem_write_read_ring_switch.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: stable@vger.kernel.org
      [danvet: Add note about the newly created igt which exercises this
      bug.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      02978ff5
    • G
      Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" · c11e5f35
      Guenter Roeck 提交于
      This patch partially reverts commit 36ec8f87 for
      IvyBridge CPUs.
      
      The original commit results in repeated 'Timed out waiting for forcewake old
      ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
      with i7-3770K CPU. It ultimately results in a hangup if the system is highly
      loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
      
      Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
      this condition can result in secondary issues.
      
      v2: Only revert patch for Ivybridge CPUs
          Issue info message if mt forcewake is disabled on Ivybridge
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
      Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Cc: stable@vger.kernel.org
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c11e5f35
  6. 09 7月, 2013 13 次提交