- 07 Jun, 2014 40 commits
-
-
Xose Vazquez Perez authored
commit 8f35f787 upstream. put back 0x050d,0x7050 to rt73usb, same usb_id for two chips: K7SF5D7050A ver 2xxx is rt2500 K7SF5D7050B ver 3xxx is rt73 <http://en-us-support.belkin.com/app/answers/detail/a_id/297/kw/K7SF5D7050> Signed-off-by:
Xose Vazquez Perez <xose.vazquez@gmail.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Qiang Huang <h.huangqiang@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Haojian Zhuang authored
commit e7e034e1 upstream. The RTC control register should be enabled in the process of initializing. Without this patch, I failed to enable RTC in Hisilicon Hi3620 SoC. The register mapping section in RTC is always read as zero. So I doubt that ST guys may already enable this register in bootloader. So they won't meet this issue. Signed-off-by:
Haojian Zhuang <haojian.zhuang@linaro.org> Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Alex Deucher authored
commit 6fab3feb upstream. For r6xx+ asics. This mirrors the behavior of pre-r6xx asics. We need to program the MC even if something else in startup() fails. Failure to do so results in an unusable GPU. Based on a fix from: Mark Kettenis <kettenis@openbsd.org> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> [wml: Backported to 3.4: - adjust context - drop changes to cik.c] Signed-off-by:
Weng Meiling <wengmeiling.weng@huawei.com> Signed-off-by:
-
Alex Deucher authored
commit dcb85290 upstream. These chips were previously skipped since they are pre-R600. Signed-off-by:
-
Thomas Hellstrom authored
commit 59c8e663 upstream. Also check the busy placements before deciding to move a buffer object. Failing to do this may result in a completely unneccessary move within a single memory type. Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Chris Wilson authored
commit bc5bd37c upstream. Pavel Roskin reported that DRM_IOCTL_MODE_GETCONNECTOR was overwritting the 4 bytes beyond the end of its structure with a 32-bit userspace running on a 64-bit kernel. This is due to the padding gcc inserts as the drm_mode_get_connector struct includes a u64 and its size is not a natural multiple of u64s. 64-bit kernel: sizeof(drm_mode_get_connector)=80, alignof=8 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 32-bit userspace: sizeof(drm_mode_get_connector)=76, alignof=4 sizeof(drm_mode_get_encoder)=20, alignof=4 sizeof(drm_mode_modeinfo)=68, alignof=4 Fortuituously we can insert explicit padding to the tail of our structures without breaking ABI. Reported-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Dave Airlie <airlied@redhat.com> [bwh: Backported to 3.2: adjust filename] Signed-off-by:
-
Alex Deucher authored
commit 855f5f1d upstream. We were using the wrong set_properly callback so we always ended up with Full scaling even if something else (Center or Full aspect) was selected. Signed-off-by:
-
Jani Nikula authored
commit cac6a5ae upstream. ACPI has _BCM and _BQC methods to set and query the backlight brightness, respectively. The ACPI opregion has variables BCLP and CBLV to hold the requested and current backlight brightness, respectively. The BCLP variable has range 0..255 while the others have range 0..100. This means the _BCM method has to scale the brightness for BCLP, and the gfx driver has to scale the requested value back for CBLV. If the _BQC method uses the CBLV variable (apparently some implementations do, some don't) for current backlight level reporting, there's room for rounding errors. Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values that were passed to _BCM, presuming the _BCM simply uses bclp = (in * 255) / 100 for scaling to BCLP. Reference: https://gist.github.com/aaronlu/6314920Reported-by:
Aaron Lu <aaron.lu@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> [bwh: Backported to 3.2: - Adjust context - ASLE region is treated as normal memory rather than __iomem] Signed-off-by:
-
Ondrej Zary authored
commit f7929f34 upstream. Hello, got another card with "too bright" problem: Sapphire Radeon VE 7000 DDR (VGA+S-Video) lspci -vnn: 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28] The patch below fixes the problem for this card. But I don't like the blacklist, couldn't some heuristic be used instead? The interesting thing is that the manufacturer is the same as the other card needing the same quirk. I wonder how many different types are broken this way. The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300. ==================== drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR Values from BIOS are wrong, causing too bright colors. Use default values instead. Signed-off-by:
Ondrej Zary <linux@rainbow-software.org> Signed-off-by:
-
Jani Nikula authored
commit dc652f90 upstream. Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701Signed-off-by:
Peter Verthez <peter.verthez@skynet.be> Signed-off-by:
-
Chris Wilson authored
commit 25ff1195 upstream. In order to fully serialize access to the fenced region and the update to the fence register we need to take extreme measures on SNB+, and manually flush writes to memory prior to writing the fence register in conjunction with the memory barriers placed around the register write. Fixes i-g-t/gem_fence_thrash v2: Bring a bigger gun v3: Switch the bigger gun for heavier bullets (Arjan van de Ven) v4: Remove changes for working generations. v5: Reduce to a per-cpu wbinvd() call prior to updating the fences. v6: Rewrite comments to ellide forgotten history. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Alex Deucher authored
commit 0cd9cb76 upstream. If we fail to map the mmio BAR, skip driver tear down that requires mmio. Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=56541Signed-off-by:
-
Alex Deucher authored
commit 41167828 upstream. Monitors seem to prefer it. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=37696Signed-off-by:
-
Egbert Eich authored
commit 5f85f176 upstream. NCR machines with LVDS panels using Intel chipsets need to have the QUIRK_INVERT_BRIGHTNESS bit set. Unfortunately NCR doesn't set a meaningful subvendor/subdevice ID, therefore we add a DMI dependent quirk list. Signed-off-by:
Egbert Eich <eich@suse.de> [danvet: fixup whitespace fail.] Signed-off-by:
-
Jani Nikula authored
commit 5559ecad upstream. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44156Reported-by:
Alan Zimmerman <alan.zimm@gmail.com> Signed-off-by:
-
Jani Nikula authored
commit 01e3a8fe upstream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35 [Note: There are more than one broken setups in the bug. This fixes one.] Reported-by:
Martins <andrissr@inbox.lv> Signed-off-by:
-
Jani Nikula authored
commit 1ffff603 upstream. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59628Reported-by:
Roland Gruber <post@rolandgruber.de> Signed-off-by:
-
Carsten Emde authored
commit 5a15ab5b upstream. Mark the Acer Aspire 5734Z that this machines requires the module to invert the panel backlight brightness value after reading from and prior to writing to the PCI configuration space. Signed-off-by:
Carsten Emde <C.Emde@osadl.org> Acked-by:
-
Carsten Emde authored
commit 4dca20ef upstream. A machine may need to invert the panel backlight brightness value. This patch adds the infrastructure for a quirk to do so. Signed-off-by:
-
Carsten Emde authored
commit 7bd90909 upstream. Following the documentation of the Legacy Backlight Brightness (LBB) Register in the configuration space of some Intel PCI graphics adapters, setting the LBB register with the value 0x0 causes the backlight to be turned off, and 0xFF causes the backlight to be set to 100% intensity (http://download.intel.com/embedded/processors/Whitepaper/324567.pdf). The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets it to maximum intensity at 0. In consequence, the screen of this systems becomes dark at an early boot stage which makes it unusable. The same inversion applies to the BLC_PWM_CTL I915 register. This problem was introduced in kernel version 2.6.38 when the PCI device of this system was first supported by the i915 KMS module. This patch adds a parameter to the i915 module to enable inversion of the brightness variable (i915.invert_brightness). Signed-off-by:
-
Jani Nikula authored
commit fdfa175d upstream. Amending commit 4518f611 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jan 23 16:16:35 2013 +0100 drm/i915: dump UTS_RELEASE into the error_state Signed-off-by:
-
Daniel Vetter authored
commit 4518f611 upstream. Useful for statistics or on overflowing bug reports to keep things all lined up. Reviewed-by:
-
Chris Wilson authored
commit 93be8788 upstream. As along the error path we do not correct the user pin-count for the failure, we may end up with userspace believing that it has a pinned object at offset 0 (when interrupted by a signal for example). Signed-off-by:
-
Chris Wilson authored
commit e7d841ca upstream. Before queuing the flip but crucially after attaching the unpin-work to the crtc, we continue to setup the unpin-work. However, should the hardware fire early, we see the connected unpin-work and queue the task. The task then promptly runs and unpins the fb before we finish taking the required references or even pinning it... Havoc. To close the race, we use the flip-pending atomic to indicate when the flip is finally setup and enqueued. So during the flip-done processing, we can check more accurately whether the flip was expected. v2: Add the appropriate mb() to ensure that the writes to the page-flip worker are complete prior to marking it active and emitting the MI_FLIP. On the read side, the mb should be enforced by the spinlocks. Signed-off-by:
-
Alex Deucher authored
commit 695ddeb4 upstream. Add missing index that may have led us to enabling more crtcs than necessary. May also fix: https://bugs.freedesktop.org/show_bug.cgi?id=56139Signed-off-by:
Michel Dänzer <michel.daenzer@amd.com> Signed-off-by:
-
Aaro Koskinen authored
commit eda85d6a upstream. Check that the AGP aperture can be mapped. This follows a similar change done for Radeon (commit 365048ff, drm/radeon: AGP memory is only I/O if the aperture can be mapped by the CPU.). The patch fixes the following error seen on G5 iMac: nouveau E[ DRM] failed to create kernel channel, -12 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58806Reviewed-by:
Michel Dänzer <michel@daenzer.net> Signed-off-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
-
Alex Deucher authored
commit cafa59b9 upstream. Apple cards do not provide data tables in the vbios so we have to hard code the connector parameters in the driver. Reported-by:
Albrecht Dreß <albrecht.dress@arcor.de> Signed-off-by:
-
Alex Deucher authored
commit 6a556039 upstream. RV250 found on ppc embedded boards. Cc: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by:
-
Jerome Glisse authored
commit bd25f078 upstream. Set the proper number of tile pipe that should be a multiple of pipe depending on the number of se engine. Fix: https://bugs.freedesktop.org/show_bug.cgi?id=56405 https://bugs.freedesktop.org/show_bug.cgi?id=56720 v2: Don't change sumo2 Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Reviewed-by:
-
Alex Deucher authored
commit a02dc74b upstream. Fixes flickering with some high res montiors. Signed-off-by:
-
Alex Deucher authored
commit 4c9287c6 upstream. x and y parameters are offsets, not width/height Signed-off-by:
-
Jani Nikula authored
commit d0ddfbd3 upstream. Any failures in intel_sdvo_init() after the intel_sdvo_setup_output() call left behind ghost connectors, attached (with a dangling pointer) to the sdvo that has been cleaned up and freed. Properly destroy any connectors attached to the encoder. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=46381 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jason Wang authored
commit 35848f68 upstream. Even if guest were compiled without SMP support, it could not assume that host wasn't. So switch to use mb() instead of smp_mb() to force memory barriers for UP guest. Signed-off-by:
Jason Wang <jasowang@redhat.com> Cc: Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Signed-off-by:
Qiang Huang <h.huangqiang@huawei.com> Signed-off-by:
-
Paolo Bonzini authored
commit 3a2d63f8 upstream. There are two problems with shutdown in the NBD driver. 1: Receiving the NBD_DISCONNECT ioctl does not sync the filesystem. This patch adds the sync operation into __nbd_ioctl()'s NBD_DISCONNECT handler. This is useful because BLKFLSBUF is restricted to processes that have CAP_SYS_ADMIN, and the NBD client may not possess it (fsync of the block device does not sync the filesystem, either). 2: Once we clear the socket we have no guarantee that later reads will come from the same backing storage. The patch adds calls to kill_bdev() in __nbd_ioctl()'s socket clearing code so the page cache is cleaned, lest reads that hit on the page cache will return stale data from the previously-accessible disk. Example: # qemu-nbd -r -c/dev/nbd0 /dev/sr0 # file -s /dev/nbd0 /dev/stdin: # UDF filesystem data (version 1.5) etc. # qemu-nbd -d /dev/nbd0 # qemu-nbd -r -c/dev/nbd0 /dev/sda # file -s /dev/nbd0 /dev/stdin: # UDF filesystem data (version 1.5) etc. While /dev/sda has: # file -s /dev/sda /dev/sda: x86 boot sector; etc. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Acked-by:
Paul Clements <Paul.Clements@steeleye.com> Cc: Alex Bligh <alex@alex.org.uk> Signed-off-by:
-
Ben Hutchings authored
commit b8cb62f8 upstream. 1. Check for allocation failure 2. Clear the buffer contents, as they may actually be written to flash 3. Don't leak the buffer Compile-tested only. [ Tested successfully on my buggy ASUS machine - Matt ] Signed-off-by:
Matt Fleming <matt.fleming@intel.com> Cc: Rui Xiang <rui.xiang@huawei.com> Signed-off-by:
-
Matthew Garrett authored
commit f8b84043 upstream. This patch reworks the UEFI anti-bricking code, including an effective reversion of cc5a080c and 31ff2f20. It turns out that calling QueryVariableInfo() from boot services results in some firmware implementations jumping to physical addresses even after entering virtual mode, so until we have 1:1 mappings for UEFI runtime space this isn't going to work so well. Reverting these gets us back to the situation where we'd refuse to create variables on some systems because they classify deleted variables as "used" until the firmware triggers a garbage collection run, which they won't do until they reach a lower threshold. This results in it being impossible to install a bootloader, which is unhelpful. Feedback from Samsung indicates that the firmware doesn't need more than 5KB of storage space for its own purposes, so that seems like a reasonable threshold. However, there's still no guarantee that a platform will attempt garbage collection merely because it drops below this threshold. It seems that this is often only triggered if an attempt to write generates a genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to create a variable larger than the remaining space. This should fail, but if it somehow succeeds we can then immediately delete it. I've tested this on the UEFI machines I have available, but I don't have a Samsung and so can't verify that it avoids the bricking problem. Signed-off-by:
Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ] Signed-off-by:
-
Richard Weinberger authored
commit 8c58bf3e upstream. Using this parameter one can disable the storage_size/2 check if he is really sure that the UEFI does sane gc and fulfills the spec. This parameter is useful if a devices uses more than 50% of the storage by default. The Intel DQSW67 desktop board is such a sucker for exmaple. Signed-off-by:
Richard Weinberger <richard@nod.at> Signed-off-by:
-
Sergey Vlasov authored
commit 3668011d upstream. Fixes build with CONFIG_EFI_VARS=m which was broken after the commit "x86, efivars: firmware bug workarounds should be in platform code". Signed-off-by:
Sergey Vlasov <vsu@altlinux.ru> Signed-off-by:
-
Richard Weinberger authored
commit 7791c842 upstream. Some EFI implementations return always a MaximumVariableSize of 0, check against max_size only if it is non-zero. My Intel DQ67SW desktop board has such an implementation. Signed-off-by:
-
Matt Fleming authored
commit a6e4d5a0 upstream. Let's not burden ia64 with checks in the common efivars code that we're not writing too much data to the variable store. That kind of thing is an x86 firmware bug, plain and simple. efi_query_variable_store() provides platforms with a wrapper in which they can perform checks and workarounds for EFI variable storage bugs. Cc: H. Peter Anvin <hpa@zytor.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by:
Rui Xiang <rui.xiang@huawei.com> Signed-off-by:
-
