- 01 Oct, 2013 31 commits
-
-
Paulo Zanoni authored
By moving them to intel_fb.c. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
And move it so it doesn't need a forward declaration. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Also move it to the top of the file so we can remove the forward declaration. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Daniel complained that we keep adding stuff to the bottom of the file, so we constantly have conflicts. So reorganize everything and split them file-by-file, also sorting the files in alphabetical order. This way, patches touching different files will have a smaller chance of conflicting. Of course, this commit will conflict with everybody on the list :) Also remove a few useless comments and make some things fit into 80 lines. v2: - Conflict with intel_ddi_get_config Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Not valid for later non-PCH split platforms such as VLV. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Flat out skip anything to do with PLL if we have a DSI encoder (and thus DSI PLL). Also skip PLL computation if the encoder has already set clocks. This allows for some tidying up of the code, including a superfluous call to intel_limit() for LVDS downclock path. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
During SDVO initialisation it would be useful to a have a record of the individual devices we try to enable and later probe - in particular to be able to see which fail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Obtaining the forcwake requires expensive and time consuming serialisation. And we often try to obtain the forcewake multiple times in very quick succession. We can reduce the overhead of these sequences by delaying the forcewake release, and so not hammer the hw quite so hard. I was hoping this would help with the spurious [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. found on Haswell. Alas not. v2: Fix teardown ordering - unmap the regs after turning off forcewake, and make sure we do turn off forcewake - both found by Ville. v3: As we introduce intel_uncore_fini(), use it to make sure everything is disabled before we hand back to the BIOS. Note: I have no claims for improved performance, stablity or power comsumption for this patch. We should not be hitting the registers often enough for this to improve benchmarks, but given the nature of our hw it is likely to improve long term stability. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dan Carpenter authored
The | operation has higher precedence than "?:" so the macro always returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1. This regression has been introduce in "drm/i915: Add second slice l3 remapping". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we must get the pixel clock from port_clock in intel_crtc_mode_get(). This bug caused Chris's 845g machine to lockup during boot, and it was introduced in: commit 18442d08 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69713Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
Future generations will be changing these registers (thanks to design for giving us an early heads up). To help abstract, create the definition of the base of the register block, and define all registers relative to that. Design has promised to not change the offsets relative to the base. v2: Also change IS_HASWELL checks to HAS_PSR CC: Rodrigo Vivi <rodrigo.vivi@gmail.com> CC: Intel GFX <intel-gfx@lists.freedesktop.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jani Nikula authored
Reduce AUX transactions for non-eDP. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
We already restore planes during the modeset operation, so no need to do another loop over the planes and try to restore them again. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Call intel_uncore_early_sanitize() first thing during resume to prevent stale BIOS leftovers from being reported as unclaimed register access. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
i915_restore_state() -> i915_restore_display() will attempt to re-disable VGA during resume. So the power well needs to be powered on before that. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
intel_modeset_init() will already attempt to disable VGA. In order to do that, it needs the power well to be on. So move the power well init to happen before intel_modeset_init() during driver load. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
The VGA plane needs to be disabled before we start doing any modeset operations on resume. This should also guarantee that the power well will be enabled when we call i915_redisable_vga() since it gets explicitly powered on during resume, and will get powered back off during the modeset operation if no longer needed. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
VGA registers live inside the power well on HSW, so in order to write the VGA MSR register we need the power well to be on. We really must write to the register to properly clear the VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when the power well is down. It seems that the implicit zeroing done by the power well is not enough to propagate the VGA_MSR_MEM_EN bit to whomever is actually responsible for the memory decode ranges. If we leave VGA memory decode enabled, and then turn off the power well, all VGA memory reads will return zeroes. But if we first disable VGA memory deocde and then turn off the power well, VGA memory reads return all ones, indicating that the access wasn't claimed by anyone. For the vga arbiter to function correctly the IGD must not claim the VGA memory accesses. Previously we were doing the VGA_MSR register access while the power well was excplicitly powered up during driver init. But ever since commit 6e1b4fda Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 5 20:40:52 2013 +0300 drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done we delay the VGA memory disable until fbcon has initialized, and so there's a possibility that the power well got turned off during the fbcon modeset. Also vgacon_save_screen() will need the power well to be on to be able to read the VGA memory. So immediately after enabling the power well during init grab a refence for VGA purposes, and after all the VGA handling is done, release it. v2: Add intel_display_power_put() for the num_pipes==0 case Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix up the patch wiggle screw-up that I've done and which Paulo catched. Also polish spelling in the patch headline.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
It only controls the setting of the vbt.edp_support variable, which in turn only controls one debug output plus can also force-disable the lvds output. Since the value only restricted this logic to mobile ilk there's the slight risk that this will break lvds on desktop ilk or on snb/ivb platforms. But with the vbt it's better when we know what's going on here, so let's rip it out and see what happens. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
There's no reason to init a DP connector if the encoder just supports HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP AUX transactions to detect if there's something there. Same goes for a DP connector that doesn't support HDMI, but I'm not sure these actually exist. v2: - Use bit fields - Remove useless identation level - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Our code makes a lot of assumptions regarding what each DDI port actually supports, and the VBT should tell us what is really happening in the hardware. So parse the information provided by the VBT and check if any of our assumptions is wrong. Our driver also has a history of not really trusting the VBT, so a WARN here could mean that: a) our coding assumptions are wrong b) the VBT is wrong c) we're incorrectly parsing the VBT d) the checks are wrong But I really hope we won't ever trigger any of those WARNs. v2: Don't check the redundant "Capabilities" field from byte 24 since it doesn't seem to be used. v3: Rebase v4: Replace WARN with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Our code currently assumes that port X will use the DP AUX channel X and the DDC pin X. The VBT should tell us how things are mapped, so add some WARNs in case we discover our assumptions are wrong (or in case the VBT is just wrong, which is also perfectly possible). Why would someone wire port B to AUX C and DDC D? v2: Rebase v3: Convert WARNs to DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
We currently use the recommended values from BSpec, but the VBT specifies the correct value to use for the hardware we have, so use it. We also fall back to the recommended value in case we can't find the VBT. In addition, this code also provides some infrastructure to parse more information about the DDI ports. There's a lot more information we could extract and use in the future. v2: - Move some code to init_vbt_defaults. v3: - Rebase - Clarify the "DVO Port" matching code v4: - Use I915_MAX_PORTS - Change the HAS_DDI checks - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
We currently treat the child_device_config as a simple struct, but this is not correct: new BDB versions change the meaning of some offsets, so the struct needs to be adjusted for each version. Since there are too many changes (today we're in version 170!), making a big versioned union would be too complicated, so child_device_config is now a union of 3 things: (i) a "raw" byte array that's safe to use anywhere; (ii) an "old" structure that's the one we've been using and should be safe to keep in the SDVO and TV code; and (iii) a "common" structure that should contain only fields that are common for all the known VBT versions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
We never took the lock ourselves and all callers expect the struct_mutex to be locked upon return (be it success or error), thereore dropping the lock along the error paths looks to be a vestigial error from commit db1b76ca Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 9 16:51:37 2013 +0200 drm/i915: don't frob mm.suspended when not using ums Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
There's actually no real risk since we already check for stricter constraints earlier (using UINT_MAX / sizeof (struct drm_i915_gem_exec_object2) as the limit). But in eb_create we use signed integers, which steals a factor of 2. Luckily struct drm_i915_gem_exec_object2 for this to not matter. Still, be consistent and use unsigned integers. Similar use unsinged integers when checking for overflows in the relocation entry processing. I've also added a new subtests to igt/gem_reloc_overflow to also test for overflowing args->buffer_count values. v2: Give the variables again tighter scope to make it clear that the computation is purely local and doesn't leak out to the 2nd block. Requested by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
And the gratious overallocation of crtcs. Seems to go back to the ums days of yonder ... We also still need it to make the fbdev emulation happy, but I don't think there's really a need. Especially since the current fbdev emulation doesn't actually support cloning. v2: Use sizeof(*pointer) pattern (Jani). Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
No buffer overflows here, but better safe than sorry. v2: - Fixup the sizeof conversion, I've missed the pointer deref (Jani). - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani). - Use kmalloc_array for the execbuf fastpath to avoid the memset (Chris). I've opted to leave all other conversions as-is since they aren't in a fastpath and dealing with cleared memory instead of random garbage is just generally nicer. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the contentious kmalloc_array hunk in execbuf.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dave Airlie authored
Merge tag 'drm-intel-next-2013-09-21-merged' of git://people.freedesktop.org/~danvet/drm-intel into drm-next drm-intel-next-2013-09-21: - clock state handling rework from Ville - l3 parity handling fixes for hsw from Ben - some more watermark improvements from Ville - ban badly behaved context from Mika - a few vlv improvements from Jesse - VGA power domain handling from Ville drm-intel-next-2013-09-06: - Basic mipi dsi support from Jani. Not yet converted over to drm_bridge since that was too fresh, but the porting is in progress already. - More vma patches from Ben, this time the code to convert the execbuffer code. Now that the shrinker recursion bug is tracked down we can move ahead here again. Yay! - Optimize hw context switching to not generate needless interrupts (Chris Wilson). Also some shuffling for the oustanding request allocation. - Opregion support for SWSCI, although not yet fully wired up (we need a bit of runtime D3 support for that apparently, due to Windows design deficiencies), from Jani Nikula. - A few smaller changes all over. [airlied: merge conflict fix in i9xx_set_pipeconf] * tag 'drm-intel-next-2013-09-21-merged' of git://people.freedesktop.org/~danvet/drm-intel: (119 commits) drm/i915: assume all GM45 Acer laptops use inverted backlight PWM drm/i915: cleanup a min_t() cast drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw() drm/i915: Add POWER_DOMAIN_VGA drm/i915: Refactor power well refcount inc/dec operations drm/i915: Add intel_display_power_{get, put} to request power for specific domains drm/i915: Change i915_request power well handling drm/i915: POSTING_READ IPS_CTL before waiting for the vblank drm/i915: don't disable ERR_INT on the IRQ handler drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT drm/i915/vlv: honor i915_enable_rc6 boot param on VLV drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF drm/i915: Do remaps for all contexts drm/i915: Keep a list of all contexts drm/i915: Make l3 remapping use the ring drm/i915: Add second slice l3 remapping drm/i915: Fix HSW parity test drm/i915: dump crtc timings from the pipe config drm/i915: register backlight device also when backlight class is a module drm/i915: write D_COMP using the mailbox ... Conflicts: drivers/gpu/drm/i915/intel_display.c
-
- 29 Sep, 2013 9 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usbLinus Torvalds authored
Pull USB fixes from Greg KH: "Here are a number of USB driver fixes for 3.12-rc3. These are all for host controller issues that have been reported, and there's a fix for an annoying error message that gets printed every time you remove a USB 3 device from the system that's been bugging me for a while" * tag 'usb-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: usb: dwc3: add support for Merrifield USB: fsl/ehci: fix failure of checking PHY_CLK_VALID during reinitialization USB: Fix breakage in ffs_fs_mount() fsl/usb: Resolve PHY_CLK_VLD instability issue for ULPI phy usb/core/devio.c: Don't reject control message to endpoint with wrong direction bit usb: chipidea: USB_CHIPIDEA should depend on HAS_DMA usb: chipidea: udc: free pending TD at removal procedure usb: chipidea: imx: Add usb_phy_shutdown at probe's error path usb: chipidea: Fix memleak for ci->hw_bank.regmap when removal usb: chipidea: udc: fix the oops after rmmod gadget USB: fix PM config symbol in uhci-hcd, ehci-hcd, and xhci-hcd USB: OHCI: accept very late isochronous URBs USB: UHCI: accept very late isochronous URBs USB: iMX21: accept very late isochronous URBs usbcore: check usb device's state before sending a Set SEL control transfer xhci: Fix race between ep halt and URB cancellation usb: Fix xHCI host issues on remote wakeup. xhci: Ensure a command structure points to the correct trb on the command ring xhci: Fix oops happening after address device timeout
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/ttyLinus Torvalds authored
Pull tty/serial fixes from Greg KH: "Here are some serial at tty driver fixes for 3.12-rc3 The serial driver fixes some kref leaks, documentation is moved to the proper places, and the tty and n_tty fixes resolve some reported regressions. There is still one outstanding tty regression fix that isn't in here yet, as I want to test it out some more, it will be sent for 3.12-rc4 if it checks out" * tag 'tty-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: tty: ar933x_uart: move devicetree binding documentation tty: Fix SIGTTOU not sent with tcflush() n_tty: Fix EOF push index when termios changes serial: pch_uart: remove unnecessary tty_port_tty_get serial: pch_uart: fix tty-kref leak in dma-rx path serial: pch_uart: fix tty-kref leak in rx-error path serial: tegra: fix tty-kref leak
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/stagingLinus Torvalds authored
Pull staging fixes from Greg KH: "Here are some staging driver fixes, MAINTAINER updates, and a new device id. All of these have been in the linux-next tree, and are pretty simple patches" * tag 'staging-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: staging: r8188eu: Add new device ID staging: imx-drm: Fix probe failure staging: vt6656: [BUG] iwctl_siwencodeext return if device not open staging: vt6656: [BUG] main_usb.c oops on device_close move flag earlier. staging: vt6656: rxtx.c [BUG] s_vGetFreeContext dead lock on null apTD. Staging: rtl8192u: r819xU_cmdpkt: checking NULL value after doing dev_alloc_skb staging: usbip: Orphan usbip staging: r8188eu: Add files for new drive: Cocci spatch "noderef" staging: r8188eu: Cocci spatch "noderef" staging: octeon-usb: Cocci spatch "noderef" staging: r8188eu: Add files for new drive: Cocci spatch "noderef" MAINTAINERS: staging: dgnc and dgap drivers: add maintainer staging: lustre: Cocci spatch "noderef"
-
Linus Torvalds authored
Merge tag 'driver-core-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core / sysfs fixes from Greg KH: "Here are 2 fixes for 3.12-rc3. One fixes a sysfs problem with mounting caused by 3.12-rc1, and the other is a bug reported by the chromeos developers with the driver core. Both have been in linux-next for a bit" * tag 'driver-core-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: driver core : Fix use after free of dev->parent in device_shutdown sysfs: Allow mounting without CONFIG_NET
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-miscLinus Torvalds authored
Pull char/misc driver fixes from Greg KH: "Here are some HyperV and MEI driver fixes for 3.12-rc3. They resolve some issues that people have been reporting for them" * tag 'char-misc-3.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: Drivers: hv: vmbus: Terminate vmbus version negotiation on timeout Drivers: hv: util: Correctly support ws2008R2 and earlier mei: cancel stall timers in mei_reset mei: bus: stop wait for read during cl state transition mei: make me client counters less error prone
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull perf revert from Ingo Molnar: "This fixes the 'perf top' regression Markus Trippelsdorf reported" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: Revert "perf symbols: Demangle cloned functions"
-
git://people.freedesktop.org/~airlied/linuxLinus Torvalds authored
Pull drm fixes from Dave Airlie: "Nothing too major, radeon still has some dpm changes for off by default. Radeon, intel, msm: - radeon: a few more dpm fixes (still off by default), uvd fixes - i915: runtime warn backtrace and regression fix - msm: iommu changes fallout" * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux: (27 commits) drm/msm: use drm_gem_dumb_destroy helper drm/msm: deal with mach/iommu.h removal drm/msm: Remove iommu include from mdp4_kms.c drm/msm: Odd PTR_ERR usage drm/i915: Fix up usage of SHRINK_STOP drm/radeon: fix hdmi audio on DCE3.0/3.1 asics drm/i915: preserve pipe A quirk in i9xx_set_pipeconf drm/i915/tv: clear adjusted_mode.flags drm/i915/dp: increase i2c-over-aux retry interval on AUX DEFER drm/radeon/cik: fix overflow in vram fetch drm/radeon: add missing hdmi callbacks for rv6xx drm/i915: Use a temporary va_list for two-pass string handling drm/radeon/uvd: lower msg&fb buffer requirements on UVD3 drm/radeon: disable tests/benchmarks if accel is disabled drm/radeon: don't set default clocks for SI when DPM is disabled drm/radeon/dpm/ci: filter clocks based on voltage/clk dep tables drm/radeon/dpm/si: filter clocks based on voltage/clk dep tables drm/radeon/dpm/ni: filter clocks based on voltage/clk dep tables drm/radeon/dpm/btc: filter clocks based on voltage/clk dep tables drm/radeon/dpm: fetch the max clk from voltage dep tables helper ...
-
Ingo Molnar authored
This reverts commit de95ab53. Markus Trippelsdorf reported that this commit broke 'perf top': > I just see a gray screen with no text at all. Sometimes the > following error messages are printed: > > *** Error in `perf': invalid fastbin entry (free): 0x00000000029b18c0 > *** > *** Error in `perf': malloc(): memory corruption (fast): 0x0000000000ee0b10 *** While this code is fixable, the commit itself fails on several levels: - it should have been a separate helper function - why the heck does it do strchr() twice - it casts a const char * over into char * - sloppy style - it's not even a regression fix! So lets revert it and re-try the patch in v3.13. Reported-by: Markus Trippelsdorf <markus@trippelsdorf.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Ingo Molnar <mingo@kernel.org>
-