- 28 Feb, 2013 40 commits
-
-
Dave Airlie authored
commit ae128786 upstream. If grub2 loads efifb/vesafb, then when systemd starts it can set the console font on that framebuffer device, however when we then load the native KMS driver, the first thing it does is tear down the generic framebuffer driver. The thing is the generic code is doing the right thing, it frees the font because otherwise it would leak memory. However we can assume that if you are removing the generic firmware driver (vesa/efi/offb), that a new driver *should* be loading soon after, so we effectively leak the font. However the old code left a dangling pointer in vc->vc_font.data and we can now reuse that dangling pointer to load the font into the new driver, now that we aren't freeing it. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340Signed-off-by:
Dave Airlie <airlied@redhat.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Anatolij Gustschin authored
commit b2639b5f upstream. Since commit f74de500 "drivers/video: fsl-diu-fb: streamline enabling of interrupts" the interrupt handling in the driver is broken. Enabling diu interrupt causes an interrupt storm and results in system lockup. The cookie for the interrupt handler function passed to request_irq() is wrong (it must be a pointer to the diu struct, and not the address of the pointer to the diu struct). As a result the interrupt handler can not read diu registers and acknowledge the interrupt. Fix cookie arguments for request_irq() and free_irq(). Registering the diu interrupt handler in probe() must happen before install_fb() calls since this function registers framebuffer devices and if fbcon tries to take over framebuffer after registering a frame buffer device, it will call fb_open of the diu driver and enable the interrupts. At this time the diu interrupt handler must be registered already. Disabling the interrupts in fsl_diu_release() must happen only if all other AOIs are closed. Otherwise closing an overlay plane will disable the interrupts even if the primary frame buffer plane is opened. Add an appropriate check in the release function. Signed-off-by:
Anatolij Gustschin <agust@denx.de> Cc: Timur Tabi <timur@tabi.org> Signed-off-by:
-
Anatolij Gustschin authored
commit 5d3cc311 upstream. Framebuffer colors for 24 and 16 bpp are currently wrong. The order of the color component arguments in the MAKE_PF() is not natural and causes some confusion. The generated pixel format values for 24 and 16 bpp depths do not much the values in the comments. Fix the macro arguments to be in the natural RGB order and adjust the arguments for all depths to generate correct pixel format values (equal to the values mentioned in the comments). Signed-off-by:
Timur Tabi <timur@freescale.com> Signed-off-by:
-
Jean Delvare authored
commit 811af972 upstream. It doesn't seem this spinlock was properly initialized. This bug was introduced by commit 7a410e8d. Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
John David Anglin authored
commit 7139bc15 upstream. This patch goes a long way toward fixing the minifail bug, and it significantly improves the stability of SMP machines such as the rp3440. When write protecting a page for COW, we need to purge the existing translation. Otherwise, the COW break doesn't occur as expected because the TLB may still have a stale entry which allows writes. [jejb: fix up checkpatch errors] Signed-off-by:
John David Anglin <dave.anglin@bell.net> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
-
Thadeu Lima de Souza Cascardo authored
commit 6a040ce7 upstream. The DDW code uses a eeh_dev struct from the pci_dev. However, this is not set until eeh_add_device_late is called. Since pci_bus_add_devices is called before eeh_add_device_late, the PCI devices are added to the bus, making drivers' probe hooks to be called. These will call set_dma_mask, which will call the DDW code, which will require the eeh_dev struct from pci_dev. This would result in a crash, due to a NULL dereference. Calling eeh_add_device_late after pci_bus_add_devices would make the system BUG, because device files shouldn't be added to devices there were not added to the system. So, a new function is needed to add such files only after pci_bus_add_devices have been called. Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com> Acked-by:
Gavin Shan <shangw@linux.vnet.ibm.com> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Suzuki K. Poulose authored
commit 5e249d45 upstream. Uprobes uses emulate_step in sstep.c, but we haven't explicitly specified the dependency. On pseries HAVE_HW_BREAKPOINT protects us, but 44x has no such luxury. Consolidate other users that depend on sstep and create a new config option. Signed-off-by:
Ananth N Mavinakayanahalli <ananth@in.ibm.com> Signed-off-by:
Suzuki K. Poulose <suzuki@in.ibm.com> Cc: linuxppc-dev@ozlabs.org Signed-off-by:
-
Phileas Fogg authored
commit 8520e443 upstream. Disable hard IRQ before kexec a new kernel image. Not doing it can result in corrupted data in the memory segments reserved for the new kernel. Signed-off-by:
Phileas Fogg <phileas-fogg@mail.ru> Signed-off-by:
-
Joonsoo Kim authored
commit 7c4e9ced upstream. If we want load epoch_cyc and epoch_ns atomically, we should update epoch_cyc_copy first of all. This notify reader that updating is in progress. If we update epoch_cyc first like as current implementation, there is subtle error case. Look at the below example. <Initial Condition> cyc = 9 ns = 900 cyc_copy = 9 == CASE 1 == <CPU A = reader> <CPU B = updater> write cyc = 10 read cyc = 10 read ns = 900 write ns = 1000 write cyc_copy = 10 read cyc_copy = 10 output = (10, 900) == CASE 2 == <CPU A = reader> <CPU B = updater> read cyc = 9 write cyc = 10 write ns = 1000 read ns = 1000 read cyc_copy = 9 write cyc_copy = 10 output = (9, 1000) If atomic read is ensured, output should be (9, 900) or (10, 1000). But, output in example case are not. So, change updating sequence in order to correct this problem. Signed-off-by:
Joonsoo Kim <iamjoonsoo.kim@lge.com> Signed-off-by:
Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by:
-
Will Deacon authored
commit c0e01d5d upstream. struct compat_ucontext * is a 64-bit pointer, so we need to use a compat_uptr_t instead to avoid declaring a structure incompatible with what AArch32 userspace expects. Reported-by:
Edmund Grimley-Evans <Edmund.Grimley-Evans@arm.com> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Will Deacon authored
commit ab2a724a upstream. When running on Integrator/AP using atags, ap_syscon_base is initialised in ->map_io, which isn't called for !MMU platforms. Instead, initialise the pointer in ->machine_init, as we do when booting with device-tree. Acked-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
-
Steffen Trumtrar authored
commit 4b526ca5 upstream. The mxc-timer on the imx25 needs to be derived from the AHB clock. If a bootloader reparents this clock to the ipg_clk_highfreq, which according to the datasheet is a valid operation, the system can/will produce lockups/ freezes after some time [1]. This can be forced with code like while(1) syscall(SYS_clock_gettime, CLOCK_REALTIME, &tp); This was already fixed with the commit "i.MX25 GPT clock fix: ensure correct the clock source" [2], for 3.1-rc2, but was lost, when i.MX was converted to the common clock framework ("ARM i.MX25: implement clocks using common clock framework") [3] [1]: http://lists.arm.linux.org.uk/lurker/message/20130129.161230.229bda17.en.html [2]: 2012d9ca [3]: 6bbaec56Signed-off-by:
Steffen Trumtrar <s.trumtrar@pengutronix.de> Signed-off-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
-
Arnd Bergmann authored
commit 2815774b upstream. Recent assembler versions complain about extraneous whitespace inside [] brackets. This fixes all of these instances for the samsung platforms. We should backport this to all kernels that might need to be built with new binutils. arch/arm/kernel/entry-armv.S: Assembler messages: arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:214: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r2,[ r6,#(0x10)]' arch/arm/kernel/entry-armv.S:430: Error: ARM register expected -- `ldr r0,[ r6,#(0x14)]' arch/arm/mach-s3c24xx/sleep-s3c2410.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2410.S:48: Error: ARM register expected -- `ldr r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:49: Error: ARM register expected -- `ldr r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:50: Error: ARM register expected -- `ldr r9,[ r6 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:64: Error: ARM register expected -- `streq r7,[ r4 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:65: Error: ARM register expected -- `streq r8,[ r5 ]' arch/arm/mach-s3c24xx/sleep-s3c2410.S:66: Error: ARM register expected -- `streq r9,[ r6 ]' arch/arm/kernel/debug.S: Assembler messages: arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r2,#((0x0B0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-((0)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/mach-s3c24xx/pm-h1940.S: Assembler messages: arch/arm/mach-s3c24xx/pm-h1940.S:33: Error: ARM register expected -- `ldr pc,[ r0,#((0x0B8)+(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000))))-(((0x56000000)-(0x50000000))+(0xF6000000+(0x01000000)))]' arch/arm/mach-s3c24xx/sleep-s3c2412.S: Assembler messages: arch/arm/mach-s3c24xx/sleep-s3c2412.S:60: Error: ARM register expected -- `ldrne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:61: Error: ARM register expected -- `strne r9,[ r1 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:62: Error: ARM register expected -- `ldrne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:63: Error: ARM register expected -- `strne r9,[ r2 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:64: Error: ARM register expected -- `ldrne r9,[ r3 ]' arch/arm/mach-s3c24xx/sleep-s3c2412.S:65: Error: ARM register expected -- `strne r9,[ r3 ]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:83: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x08)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x18)]' arch/arm/kernel/debug.S:85: Error: ARM register expected -- `ldr r2,[ r3,#(0x10)]' Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Kukjin Kim <kgene.kim@samsung.com> Cc: Ben Dooks <ben-linux@fluff.org> Signed-off-by:
-
Nicolas Ferre authored
commit c3f0f282 upstream. Fix the use of USART on both at91sam9x5 and at91sam9n12. In DTS, the atmel,use-dma-[rx|tx] property is present but a DMA channel cannot be used. Indeed the connexion between the DMA engine and the slave is not implemented yet in Device Tree. Note however that this property is also used for PDC (private DMA) on older SoCs. This is why the driver alone cannot determine the validity of this property. Reported-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
-
Igor Grinberg authored
commit d107a204 upstream. The Chip Select Configuration Register must be programmed to 0x2 in order to achieve the correct behavior of the Static Memory Controller. Without this patch devices wired to DFI and accessed through SMC cannot be accessed after resume from S2. Do not rely on the boot loader to program the CSMSADRCFG register by programming it in the kernel smemc module. Signed-off-by:
Igor Grinberg <grinberg@compulab.co.il> Acked-by:
Eric Miao <eric.y.miao@gmail.com> Signed-off-by:
Haojian Zhuang <haojian.zhuang@gmail.com> Signed-off-by:
-
Linus Walleij authored
commit e3e92a7b upstream. The PCI IRQs were regressing due to two things: - The PCI glue layer was using an hard-coded IRQ 27 offset. This caused the immediate regression. - The SIC IRQ mask was inverted (i.e. a bit was indeed set to one for each valid IRQ on the SIC, but accidentally inverted in the init call). This has been around forever, but we have been saved by some other forgiving code that would reserve IRQ descriptors in this range, as the versatile is non-sparse. When the IRQs were bumped up 32 steps so as to avoid using IRQ zero and avoid touching the 16 legacy IRQs, things broke. Introduce an explicit valid mask for the IRQs that are active on the PIC/SIC, and pass that. Use the BIT() macro from <linux/bitops.h> to make sure we hit the right bits, readily defined in <mach/platform.h>. Reported-by:
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> Signed-off-by:
-
Ryo Tsutsui authored
commit 01f58153 upstream. Previously arizona_calc_fll() was checking if the target frequency is exactly divisible by reference frequency, but should have been product of the ratio and the reference frequency. Also scale down the Lamba and Theta coefficients be under 16-bits in order to match the registers. Signed-off-by:
Ryo Tsutsui <ryo.tsutsui@wolfsonmicro.com> Signed-off-by:
Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Signed-off-by:
Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by:
-
Chris Rattray authored
commit 0d2b6422 upstream. Signed-off-by:
Chris Rattray <crattray@opensource.wolfsonmicro.com> Signed-off-by:
-
Malcolm Priestley authored
commit ae5943de upstream. This error happens because PIPEnsControlOut and PIPEnsControlIn unlock the spin lock for delay, letting in another thread. The patch moves the current MP_SET_FLAG to before filling of sUsbCtlRequest for pControlURB and clears it in event of failing. Any thread calling either function while fMP_CONTROL_READS or fMP_CONTROL_WRITES flags set will return STATUS_FAILURE. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Signed-off-by:
-
Malcolm Priestley authored
commit 392c6ff8 upstream. The patch was totally wrong and is reverted. The problem was ultimately fixed by upstream commit. 1ee4c55f staging: vt6656: Fix inconsistent structure packing Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
-
Malcolm Priestley authored
commit d61ac98a upstream. The patch is wrong and is partially reverted. The NULL check of pTransmitKey->pvKeyTable is kept. The problem was ultimately fixed by upstream commit. 1ee4c55f staging: vt6656: Fix inconsistent structure packing Reported-by:
-
Ian Abbott authored
commit 4c4bc25d upstream. Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting meaningful output from a Lab-PC+ in differential mode for AI cmds, but AI insn reads gave correct readings. He tracked it down to two problems, one of which is addressed by this patch. It seems the setting of the channel bits for particular scanning modes was incorrect for differential mode. (Only half the number of channels are available in differential mode; comedi refers to them as channels 0, 1, 2 and 3, but the hardware documentation refers to them as channels 0, 2, 4 and 6.) In differential mode, the setting of the channel enable bits in the command1 register should depend on whether the scan enable bit is set. Effectively, we need to double the comedi channel number when the scan enable bit is not set in differential mode. The scan enable bit gets set when the AI scan mode is `MODE_MULT_CHAN_UP` or `MODE_MULT_CHAN_DOWN`, and gets cleared when the AI scan mode is `MODE_SINGLE_CHAN` or `MODE_SINGLE_CHAN_INTERVAL`. The existing test for whether the comedi channel number needs to be doubled in differential mode is incorrect in `labpc_ai_cmd()`. This patch corrects the test. Thanks to Tuomas for suggesting the fix. Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Signed-off-by:
-
Ian Abbott authored
commit 22056e2b upstream. Tuomas <tvainikk _at_ gmail _dot_ com> reported problems getting meaningful output from a Lab-PC+ in differential mode for AI cmds, but AI insn reads gave correct readings. He tracked it down to two problems, one of which is addressed by this patch. It seems that writing to the command3 register after writing to the command4 register in `labpc_ai_cmd()` messes up the differential reference bit setting in the command4 register. Set up the command4 register after the command3 register (as in `labpc_ai_rinsn()`) to avoid the problem. Thanks to Tuomas for suggesting the fix. Signed-off-by:
-
Ian Abbott authored
commit 754ab5c0 upstream. Comedi has two sorts of minor devices: (a) normal board minor devices in the range 0 to COMEDI_NUM_BOARD_MINORS-1 inclusive; and (b) special subdevice minor devices in the range COMEDI_NUM_BOARD_MINORS upwards that are used to open the same underlying comedi device as the normal board minor devices, but with non-default read and write subdevices for asynchronous commands. The special subdevice minor devices get created when a board supporting asynchronous commands is attached to a normal board minor device, and destroyed when the board is detached from the normal board minor device. One way to attach or detach a board is by using the COMEDI_DEVCONFIG ioctl. This should only be used on normal board minors as the special subdevice minors are too ephemeral. In particular, the change introduced in commit 7d3135af ("staging: comedi: prevent auto-unconfig of manually configured devices") breaks horribly for special subdevice minor devices. Since there's no legitimate use for the COMEDI_DEVCONFIG ioctl on a special subdevice minor device node, disallow it and return -ENOTTY. Signed-off-by:
-
Minchan Kim authored
commit 99155188 upstream. Recently, Matt Sealey reported he fail to build zsmalloc caused by using of local_flush_tlb_kernel_range which are architecture dependent function so !CONFIG_SMP in ARM couldn't implement it so it ends up build error following as. MODPOST 216 modules LZMA arch/arm/boot/compressed/piggy.lzma AS arch/arm/boot/compressed/lib1funcs.o ERROR: "v7wbi_flush_kern_tlb_range" [drivers/staging/zsmalloc/zsmalloc.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 make: *** Waiting for unfinished jobs.... The reason we used that function is copy method by [1] was really slow in ARM but at that time. More severe problem is ARM can prefetch speculatively on other CPUs so under us, other TLBs can have an entry only if we do flush local CPU. Russell King pointed that. Thanks! We don't have many choices except using flush_tlb_kernel_range. My experiment in ARMv7 processor 4 core didn't make any difference with zsmapbench[2] between local_flush_tlb_kernel_range and flush_tlb_kernel_range but still page-table based is much better than copy-based. * bigger is better. 1. local_flush_tlb_kernel_range: 3918795 mappings 2. flush_tlb_kernel_range : 3989538 mappings 3. copy-based: 635158 mappings This patch replace local_flush_tlb_kernel_range with flush_tlb_kernel_range which are avaialbe in all architectures because we already have used it in vmalloc allocator which are generic one so build problem should go away and performane loss shoud be void. [1] f553646a, zsmalloc: add page table mapping method [2] https://github.com/spartacus06/zsmapbenchReported-by:
Matt Sealey <matt@genesi-usa.com> Cc: Dan Magenheimer <dan.magenheimer@oracle.com> Cc: Russell King <linux@arm.linux.org.uk> Cc: Konrad Rzeszutek Wilk <konrad@darnok.org> Cc: Nitin Gupta <ngupta@vflare.org> Cc: Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by:
Minchan Kim <minchan@kernel.org> Signed-off-by:
-
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:
-
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:
-
