- 28 Feb, 2013 40 commits
-
-
Chris Wilson authored
commit bc752862 upstream. We trim the fb to fit the CRTC by computing the offset of that CRTC to its nearest tile_row origin. This allows us to use framebuffers that are larger than the CRTC limits without additional work. However, we failed to compute the offset for a linear framebuffer correctly as we treated its x-advance in whole tiles (instead of the linear increment expected), leaving the CRTC misaligned with its contents. Fixes regression from commit c2c75131 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 5 12:17:30 2012 +0200 drm/i915: adjust framebuffer base address on gen4+ v2: Adjust relative x-coordinate after linear alignment (vsyrjala) v3: Repaint with pokadots (vsyrjala) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61152Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Daniel Vetter authored
commit ac4199e0 upstream. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53881 Cc: Jani Nikula <jani.nikula@intel.com> Tested-by:
Jani Monoses <jani@ubuntu.com> Signed-off-by:
-
Daniel Vetter authored
commit eb32e458 upstream. Yet another remnant ... this might explain why l3 remapping didn't really work on HSW. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441Spotted-by:
Ben Widawsky <ben@bwidawsk.net> 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:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
Patrik Jakobsson authored
commit 4f7dfb67 upstream. The Intel PRM says the M1 and M2 divisors must be in the range of 10-20 and 5-9. Since we do all calculations based on them being register values (which are subtracted by 2) we need to specify them accordingly. Signed-off-by:
Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Reviewed-by:
-
Mika Kuoppala authored
commit 24a1f16d upstream. If encoder is switched off by BIOS, but the panel fitter is left on, we never try to turn off the panel fitter and leave it still attached to the pipe - which can cause blurry output elsewhere. Based on work by Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58867Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Tested-by:
Andreas Sturmlechner <andreas.sturmlechner@gmail.com> [danvet: Remove the redundant HAS_PCH_SPLIT check and add a tiny comment.] Signed-off-by:
-
Daniel Vetter authored
commit cf0a6584 upstream. 770c1231 is the first bad commit commit 770c1231 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid changed the register write sequence for restoring the backlight, which helped prevent non-working backlights on some machines. Turns out that the original sequence was the right thing to do for a different set of machines. Worse, setting the backlight level _after_ enabling it seems to reset it somehow. So we need to make that one conditional upon the backlight having been reset to zero, and add the old one back. Cargo-culting at it's best, but it seems to work. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Ben Widawsky authored
commit 7083e050 upstream. The RC6 VIDS has a linear ramp starting at 250mv, which means any values below 250 are invalid. The old buggy macros tried to adjust for this to be more flexible, but there is no need. As Dan pointed out the ENCODE only ever has one value. The only invalid value for decode is an input of 0 which means something is really wonky, and the cases where DECODE are used either don't matter (debug values), or would be implicitly correct (the check for less than 450). This patch makes simpler, easier to read macros which are actually correct. Maybe this patch can actually fix some bugs now. Thanks to Dan for catching this. /me hides Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ben Widawsky authored
commit f82855d3 upstream. The shift changed, hurray. Reported-by:
Kenneth Graunke <kenneth@whitecape.org> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
-
Chris Wilson authored
commit 725a5b54 upstream. When adding the fb idle detection to mark-inactive, it was forgotten that userspace can drive the processing of retire-requests. We assumed that it would be principally driven by the retire requests worker, running once every second whilst active and so we would get the deferred timer for free. Instead we spend too many CPU cycles reclocking the LVDS preventing real work from being done. Signed-off-by:
Alexander Lam <lambchop468@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58843Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Damien Lespiau authored
commit 3e68320e upstream. The FDI link has supported link reversal to make the PCB layout engineer's life easier for quite a while and we have always presered this bit as we programmed FDI_RX_CTL with a read/modify/write sequence. We're trying to take a bit more control over what the BIOS leaves in various register and with the introduction of DDI, started to program FDI_RX_CTL fully. There's a fused bit to indicate DMI link reversal and FDI defaults to mirroring that configuration. We have a bit to override that behaviour that we need to preserve from the BIOS. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Damien Lespiau authored
commit 876a8cdf upstream. Similarly to: commit 6a0d1df3d3a0d2370541164eb0595fe35dcd6de3 Author: Damien Lespiau <damien.lespiau@intel.com> Date: Tue Dec 11 15:18:28 2012 +0000 drm/i915: Preserve the FDI line reversal override bit on CPT DDI port support lane reversal to easy the PCB layouting work. Let's preserve the bit configured by the BIOS (until we find how to correctly retrieve the information from the VBT, but this does sound more fragile then just relying on the BIOS that has, hopefully, been validated already. Signed-off-by:
-
Al Viro authored
commit 9b40bc90 upstream. It's safe only under namespace_sem or vfsmount_lock; all places in fs/namespace.c that want mnt->mnt_ns->user_ns actually want to use current->nsproxy->mnt_ns->user_ns (note the calls of check_mnt() in there). Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Daniel Vetter authored
commit 210561ff upstream. We already have the quirk entry for the mobile platform, but also reports on some desktop versions. So be paranoid and set it everywhere. References: http://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg33138.htmlReported-and-tested-by:
Mihai Moldovan <ionic@ionic.de> Cc: David Woodhouse <dwmw2@infradead.org> Cc: "Sankaran, Rajesh" <rajesh.sankaran@intel.com> Signed-off-by:
-
Dave Airlie authored
commit 9f23de52 upstream. While looking at plymouth on udl I noticed that plymouth was trying to use its fb plugin not its drm one, it was trying to drmOpen a driver called usb not udl, noticed that we actually had out driver pointing at the wrong device. Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
Daniel Vetter authored
commit db3985e5 upstream. This reverts commit 6f33814b. The quirk cause a regression, and it looks like the original bug was simply a lack of FIFO bandwidth on the i915G of the reporter. Which should eventually be fixed as soon as we get around to implemented DSPARB FIFO reassignment on gen 3. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=52281Signed-off-by:
-
Ville Syrjälä authored
commit d84f031b upstream. Support for real RGB332 is a rarity, most hardware only really support C8. So use C8 instead of RGB332 when determining the format based on depth/bpp. This fixes 8bpp fbcon on i915, since i915 will only accept C8 and not RGB332. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59572Signed-off-by:
Dave Airlie <airlied@gmail.com> Tested-by: mlsemon35@gmail.com Signed-off-by:
-
Ville Syrjälä authored
commit c51a6bc5 upstream. Set depth/bits_per_pixel to 8 for C8 format. Signed-off-by:
-
Maarten Lankhorst authored
commit f934ec8c upstream. My cheapo monitor has an invalid block 1, resulting in a lot of dmesg spam every few seconds. I get it the first time that the entire block is all 0xff.. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
-
Paulo Zanoni authored
commit 196e077d upstream. If bit 0 of the features byte (0x18) is set to 0, then, according to the EDID spec, "the display is non-continuous frequency (multi-mode) and is only specified to accept the video timing formats that are listed in Base EDID and certain Extension Blocks". For more information, please see the EDID spec, check the notes of the table that explains the "Feature Support" byte (18h) and also the notes on the tables of the section that explains "Display Range Limits & Additional Timing Description Definition (tag #FDh)". Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Alex Williamson authored
commit 969daa34 upstream. PCI_EXP_FLAGS_TYPE is a mask, not an offset. Fix it. Previously, pcie_capability_read_word(..., PCI_EXP_FLAGS, ...) would fail. [bhelgaas: tweak changelog] Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Dave Airlie authored
commit 2a248307 upstream. When we switch from 256->512 byte font rendering mode, it means the current contents of the screen is being reinterpreted. The bit that holds the high bit of the 9-bit font, may have been previously set, and thus the new font misrenders. The problem case we see is grub2 writes spaces with the bit set, so it ends up with data like 0x820, which gets reinterpreted into 0x120 char which the font translates into G with a circumflex. This flashes up on screen at boot and is quite ugly. A current side effect of this patch though is that any rendering on the screen changes color to a slightly darker color, but at least the screen no longer corrupts. v2: as suggested by hpa, always clear the attribute space, whether we are are going to or from 512 chars. Signed-off-by:
-
Dave Airlie authored
commit 677d23b7 upstream. There seems to be a bad interaction between gem/shmem and defio on top, I get list corruption on the page lru in the shmem code. Turn it off for now until we get some more digging done. Signed-off-by:
-
Dave Airlie authored
commit bcb39af4 upstream. Okay you don't really want to use udl devices as your console, but if you are unlucky enough to do so, you run into a lot of schedule while atomic due to printk being called from all sorts of funky places. So check if we are in an atomic context, and queue the damage for later, the next printk should cause it to appear. This isn't ideal, but it is simple, and seems to work okay in my testing here. (dirty area idea came from xenfb) fixes a bunch of sleeping while atomic issues running fbcon on udl devices. Signed-off-by:
-
Alex Deucher authored
commit 43a23aa4 upstream. Some bioses don't set the function mask correctly which caused required functions to be disabled. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=53111Signed-off-by:
-
Alex Deucher authored
commit c944b2ab upstream. hdmi audio works fine. The warning just confuses users. fixes: https://bugzilla.kernel.org/show_bug.cgi?id=44341Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Alex Deucher authored
commit 7ae764b1 upstream. vddci needs to track mclk for multi-head. Signed-off-by:
-
Alex Deucher authored
commit 0e3d50bf upstream. Only enable it when we disable the display rather than at DPMS time since enabling it requires a full modeset to restore the display state. Fixes blank screens in certain cases. Signed-off-by:
-
David S. Miller authored
[ Upstream commit 76968ad2 ] When we set the sun4u version of the PTE execute bit, it's: or REG, _PAGE_EXEC_4U, REG _PAGE_EXEC_4U is 0x1000, unfortunately the immedate field of the 'or' instruction is a signed 13-bit value. So the above actually assembles into: or REG, -4096, REG completely corrupting the final PTE value. Set it with a: sethi %hi(_PAGE_EXEC_4U), TMP or REG, TMP, REG sequence instead. This fixes "git gc" crashes on sun4u machines. Reported-by:
Meelis Roos <mroos@linux.ee> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David S. Miller authored
[ Upstream commit 0fbebed6 ] If our first THP installation for an MM is via the set_pmd_at() done during khugepaged's collapsing we'll end up in tsb_grow() trying to do a GFP_KERNEL allocation with several locks held. Simply using GFP_ATOMIC in this situation is not the best option because we really can't have this fail, so we'd really like to keep this an order 0 GFP_KERNEL allocation if possible. Also, doing the TSB allocation from khugepaged is a really bad idea because we'll allocate it potentially from the wrong NUMA node in that context. So what we do is defer the hugepage TSB allocation until the first TLB miss we take on a hugepage. This is slightly tricky because we have to handle two unusual cases: 1) Taking the first hugepage TLB miss in the window trap handler. We'll call the winfix_trampoline when that is detected. 2) An initial TSB allocation via TLB miss races with a hugetlb fault on another cpu running the same MM. We handle this by unconditionally loading the TSB we see into the current cpu even if it's non-NULL at hugetlb_setup time. Reported-by:
Meelis Roos <mroos@ut.ee> Signed-off-by:
-
David S. Miller authored
[ Upstream commit bcd896ba ] Accomodate the possibility that the TSB might be NULL at the point that update_mmu_cache() is invoked. This is necessary because we will sometimes need to defer the TSB allocation to the first fault that happens in the 'mm'. Seperate out the hugepage PTE test into a seperate function so that the logic is clearer. Signed-off-by:
-
David S. Miller authored
[ Upstream commit a55ee1ff ] We should "|= more_flags" rather than "= more_flags". Reported-by:
David Rientjes <rientjes@google.com> Acked-by:
-
Bob Peterson authored
commit d2b47cfb upstream. This patch allocates a block reservation structure before growing or shrinking a file. Without this structure, the grow or shink code can reference the bad pointer. Signed-off-by:
Bob Peterson <rpeterso@redhat.com> Signed-off-by:
Steven Whitehouse <swhiteho@redhat.com> Signed-off-by:
-
David Henningsson authored
commit bbfd8a19 upstream. Currently, eld_valid is never set to false, except at kernel module load time. This patch makes sure that eld is no longer valid when the cable is (hot-)unplugged. Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Takashi Iwai authored
commit ea9b43ad upstream. The commit [dcda5806: ALSA: hda - Add workaround for conflicting IEC958 controls] introduced a workaround for cards that have both SPDIF and HDMI devices for giving device=1 to SPDIF control elements. It turned out, however, that this workaround doesn't work well - - The workaround checks only conflicts in a single codec, but SPDIF and HDMI are provided by multiple codecs in many cases, and - ALSA mixer abstraction doesn't care about the device number in ctl elements, thus you'll get errors from amixer such as % amixer scontrols -c 0 ALSA lib simple_none.c:1551:(simple_add1) helem (MIXER,'IEC958 Playback Switch',0,1,0) appears twice or more amixer: Mixer hw:0 load error: Invalid argument This patch fixes the previous broken workaround. Instead of changing the device number of SPDIF ctl elements, shift the element indices of such controls up to 16. Also, the conflict check is performed over all codecs found on the bus. HDMI devices will be put to dev=0,index=0 as before. Only the conflicting SPDIF device is moved to a different place. The new place of SPDIF device is supposed by the updated alsa-lib HDA-Intel.conf, respectively. Reported-by:
Stephan Raue <stephan@openelec.tv> Reported-by:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
-
Fernando Luis Vazquez Cao authored
commit 12e31a78 upstream. Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by the same issue that caused Vaio Z laptops to become silent: the speaker pin must be connected to the first DAC even though the codec itself advertises flexible routing through any of the DACs. Use the no-primary-hp fixup for choosing the speaker pin as the primary so that the right DAC is assigned on this device. Signed-off-by:
Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp> Signed-off-by:
-
Anssi Hannula authored
commit 20608731 upstream. Commit d45e6889 ("ALSA: hda - Provide the proper channel mapping for generic HDMI driver") added support for custom channel maps in the HDA HDMI driver. Due to a mistake in an 'if' condition the custom map is always used even when no such map has been set. This causes incorrect channel mapping for multichannel audio by default. Pass per_pin->chmap_set to hdmi_setup_channel_mapping() as a parameter so that it can use it for detecting if a custom map has been set instead of checking if map is NULL (which is never the case). Reported-by:
Staffan Lindberg <pike@xbmc.org> Signed-off-by:
-
Takashi Iwai authored
commit 2ad779b7 upstream. If the driver detects and invalid ELD, it gives an open error. But it forgot to release the assigned pin, converter and spdif ctls before returning. Signed-off-by:
-
Takashi Iwai authored
commit 2c1350fd upstream. We've got a regression report wrt the IRQ issue related with the power-save on a Dell machine, and disabling runtime PM works around. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=53441Signed-off-by:
-
Pawel Moll authored
commit b531f81b upstream. Commit 99fc8645 "ALSA: usb-mixer: parse descriptors with structs" introduced a set of useful parsers for descriptors. Unfortunately the parses for the Processing Unit Descriptor came with a very subtle bug... Functions uac_processing_unit_iProcessing() and uac_processing_unit_specific() were indexing the baSourceID array forgetting the fields before the iProcessing and process-specific descriptors. The problem was observed with Sound Blaster Extigy mixer, where nNrModes in Up/Down-mix Processing Unit Descriptor was accessed at offset 10 of the descriptor (value 0) instead of offset 15 (value 7). In result the resulting control had interesting limit values: Simple mixer control 'Channel Routing Mode Select',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - -1 Mono: -1 [100%] Fixed by starting from the bmControls, which was calculated correctly, instead of baSourceID. Now the mentioned control is fine: Simple mixer control 'Channel Routing Mode Select',0 Capabilities: volume volume-joined penum Playback channels: Mono Capture channels: Mono Limits: 0 - 6 Mono: 0 [0%] Signed-off-by:
Pawel Moll <mail@pawelmoll.com> Signed-off-by:
-
