- 27 Jul, 2016 40 commits
-
-
David Daney authored
commit 1b45996d upstream. We are getting somewhat random soft lockups with this signature: [ 86.992215] [<fffffc00080935e0>] el1_irq+0xa0/0x10c [ 86.997082] [<fffffc000841822c>] cursor_timer_handler+0x30/0x54 [ 87.002991] [<fffffc000810ec44>] call_timer_fn+0x54/0x1a8 [ 87.008378] [<fffffc000810ef88>] run_timer_softirq+0x1c4/0x2bc [ 87.014200] [<fffffc000809077c>] __do_softirq+0x114/0x344 [ 87.019590] [<fffffc00080af45c>] irq_exit+0x74/0x98 [ 87.024458] [<fffffc00080fac20>] __handle_domain_irq+0x98/0xfc [ 87.030278] [<fffffc000809056c>] gic_handle_irq+0x94/0x190 This is caused by the vt visual_init() function calling into fbcon_init() with a vc_cur_blink_ms value of zero. This is a transient condition, as it is later set to a non-zero value. But, if the timer happens to expire while the blink rate is zero, it goes into an endless loop, and we get soft lockup. The fix is to initialize vc_cur_blink_ms before calling the con_init() function. Signed-off-by:
David Daney <david.daney@cavium.com> Acked-by:
Pavel Machek <pavel@ucw.cz> Tested-by:
Ming Lei <ming.lei@canonical.com> Acked-by:
Scot Doyle <lkml14@scotdoyle.com> Tested-by:
Henrique de Moraes Holschuh <hmh@hmh.eng.br> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Mark Brown authored
commit 68b356eb upstream. Currently the ad7266 driver treats any failure to get vref as though the regulator were not present but this means that if probe deferral is triggered the driver will act as though the regulator were not present. Instead only use the internal reference if we explicitly got -ENODEV which is what is returned for absent regulators. Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Mark Brown authored
commit e5511c81 upstream. The ad7266 driver attempts to support deciding between the use of internal and external power supplies by checking to see if an error is returned when requesting the regulator. This doesn't work with the current code since the driver uses a normal regulator_get() which is for non-optional supplies and so assumes that if a regulator is not provided by the platform then this is a bug in the platform integration and so substitutes a dummy regulator. Use regulator_get_optional() instead which indicates to the framework that the regulator may be absent and provides a dummy regulator instead. Signed-off-by:
-
Mark Brown authored
commit 6b7f4e25 upstream. All regulator_get() variants return either a pointer to a regulator or an ERR_PTR() so testing for NULL makes no sense and may lead to bugs if we use NULL as a valid regulator. Fix this by using IS_ERR() as expected. Signed-off-by:
-
Linus Walleij authored
commit 0c1f91b9 upstream. These two spi_w8r8() calls return a value with is used by the code following the error check. The dubious use was caused by a cleanup patch. Fixes: d34dbee8 ("staging:iio:accel:kxsd9 cleanup and conversion to iio_chan_spec.") Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Luis de Bethencourt authored
commit ef3149eb upstream. sca3000_read_ctrl_reg() returns a negative number on failure, check for this instead of zero. Signed-off-by:
Luis de Bethencourt <luisbg@osg.samsung.com> Signed-off-by:
-
Matt Ranostay authored
commit 94bef000 upstream. Shifting sensor data to the right 2 bits was incorrect and caused the scaling values + offsets to be invalid. Reported-by:
Alison Schofield <amsfield22@gmail.com> Signed-off-by:
Matt Ranostay <mranostay@gmail.com> Tested-by:
-
Matt Ranostay authored
commit 09bc0dda upstream. IIO_TEMP channel was being incorrectly reported back as Celsius when it should have been milliCelsius. This is via an incorrect scale value being returned to userspace. Signed-off-by:
-
Alison Schofield authored
commit 0e35cf5c upstream. Apply the correct mask to enable all available humidity integration times. Currently, the driver defaults to 6500 and all is okay with that. However, if 3850 is selected we get a stuck bit and can't change back to 6500 or select 2500. (Verified with HDC1008) Signed-off-by:
-
Matt Ranostay authored
commit 37b1ba2c upstream. Buffer wasn't of a valid size to allow the timestamp, and correct padding. This patchset also moves the buffer off the stack, and onto the heap. Cc: george.mccollister@gmail.com Signed-off-by:
-
Matt Ranostay authored
commit 7d064363 upstream. Triggered buffers shouldn't return processed data, and the respective conversion was overflowing the defined .realbits for the channel. Cc: george.mccollister@gmail.com Signed-off-by:
-
Matt Ranostay authored
commit 5138806f upstream. IIO_CHAN_INFO_RAW was returning processed data which was incorrect. This also adds the IIO_CHAN_INFO_SCALE value to convert to a processed value. Signed-off-by:
-
Yong Li authored
commit 590b92a3 upstream. Without this, the iio:deviceX is missing in the /sys/bus/i2c/devices/0-0039 Some userspace tools use this path to identify a specific instance of the device. Signed-off-by:
Yong Li <sdliyong@gmail.com> Reviewed-By:
-
Gregor Boirie authored
commit d43a4115 upstream. Temperature channels report scaled samples in Celsius although expected as milli degree Celsius in Documentation/ABI/testing/sysfs-bus-iio. Gains are not implemented at all for LPS001WP pressure and temperature channels. This patch ensures that proper offsets and scales are exposed to userpace for both pressure and temperature channels. Also fix a NULL pointer exception when userspace reads content of sysfs scale attribute when gains are not defined. Signed-off-by:
Gregor Boirie <gregor.boirie@parrot.com> Signed-off-by:
-
Crestez Dan Leonard authored
commit 99543823 upstream. When attaching a pollfunc iio_trigger_attach_poll_func will allocate a virtual irq and call the driver's set_trigger_state function. Fix error handling to undo previous steps if any fails. In particular this fixes handling errors from a driver's set_trigger_state function. When using triggered buffers a failure to enable the trigger used to make the buffer unusable. Signed-off-by:
Crestez Dan Leonard <leonard.crestez@intel.com> Signed-off-by:
-
Ross Lagerwall authored
commit 842775f1 upstream. Fix a declared-but-not-defined warning when building with XEN_BALLOON_MEMORY_HOTPLUG=n. This fixes a regression introduced by commit dfd74a1e ("xen/balloon: Fix crash when ballooning on x86 32 bit PAE"). Signed-off-by:
Ross Lagerwall <ross.lagerwall@citrix.com> Acked-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Andrey Ryabinin authored
commit 6d6f2833 upstream. Jim reported: UBSAN: Undefined behaviour in arch/x86/events/intel/core.c:3708:12 shift exponent 35 is too large for 32-bit type 'long unsigned int' The use of 'unsigned long' type obviously is not correct here, make it 'unsigned long long' instead. Reported-by:
Jim Cromie <jim.cromie@gmail.com> Signed-off-by:
Andrey Ryabinin <aryabinin@virtuozzo.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Imre Palik <imrep@amazon.de> Cc: Jiri Olsa <jolsa@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian <eranian@google.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Vince Weaver <vincent.weaver@maine.edu> Fixes: 2c33645d ("perf/x86: Honor the architectural performance monitoring version") Link: http://lkml.kernel.org/r/1462974711-10037-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by:
Ingo Molnar <mingo@kernel.org> Cc: Kevin Christopher <kevinc@vmware.com> Signed-off-by:
-
Ocquidant, Sebastien authored
commit 8f50b8e5 upstream. In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY is overwritten by the WEEXTRADELAY value from the device tree and GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device tree. As a consequence, the memory accesses cannot be configured properly when the extra delay are needed for OE and WE. Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the device tree file and prevents GPMC_CONFIG4_OEXTRADELAY being overwritten by the WEXTRADELAY value from the device tree. Signed-off-by:
Ocquidant, Sebastien <sebastienocquidant@eaton.com> Signed-off-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Sinclair Yeh authored
commit 58541f7a upstream. Rather than returning immediately, make sure to unlock the mutexes first. Signed-off-by:
Sinclair Yeh <syeh@vmware.com> Reviewed-by:
Charmaine Lee <charmainel@vmware.com> Reported-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Sinclair Yeh authored
commit d5f1a291 upstream. For the Screen Object display unit, we need to reserve a guest-invisible region equal to the size of the framebuffer for the host. This region can only be reserved in VRAM, whereas the guest-visible framebuffer can be reserved in either VRAM or GMR. As such priority should be given to the guest-invisible region otherwise in a limited VRAM situation, we can fail to allocate this region. This patch makes it so that vmw_sou_backing_alloc() is called before the framebuffer is pinned. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Sinclair Yeh authored
commit 4ed7e224 upstream. In certain scenarios, e.g. when fbdev is enabled, we can get into a situation where a vmw_framebuffer_pin() is called on a buffer that is already pinned. When this happens, ttm_bo_validate() will unintentially remove the TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way to actually pin the buffer again. To prevent this, if a buffer is already pinned, then instead of calling ttm_bo_validate(), just make sure the proposed placement is compatible with the existing placement. Signed-off-by:
-
Sinclair Yeh authored
commit 7c20d213 upstream. In a low-memory 2D VM, fbdev can take up a large percentage of available memory, making them unavailable for other DRM clients. Since we do not take fbdev into account when filtering modes, we end up claiming to support more modes than we actually do. As a result, users get a black screen when setting a mode too large for current available memory. In a low-memory VM configuration, users can get a black screen for a mode as low as 1024x768. The current mode filtering mechanism keys off of SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount of surface memory we have. Since this value is a performance suggestion, not a hard limit, and since there should not be much of a performance impact for a 2D VM, rather than filtering out more modes, we will just allow ourselves to exceed the SVGA's performance suggestion. Also changed assumed bpp to 32 from 16 to make sure we can actually support all the modes listed. Signed-off-by:
-
Sinclair Yeh authored
commit 04319d89 upstream. Offer an option for advanced users who want larger modes at 16bpp. This becomes necessary after the fix: "Work around mode set failure in 2D VMs." Without this patch, there would be no way for existing advanced users to get to a high res mode, and the regression is they will likely get a black screen after a software update on their current VM. Signed-off-by:
-
Sinclair Yeh authored
commit 94477bff upstream. There are cases where it is desired to see if a proposed placement is compatible with a buffer object before calling ttm_bo_validate(). Signed-off-by:
-
Boris Brezillon authored
commit 1b7e38b9 upstream. The driver is only enabling scaling, but never disabling it, thus, if you enable the scaling feature once it stays enabled forever. Signed-off-by:
Boris Brezillon <boris.brezillon@free-electrons.com> Reported-by:
Alex Vazquez <avazquez.dev@gmail.com> Reviewed-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Fixes: 1a396789 ("drm: add Atmel HLCDC Display Controller support") Signed-off-by:
-
Tomi Valkeinen authored
commit 6709887c upstream. drm_atomic_set_mode_prop_for_crtc() does not clear the state->mode, so old data may be left there when a new mode is set, possibly causing odd issues. This patch improves the situation by always clearing the state->mode first. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Tomi Valkeinen authored
commit b201e743 upstream. When setting mode via MODE_ID property, drm_atomic_set_mode_prop_for_crtc() does not call drm_mode_set_crtcinfo() which possibly causes: "[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 32: Can't calculate constants, dotclock = 0!" Whether the error is seen depends on the previous data in state->mode, as state->mode is not cleared when setting new mode. This patch adds drm_mode_set_crtcinfo() call to drm_mode_convert_umode(), which is called in both legacy and atomic paths. This should be fine as there's no reason to call drm_mode_convert_umode() without also setting the crtc related fields. drm_mode_set_crtcinfo() is removed from the legacy drm_mode_setcrtc() as that is no longer needed. Signed-off-by:
-
Ville Syrjälä authored
commit a04e23d4 upstream. Update CDCLK_FREQ on BDW after changing the cdclk frequency. Not sure if this is a late addition to the spec, or if I simply overlooked this step when writing the original code. This is what Bspec has to say about CDCLK_FREQ: "Program this field to the CD clock frequency minus one. This is used to generate a divided down clock for miscellaneous timers in display." And the "Broadwell Sequences for Changing CD Clock Frequency" section clarifies this further: "For CD clock 337.5 MHz, program 337 decimal. For CD clock 450 MHz, program 449 decimal. For CD clock 540 MHz, program 539 decimal. For CD clock 675 MHz, program 674 decimal." Cc: stable@vger.kernel.org Cc: Mika Kahola <mika.kahola@intel.com> Fixes: b432e5cf ("drm/i915: BDW clock change support") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1461689194-6079-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by:
Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 7f1052a8) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
commit b1924006 upstream. In commit 7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER when appropriate") the owner field in the mutex was updated from being dependent upon CONFIG_SMP to using optimistic spin. Update our peek function to suite. Fixes:7608a43d ("locking/mutexes: Use MUTEX_SPIN_ON_OWNER...") Reported-by:
Hong Liu <hong.liu@intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1468244777-4888-1-git-send-email-chris@chris-wilson.co.ukReviewed-by:
Matthew Auld <matthew.auld@intel.com> (cherry picked from commit 4f074a53) Signed-off-by:
-
Ville Syrjälä authored
commit 664a84d2 upstream. During hibernation the cached DP port register value will be left with whatever value we have there when we create the hibernation image. Currently that means the port (and eDP PLL) will be off in the cached value. However when we resume there is no guarantee that the value in the actual register will match the cached value. If i915 isn't loaded in the kernel that loads the hibernation image, the port may well be on (eg. left on by the BIOS). The encoder state readout does the right thing in this case and updates our encoder state to reflect the actual hardware state. However the post-resume modeset will then use the stale cached port register value in intel_dp_link_down() and potentially confuse the hardware. This was caught by the following assert WARNING: CPU: 3 PID: 5288 at ../drivers/gpu/drm/i915/intel_dp.c:2184 assert_edp_pll+0x99/0xa0 [i915] eDP PLL state assertion failure (expected on, current off) on account of the eDP PLL getting prematurely turned off when shutting down the port, since the DP_PLL_ENABLE bit wasn't set in the cached register value. Presumably I introduced this problem in commit 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") as before that we didn't update the cached value after shuttting the port down. That's assuming the port got enabled at least once prior to hibernating. If that didn't happen then the cached value would still have been totally out of sync with reality (eg. first boot w/o eDP on, then hibernate, and then resume with eDP on). So, let's fix this properly and refresh the cached register value from the hardware register during resume. DDI platforms shouldn't use the cached value during port disable at least, so shouldn't have this particular issue. They might still have issues if we skip the initial modeset and then try to retrain the link or something. But untangling this DP vs. DDI mess is a bigger topic, so let's jut punt on DDI for now. Cc: Jani Nikula <jani.nikula@intel.com> Fixes: 6fec7662 ("drm/i915: Use intel_dp->DP in eDP PLL setup") Signed-off-by:
Imre Deak <imre.deak@intel.com> (cherry picked from commit 64989ca4) Signed-off-by:
-
Lyude authored
commit 476490a9 upstream. Thanks to Ville Syrjälä for pointing me towards the cause of this issue. Unfortunately one of the sideaffects of having the refclk for a DPLL set to SSC is that as long as it's set to SSC, the GPU will prevent us from powering down any of the pipes or transcoders using it. A couple of BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL configurations. This causes issues on the first modeset, since we don't expect SSC to be left on and as a result, can't successfully power down the pipes or the transcoders using it. Here's an example from this Dell OptiPlex 990: [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled [drm:intel_modeset_init] 2 display pipes available. [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [drm:intel_crt_reset] crt adpa set to 0xf40000 [drm:intel_dp_init_connector] Adding DP connector on port C [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1 [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0 [drm:ironlake_init_pch_refclk] Disabling SSC entirely … later we try committing the first modeset … [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A [drm:intel_dump_pipe_config] cpu_transcoder: A … [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07 [drm:intel_dump_pipe_config] planes on this crtc [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled [drm:intel_dump_pipe_config] FB:42, fb = 800x600 format = 0x34325258 [drm:intel_dump_pipe_config] scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600 [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0 [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0 [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A [drm:intel_disable_pipe] disabling pipe A ------------[ cut here ]------------ WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915] pipe_off wait timed out … ---[ end trace 94fc8aa03ae139e8 ]--- [drm:intel_dp_link_down] [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A Later modesets succeed since they reset the DPLL's configuration anyway, but this is enough to get stuck with a big fat warning in dmesg. A better solution would be to add refcounts for the SSC source, but for now leaving the source clock on should suffice. Changes since v4: - Fix calculation of final for systems with LVDS panels (fixes BUG() on CI test suite) Changes since v3: - Move temp variable into loop - Move checks for using_ssc_source to after we've figured out has_ck505 - Add using_ssc_source to debug output Changes since v2: - Fix debug output for when we disable the CPU source Changes since v1: - Leave the SSC source clock on instead of just shutting it off on all of the DPLL configurations. Reviewed-by:
Lyude <cpaul@redhat.com> Signed-off-by:
-
Ben Skeggs authored
commit 21721504 upstream. Fixes a regression caused by a stupid thinko from "disp/sor/gf119: both links use the same training register". Signed-off-by:
Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Dmitrii Tcvetkov authored
commit 52dfcc5c upstream. Hello, after this commit: commit f045f459 Author: Ben Skeggs <bskeggs@redhat.com> Date: Thu Jun 2 12:23:31 2016 +1000 drm/nouveau/fbcon: fix out-of-bounds memory accesses kernel started to oops when loading nouveau module when using GTX 780 Ti video adapter. This patch fixes the problem. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=120591Signed-off-by:
Dmitrii Tcvetkov <demfloro@demfloro.ru> Suggested-by:
Ilia Mirkin <imirkin@alum.mit.edu> Fixes: f045f459 ("nouveau_fbcon_init()") Signed-off-by:
-
Ben Skeggs authored
commit f045f459 upstream. Reported by KASAN. Signed-off-by:
-
Ben Skeggs authored
commit 383d0a41 upstream. Signed-off-by:
-
Ben Skeggs authored
commit a8953c52 upstream. It appears that, for whatever reason, both link A and B use the same register to control the training pattern. It's a little odd, as the GPUs before this (Tesla/Fermi1) have per-link registers, as do newer GPUs (Maxwell). Fixes the third DP output on NVS 510 (GK107). Signed-off-by:
-
Michael S. Tsirkin authored
commit 87c9403b upstream. Everything should be LE when using virtio-1, but the linux balloon driver does not seem to care about that. Reported-by:
Cornelia Huck <cornelia.huck@de.ibm.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Tested-by:
-
Andrey Grodzovsky authored
commit fd2d2bac upstream. Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch. Fixes: 91a25e46 ("drm/dp/mst: deallocate payload on port destruction") Signed-off-by:
Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Reviewed-by:
-
Oded Gabbay authored
commit bc4755a4 upstream. amdkfd need to destroy the debug manager in case amdkfd's notifier function is called before the unbind function, because in that case, the unbind function will exit without destroying debug manager. Signed-off-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
Oded Gabbay authored
commit 121b78e6 upstream. When unbinding a process from a device (initiated by amd_iommu_v2), the driver needs to make sure that process still exists in the process table. There is a possibility that amdkfd's own notifier handler - kfd_process_notifier_release() - was called before the unbind function and it already removed the process from the process table. v2: Because there can be only one process with the specified pasid, and because *p can't be NULL inside the hash_for_each_rcu macro, it is more reasonable to just put the whole code inside the if statement that compares the pasid value. That way, when we exit hash_for_each_rcu, we simply exit the function as well. Signed-off-by:
-
