summaryrefslogtreecommitdiffstats
path: root/drivers
Commit message (Collapse)AuthorAgeFilesLines
* md: allow a partially recovered device to be hot-added to an array.NeilBrown2014-01-141-1/+2
| | | | | | | | | | | | | | | | When adding a new device into an array it is normally important to clear any stale data from ->recovery_offset else the new device may not be recovered properly. However when re-adding a device which is known to be nearly in-sync, this is not needed and can be detrimental. The (bitmap-based) resync will still happen, and further recovery is only needed from where-ever it was already up to. So if save_raid_disk is set, signifying a re-add, don't clear ->recovery_offset. Signed-off-by: NeilBrown <neilb@suse.de>
* md: Change handling of save_raid_disk and metadata update during recovery.NeilBrown2014-01-141-19/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit d70ed2e4fafdbef0800e739 MD: Allow restarting an interrupted incremental recovery. we don't write out the metadata to devices while they are recovering. This had a good reason, but has unfortunate consequences. This patch changes things to make them work better. At issue is what happens if the array is shut down while a recovery is happening, particularly a bitmap-guided recovery. Ideally the recovery should pick up where it left off. However the metadata cannot represent the state "A recovery is in process which is guided by the bitmap". Before the above mentioned commit, we wrote metadata to the device which said "this is being recovered and it is up to <here>". So after a restart, a full recovery (not bitmap-guided) would happen from where-ever it was up to. After the commit the metadata wasn't updated so it still said "This device is fully in sync with <this> event count". That leads to a bitmap-based recovery following the whole bitmap, which should be a lot less work than a full recovery from some starting point. So this was an improvement. However updates some metadata but not all leads to other problems. In particular, the metadata written to the fully-up-to-date device record that the array has all devices present (even though some are recovering). So on restart, mdadm wants to find all devices and expects them to have current event counts. Obviously it doesn't (some have old event counts) so (when assembling with --incremental) it waits indefinitely for the rest of the expected devices. It really is wrong to not update all the metadata together. Do that is bound to cause confusion. Instead, we should make it possible to record the truth in the metadata. i.e. we need to be able to record that a device is being recovered based on the bitmap. We already have a Feature flag to say that recovery is happening. We now add another one to say that it is a bitmap-based recovery. With this we can remove the code that disables the write-out of metadata on some devices. So this patch: - moves the setting of 'saved_raid_disk' from add_new_disk to the validate_super methods. This makes sure it is always set properly, both when adding a new device to an array, and when assembling an array from a collection of devices. - Adds a metadata flag MD_FEATURE_RECOVERY_BITMAP which is only used if MD_FEATURE_RECOVERY_OFFSET is set, and record that a bitmap-based recovery is allowed. This is only present in v1.x metadata. v0.90 doesn't support devices which are in the middle of recovery at all. - Only skips writing metadata to Faulty devices. - Also allows rdev state to be set to "-insync" via sysfs. This can be used for external-metadata arrays. When the 'role' is set the device is assumed to be in-sync. If, after setting the role, we set the state to "-insync", the role is moved to saved_raid_disk which effectively says the device is partly in-sync with that slot and needs a bitmap recovery. Cc: Andrei Warkentin <andreiw@vmware.com> Signed-off-by: NeilBrown <neilb@suse.de>
* md: fix problem when adding device to read-only array with bitmap.NeilBrown2014-01-142-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If an array is started degraded, and then the missing device is found it can be re-added and a minimal bitmap-based recovery will bring it fully up-to-date. If the array is read-only a recovery would not be allowed. But also if the array is read-only and the missing device was present very recently, then there could be no need for any recovery at all, so we simply include the device in the read-only array without any recovery. However... if the missing device was removed a little longer ago it could be missing some updates, but if a bitmap is present it will be conditionally accepted pending a bitmap-based update. We don't currently detect this case properly and will include that old device into the read-only array with no recovery even though it really needs a recovery. This patch keeps track of whether a bitmap-based-recovery is really needed or not in the new Bitmap_sync rdev flag. If that is set, then the device will not be added to a read-only array. Cc: Andrei Warkentin <andreiw@vmware.com> Fixes: d70ed2e4fafdbef0800e73942482bb075c21578b Cc: stable@vger.kernel.org (3.2+) Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid10: fix bug when raid10 recovery fails to recover a block.NeilBrown2014-01-141-4/+4
| | | | | | | | | | | | | | | | | | | commit e875ecea266a543e643b19e44cf472f1412708f9 md/raid10 record bad blocks as needed during recovery. added code to the "cannot recover this block" path to record a bad block rather than fail the whole recovery. Unfortunately this new case was placed *after* r10bio was freed rather than *before*, yet it still uses r10bio. This is will crash with a null dereference. So move the freeing of r10bio down where it is safe. Cc: stable@vger.kernel.org (v3.1+) Fixes: e875ecea266a543e643b19e44cf472f1412708f9 Reported-by: Damian Nowak <spam@nowaker.net> URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181 Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid5: fix a recently broken BUG_ON().NeilBrown2014-01-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | commit 6d183de4077191d1201283a9035ce57a9b05254d md/raid5: fix newly-broken locking in get_active_stripe. simplified a BUG_ON, but removed too much so now it sometimes fires when it shouldn't. When the STRIPE_EXPANDING flag is set, the stripe_head might be on a special list while multiple stripe_heads are collected, or it might not be on any list, even a 'free' list when the refcount is zero. As long as STRIPE_EXPANDING is set, it will be found and added back to a list eventually. So both of the BUG_ONs which test for the ->lru being empty or not need to avoid the case where STRIPE_EXPANDING is set. The patch which broke this was marked for -stable, so this patch needs to be applied to any branch that received 6d183de4 Fixes: 6d183de4077191d1201283a9035ce57a9b05254d Cc: stable@vger.kernel.org (any release to which above was applied) Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid1: fix request counting bug in new 'barrier' code.NeilBrown2014-01-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The new iobarrier implementation in raid1 (which keeps normal writes and resync activity separate) counts every request what is not before the current resync point in either next_window_requests or current_window_requests. It flags that the request is counted by setting ->start_next_window. allow_barrier follows this model exactly and decrements one of the *_window_requests if and only if ->start_next_window is set. However wait_barrier(), which increments *_window_requests uses a slightly different test for setting -.start_next_window (which is set from the return value of this function). So there is a possibility of the counts getting out of sync, and this leads to the resync hanging. So change wait_barrier() to return a non-zero value in exactly the same cases that it increments *_window_requests. But was introduced in 3.13-rc1. Reported-by: Bruno Wolff III <bruno@wolff.to> URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061 Fixes: 79ef3a8aa1cb1523cc231c9a90a278333c21f761 Cc: majianpeng <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid10: fix two bugs in handling of known-bad-blocks.NeilBrown2014-01-141-2/+2
| | | | | | | | | | | | | | | | | | | If we discover a bad block when reading we split the request and potentially read some of it from a different device. The code path of this has two bugs in RAID10. 1/ we get a spin_lock with _irq, but unlock without _irq!! 2/ The calculation of 'sectors_handled' is wrong, as can be clearly seen by comparison with raid1.c This leads to at least 2 warnings and a probable crash is a RAID10 ever had known bad blocks. Cc: stable@vger.kernel.org (v3.1+) Fixes: 856e08e23762dfb92ffc68fd0a8d228f9e152160 Reported-by: Damian Nowak <spam@nowaker.net> URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181 Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid5: Fix possible confusion when multiple write errors occur.NeilBrown2014-01-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | commit 5d8c71f9e5fbdd95650be00294d238e27a363b5c md: raid5 crash during degradation Fixed a crash in an overly simplistic way which could leave R5_WriteError or R5_MadeGood set in the stripe cache for devices for which it is no longer relevant. When those devices are removed and spares added the flags are still set and can cause incorrect behaviour. commit 14a75d3e07c784c004b4b44b34af996b8e4ac453 md/raid5: preferentially read from replacement device if possible. Fixed the same bug if a more effective way, so we can now revert the original commit. Reported-and-tested-by: Alexander Lyakas <alex.bolshoy@gmail.com> Cc: stable@vger.kernel.org (3.2+ - 3.2 will need a different fix though) Fixes: 5d8c71f9e5fbdd95650be00294d238e27a363b5c Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid5: fix newly-broken locking in get_active_stripe.NeilBrown2013-11-281-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 566c09c53455d7c4f1 raid5: relieve lock contention in get_active_stripe() modified the locking in get_active_stripe() reducing the range protected by the (highly contended) device_lock. Unfortunately it reduced the range too much opening up some races. One race can occur if get_priority_stripe runs between the test on sh->count and device_lock being taken. This will mean that sh->lru is not empty while get_active_stripe thinks ->count is zero resulting in a 'BUG' firing. Another race happens if __release_stripe is called immediately after sh->count is tested and found to be non-zero. If STRIPE_HANDLE is not set, get_active_stripe should increment ->active_stripes when it increments ->count from 0, but as it didn't think it was 0, it doesn't. Extending device_lock to cover the test on sh->count close these races. While we are here, fix the two BUG tests: -If count is zero, then lru really must not be empty, or we've lock the stripe_head somehow - no other tests are relevant. -STRIPE_ON_RELEASE_LIST is completely independent of ->lru so testing it is pointless. Reported-and-tested-by: Brassow Jonathan <jbrassow@redhat.com> Reviewed-by: Shaohua Li <shli@kernel.org> Fixes: 566c09c53455d7c4f1 Signed-off-by: NeilBrown <neilb@suse.de>
* md: test mddev->flags more safely in md_check_recovery.NeilBrown2013-11-281-1/+1
| | | | | | | | | | | | | | | | | | commit 7a0a5355cbc71efa md: Don't test all of mddev->flags at once. made most tests on mddev->flags safer, but missed one. When commit 260fa034ef7a4ff8b7306 md: avoid deadlock when dirty buffers during md_stop. added MD_STILL_CLOSED, this caused md_check_recovery to misbehave. It can think there is something to do but find nothing. This can lead to the md thread spinning during array shutdown. https://bugzilla.kernel.org/show_bug.cgi?id=65721 Reported-and-tested-by: Richard W.M. Jones <rjones@redhat.com> Fixes: 260fa034ef7a4ff8b7306 Cc: stable@vger.kernel.org (3.12) Signed-off-by: NeilBrown <neilb@suse.de>
* md/raid5: fix new memory-reference bug in alloc_thread_groups.NeilBrown2013-11-281-1/+1
| | | | | | | | | | | | | | | In alloc_thread_groups, worker_groups is a pointer to an array, not an array of pointers. So worker_groups[i] is wrong. It should be &(*worker_groups)[i] Found-by: coverity Fixes: 60aaf9338545 Reported-by: Ben Hutchings <bhutchings@solarflare.com> Cc: majianpeng <majianpeng@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
* Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2013-11-2249-318/+989
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull DRM fixes from Dave Airlie: "I was going to leave this until post -rc1 but sysfs fixes broke hotplug in userspace, so I had to fix it harder, otherwise a set of pulls from intel, radeon and vmware, The vmware/ttm changes are bit larger but since its early and they are unlikely to break anything else I put them in, it lets vmware work with dri3" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (36 commits) drm/sysfs: fix hotplug regression since lifetime changes drm/exynos: g2d: fix memory leak to userptr drm/i915: Fix gen3 self-refresh watermarks drm/ttm: Remove set_need_resched from the ttm fault handler drm/ttm: Don't move non-existing data drm/radeon: hook up backlight functions for CI and KV family. drm/i915: Replicate BIOS eDP bpp clamping hack for hsw drm/i915: Do not enable package C8 on unsupported hardware drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: encoder->get_config is no longer optional drm/i915/tv: add ->get_config callback drm/radeon/cik: Add macrotile mode array query drm/radeon/cik: Return backend map information to userspace drm/vmwgfx: Make vmwgfx dma buffers prime aware drm/vmwgfx: Make surfaces prime-aware drm/vmwgfx: Hook up the prime ioctls drm/ttm: Add a minimal prime implementation for ttm base objects drm/vmwgfx: Fix false lockdep warning drm/ttm: Allow execbuf util reserves without ticket drm/i915: restore the early forcewake cleanup ...
| * drm/sysfs: fix hotplug regression since lifetime changesDavid Herrmann2013-11-211-7/+33
| | | | | | | | | | | | | | | | | | | | | | | | airlied: The lifetime changes introduced in 5bdebb183c9702a8c57a01dff09337be3de337a6 tried to use device_create, however that led to the regression where dev->type wasn't getting set correctly. First attempt at fixing it would have led to a race, so this undoes the device_createa work and does it all manually making sure the dev->type is setup before we register the device. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/exynos: g2d: fix memory leak to userptrInki Dae2013-11-211-0/+2
| | | | | | | | | | | | | | | | | | | | | | This patch releases a vma object when cleaning up userptr resources. A new vma object was allocated and copied when getting userptr pages so the new vma object should be freed properly if the userptr pages aren't used anymore. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie2013-11-213-9/+59
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes The set_need_resched() removal fix and yet another fix in ttm_bo_move_memcpy(). * 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/ttm: Remove set_need_resched from the ttm fault handler drm/ttm: Don't move non-existing data
| | * drm/ttm: Remove set_need_resched from the ttm fault handlerThomas Hellstrom2013-11-202-7/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Addresses "[BUG] completely bonkers use of set_need_resched + VM_FAULT_NOPAGE". In the first occurence it was used to try to be nice while releasing the mmap_sem and retrying the fault to work around a locking inversion. The second occurence was never used. There has been some discussion whether we should change the locking order to mmap_sem -> bo_reserve. This patch doesn't address that issue, and leaves that locking order undefined. The solution that we release the mmap_sem if tryreserve fails and wait for the buffer to become unreserved is something we want in any case, and follows how the core vm system waits for pages to be come unlocked while releasing the mmap_sem. The code also outlines what needs to be changed if we want to establish the locking order as mmap_sem -> bo::reserve. One slight issue that remains with this code is that the fault handler might be prone to starvation if another thread countinously reserves the buffer. IMO that usage pattern is highly unlikely. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
| | * drm/ttm: Don't move non-existing dataThomas Hellstrom2013-11-201-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If ttm_bo_move_memcpy was instructed to move a non-populated ttm to io memory, it would first populate the ttm, then move the data and then destroy the ttm. That's stupid. However, some drivers might have relied on this to clear io memory from old stuff. So instead of a NOP, which would be the most efficient, just clear the destination. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| * | Merge branch 'vmwgfx-fixes-3.13' of ↵Dave Airlie2013-11-218-67/+472
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~thomash/linux into drm-fixes Below is a fix for a false lockep warning, and the vmwgfx prime implementation. * 'vmwgfx-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Make vmwgfx dma buffers prime aware drm/vmwgfx: Make surfaces prime-aware drm/vmwgfx: Hook up the prime ioctls drm/ttm: Add a minimal prime implementation for ttm base objects drm/vmwgfx: Fix false lockdep warning drm/ttm: Allow execbuf util reserves without ticket
| | * | drm/vmwgfx: Make vmwgfx dma buffers prime awareThomas Hellstrom2013-11-181-20/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Should we need to share dma buffers using prime, let's make them prime aware. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Make surfaces prime-awareThomas Hellstrom2013-11-182-15/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add prime exporting and imporing operations to surfaces Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Hook up the prime ioctlsThomas Hellstrom2013-11-184-3/+157
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also provide a completely dumb dma-buf ops implementation. Once we have other virtual dma-buf aware devices, we need to provide something better. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/ttm: Add a minimal prime implementation for ttm base objectsThomas Hellstrom2013-11-181-6/+248
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/vmwgfx: Fix false lockdep warningThomas Hellstrom2013-11-181-10/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A lockdep warning is hit when evicting surfaces and reserving the backup buffer. Since this buffer can only be reserved by the process holding the surface reservation or by the buffer eviction processes that use tryreserve, there is no real deadlock here, but there's no other way to silence lockdep than to use a tryreserve. This means the reservation might fail if the buffer is about to be evicted or swapped out, but we now have code in place to handle that reasonably well. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| | * | drm/ttm: Allow execbuf util reserves without ticketThomas Hellstrom2013-11-181-13/+19
| | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | If no reservation ticket is given to the execbuf reservation utilities, try reservation with non-blocking semantics. This is intended for eviction paths that use the execbuf reservation utilities for convenience rather than for deadlock avoidance. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
| * | Merge tag 'drm-intel-fixes-2013-11-20' of ↵Dave Airlie2013-11-218-22/+79
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just a small pile of fixes for bugs and a few regressions. I'm still trying to track down a driver load hang on my g33 (which infuriatingly doesn't happen when loading the module manually after boot), somehow bisecting loves to go astray on this one :( And there's a (harmless) locking WARN in the suspend code due to one of Jesse's vlv backlight rework patches. Otherwise nothing outstanding afaik. * tag 'drm-intel-fixes-2013-11-20' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Fix gen3 self-refresh watermarks drm/i915: Replicate BIOS eDP bpp clamping hack for hsw drm/i915: Do not enable package C8 on unsupported hardware drm/i915: Hold pc8 lock around toggling pc8.gpu_idle drm/i915: encoder->get_config is no longer optional drm/i915/tv: add ->get_config callback drm/i915: restore the early forcewake cleanup Partially revert "drm/i915: tune the RC6 threshold for stability" drm/i915: flush cursors harder i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7 x86/early quirk: use gen6 stolen detection for VLV drm/i915/dp: set sink to power down mode on dp disable
| | * | drm/i915: Fix gen3 self-refresh watermarksDaniel Vetter2013-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This regression has been introduced in commit 4fe8590a921d0b2e36e542dbfa89a8c5993f5a3f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Wed Sep 4 18:25:22 2013 +0300 drm/i915: Use adjusted_mode appropriately when computing watermarks I guess we should renable the enabled local variable into something a notch more descriptive, but that's something for -next. The effect on my i945gme netbook is pretty severe amounts of underruns - usually the very first pixel gets used for the entire screeen. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Replicate BIOS eDP bpp clamping hack for hswDaniel Vetter2013-11-191-0/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Haswell's DDI encoders have their own ->get_config callback and in commit c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Oct 21 10:52:07 2013 +0300 drm/i915/dp: workaround BIOS eDP bpp clamping issue we've forgotten to replicate this hack. So let's do it that. Note for backporters: The above commit and all it's depencies need to be backported first. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049 Cc: stable@vger.kernel.org Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Do not enable package C8 on unsupported hardwareChris Wilson2013-11-192-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the hardware does not support package C8, then do not even schedule work to enable it. Thereby we can eliminate a bunch of dangerous work. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: Hold pc8 lock around toggling pc8.gpu_idleChris Wilson2013-11-191-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need to hold the pc8 lock around toggling the value of gpu_idle. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: encoder->get_config is no longer optionalDaniel Vetter2013-11-181-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We must have one to fill out the adjusted_mode.crtc_clock. And with the tv encoder fixed up every encoder we have has a ->get_config callback. So we can drop the checks. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/tv: add ->get_config callbackDaniel Vetter2013-11-181-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need this to properly fill in adjusted_mode.crtc_clock, otherwise the state checker gets unhappy. This seems to have been forgotten in the big clock rework in commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: restore the early forcewake cleanupDaniel Vetter2013-11-171-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some BIOS just leak the forcewak bits, which we clean up. Unfortunately this has been broken in commit 521198a2e7095c8c7daa8d7d3a76a110c346be6f Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset To make this work both for resets and for BIOS takeover just add the forcewake clearing call back to intel_uncore_early_sanitize. We need to clear the forcewake in early sanitize so that the forcewak dance in intel_uncore_init (to figure out whether we have mt or legacy forcewake on ivb) works. That cleanup fits in nicely with the general topic of early_sanitize to prepare for the very first mmio ops. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Jörg Otte <jrg.otte@gmail.com> Cc: Jörg Otte <jrg.otte@gmail.com> References: https://lkml.org/lkml/2013/11/16/40 Cc: stable@vger.kernel.org (for 3.12 only) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | Partially revert "drm/i915: tune the RC6 threshold for stability"Daniel Vetter2013-11-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 351aa5666d02062b52329bcfe4bcf9d1f882fba9. It breaks rc6 on at least one snb machine. Since we don't yet have a report for ivb let's keep it there for now. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71656 Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: erik@vontaene.de Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915: flush cursors harderDaniel Vetter2013-11-151-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently they need the same treatment as primary planes. This fixes modesetting failures because of stuck cursors (!) on Thomas' i830M machine. I've figured while at it I'll also roll it out for the ivb 3 pipe version of this function. I didn't do this for i845/i865 since Bspec says the update mechanism works differently, and there's some additional rules about what can be updated in which order. Tested-by: Thomas Richter <thor@math.tu-berlin.de> Cc: stable@vger.kernel.org Cc: Thomas Richter <thor@math.tu-berlin.de> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | i915: Use 120MHz LVDS SSC clock for gen5/gen6/gen7Duncan Laurie2013-11-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had been using a DMI table workaround to select the right frequency for devices, but this is fragile and must be updated with every new platform. Instead the default case when VBT is missing is changed to use 120MHz clock for LVDS SSC for these generations. The docs for 2010-Core, SandyBridge, and IvyBridge all indicate that the reference frequency for LVDS is 120MHz: "2010 Core" http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf page 38 Reference Frequency: 120MHz for CRT and LVDS. 100MHz for the FDI. "2011 SandyBridge" http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf page 33 Reference Frequency: 120MHz for CRT, HDMI, LVDS. 100MHz for the FDI. "2012 IvyBridge" http://intellinuxgraphics.org/documentation/IVB/IHD_OS_Vol3_Part4.pdf page 27 Reference Frequency: 120 MHz for CRT, HDMI, LVDS, 100MHz for the FDI. Signed-off-by: Duncan Laurie <dlaurie@chromium.org> [olof: Fixup for recent base, switched from if/else to single call] Signed-off-by: Olof Johansson <olof@lixom.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | drm/i915/dp: set sink to power down mode on dp disableJani Nikula2013-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to put the local sink and any downstream sinks to power down mode at disable or dpms off using the DPCD SET_POWER register, until this was broken by commit e8cb455876fa8f67c6aba394d0a14b697bf04cc3 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 1 13:05:48 2012 +0200 drm/i915/dp: convert to encoder disable/enable Fix it. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | Merge branch 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2013-11-2128-213/+344
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes More fixes for radeon. This adds new queries for tiling on CIK, and fixes a crash in handling acpi atif backlight events on CIK. Some fixes for radeon for 3.13. Mostly CI stability fixes. I think I've tracked down the stability problems with dpm on Trinity/Richland, so I'm going to enable that by default now. * 'drm-next-3.13' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: hook up backlight functions for CI and KV family. drm/radeon/cik: Add macrotile mode array query drm/radeon/cik: Return backend map information to userspace drm/radeon: enable DPM by default in TN asics drm/radeon: adjust TN dpm parameters for stability (v2) drm/radeon: use a single doorbell for cik kms compute drm/radeon/vm: don't attempt to update ptes if ib allocation fails drm/radeon: disable CIK CP semaphores for now drm/radeon: allow semaphore emission to fail drm/radeon: add semaphore trace point radeon: workaround pinning failure on low ram gpu radeon/i2c: do not count reg index in number of i2c byte we are writing. drm/radeon: cypress_dpm: Fix unused variable warning when CONFIG_ACPI=n drm: radeon: ni_dpm: Fix unused variable warning when CONFIG_ACPI=n
| | * | | drm/radeon: hook up backlight functions for CI and KV family.Samuel Li2013-11-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes crashes when handling atif events due to the lack of a callback being registered. Signed-off-by: Samuel Li <samuel.li@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon/cik: Add macrotile mode array queryMichel Dänzer2013-11-184-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required to properly calculate the tiling parameters in userspace. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/radeon/cik: Return backend map information to userspaceMichel Dänzer2013-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is required to properly calculate the tiling parameters in userspace. Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/radeon: enable DPM by default in TN asicsAlex Deucher2013-11-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After adjusting the dpm parameters this seems to be stable on most TN systems. DPM is important for APUs since the boot clocks are generally pretty low. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/radeon: adjust TN dpm parameters for stability (v2)Alex Deucher2013-11-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adjust some of the TN dpm settings for stability. Enabling these features causes hangs and other stability problems on certain boards. v2: leave uvd dpm enabled Bug: https://bugzilla.kernel.org/show_bug.cgi?id=63101 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: use a single doorbell for cik kms computeAndrew Lewycky2013-11-153-58/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A single doorbell page is plenty for cik kms compute. Use a single page and manage doorbell allocation by individual doorbells rather than pages. Identify doorbells by their index rather than byte offset. Signed-off-by: Andrew Lewycky <Andrew.Lewycky@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| | * | | drm/radeon/vm: don't attempt to update ptes if ib allocation failsAlex Deucher2013-11-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we fail to allocate an indirect buffer (ib) when updating the ptes, return an error instead of trying to use the ib. Avoids a null pointer dereference. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=58621 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: disable CIK CP semaphores for nowChristian König2013-11-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: allow semaphore emission to failChristian König2013-11-1517-147/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To workaround bugs and/or certain limits it's sometimes useful to fall back to waiting on fences. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: add semaphore trace pointChristian König2013-11-152-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | radeon: workaround pinning failure on low ram gpuJerome Glisse2013-11-151-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | GPU with low amount of ram can fails at pinning new framebuffer before unpinning old one. On such failure, retry with unpinning old one before pinning new one allowing to work around the issue. This is somewhat ugly but only affect those old GPU we care about. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | radeon/i2c: do not count reg index in number of i2c byte we are writing.Jerome Glisse2013-11-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Useless to count the register index in number of bytes we are writing. Fixes a regression with hw i2c enabled. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| | * | | drm/radeon: cypress_dpm: Fix unused variable warning when CONFIG_ACPI=nAlex Deucher2013-11-151-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With CONFIG_ACPI=n the following build warning is seen: drivers/gpu/drm/radeon/cypress_dpm.c:302:31: warning: unused variable 'eg_pi' [-Wunused-variable] Protect eg_pi with CONFIG_ACPI. Based on patch from: Fabio Estevam <fabio.estevam@freescale.com> but doesn't mix allocation and code. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-07 10:37:27 +0000