From: Greg Kroah-Hartman Date: Thu, 1 Aug 2013 21:35:26 +0000 (+0800) Subject: 3.10-stable patches X-Git-Tag: v3.0.89~10 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=d4a39a23f7e7cfce218619424ecb10cd8f43ffde;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: drm-i915-correctly-restore-fences-with-objects-attached.patch drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch drm-i915-fix-missed-hunk-after-gt-access-breakage.patch drm-i915-fix-up-gt-init-sequence-fallout.patch drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch drm-i915-fix-write-read-race-with-multiple-rings.patch drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch drm-i915-serialize-almost-all-register-access.patch drm-nouveau-fix-semaphore-dmabuf-obj.patch drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch drm-radeon-fix-audio-dto-programming-on-dce4.patch livelock-avoidance-in-sget.patch mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch rtlwifi-initialize-power-setting-callback-for-usb-devices.patch tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch --- diff --git a/queue-3.10/drm-i915-correctly-restore-fences-with-objects-attached.patch b/queue-3.10/drm-i915-correctly-restore-fences-with-objects-attached.patch new file mode 100644 index 00000000000..bc475c86c33 --- /dev/null +++ b/queue-3.10/drm-i915-correctly-restore-fences-with-objects-attached.patch @@ -0,0 +1,110 @@ +From 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Wed, 17 Jul 2013 14:51:28 +0200 +Subject: drm/i915: correctly restore fences with objects attached + +From: Daniel Vetter + +commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream. + +To avoid stalls we delay tiling changes and especially hold of +committing the new fence state for as long as possible. +Synchronization points are in the execbuf code and in our gtt fault +handler. + +Unfortunately we've missed that tricky detail when adding proper fence +restore code in + +commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7 +Author: Chris Wilson +Date: Wed Jun 12 10:15:12 2013 +0100 + + drm/i915: Restore fences after resume and GPU resets + +The result was that we've restored fences for objects with no tiling, +since the object<->fence link still existed after resume. Now that +wouldn't have been too bad since any subsequent access would have +fixed things up, but if we've changed from tiled to untiled real havoc +happened: + +The tiling stride is stored -1 in the fence register, so a stride of 0 +resulted in all 1s in the top 32bits, and so a completely bogus fence +spanning everything from the start of the object to the top of the +GTT. The tell-tale in the register dumps looks like: + + FENCE START 2: 0x0214d001 + FENCE END 2: 0xfffff3ff + +Bit 11 isn't set since the hw doesn't store it, even when writing all +1s (at least on my snb here). + +To prevent such a gaffle in the future add a sanity check for fences +with an untiled object attached in i915_gem_write_fence. + +v2: Fix the WARN, spotted by Chris. + +v3: Trying to reuse get_fences looked ugly and obfuscated the code. +Instead reuse update_fence and to make it really dtrt also move the +fence dirty state clearing into update_fence. + +Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530 +Cc: Chris Wilson +Cc: Stéphane Marchesin +Reviewed-by: Chris Wilson +Tested-by: Matthew Garrett +Tested-by: Björn Bidar +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem.c | 18 ++++++++++++++++-- + 1 file changed, 16 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -2138,7 +2138,17 @@ void i915_gem_restore_fences(struct drm_ + + for (i = 0; i < dev_priv->num_fence_regs; i++) { + struct drm_i915_fence_reg *reg = &dev_priv->fence_regs[i]; +- i915_gem_write_fence(dev, i, reg->obj); ++ ++ /* ++ * Commit delayed tiling changes if we have an object still ++ * attached to the fence, otherwise just clear the fence. ++ */ ++ if (reg->obj) { ++ i915_gem_object_update_fence(reg->obj, reg, ++ reg->obj->tiling_mode); ++ } else { ++ i915_gem_write_fence(dev, i, NULL); ++ } + } + } + +@@ -2676,6 +2686,10 @@ static void i915_gem_write_fence(struct + if (i915_gem_object_needs_mb(dev_priv->fence_regs[reg].obj)) + mb(); + ++ WARN(obj && (!obj->stride || !obj->tiling_mode), ++ "bogus fence setup with stride: 0x%x, tiling mode: %i\n", ++ obj->stride, obj->tiling_mode); ++ + switch (INTEL_INFO(dev)->gen) { + case 7: + case 6: +@@ -2735,6 +2749,7 @@ static void i915_gem_object_update_fence + fence->obj = NULL; + list_del_init(&fence->lru_list); + } ++ obj->fence_dirty = false; + } + + static int +@@ -2864,7 +2879,6 @@ i915_gem_object_get_fence(struct drm_i91 + return 0; + + i915_gem_object_update_fence(obj, reg, enable); +- obj->fence_dirty = false; + + return 0; + } diff --git a/queue-3.10/drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch b/queue-3.10/drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch new file mode 100644 index 00000000000..cc8ad3dd79c --- /dev/null +++ b/queue-3.10/drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch @@ -0,0 +1,79 @@ +From 2e57f47d317dd035b18634b0c602272529368fcc Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Wed, 17 Jul 2013 12:14:40 +0100 +Subject: drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off() + +From: Chris Wilson + +commit 2e57f47d317dd035b18634b0c602272529368fcc upstream. + +In commit e3de42b68478a8c95dd27520e9adead2af9477a5 +Author: Imre Deak +Date: Fri May 3 19:44:07 2013 +0200 + + drm/i915: force full modeset if the connector is in DPMS OFF mode + +a new function was added that walked over the set of connectors to see +if any of the currently associated CRTC was switched off. This function +walked an array of connectors, rather than the array of pointers to +connectors contained in the drm_mode_set - i.e. it was dereferencing far +past the end of the first connector. This only becomes an issue if we +attempt to use a clone mode (i.e. more than one connector per CRTC) such +that set->num_connectors > 1. + +Reported-by: Timo Aaltonen +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927 +Signed-off-by: Chris Wilson +Cc: Imre Deak +Cc: Egbert Eich +Cc: Jesse Barnes +Cc: Daniel Vetter +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_display.c | 23 +++++++++++++---------- + 1 file changed, 13 insertions(+), 10 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -8146,15 +8146,20 @@ static void intel_set_config_restore_sta + } + + static bool +-is_crtc_connector_off(struct drm_crtc *crtc, struct drm_connector *connectors, +- int num_connectors) ++is_crtc_connector_off(struct drm_mode_set *set) + { + int i; + +- for (i = 0; i < num_connectors; i++) +- if (connectors[i].encoder && +- connectors[i].encoder->crtc == crtc && +- connectors[i].dpms != DRM_MODE_DPMS_ON) ++ if (set->num_connectors == 0) ++ return false; ++ ++ if (WARN_ON(set->connectors == NULL)) ++ return false; ++ ++ for (i = 0; i < set->num_connectors; i++) ++ if (set->connectors[i]->encoder && ++ set->connectors[i]->encoder->crtc == set->crtc && ++ set->connectors[i]->dpms != DRM_MODE_DPMS_ON) + return true; + + return false; +@@ -8167,10 +8172,8 @@ intel_set_config_compute_mode_changes(st + + /* We should be able to check here if the fb has the same properties + * and then just flip_or_move it */ +- if (set->connectors != NULL && +- is_crtc_connector_off(set->crtc, *set->connectors, +- set->num_connectors)) { +- config->mode_changed = true; ++ if (is_crtc_connector_off(set)) { ++ config->mode_changed = true; + } else if (set->crtc->fb != set->fb) { + /* If we have no fb then treat it as a full mode set */ + if (set->crtc->fb == NULL) { diff --git a/queue-3.10/drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch b/queue-3.10/drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch new file mode 100644 index 00000000000..c64967cb84a --- /dev/null +++ b/queue-3.10/drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch @@ -0,0 +1,109 @@ +From d18b9619034230b6f945e215276425636ca401fe Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Wed, 10 Jul 2013 13:36:23 +0100 +Subject: drm/i915: Fix incoherence with fence updates on Sandybridge+ + +From: Chris Wilson + +commit d18b9619034230b6f945e215276425636ca401fe upstream. + +This hopefully fixes the root cause behind the workaround added in + +commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 +Author: Chris Wilson +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: Jon Bloomfield +Signed-off-by: Chris Wilson +Cc: Daniel Vetter +Cc: Carsten Emde +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem.c | 30 ++++++++++++++++++++++++------ + 1 file changed, 24 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -2538,7 +2538,6 @@ static void i965_write_fence_reg(struct + drm_i915_private_t *dev_priv = dev->dev_private; + int fence_reg; + int fence_pitch_shift; +- uint64_t val; + + if (INTEL_INFO(dev)->gen >= 6) { + fence_reg = FENCE_REG_SANDYBRIDGE_0; +@@ -2548,8 +2547,23 @@ static void i965_write_fence_reg(struct + fence_pitch_shift = I965_FENCE_PITCH_SHIFT; + } + ++ fence_reg += reg * 8; ++ ++ /* To w/a incoherency with non-atomic 64-bit register updates, ++ * we split the 64-bit update into two 32-bit writes. In order ++ * for a partial fence not to be evaluated between writes, we ++ * precede the update with write to turn off the fence register, ++ * and only enable the fence as the last step. ++ * ++ * For extra levels of paranoia, we make sure each step lands ++ * before applying the next step. ++ */ ++ I915_WRITE(fence_reg, 0); ++ POSTING_READ(fence_reg); ++ + if (obj) { + u32 size = obj->gtt_space->size; ++ uint64_t val; + + val = (uint64_t)((obj->gtt_offset + size - 4096) & + 0xfffff000) << 32; +@@ -2558,12 +2572,16 @@ static void i965_write_fence_reg(struct + if (obj->tiling_mode == I915_TILING_Y) + val |= 1 << I965_FENCE_TILING_Y_SHIFT; + val |= I965_FENCE_REG_VALID; +- } else +- val = 0; + +- fence_reg += reg * 8; +- I915_WRITE64(fence_reg, val); +- POSTING_READ(fence_reg); ++ I915_WRITE(fence_reg + 4, val >> 32); ++ POSTING_READ(fence_reg + 4); ++ ++ I915_WRITE(fence_reg + 0, val); ++ POSTING_READ(fence_reg); ++ } else { ++ I915_WRITE(fence_reg + 4, 0); ++ POSTING_READ(fence_reg + 4); ++ } + } + + static void i915_write_fence_reg(struct drm_device *dev, int reg, diff --git a/queue-3.10/drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch b/queue-3.10/drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch new file mode 100644 index 00000000000..113b632995d --- /dev/null +++ b/queue-3.10/drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch @@ -0,0 +1,116 @@ +From 7dcd2677ea912573d9ed4bcd629b0023b2d11505 Mon Sep 17 00:00:00 2001 +From: Konstantin Khlebnikov +Date: Wed, 17 Jul 2013 10:22:58 +0400 +Subject: drm/i915: fix long-standing SNB regression in power consumption after resume v2 + +From: Konstantin Khlebnikov + +commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream. + +This patch fixes regression in power consumtion of sandy bridge gpu, which +exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that +it's extremely busy. After that it never reaches rc6 state. + +Bug exists since kernel v3.6: + +commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0 +Author: Jesse Barnes +Date: Thu Jun 14 11:04:48 2012 -0700 + + drm/i915: load boot context at driver init time + +For some reason RC6 is already enabled at the beginning of resuming process. +Following initliaztion breaks some internal state and confuses RPS engine. +This patch disables RC6 at the beginnig of resume and initialization. + +I've rearranged initialization sequence, because intel_disable_gt_powersave() +needs initialized force_wake_get/put and some locks from the dev_priv. + +Note: The culprit in the initialization sequence seems to be the write +to MBCTL added in the above mentioned commit. The first version of +this patch just held a forcewake reference across the clock gating +init functions, which seems to have been enought to gather quite a few +positive test reports. But since that smelled a bit like ad-hoc +duct-tape v2 now just disables rps/rc6 across the entire hw setup. + +References: https://bugs.freedesktop.org/show_bug.cgi?id=54089 +References: https://bugzilla.kernel.org/show_bug.cgi?id=58971 +References: https://patchwork.kernel.org/patch/2827634/ (patch v1) +Signed-off-by: Konstantin Khlebnikov +Cc: Daniel Vetter +Cc: Chris Wilson +Cc: Jesse Barnes +[danvet: Add note about v1 vs. v2 of this patch and use standard +layout for the commit citation. Also add the tested-bys from v1 and a +cc: stable.] +Tested-by: Alexander Kaltsas (v1) +Tested-by: rocko (v1) +Tested-by: JohnMB (v1) +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_dma.c | 16 ++++++++-------- + drivers/gpu/drm/i915/intel_pm.c | 5 +++-- + 2 files changed, 11 insertions(+), 10 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_dma.c ++++ b/drivers/gpu/drm/i915/i915_dma.c +@@ -1511,6 +1511,13 @@ int i915_driver_load(struct drm_device * + dev_priv->dev = dev; + dev_priv->info = info; + ++ spin_lock_init(&dev_priv->irq_lock); ++ spin_lock_init(&dev_priv->gpu_error.lock); ++ spin_lock_init(&dev_priv->rps.lock); ++ mutex_init(&dev_priv->dpio_lock); ++ mutex_init(&dev_priv->rps.hw_lock); ++ mutex_init(&dev_priv->modeset_restore_lock); ++ + i915_dump_device_info(dev_priv); + + if (i915_get_bridge_dev(dev)) { +@@ -1602,6 +1609,7 @@ int i915_driver_load(struct drm_device * + + intel_irq_init(dev); + intel_gt_init(dev); ++ intel_gt_reset(dev); + + /* Try to make sure MCHBAR is enabled before poking at it */ + intel_setup_mchbar(dev); +@@ -1626,14 +1634,6 @@ int i915_driver_load(struct drm_device * + if (!IS_I945G(dev) && !IS_I945GM(dev)) + pci_enable_msi(dev->pdev); + +- spin_lock_init(&dev_priv->irq_lock); +- spin_lock_init(&dev_priv->gpu_error.lock); +- spin_lock_init(&dev_priv->rps.lock); +- mutex_init(&dev_priv->dpio_lock); +- +- mutex_init(&dev_priv->rps.hw_lock); +- mutex_init(&dev_priv->modeset_restore_lock); +- + dev_priv->num_plane = 1; + if (IS_VALLEYVIEW(dev)) + dev_priv->num_plane = 2; +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4497,6 +4497,9 @@ void intel_gt_reset(struct drm_device *d + if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) + __gen6_gt_force_wake_mt_reset(dev_priv); + } ++ ++ /* BIOS often leaves RC6 enabled, but disable it for hw init */ ++ intel_disable_gt_powersave(dev); + } + + void intel_gt_init(struct drm_device *dev) +@@ -4505,8 +4508,6 @@ void intel_gt_init(struct drm_device *de + + spin_lock_init(&dev_priv->gt_lock); + +- intel_gt_reset(dev); +- + if (IS_VALLEYVIEW(dev)) { + dev_priv->gt.force_wake_get = vlv_force_wake_get; + dev_priv->gt.force_wake_put = vlv_force_wake_put; diff --git a/queue-3.10/drm-i915-fix-missed-hunk-after-gt-access-breakage.patch b/queue-3.10/drm-i915-fix-missed-hunk-after-gt-access-breakage.patch new file mode 100644 index 00000000000..4ec5dceacc4 --- /dev/null +++ b/queue-3.10/drm-i915-fix-missed-hunk-after-gt-access-breakage.patch @@ -0,0 +1,71 @@ +From e1b4d3036c07ff137955fb1c0197ab62534f46ec Mon Sep 17 00:00:00 2001 +From: Ben Widawsky +Date: Tue, 30 Jul 2013 16:27:57 -0700 +Subject: drm/i915: fix missed hunk after GT access breakage + +From: Ben Widawsky + +commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream. + +Upon some code refactoring, a hunk was missed. This was fixed for +next, but missed the current trees, and hasn't yet been merged by Dave +Airlie. It is fixed in: +commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c +Author: Chris Wilson +Date: Fri Jul 19 20:36:52 2013 +0100 + + drm/i915: Colocate all GT access routines in the same file + +It is introduced by: +commit 181d1b9e31c668259d3798c521672afb8edd355c +Author: Daniel Vetter +Date: Sun Jul 21 13:16:24 2013 +0200 + + drm/i915: fix up gt init sequence fallout + +Reported-by: Dave Jones +Signed-off-by: Ben Widawsky +Signed-off-by: Dave Airlie +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_dma.c | 1 + + drivers/gpu/drm/i915/i915_drv.h | 1 + + drivers/gpu/drm/i915/intel_pm.c | 6 ++++++ + 3 files changed, 8 insertions(+) + +--- a/drivers/gpu/drm/i915/i915_dma.c ++++ b/drivers/gpu/drm/i915/i915_dma.c +@@ -1608,6 +1608,7 @@ int i915_driver_load(struct drm_device * + intel_detect_pch(dev); + + intel_irq_init(dev); ++ intel_pm_init(dev); + intel_gt_sanitize(dev); + intel_gt_init(dev); + +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1475,6 +1475,7 @@ void i915_hangcheck_elapsed(unsigned lon + void i915_handle_error(struct drm_device *dev, bool wedged); + + extern void intel_irq_init(struct drm_device *dev); ++extern void intel_pm_init(struct drm_device *dev); + extern void intel_hpd_init(struct drm_device *dev); + extern void intel_gt_init(struct drm_device *dev); + extern void intel_gt_sanitize(struct drm_device *dev); +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4548,6 +4548,12 @@ void intel_gt_init(struct drm_device *de + dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; + dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; + } ++} ++ ++void intel_pm_init(struct drm_device *dev) ++{ ++ struct drm_i915_private *dev_priv = dev->dev_private; ++ + INIT_DELAYED_WORK(&dev_priv->rps.delayed_resume_work, + intel_gen6_powersave_work); + } diff --git a/queue-3.10/drm-i915-fix-up-gt-init-sequence-fallout.patch b/queue-3.10/drm-i915-fix-up-gt-init-sequence-fallout.patch new file mode 100644 index 00000000000..a740d080fef --- /dev/null +++ b/queue-3.10/drm-i915-fix-up-gt-init-sequence-fallout.patch @@ -0,0 +1,113 @@ +From 181d1b9e31c668259d3798c521672afb8edd355c Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Sun, 21 Jul 2013 13:16:24 +0200 +Subject: drm/i915: fix up gt init sequence fallout + +From: Daniel Vetter + +commit 181d1b9e31c668259d3798c521672afb8edd355c upstream. + +The regression fix for gen6+ rps fallout + +commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 +Author: Konstantin Khlebnikov +Date: Wed Jul 17 10:22:58 2013 +0400 + + drm/i915: fix long-standing SNB regression in power consumption after resume + +unintentionally also changed the init sequence ordering between +gt_init and gt_reset - we need to reset BIOS damage like leftover +forcewake references before we run our own code. Otherwise we can get +nasty dmesg noise like + +[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. + +again. Since _reset suggests that we first need to have stuff +initialized (which isn't the case here) call it sanitze instead. + +While at it also block out the rps disable introduced by the above +commit on ilk: We don't have any knowledge of ilk rps being broken in +similar ways. And the disable functions uses the default hw state +which is only read out when we're enabling rps. So essentially we've +been writing random grabage into that register. + +Reported-by: Chris Wilson +Cc: Chris Wilson +Cc: Konstantin Khlebnikov +Cc: Jesse Barnes +Tested-by: Chris Wilson +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_dma.c | 2 +- + drivers/gpu/drm/i915/i915_drv.c | 4 ++-- + drivers/gpu/drm/i915/i915_drv.h | 2 +- + drivers/gpu/drm/i915/intel_pm.c | 5 +++-- + 4 files changed, 7 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_dma.c ++++ b/drivers/gpu/drm/i915/i915_dma.c +@@ -1608,8 +1608,8 @@ int i915_driver_load(struct drm_device * + intel_detect_pch(dev); + + intel_irq_init(dev); ++ intel_gt_sanitize(dev); + intel_gt_init(dev); +- intel_gt_reset(dev); + + /* Try to make sure MCHBAR is enabled before poking at it */ + intel_setup_mchbar(dev); +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -685,7 +685,7 @@ static int i915_drm_thaw(struct drm_devi + { + int error = 0; + +- intel_gt_reset(dev); ++ intel_gt_sanitize(dev); + + if (drm_core_check_feature(dev, DRIVER_MODESET)) { + mutex_lock(&dev->struct_mutex); +@@ -711,7 +711,7 @@ int i915_resume(struct drm_device *dev) + + pci_set_master(dev->pdev); + +- intel_gt_reset(dev); ++ intel_gt_sanitize(dev); + + /* + * Platforms with opregion should have sane BIOS, older ones (gen3 and +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -1477,7 +1477,7 @@ void i915_handle_error(struct drm_device + extern void intel_irq_init(struct drm_device *dev); + extern void intel_hpd_init(struct drm_device *dev); + extern void intel_gt_init(struct drm_device *dev); +-extern void intel_gt_reset(struct drm_device *dev); ++extern void intel_gt_sanitize(struct drm_device *dev); + + void i915_error_state_free(struct kref *error_ref); + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4486,7 +4486,7 @@ static void vlv_force_wake_put(struct dr + gen6_gt_check_fifodbg(dev_priv); + } + +-void intel_gt_reset(struct drm_device *dev) ++void intel_gt_sanitize(struct drm_device *dev) + { + struct drm_i915_private *dev_priv = dev->dev_private; + +@@ -4499,7 +4499,8 @@ void intel_gt_reset(struct drm_device *d + } + + /* BIOS often leaves RC6 enabled, but disable it for hw init */ +- intel_disable_gt_powersave(dev); ++ if (INTEL_INFO(dev)->gen >= 6) ++ intel_disable_gt_powersave(dev); + } + + void intel_gt_init(struct drm_device *dev) diff --git a/queue-3.10/drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch b/queue-3.10/drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch new file mode 100644 index 00000000000..0b4975e9879 --- /dev/null +++ b/queue-3.10/drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch @@ -0,0 +1,61 @@ +From aaf8a5167291b65e9116cb8736d862965b57c13a Mon Sep 17 00:00:00 2001 +From: Daniel Vetter +Date: Fri, 5 Jul 2013 23:39:50 +0200 +Subject: drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a + +From: Daniel Vetter + +commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream. + +It's not a good idea to also run the pipe_control cleanup. + +This regression has been introduced whith the original cs tlb w/a in + +commit b45305fce5bb1abec263fcff9d81ebecd6306ede +Author: Daniel Vetter +Date: Mon Dec 17 16:21:27 2012 +0100 + + drm/i915: Implement workaround for broken CS tlb on i830/845 + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610 +Cc: Chris Wilson +Reviewed-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_ringbuffer.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_ringbuffer.c ++++ b/drivers/gpu/drm/i915/intel_ringbuffer.c +@@ -490,9 +490,6 @@ cleanup_pipe_control(struct intel_ring_b + struct pipe_control *pc = ring->private; + struct drm_i915_gem_object *obj; + +- if (!ring->private) +- return; +- + obj = pc->obj; + + kunmap(sg_page(obj->pages->sgl)); +@@ -500,7 +497,6 @@ cleanup_pipe_control(struct intel_ring_b + drm_gem_object_unreference(&obj->base); + + kfree(pc); +- ring->private = NULL; + } + + static int init_render_ring(struct intel_ring_buffer *ring) +@@ -571,7 +567,10 @@ static void render_ring_cleanup(struct i + if (HAS_BROKEN_CS_TLB(dev)) + drm_gem_object_unreference(to_gem_object(ring->private)); + +- cleanup_pipe_control(ring); ++ if (INTEL_INFO(dev)->gen >= 5) ++ cleanup_pipe_control(ring); ++ ++ ring->private = NULL; + } + + static void diff --git a/queue-3.10/drm-i915-fix-write-read-race-with-multiple-rings.patch b/queue-3.10/drm-i915-fix-write-read-race-with-multiple-rings.patch new file mode 100644 index 00000000000..1b5e3fe4db8 --- /dev/null +++ b/queue-3.10/drm-i915-fix-write-read-race-with-multiple-rings.patch @@ -0,0 +1,46 @@ +From 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Tue, 9 Jul 2013 09:22:39 +0100 +Subject: drm/i915: Fix write-read race with multiple rings + +From: Chris Wilson + +commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream. + +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: Chris Wilson +Cc: Daniel Vetter +[danvet: Add note about the newly created igt which exercises this bug.] +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_gem.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -1881,6 +1881,10 @@ i915_gem_object_move_to_active(struct dr + u32 seqno = intel_ring_get_seqno(ring); + + BUG_ON(ring == NULL); ++ if (obj->ring != ring && obj->last_write_seqno) { ++ /* Keep the seqno relative to the current ring */ ++ obj->last_write_seqno = seqno; ++ } + obj->ring = ring; + + /* Add a reference if we're newly entering the active list. */ diff --git a/queue-3.10/drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch b/queue-3.10/drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch new file mode 100644 index 00000000000..e541c825388 --- /dev/null +++ b/queue-3.10/drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch @@ -0,0 +1,83 @@ +From e85843bec6c2ea7c10ec61238396891cc2b753a9 Mon Sep 17 00:00:00 2001 +From: Kamal Mostafa +Date: Fri, 19 Jul 2013 15:02:01 -0700 +Subject: drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight + +From: Kamal Mostafa + +commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream. + +BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941 +BugLink: https://bugs.launchpad.net/bugs/1163720 +BugLink: https://bugs.launchpad.net/bugs/1162026 + +Some machines suffer from non-functional backlight controls if +BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so. +Apply this quirk to Dell XPS 13 models. + +Tested-by: Eric Griffith +Tested-by: Kent Baxley +Signed-off-by: Kamal Mostafa +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.h | 1 + + drivers/gpu/drm/i915/intel_display.c | 16 ++++++++++++++++ + drivers/gpu/drm/i915/intel_panel.c | 3 ++- + 3 files changed, 19 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/i915_drv.h ++++ b/drivers/gpu/drm/i915/i915_drv.h +@@ -491,6 +491,7 @@ enum intel_sbi_destination { + #define QUIRK_PIPEA_FORCE (1<<0) + #define QUIRK_LVDS_SSC_DISABLE (1<<1) + #define QUIRK_INVERT_BRIGHTNESS (1<<2) ++#define QUIRK_NO_PCH_PWM_ENABLE (1<<3) + + struct intel_fbdev; + struct intel_fbc_work; +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -8917,6 +8917,17 @@ static void quirk_invert_brightness(stru + DRM_INFO("applying inverted panel brightness quirk\n"); + } + ++/* ++ * Some machines (Dell XPS13) suffer broken backlight controls if ++ * BLM_PCH_PWM_ENABLE is set. ++ */ ++static void quirk_no_pcm_pwm_enable(struct drm_device *dev) ++{ ++ struct drm_i915_private *dev_priv = dev->dev_private; ++ dev_priv->quirks |= QUIRK_NO_PCH_PWM_ENABLE; ++ DRM_INFO("applying no-PCH_PWM_ENABLE quirk\n"); ++} ++ + struct intel_quirk { + int device; + int subsystem_vendor; +@@ -8986,6 +8997,11 @@ static struct intel_quirk intel_quirks[] + + /* Acer Aspire 4736Z */ + { 0x2a42, 0x1025, 0x0260, quirk_invert_brightness }, ++ ++ /* Dell XPS13 HD Sandy Bridge */ ++ { 0x0116, 0x1028, 0x052e, quirk_no_pcm_pwm_enable }, ++ /* Dell XPS13 HD and XPS13 FHD Ivy Bridge */ ++ { 0x0166, 0x1028, 0x058b, quirk_no_pcm_pwm_enable }, + }; + + static void intel_init_quirks(struct drm_device *dev) +--- a/drivers/gpu/drm/i915/intel_panel.c ++++ b/drivers/gpu/drm/i915/intel_panel.c +@@ -354,7 +354,8 @@ void intel_panel_enable_backlight(struct + POSTING_READ(reg); + I915_WRITE(reg, tmp | BLM_PWM_ENABLE); + +- if (HAS_PCH_SPLIT(dev)) { ++ if (HAS_PCH_SPLIT(dev) && ++ !(dev_priv->quirks & QUIRK_NO_PCH_PWM_ENABLE)) { + tmp = I915_READ(BLC_PWM_PCH_CTL1); + tmp |= BLM_PCH_PWM_ENABLE; + tmp &= ~BLM_PCH_OVERRIDE_ENABLE; diff --git a/queue-3.10/drm-i915-serialize-almost-all-register-access.patch b/queue-3.10/drm-i915-serialize-almost-all-register-access.patch new file mode 100644 index 00000000000..d756d47c352 --- /dev/null +++ b/queue-3.10/drm-i915-serialize-almost-all-register-access.patch @@ -0,0 +1,87 @@ +From a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a Mon Sep 17 00:00:00 2001 +From: Chris Wilson +Date: Fri, 19 Jul 2013 20:36:51 +0100 +Subject: drm/i915: Serialize almost all register access + +From: Chris Wilson + +commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream. + +In theory, the different register blocks were meant to be only ever +touched when holding either the struct_mutex, mode_config.lock or even a +specific localised lock. This does not seem to be the case, and the +hardware reacts extremely badly if we attempt to concurrently access two +registers within the same cacheline. + +The HSD suggests that we only need to do this workaround for display +range registers. However, upon review we need to serialize the multiple +stages in our register write functions - if only for preemption +protection. + +Irrespective of the hardware requirements, the current io functions are +a little too loose with respect to the combination of pre- and +post-condition testing that we do in conjunction with the actual io. As +a result, we may be pre-empted and generate both false-postive and +false-negative errors. + +Note well that this is a "90%" solution, there remains a few direct +users of ioread/iowrite which will be fixed up in the next few patches. +Since they are more invasive and that this simple change will prevent +almost all lockups on Haswell, we kept this patch simple to facilitate +backporting to stable. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914 +Signed-off-by: Chris Wilson +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/i915_drv.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +--- a/drivers/gpu/drm/i915/i915_drv.c ++++ b/drivers/gpu/drm/i915/i915_drv.c +@@ -1247,21 +1247,21 @@ hsw_unclaimed_reg_check(struct drm_i915_ + + #define __i915_read(x, y) \ + u##x i915_read##x(struct drm_i915_private *dev_priv, u32 reg) { \ ++ unsigned long irqflags; \ + u##x val = 0; \ ++ spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \ + if (IS_GEN5(dev_priv->dev)) \ + ilk_dummy_write(dev_priv); \ + if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \ +- unsigned long irqflags; \ +- spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \ + if (dev_priv->forcewake_count == 0) \ + dev_priv->gt.force_wake_get(dev_priv); \ + val = read##y(dev_priv->regs + reg); \ + if (dev_priv->forcewake_count == 0) \ + dev_priv->gt.force_wake_put(dev_priv); \ +- spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \ + } else { \ + val = read##y(dev_priv->regs + reg); \ + } \ ++ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \ + trace_i915_reg_rw(false, reg, val, sizeof(val)); \ + return val; \ + } +@@ -1274,8 +1274,10 @@ __i915_read(64, q) + + #define __i915_write(x, y) \ + void i915_write##x(struct drm_i915_private *dev_priv, u32 reg, u##x val) { \ ++ unsigned long irqflags; \ + u32 __fifo_ret = 0; \ + trace_i915_reg_rw(true, reg, val, sizeof(val)); \ ++ spin_lock_irqsave(&dev_priv->gt_lock, irqflags); \ + if (NEEDS_FORCE_WAKE((dev_priv), (reg))) { \ + __fifo_ret = __gen6_gt_wait_for_fifo(dev_priv); \ + } \ +@@ -1287,6 +1289,7 @@ void i915_write##x(struct drm_i915_priva + gen6_gt_check_fifodbg(dev_priv); \ + } \ + hsw_unclaimed_reg_check(dev_priv, reg); \ ++ spin_unlock_irqrestore(&dev_priv->gt_lock, irqflags); \ + } + __i915_write(8, b) + __i915_write(16, w) diff --git a/queue-3.10/drm-nouveau-fix-semaphore-dmabuf-obj.patch b/queue-3.10/drm-nouveau-fix-semaphore-dmabuf-obj.patch new file mode 100644 index 00000000000..00898c3afc4 --- /dev/null +++ b/queue-3.10/drm-nouveau-fix-semaphore-dmabuf-obj.patch @@ -0,0 +1,76 @@ +From 7a7da592cbb22a1d360638dbecc393470c5effe3 Mon Sep 17 00:00:00 2001 +From: Maarten Lankhorst +Date: Tue, 23 Jul 2013 15:49:39 +0200 +Subject: drm/nouveau: fix semaphore dmabuf obj + +From: Maarten Lankhorst + +commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream. + +Fixes some dmabuf object errors on nv50 chipset and below. + +Signed-off-by: Maarten Lankhorst +Signed-off-by: Ben Skeggs +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/nouveau/nv17_fence.c | 2 +- + drivers/gpu/drm/nouveau/nv50_fence.c | 14 +++++++++----- + 2 files changed, 10 insertions(+), 6 deletions(-) + +--- a/drivers/gpu/drm/nouveau/nv17_fence.c ++++ b/drivers/gpu/drm/nouveau/nv17_fence.c +@@ -76,7 +76,7 @@ nv17_fence_context_new(struct nouveau_ch + struct ttm_mem_reg *mem = &priv->bo->bo.mem; + struct nouveau_object *object; + u32 start = mem->start * PAGE_SIZE; +- u32 limit = mem->start + mem->size - 1; ++ u32 limit = start + mem->size - 1; + int ret = 0; + + fctx = chan->fence = kzalloc(sizeof(*fctx), GFP_KERNEL); +--- a/drivers/gpu/drm/nouveau/nv50_fence.c ++++ b/drivers/gpu/drm/nouveau/nv50_fence.c +@@ -39,6 +39,8 @@ nv50_fence_context_new(struct nouveau_ch + struct nv10_fence_chan *fctx; + struct ttm_mem_reg *mem = &priv->bo->bo.mem; + struct nouveau_object *object; ++ u32 start = mem->start * PAGE_SIZE; ++ u32 limit = start + mem->size - 1; + int ret, i; + + fctx = chan->fence = kzalloc(sizeof(*fctx), GFP_KERNEL); +@@ -51,26 +53,28 @@ nv50_fence_context_new(struct nouveau_ch + fctx->base.sync = nv17_fence_sync; + + ret = nouveau_object_new(nv_object(chan->cli), chan->handle, +- NvSema, 0x0002, ++ NvSema, 0x003d, + &(struct nv_dma_class) { + .flags = NV_DMA_TARGET_VRAM | + NV_DMA_ACCESS_RDWR, +- .start = mem->start * PAGE_SIZE, +- .limit = mem->size - 1, ++ .start = start, ++ .limit = limit, + }, sizeof(struct nv_dma_class), + &object); + + /* dma objects for display sync channel semaphore blocks */ + for (i = 0; !ret && i < dev->mode_config.num_crtc; i++) { + struct nouveau_bo *bo = nv50_display_crtc_sema(dev, i); ++ u32 start = bo->bo.mem.start * PAGE_SIZE; ++ u32 limit = start + bo->bo.mem.size - 1; + + ret = nouveau_object_new(nv_object(chan->cli), chan->handle, + NvEvoSema0 + i, 0x003d, + &(struct nv_dma_class) { + .flags = NV_DMA_TARGET_VRAM | + NV_DMA_ACCESS_RDWR, +- .start = bo->bo.offset, +- .limit = bo->bo.offset + 0xfff, ++ .start = start, ++ .limit = limit, + }, sizeof(struct nv_dma_class), + &object); + } diff --git a/queue-3.10/drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch b/queue-3.10/drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch new file mode 100644 index 00000000000..d12f94ce42d --- /dev/null +++ b/queue-3.10/drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch @@ -0,0 +1,45 @@ +From 42a21826dc54583cdb79cc8477732e911ac9c376 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Tue, 30 Jul 2013 00:22:53 -0400 +Subject: drm/radeon/atom: initialize more atom interpretor elements to 0 + +From: Alex Deucher + +commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream. + +The ProcessAuxChannel table on some rv635 boards assumes +the divmul members are initialized to 0 otherwise we get +an invalid fb offset since it has a bad mask set when +setting the fb base. While here initialize all the +atom interpretor elements to 0. + +Fixes: +https://bugzilla.kernel.org/show_bug.cgi?id=60639 + +Signed-off-by: Alex Deucher +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/atom.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/gpu/drm/radeon/atom.c ++++ b/drivers/gpu/drm/radeon/atom.c +@@ -1222,12 +1222,17 @@ int atom_execute_table(struct atom_conte + int r; + + mutex_lock(&ctx->mutex); ++ /* reset data block */ ++ ctx->data_block = 0; + /* reset reg block */ + ctx->reg_block = 0; + /* reset fb window */ + ctx->fb_base = 0; + /* reset io mode */ + ctx->io_mode = ATOM_IO_MM; ++ /* reset divmul */ ++ ctx->divmul[0] = 0; ++ ctx->divmul[1] = 0; + r = atom_execute_table_locked(ctx, index, params); + mutex_unlock(&ctx->mutex); + return r; diff --git a/queue-3.10/drm-radeon-fix-audio-dto-programming-on-dce4.patch b/queue-3.10/drm-radeon-fix-audio-dto-programming-on-dce4.patch new file mode 100644 index 00000000000..3f2865d2165 --- /dev/null +++ b/queue-3.10/drm-radeon-fix-audio-dto-programming-on-dce4.patch @@ -0,0 +1,34 @@ +From 7d61d835824f73dc4097b51f800382467c8049c5 Mon Sep 17 00:00:00 2001 +From: Alex Deucher +Date: Fri, 26 Jul 2013 13:26:05 -0400 +Subject: drm/radeon: fix audio dto programming on DCE4+ + +From: Alex Deucher + +commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream. + +We need to set the dto source before setting the +dividers otherwise we may get stability problems +with the dto leading to audio playback problems. + +Signed-off-by: Alex Deucher +Reviewed-by: Christian König +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/radeon/evergreen_hdmi.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpu/drm/radeon/evergreen_hdmi.c ++++ b/drivers/gpu/drm/radeon/evergreen_hdmi.c +@@ -157,9 +157,9 @@ static void evergreen_audio_set_dto(stru + * number (coefficient of two integer numbers. DCCG_AUDIO_DTOx_PHASE + * is the numerator, DCCG_AUDIO_DTOx_MODULE is the denominator + */ ++ WREG32(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL(radeon_crtc->crtc_id)); + WREG32(DCCG_AUDIO_DTO0_PHASE, base_rate * 100); + WREG32(DCCG_AUDIO_DTO0_MODULE, clock * 100); +- WREG32(DCCG_AUDIO_DTO_SOURCE, DCCG_AUDIO_DTO0_SOURCE_SEL(radeon_crtc->crtc_id)); + } + + diff --git a/queue-3.10/livelock-avoidance-in-sget.patch b/queue-3.10/livelock-avoidance-in-sget.patch new file mode 100644 index 00000000000..8e59025daea --- /dev/null +++ b/queue-3.10/livelock-avoidance-in-sget.patch @@ -0,0 +1,100 @@ +From acfec9a5a892f98461f52ed5770de99a3e571ae2 Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Sat, 20 Jul 2013 03:13:55 +0400 +Subject: livelock avoidance in sget() + +From: Al Viro + +commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream. + +Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about +to fail. The superblock is on ->fs_supers, ->s_umount is held exclusive, +->s_active is 1. Along comes two more processes, trying to mount the same +thing; sget() in each is picking that superblock, bumping ->s_count and +trying to grab ->s_umount. ->s_active is 3 now. Original mount(2) +finally gets to deactivate_locked_super() on failure; ->s_active is 2, +superblock is still ->fs_supers because shutdown will *not* happen until +->s_active hits 0. ->s_umount is dropped and now we have two processes +chasing each other: +s_active = 2, A acquired ->s_umount, B blocked +A sees that the damn thing is stillborn, does deactivate_locked_super() +s_active = 1, A drops ->s_umount, B gets it +A restarts the search and finds the same superblock. And bumps it ->s_active. +s_active = 2, B holds ->s_umount, A blocked on trying to get it +... and we are in the earlier situation with A and B switched places. + +The root cause, of course, is that ->s_active should not grow until we'd +got MS_BORN. Then failing ->mount() will have deactivate_locked_super() +shut the damn thing down. Fortunately, it's easy to do - the key point +is that grab_super() is called only for superblocks currently on ->fs_supers, +so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and +bump ->s_active; we must never increment ->s_count for superblocks past +->kill_sb(), but grab_super() is never called for those. + +The bug is pretty old; we would've caught it by now, if not for accidental +exclusion between sget() for block filesystems; the things like cgroup or +e.g. mtd-based filesystems don't have anything of that sort, so they get +bitten. The right way to deal with that is obviously to fix sget()... + +Signed-off-by: Al Viro +Signed-off-by: Greg Kroah-Hartman + +--- + fs/super.c | 25 ++++++++++--------------- + 1 file changed, 10 insertions(+), 15 deletions(-) + +--- a/fs/super.c ++++ b/fs/super.c +@@ -336,19 +336,19 @@ EXPORT_SYMBOL(deactivate_super); + * and want to turn it into a full-blown active reference. grab_super() + * is called with sb_lock held and drops it. Returns 1 in case of + * success, 0 if we had failed (superblock contents was already dead or +- * dying when grab_super() had been called). ++ * dying when grab_super() had been called). Note that this is only ++ * called for superblocks not in rundown mode (== ones still on ->fs_supers ++ * of their type), so increment of ->s_count is OK here. + */ + static int grab_super(struct super_block *s) __releases(sb_lock) + { +- if (atomic_inc_not_zero(&s->s_active)) { +- spin_unlock(&sb_lock); +- return 1; +- } +- /* it's going away */ + s->s_count++; + spin_unlock(&sb_lock); +- /* wait for it to die */ + down_write(&s->s_umount); ++ if ((s->s_flags & MS_BORN) && atomic_inc_not_zero(&s->s_active)) { ++ put_super(s); ++ return 1; ++ } + up_write(&s->s_umount); + put_super(s); + return 0; +@@ -463,11 +463,6 @@ retry: + destroy_super(s); + s = NULL; + } +- down_write(&old->s_umount); +- if (unlikely(!(old->s_flags & MS_BORN))) { +- deactivate_locked_super(old); +- goto retry; +- } + return old; + } + } +@@ -660,10 +655,10 @@ restart: + if (hlist_unhashed(&sb->s_instances)) + continue; + if (sb->s_bdev == bdev) { +- if (grab_super(sb)) /* drops sb_lock */ +- return sb; +- else ++ if (!grab_super(sb)) + goto restart; ++ up_write(&sb->s_umount); ++ return sb; + } + } + spin_unlock(&sb_lock); diff --git a/queue-3.10/mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch b/queue-3.10/mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch new file mode 100644 index 00000000000..3fbcb70ebf3 --- /dev/null +++ b/queue-3.10/mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch @@ -0,0 +1,76 @@ +From 3964acd0dbec123aa0a621973a2a0580034b4788 Mon Sep 17 00:00:00 2001 +From: Oleg Nesterov +Date: Wed, 31 Jul 2013 13:53:28 -0700 +Subject: mm: mempolicy: fix mbind_range() && vma_adjust() interaction + +From: Oleg Nesterov + +commit 3964acd0dbec123aa0a621973a2a0580034b4788 upstream. + +vma_adjust() does vma_set_policy(vma, vma_policy(next)) and this +is doubly wrong: + +1. This leaks vma->vm_policy if it is not NULL and not equal to + next->vm_policy. + + This can happen if vma_merge() expands "area", not prev (case 8). + +2. This sets the wrong policy if vma_merge() joins prev and area, + area is the vma the caller needs to update and it still has the + old policy. + +Revert commit 1444f92c8498 ("mm: merging memory blocks resets +mempolicy") which introduced these problems. + +Change mbind_range() to recheck mpol_equal() after vma_merge() to fix +the problem that commit tried to address. + +Signed-off-by: Oleg Nesterov +Acked-by: KOSAKI Motohiro +Cc: Steven T Hampson +Cc: Mel Gorman +Cc: KOSAKI Motohiro +Cc: Rik van Riel +Cc: Andi Kleen +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + mm/mempolicy.c | 6 +++++- + mm/mmap.c | 2 +- + 2 files changed, 6 insertions(+), 2 deletions(-) + +--- a/mm/mempolicy.c ++++ b/mm/mempolicy.c +@@ -732,7 +732,10 @@ static int mbind_range(struct mm_struct + if (prev) { + vma = prev; + next = vma->vm_next; +- continue; ++ if (mpol_equal(vma_policy(vma), new_pol)) ++ continue; ++ /* vma_merge() joined vma && vma->next, case 8 */ ++ goto replace; + } + if (vma->vm_start != vmstart) { + err = split_vma(vma->vm_mm, vma, vmstart, 1); +@@ -744,6 +747,7 @@ static int mbind_range(struct mm_struct + if (err) + goto out; + } ++ replace: + err = vma_replace_policy(vma, new_pol); + if (err) + goto out; +--- a/mm/mmap.c ++++ b/mm/mmap.c +@@ -865,7 +865,7 @@ again: remove_next = 1 + (end > next-> + if (next->anon_vma) + anon_vma_merge(vma, next); + mm->map_count--; +- vma_set_policy(vma, vma_policy(next)); ++ mpol_put(vma_policy(next)); + kmem_cache_free(vm_area_cachep, next); + /* + * In mprotect's case 6 (see comments on vma_merge), diff --git a/queue-3.10/partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch b/queue-3.10/partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch new file mode 100644 index 00000000000..a797557d803 --- /dev/null +++ b/queue-3.10/partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch @@ -0,0 +1,78 @@ +From c11e5f35ab490bd30591563816fbc83526521777 Mon Sep 17 00:00:00 2001 +From: Guenter Roeck +Date: Tue, 9 Jul 2013 16:00:31 -0700 +Subject: Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb" + +From: Guenter Roeck + +commit c11e5f35ab490bd30591563816fbc83526521777 upstream. + +This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 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 +Cc: Daniel Vetter +Cc: Mika Kuoppala +Signed-off-by: Guenter Roeck +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139 +Signed-off-by: Daniel Vetter +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/i915/intel_pm.c | 31 ++++++++++++++++++++++++++++++- + 1 file changed, 30 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -4510,9 +4510,38 @@ void intel_gt_init(struct drm_device *de + if (IS_VALLEYVIEW(dev)) { + dev_priv->gt.force_wake_get = vlv_force_wake_get; + dev_priv->gt.force_wake_put = vlv_force_wake_put; +- } else if (IS_IVYBRIDGE(dev) || IS_HASWELL(dev)) { ++ } else if (IS_HASWELL(dev)) { + dev_priv->gt.force_wake_get = __gen6_gt_force_wake_mt_get; + dev_priv->gt.force_wake_put = __gen6_gt_force_wake_mt_put; ++ } else if (IS_IVYBRIDGE(dev)) { ++ u32 ecobus; ++ ++ /* IVB configs may use multi-threaded forcewake */ ++ ++ /* A small trick here - if the bios hasn't configured ++ * MT forcewake, and if the device is in RC6, then ++ * force_wake_mt_get will not wake the device and the ++ * ECOBUS read will return zero. Which will be ++ * (correctly) interpreted by the test below as MT ++ * forcewake being disabled. ++ */ ++ mutex_lock(&dev->struct_mutex); ++ __gen6_gt_force_wake_mt_get(dev_priv); ++ ecobus = I915_READ_NOTRACE(ECOBUS); ++ __gen6_gt_force_wake_mt_put(dev_priv); ++ mutex_unlock(&dev->struct_mutex); ++ ++ if (ecobus & FORCEWAKE_MT_ENABLE) { ++ dev_priv->gt.force_wake_get = ++ __gen6_gt_force_wake_mt_get; ++ dev_priv->gt.force_wake_put = ++ __gen6_gt_force_wake_mt_put; ++ } else { ++ DRM_INFO("No MT forcewake available on Ivybridge, this can result in issues\n"); ++ DRM_INFO("when using vblank-synced partial screen updates.\n"); ++ dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; ++ dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; ++ } + } else if (IS_GEN6(dev)) { + dev_priv->gt.force_wake_get = __gen6_gt_force_wake_get; + dev_priv->gt.force_wake_put = __gen6_gt_force_wake_put; diff --git a/queue-3.10/rtlwifi-initialize-power-setting-callback-for-usb-devices.patch b/queue-3.10/rtlwifi-initialize-power-setting-callback-for-usb-devices.patch new file mode 100644 index 00000000000..8bcc40421f8 --- /dev/null +++ b/queue-3.10/rtlwifi-initialize-power-setting-callback-for-usb-devices.patch @@ -0,0 +1,93 @@ +From bcfb879432094c267c35a7ff75d953d3a66c193a Mon Sep 17 00:00:00 2001 +From: Larry Finger +Date: Fri, 28 Jun 2013 09:12:53 -0500 +Subject: rtlwifi: Initialize power-setting callback for USB devices + +From: Larry Finger + +commit bcfb879432094c267c35a7ff75d953d3a66c193a upstream. + +Commit a269913c5 entitled "rtlwifi: Rework rtl_lps_leave() and +rtl_lps_enter() to use work queue" has two bugs for USB drivers. +Firstly, the work queue in question was not initialized. Secondly, +the callback routine used by this queue is contained within the +file used for PCI devices. As a result, it is not available for +architectures without PCI hardware. + +Signed-off-by: Larry Finger +Reported-by: Richard Genoud +Tested-by: Richard Genoud +Cc: Richard Genoud +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rtlwifi/pci.c | 13 ------------- + drivers/net/wireless/rtlwifi/ps.c | 12 ++++++++++++ + drivers/net/wireless/rtlwifi/ps.h | 1 + + drivers/net/wireless/rtlwifi/usb.c | 2 ++ + 4 files changed, 15 insertions(+), 13 deletions(-) + +--- a/drivers/net/wireless/rtlwifi/pci.c ++++ b/drivers/net/wireless/rtlwifi/pci.c +@@ -1008,19 +1008,6 @@ static void _rtl_pci_prepare_bcn_tasklet + return; + } + +-static void rtl_lps_change_work_callback(struct work_struct *work) +-{ +- struct rtl_works *rtlworks = +- container_of(work, struct rtl_works, lps_change_work); +- struct ieee80211_hw *hw = rtlworks->hw; +- struct rtl_priv *rtlpriv = rtl_priv(hw); +- +- if (rtlpriv->enter_ps) +- rtl_lps_enter(hw); +- else +- rtl_lps_leave(hw); +-} +- + static void _rtl_pci_init_trx_var(struct ieee80211_hw *hw) + { + struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw)); +--- a/drivers/net/wireless/rtlwifi/ps.c ++++ b/drivers/net/wireless/rtlwifi/ps.c +@@ -611,6 +611,18 @@ void rtl_swlps_rf_sleep(struct ieee80211 + MSECS(sleep_intv * mac->vif->bss_conf.beacon_int - 40)); + } + ++void rtl_lps_change_work_callback(struct work_struct *work) ++{ ++ struct rtl_works *rtlworks = ++ container_of(work, struct rtl_works, lps_change_work); ++ struct ieee80211_hw *hw = rtlworks->hw; ++ struct rtl_priv *rtlpriv = rtl_priv(hw); ++ ++ if (rtlpriv->enter_ps) ++ rtl_lps_enter(hw); ++ else ++ rtl_lps_leave(hw); ++} + + void rtl_swlps_wq_callback(void *data) + { +--- a/drivers/net/wireless/rtlwifi/ps.h ++++ b/drivers/net/wireless/rtlwifi/ps.h +@@ -49,5 +49,6 @@ void rtl_swlps_rf_awake(struct ieee80211 + void rtl_swlps_rf_sleep(struct ieee80211_hw *hw); + void rtl_p2p_ps_cmd(struct ieee80211_hw *hw, u8 p2p_ps_state); + void rtl_p2p_info(struct ieee80211_hw *hw, void *data, unsigned int len); ++void rtl_lps_change_work_callback(struct work_struct *work); + + #endif +--- a/drivers/net/wireless/rtlwifi/usb.c ++++ b/drivers/net/wireless/rtlwifi/usb.c +@@ -1070,6 +1070,8 @@ int rtl_usb_probe(struct usb_interface * + spin_lock_init(&rtlpriv->locks.usb_lock); + INIT_WORK(&rtlpriv->works.fill_h2c_cmd, + rtl_fill_h2c_cmd_work_callback); ++ INIT_WORK(&rtlpriv->works.lps_change_work, ++ rtl_lps_change_work_callback); + + rtlpriv->usb_data_index = 0; + init_completion(&rtlpriv->firmware_loading_complete); diff --git a/queue-3.10/series b/queue-3.10/series index 3d622808699..9a63ce5b414 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -70,3 +70,23 @@ drm-radeon-fix-endian-issues-with-dp-handling-v3.patch drm-radeon-another-card-with-wrong-primary-dac-adj.patch drm-radeon-fix-combios-tables-on-older-cards.patch drm-radeon-improve-dac-adjust-heuristics-for-legacy-pdac.patch +drm-i915-fix-up-ring-cleanup-for-the-i830-i845-cs-tlb-w-a.patch +drm-i915-fix-write-read-race-with-multiple-rings.patch +partially-revert-drm-i915-unconditionally-use-mt-forcewake-on-hsw-ivb.patch +drm-i915-fix-incoherence-with-fence-updates-on-sandybridge.patch +drm-i915-fix-long-standing-snb-regression-in-power-consumption-after-resume-v2.patch +drm-i915-fix-dereferencing-invalid-connectors-in-is_crtc_connector_off.patch +drm-i915-correctly-restore-fences-with-objects-attached.patch +drm-i915-quirk-no-pch_pwm_enable-for-dell-xps13-backlight.patch +drm-i915-serialize-almost-all-register-access.patch +drm-i915-fix-up-gt-init-sequence-fallout.patch +drm-i915-fix-missed-hunk-after-gt-access-breakage.patch +drm-nouveau-fix-semaphore-dmabuf-obj.patch +drm-radeon-fix-audio-dto-programming-on-dce4.patch +drm-radeon-atom-initialize-more-atom-interpretor-elements-to-0.patch +rtlwifi-initialize-power-setting-callback-for-usb-devices.patch +usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch +usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch +mm-mempolicy-fix-mbind_range-vma_adjust-interaction.patch +tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch +livelock-avoidance-in-sget.patch diff --git a/queue-3.10/tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch b/queue-3.10/tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch new file mode 100644 index 00000000000..411ca34b22d --- /dev/null +++ b/queue-3.10/tty_port-fix-refcounting-leak-in-tty_port_tty_hangup.patch @@ -0,0 +1,49 @@ +From 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f Mon Sep 17 00:00:00 2001 +From: Gianluca Anzolin +Date: Thu, 25 Jul 2013 07:26:16 +0200 +Subject: tty_port: Fix refcounting leak in tty_port_tty_hangup() + +From: Gianluca Anzolin + +commit 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f upstream. + +The function tty_port_tty_hangup() could leak a reference to the tty_struct: + + struct tty_struct *tty = tty_port_tty_get(port); + + if (tty && (!check_clocal || !C_CLOCAL(tty))) { + tty_hangup(tty); + tty_kref_put(tty); + } + +If tty != NULL and the second condition is false we never call tty_kref_put and +the reference is leaked. + +Fix by always calling tty_kref_put() which accepts a NULL argument. + +The patch fixes a regression introduced by commit aa27a094. + +Acked-by: Gustavo Padovan +Signed-off-by: Gianluca Anzolin +Acked-by: Jiri Slaby +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/tty_port.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +--- a/drivers/tty/tty_port.c ++++ b/drivers/tty/tty_port.c +@@ -256,10 +256,9 @@ void tty_port_tty_hangup(struct tty_port + { + struct tty_struct *tty = tty_port_tty_get(port); + +- if (tty && (!check_clocal || !C_CLOCAL(tty))) { ++ if (tty && (!check_clocal || !C_CLOCAL(tty))) + tty_hangup(tty); +- tty_kref_put(tty); +- } ++ tty_kref_put(tty); + } + EXPORT_SYMBOL_GPL(tty_port_tty_hangup); + diff --git a/queue-3.10/usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch b/queue-3.10/usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch new file mode 100644 index 00000000000..a9c75a22b5b --- /dev/null +++ b/queue-3.10/usb-gadget-udc-core-fix-the-typo-of-udc-state-attribute.patch @@ -0,0 +1,33 @@ +From 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 Mon Sep 17 00:00:00 2001 +From: Rong Wang +Date: Sun, 28 Jul 2013 23:01:35 +0800 +Subject: usb: gadget: udc-core: fix the typo of udc state attribute + +From: Rong Wang + +commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream. + +The name of udc state attribute file under sysfs is registered as +"state", while usb_gadget_set_state take it as "status" when it's +going to update. This patch fixes the typo. + +Signed-off-by: Rong Wang +Signed-off-by: Barry Song +Signed-off-by: Felipe Balbi +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/gadget/udc-core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/usb/gadget/udc-core.c ++++ b/drivers/usb/gadget/udc-core.c +@@ -105,7 +105,7 @@ void usb_gadget_set_state(struct usb_gad + enum usb_device_state state) + { + gadget->state = state; +- sysfs_notify(&gadget->dev.kobj, NULL, "status"); ++ sysfs_notify(&gadget->dev.kobj, NULL, "state"); + } + EXPORT_SYMBOL_GPL(usb_gadget_set_state); + diff --git a/queue-3.10/usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch b/queue-3.10/usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch new file mode 100644 index 00000000000..1b4393ce84e --- /dev/null +++ b/queue-3.10/usb-serial-ftdi_sio-add-more-rt-systems-ftdi-devices.patch @@ -0,0 +1,105 @@ +From fed1f1ed90bce42ea010e2904cbc04e7b8304940 Mon Sep 17 00:00:00 2001 +From: "Rick Farina (Zero_Chaos)" +Date: Mon, 29 Jul 2013 15:17:59 -0400 +Subject: USB: serial: ftdi_sio: add more RT Systems ftdi devices + +From: "Rick Farina (Zero_Chaos)" + +commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream. + +RT Systems makes many usb serial cables based on the ftdi_sio driver for +programming various amateur radios. This patch is a full listing of +their current product offerings and should allow these cables to all +be recognized. + +Signed-off-by: Rick Farina (Zero_Chaos) +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/serial/ftdi_sio.c | 31 ++++++++++++++++++++++++++++--- + drivers/usb/serial/ftdi_sio_ids.h | 34 +++++++++++++++++++++++++++++----- + 2 files changed, 57 insertions(+), 8 deletions(-) + +--- a/drivers/usb/serial/ftdi_sio.c ++++ b/drivers/usb/serial/ftdi_sio.c +@@ -735,9 +735,34 @@ static struct usb_device_id id_table_com + { USB_DEVICE(FTDI_VID, FTDI_NDI_AURORA_SCU_PID), + .driver_info = (kernel_ulong_t)&ftdi_NDI_device_quirk }, + { USB_DEVICE(TELLDUS_VID, TELLDUS_TELLSTICK_PID) }, +- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_SERIAL_VX7_PID) }, +- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_CT29B_PID) }, +- { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_RTS01_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S03_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_59_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57A_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_57B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29A_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29F_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S01_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_29C_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_81B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_82B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5D_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K4Y_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_K5G_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_S05_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_60_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_61_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_62_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_63B_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_64_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_65_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_92D_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_W5R_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_A5R_PID) }, ++ { USB_DEVICE(RTSYSTEMS_VID, RTSYSTEMS_USB_PW1_PID) }, + { USB_DEVICE(FTDI_VID, FTDI_MAXSTREAM_PID) }, + { USB_DEVICE(FTDI_VID, FTDI_PHI_FISCO_PID) }, + { USB_DEVICE(TML_VID, TML_USB_SERIAL_PID) }, +--- a/drivers/usb/serial/ftdi_sio_ids.h ++++ b/drivers/usb/serial/ftdi_sio_ids.h +@@ -815,11 +815,35 @@ + /* + * RT Systems programming cables for various ham radios + */ +-#define RTSYSTEMS_VID 0x2100 /* Vendor ID */ +-#define RTSYSTEMS_SERIAL_VX7_PID 0x9e52 /* Serial converter for VX-7 Radios using FT232RL */ +-#define RTSYSTEMS_CT29B_PID 0x9e54 /* CT29B Radio Cable */ +-#define RTSYSTEMS_RTS01_PID 0x9e57 /* USB-RTS01 Radio Cable */ +- ++#define RTSYSTEMS_VID 0x2100 /* Vendor ID */ ++#define RTSYSTEMS_USB_S03_PID 0x9001 /* RTS-03 USB to Serial Adapter */ ++#define RTSYSTEMS_USB_59_PID 0x9e50 /* USB-59 USB to 8 pin plug */ ++#define RTSYSTEMS_USB_57A_PID 0x9e51 /* USB-57A USB to 4pin 3.5mm plug */ ++#define RTSYSTEMS_USB_57B_PID 0x9e52 /* USB-57B USB to extended 4pin 3.5mm plug */ ++#define RTSYSTEMS_USB_29A_PID 0x9e53 /* USB-29A USB to 3.5mm stereo plug */ ++#define RTSYSTEMS_USB_29B_PID 0x9e54 /* USB-29B USB to 6 pin mini din */ ++#define RTSYSTEMS_USB_29F_PID 0x9e55 /* USB-29F USB to 6 pin modular plug */ ++#define RTSYSTEMS_USB_62B_PID 0x9e56 /* USB-62B USB to 8 pin mini din plug*/ ++#define RTSYSTEMS_USB_S01_PID 0x9e57 /* USB-RTS01 USB to 3.5 mm stereo plug*/ ++#define RTSYSTEMS_USB_63_PID 0x9e58 /* USB-63 USB to 9 pin female*/ ++#define RTSYSTEMS_USB_29C_PID 0x9e59 /* USB-29C USB to 4 pin modular plug*/ ++#define RTSYSTEMS_USB_81B_PID 0x9e5A /* USB-81 USB to 8 pin mini din plug*/ ++#define RTSYSTEMS_USB_82B_PID 0x9e5B /* USB-82 USB to 2.5 mm stereo plug*/ ++#define RTSYSTEMS_USB_K5D_PID 0x9e5C /* USB-K5D USB to 8 pin modular plug*/ ++#define RTSYSTEMS_USB_K4Y_PID 0x9e5D /* USB-K4Y USB to 2.5/3.5 mm plugs*/ ++#define RTSYSTEMS_USB_K5G_PID 0x9e5E /* USB-K5G USB to 8 pin modular plug*/ ++#define RTSYSTEMS_USB_S05_PID 0x9e5F /* USB-RTS05 USB to 2.5 mm stereo plug*/ ++#define RTSYSTEMS_USB_60_PID 0x9e60 /* USB-60 USB to 6 pin din*/ ++#define RTSYSTEMS_USB_61_PID 0x9e61 /* USB-61 USB to 6 pin mini din*/ ++#define RTSYSTEMS_USB_62_PID 0x9e62 /* USB-62 USB to 8 pin mini din*/ ++#define RTSYSTEMS_USB_63B_PID 0x9e63 /* USB-63 USB to 9 pin female*/ ++#define RTSYSTEMS_USB_64_PID 0x9e64 /* USB-64 USB to 9 pin male*/ ++#define RTSYSTEMS_USB_65_PID 0x9e65 /* USB-65 USB to 9 pin female null modem*/ ++#define RTSYSTEMS_USB_92_PID 0x9e66 /* USB-92 USB to 12 pin plug*/ ++#define RTSYSTEMS_USB_92D_PID 0x9e67 /* USB-92D USB to 12 pin plug data*/ ++#define RTSYSTEMS_USB_W5R_PID 0x9e68 /* USB-W5R USB to 8 pin modular plug*/ ++#define RTSYSTEMS_USB_A5R_PID 0x9e69 /* USB-A5R USB to 8 pin modular plug*/ ++#define RTSYSTEMS_USB_PW1_PID 0x9e6A /* USB-PW1 USB to 8 pin modular plug*/ + + /* + * Physik Instrumente