aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2013-09-04drm/nouveau/timer: add a way to cancel alarmsMartin Peres3-0/+29
Since alarms don't play well with suspend, it is important every alarm user cancels his tasks before suspending. The task should be rescheduled on resume. Signed-off-by: Martin Peres <[email protected]> Tested-by: Martin Peres <[email protected]> Tested-by: Dash Four <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau/timer: restore the time on resumeMartin Peres1-1/+14
This can be useful if some parts of Nouveau try to calculate the time between two events. Without this patch, the time difference would be negative in the case where the computer is suspended/resumed between two events. This patch should fix fan speed probing when done while suspending/resuming. Solve this by saving the current time before suspending and by restoring it on resume. Signed-off-by: Martin Peres <[email protected]> Tested-by: Martin Peres <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau/fan: restore pwm value on resume when in manual/auto modeMartin Peres2-1/+9
If the fan was in manual or auto mode, we should restore the fan speed that was previously set when resuming. The initial pwm value is saved when loading the module. Signed-off-by: Martin Peres <[email protected]> Tested-by: Martin Peres <[email protected]> Tested-by: Dash Four <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau/therm: Set the correct pwm_mode upon resumeEmil Velikov1-1/+1
Signed-off-by: Emil Velikov <[email protected]> Signed-off-by: Martin Peres <[email protected]> Tested-by: Martin Peres <[email protected]> Tested-by: Dash Four <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau: require contiguous bo for framebufferMaarten Lankhorst1-0/+5
This was already required before, but no check in the kernel was done to enforce it. Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nv50-/disp: use the number of dac, sor, pior rather than hardcoded valuesEmil Velikov1-17/+17
The values are already stored on chipset specific basis in the ctor. Make the most of them and simplify the code further by using a temporary variable to avoid code duplication. Signed-off-by: Emil Velikov <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau: remove duplicate copy of nv44_graph_classIlia Mirkin2-8/+5
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau/vdec: implement support for VP3 enginesIlia Mirkin6-53/+104
For NV98+, BSP/VP/PPP are all FUC-based engines. Hook them all up in the same way as NVC0, but with a couple of different values. Also make sure that the PPP engine is handled in the fifo/mc/vm. Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04drm/nouveau/core: get rid of math.h, replace log2i with order_base_2Ilia Mirkin7-27/+7
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-09-04Merge tag 'drm/for-3.12-rc1' of git://anongit.freedesktop.org/tegra/linux ↵Dave Airlie5-17/+23
into drm-next drm/tegra: Changes for v3.12-rc1 Only a couple of small patches this time around. These are mostly fixes for minor bugs that showed up, but there is also some preparatory work that will come in handy for future patches. * tag 'drm/for-3.12-rc1' of git://anongit.freedesktop.org/tegra/linux: drm/tegra: Parse device tree earlier gpu: host1x: Sort drivers by probe order gpu: host1x: Check for valid host1x pointer gpu: host1x: returning success instead of -ENOMEM gpu: host1x: fix an integer overflow check drm/tegra: hdmi: Make sure clock is enabled before dumping registers
2013-09-03drm/i915: fix up the relocate_entry refactoringDaniel Vetter1-0/+3
Somehow we've lost the error handling in the patch split-up between the internal and external patch. This regression has been introduced in commit 5032d871f7d300aee10c309ea004eb4f851553fe Author: Rafael Barbalho <[email protected]> Date: Wed Aug 21 17:10:51 2013 +0100 drm/i915: Cleaning up the relocate entry function This bug is exercised by igt/gem_reloc_vs_gpu/interruptible. Cc: Rafael Barbalho <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Fix pipe config warnings when dealing with LVDS fixed modeVille Syrjälä3-17/+7
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we filled out the adjusted_mode in get_config from the real registers. Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the whole thing, and then just use adjusted_mode in the LVDS code to figure out which sync settings the hardware needs. Also constify the fixed_mode argument to intel_fixed_panel_mode(). Signed-off-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Don't call sg_free_table() if sg_alloc_table() failsDamien Lespiau1-1/+0
One needs to call __sg_free_table() if __sg_alloc_table() fails, but sg_alloc_table() does that for us already. Signed-off-by: Damien Lespiau <[email protected]> Reviewd-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03i915: Update VGA arbiter support for newer devicesAlex Williamson2-3/+31
This is intended to add VGA arbiter support for Intel HD graphics on Core processors. The old GMCH registers no longer exist, so even though it appears that i915 participates in VGA arbitration, it doesn't work. On Intel HD graphics we already attempt to disable VGA regions of the device. This makes registering as a VGA client unnecessary since we don't intend to operate differently depending on how many VGA devices are present. We can disable VGA memory regions by clearing the memory enable bit in the VGA MSR. That only leaves VGA IO, which we update the VGA arbiter to know that we don't participate in VGA memory arbitration. We also add a hook on unload to re-enable memory and reinstate VGA memory arbitration. v3: Use explicit LEGACY_IO | LEGACY_MEM when restoring rather than LEGACY_MASK, per Ville's comments. v2: I915_READ/WRITE accessors don't work in i915_disable_vga, use inb/outb directly. Also, on the driver unbind VGA enable path, acquire legacy IO to re-enable VGA memory. Correct comment. Signed-off-by: Alex Williamson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> [danvet: Add patch changelog. Also squash in a fixup to have a dummy static inline for vga_set_legacy_decoding for CONFIG_VGA_ARB=n as reported by the 0-day kernel build bot.] Signed-off-by: Daniel Vetter <[email protected]> fixup 2
2013-09-03vgaarb: Fix VGA decodes changesAlex Williamson1-24/+17
When VGA decodes change we need to do a bit more evaluation of exactly what has changed. We don't necessarily give up all the old owns resources and we need to account for resources with locks. The new algorithm is: If something is added, update decodes. If legacy resources were added and none were there before, we have a new participant. If something is removed, update decodes. If we previously owned it, we no longer own it. If it was previously locked, invalidate all locks and release it. If legacy resources were removed and none are left, remove the participant from VGA arbitration. Previously we updated decodes, released ownership of everything that was previously decoded, ignored all locks, and went off looking for another device to transfer VGA to. In a test case where Intel IGD removes only legacy VGA memory decoding, this left the arbiter switching to discrete graphics without actually disabling legacy VGA IO from the IGD. As a bonus, we bumped up the count of VGA arbitration participants for no good reason. Signed-off-by: Alex Williamson <[email protected]> Cc: Dave Airlie <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> [danvet: Kill now unused variables, reported by the 0-day kernel builtbot.] Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03vgaarb: Don't disable resources that are not ownedAlex Williamson1-5/+5
If a device does not own a resource then we don't need to disable it. This resolves the case where an Intel IGD device can be configured to disable decode of VGA memory but we still need the arbiter to handle VGA I/O port routing. When the IGD device is in conflict, only PCI_COMMAND_IO should be disabled since VGA memory does not require arbitration on this device. Signed-off-by: Alex Williamson <[email protected]> Cc: Dave Airlie <[email protected]> Acked-by: Dave Airlie <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Pin pages whilst mapping the dma-bufChris Wilson1-19/+22
As we attempt to kmalloc after calling get_pages, there is a possibility that the shrinker may reap the pages we just acquired. To prevent this we need to increment the pages_pin_count early, so rearrange the code and error paths to make it so. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: enable trickle feed on HaswellPaulo Zanoni4-7/+13
We shouldn't disable the trickle feed bits on Haswell. Our documentation explicitly says the trickle feed bits of PRI_CTL and CUR_CTL should not be programmed to 1, and the hardware engineer also asked us to not program the SPR_CTL field to 1. Leaving the bits as 1 could cause underflows. Reported-by: Arthur Runyan <[email protected]> Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03x86: add early quirk for reserving Intel graphics stolen memory v5Jesse Barnes1-15/+0
Systems with Intel graphics controllers set aside memory exclusively for gfx driver use. This memory is not always marked in the E820 as reserved or as RAM, and so is subject to overlap from E820 manipulation later in the boot process. On some systems, MMIO space is allocated on top, despite the efforts of the "RAM buffer" approach, which simply rounds memory boundaries up to 64M to try to catch space that may decode as RAM and so is not suitable for MMIO. v2: use read_pci_config for 32 bit reads instead of adding a new one (Chris) add gen6 stolen size function (Chris) v3: use a function pointer (Chris) drop gen2 bits (Daniel) v4: call e820_sanitize_map after adding the region v5: fixup comments (Peter) simplify loop (Chris) Acked-by: Ingo Molnar <[email protected]> Signed-off-by: Jesse Barnes <[email protected]> Acked-by: H. Peter Anvin <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66726 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66844 Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: split PCI IDs out into i915_drm.h v4Jesse Barnes1-130/+34
For use by userspace (at some point in the future) and other kernel code. v2: move PCI IDs to uabi (Chris) move PCI IDs to drm/ (Dave) v3: fixup Quanta detection - needs to come first (Daniel) v4: fix up PCI match structure init for easier use by userspace (Chris) Signed-off-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03i915_gem: Convert kmem_cache_alloc(...GFP_ZERO) to kmem_cache_zallocJoe Perches1-1/+1
The helper exists, might as well use it instead of __GFP_ZERO. Signed-off-by: Joe Perches <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Use RCS flips on Ivybridge+Chris Wilson2-9/+49
RCS flips do work on Iybridge+ so long as we can unmask the messages through DERRMR. However, there are quite a few workarounds mentioned regarding unmasking more than one event or triggering more than one message through DERRMR. Those workarounds in principle prevent us from performing pipelined flips (and asynchronous flips across multiple planes) and equally apply to the "known good" BCS ring. Given that it already appears to work, and also appears to work with unmasking all 3 planes at once (and queuing flips across multiple planes), be brave. Bugzlla: https://bugs.freedesktop.org/show_bug.cgi?id=67600 Signed-off-by: Chris Wilson <[email protected]> Lightly-tested-by: Stephane Marchesin <[email protected]> Cc: Stephane Marchesin <[email protected]> Cc: Ben Widawsky <[email protected]> Tested-by: Stéphane Marchesin <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Embed the ring->private within the struct intel_ring_bufferChris Wilson3-72/+35
We now have more devices using ring->private than not, and they all want the same structure. Worse, I would like to use a scratch page from outside of intel_ringbuffer.c and so for convenience would like to reuse ring->private. Embed the object into the struct intel_ringbuffer so that we can keep the code clean. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: fix lvds/dp panel fitter settingImre Deak1-0/+2
If need to enable the panel fitter, the crtc timings have to be programmed according to the panel's native (fixed) mode. This isn't the case atm, since after the encoder changes adjusted_mode to fixed mode the crtc_* timing fields of adjusted_mode will stay at their original non-native values that the user passed in. This results in a corrupted output. One exception is when we have a second pass of computing encoder configs due to bandwidth limitation, since then we'll set adjusted_mode.crtc_* fields to the fixed mode values set in the first pass; so in this case things will work out. Fix this by updating the adjusted_mode.crtc_* fields when we set the fixed panel mode. This regression has been introduced in commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64 Author: Daniel Vetter <[email protected]> Date: Sun Jul 21 21:37:09 2013 +0200 drm/i915: clean up crtc timings computation Signed-off-by: Imre Deak <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: tune down hangcheck noiseDaniel Vetter1-3/+3
We already have a big splashing *ERROR* for all the relevant cases of hangs, so this one here is redudant. And it results in an unclean dmesg when running with simulated hangs. Regression has been introduced in commit 05407ff889ceebe383aa5907219f86582ef96b72 Author: Mika Kuoppala <[email protected]> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score Cc: Mika Kuoppala <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68641 Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Report requested frequency alongside current frequency in debugfsChris Wilson1-1/+10
It can be useful to compare at times the current vs requested frequency of the GPU, so provide the contents of RPNSWREQ alonside CAGF. Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Rodrigo Vivi <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Apply the force-detect VGA w/a to ValleyviewChris Wilson1-1/+1
It appears that Valleyview shares its VGA encoder with more recent siblings and requires the same forced detection cycle after a hardware reset before we can rely on hotplugging. Reported-and-tested-by: kobeqin <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67733 Tested-by: kobeqin <[email protected]> Signed-off-by: Chris Wilson <[email protected]> [danvet: Check for gen >= 5 insted, acked by Chris.] Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Adjust available RPS information through sysfs for vlvChris Wilson1-5/+31
Valleyview has its own render power state implementation with different capability knobs - it has no RP0,RP1,RPn but rather RPe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67734 Signed-off-by: Chris Wilson <[email protected]> Tested-by: [email protected] Reviewed-by: Jani Nikula <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: sanitize forcewake registers on resetMika Kuoppala1-1/+8
In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. Use same mechanism as intel_uncore_sanitize() does when loading driver to reset the forcewake bits, right after the chip has been reset. Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/i915: Don't mask EI UP interrupt on IVB|SNBMika Kuoppala1-1/+11
Submitting a batchbuffer which simulates a gpu hang by doing MI_BATCH_BUFFER_START into itself, to test hangcheck, started to hard hang the whole box (IVB). Bisecting lead to this commit: commit 664b422c2966cd39b8f67e8d53a566ea8c877cd6 Author: Vinit Azad <[email protected]> Date: Wed Aug 14 13:34:33 2013 -0700 drm/i915: Only unmask required PM interrupts Experimenting with the mask register showed that unmasking EI UP will prevent the hard hang in IVB and SNB. HSW doesn't hang with EI UP masked. Considering we are just disabling interrupts that aren't even delivered to driver, this change is more likely to paper over some weirdness in gpu's internal state machine. But until better explanation can be found, let's trade little bit of power for stability on these architectures. v2: - Unmask EI_EXPIRED directly in I915_WRITE (Vinit) v3: - Only unmask on SNB and IVB Cc: Vinit Azad <[email protected]> Signed-off-by: Mika Kuoppala <[email protected]> Acked-by: Vinit Azad <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-09-03drm/tegra: Parse device tree earlierThierry Reding1-7/+7
Parsing the device tree may cause probing to be deferred. Doing this as early as possible prevents any other resources from being requested and enabled, therefore reducing the need to cleanup on deferred probe while at the same time not wasting precious CPU cycles determining if probing needs to be deferred or not. Signed-off-by: Thierry Reding <[email protected]>
2013-09-03gpu: host1x: Sort drivers by probe orderThierry Reding1-1/+1
External driver declarations are sorted by probe order for consistency. Signed-off-by: Thierry Reding <[email protected]>
2013-09-03gpu: host1x: Check for valid host1x pointerThierry Reding1-1/+1
Under rare circumstances it can happen that the host1x driver's .probe() doesn't finish properly, in which case the device's driver-specific data will not be set. Instead of crashing in such a situation, propagate the error to callers of the host1x_get_drm_data() function. Signed-off-by: Thierry Reding <[email protected]>
2013-09-02drm/radeon: support render nodesChristian König2-12/+12
Enable support for drm render nodes for radeon by flagging the ioctls that are safe and just needed for rendering. Signed-off-by: Christian König <[email protected]> Signed-off-by: David Herrmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm/nouveau: Support render nodesMartin Peres1-12/+12
Enable support for drm render nodes for nouveau by flagging the ioctls that are safe and just needed for rendering. Cc: Ben Skeggs <[email protected]> Cc: Maarten Lankhorst <[email protected]> Signed-off-by: Martin Peres <[email protected]> Signed-off-by: David Herrmann <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm/i915: Support render nodesKristian Høgsberg2-22/+23
Enable support for drm render nodes for i915 by flagging the ioctls that are safe and just needed for rendering. v2: mark reg_read, set_caching and get_caching (ickle, danvet) Signed-off-by: Kristian Høgsberg <[email protected]> Signed-off-by: David Herrmann <[email protected]> Reviewed-by: Daniel Vetter <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm: fix DRM_IOCTL_MODE_GETFB handle-leakDavid Herrmann1-3/+15
DRM_IOCTL_MODE_GETFB is used to retrieve information about a given framebuffer ID. It is a read-only helper and was thus declassified for unprivileged access in: commit a14b1b42477c5ef089fcda88cbaae50d979eb8f9 Author: Mandeep Singh Baines <[email protected]> Date: Fri Jan 20 12:11:16 2012 -0800 drm: remove master fd restriction on mode setting getters However, alongside width, height and stride information, DRM_IOCTL_MODE_GETFB also passes back a handle to the underlying buffer of the framebuffer. This handle allows users to mmap() it and read or write into it. Obviously, this should be restricted to DRM-Master. With the current setup, *any* process with access to /dev/dri/card0 (which means any process with access to hardware-accelerated rendering) can access the current screen framebuffer and modify it ad libitum. For backwards-compatibility reasons we want to keep the DRM_IOCTL_MODE_GETFB call unprivileged. Besides, it provides quite useful information regarding screen setup. So we simply test whether the caller is the current DRM-Master and if not, we return 0 as handle, which is always invalid. A following DRM_IOCTL_GEM_CLOSE on this handle will fail with EINVAL, but we accept this. Users shouldn't test for errors during GEM_CLOSE, anyway. And it is still better as a failing MODE_GETFB call. v2: add capable(CAP_SYS_ADMIN) check for compatibility with i-g-t Cc: <[email protected]> Signed-off-by: David Herrmann <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm/msm: convert to drm_bridgeRob Clark10-260/+274
Drop the msm_connector base class, and special calls to base class methods from the encoder, and use instead drm_bridge. This allows for a cleaner division between the hdmi (and in future dsi) blocks, from the mdp block. Signed-off-by: Rob Clark <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm: Add drm_bridgeSean Paul2-19/+120
This patch adds the notion of a drm_bridge. A bridge is a chained device which hangs off an encoder. The drm driver using the bridge should provide the association between encoder and bridge. Once a bridge is associated with an encoder, it will participate in mode set, and dpms (via the enable/disable hooks). Signed-off-by: Sean Paul <[email protected]> Acked-by: Daniel Vetter <[email protected]> Reviewed-by: Rob Clark <[email protected]> Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm/nouveau: fix up 32-bit ioctls and device wake up.Dave Airlie2-1/+2
Noticed by kbuild test robot. Signed-off-by: Dave Airlie <[email protected]>
2013-09-02drm/tegra: fix up page flip flags.Dave Airlie1-1/+1
This was one level away from where I'd grepped. Signed-off-by: Dave Airlie <[email protected]>
2013-09-02Merge branch 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie142-6657/+20937
into drm-next Alex writes: This is the radeon drm-next request. Big changes include: - support for dpm on CIK parts - support for ASPM on CIK parts - support for berlin GPUs - major ring handling cleanup - remove the old 3D blit code for bo moves in favor of CP DMA or sDMA - lots of bug fixes [airlied: fix up a bunch of conflicts from drm_order removal] * 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits) drm/radeon/dpm: make sure dc performance level limits are valid (CI) drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2) drm/radeon: gcc fixes for extended dpm tables drm/radeon: gcc fixes for kb/kv dpm drm/radeon: gcc fixes for ci dpm drm/radeon: gcc fixes for si dpm drm/radeon: gcc fixes for ni dpm drm/radeon: gcc fixes for trinity dpm drm/radeon: gcc fixes for sumo dpm drm/radeonn: gcc fixes for rv7xx/eg/btc dpm drm/radeon: gcc fixes for rv6xx dpm drm/radeon: gcc fixes for radeon_atombios.c drm/radeon: enable UVD interrupts on CIK drm/radeon: fix init ordering for r600+ drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume radeon kms: fix uninitialised hotplug work usage in r100_irq_process() drm/radeon/audio: set up the sads on DCE3.2 asics drm/radeon: fix handling of variable sized arrays for router objects ... Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem_dmabuf.c drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/radeon/cik.c drivers/gpu/drm/radeon/ni.c drivers/gpu/drm/radeon/r600.c
2013-08-30drm/radeon/dpm: make sure dc performance level limits are valid (CI)Alex Deucher1-0/+6
Check to make sure the dc limits are valid before using them. Some systems may not have a dc limits table. In that case just use the ac limits. This fixes hangs on systems when the power state is changed when on battery (dc) due to invalid performance state parameters. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=68708 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2)Alex Deucher3-0/+18
Check to make sure the dc limits are valid before using them. Some systems may not have a dc limits table. In that case just use the ac limits. This fixes hangs on systems when the power state is changed when on battery (dc) due to invalid performance state parameters. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=68708 v2: fix up limits in dpm_init() Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2013-08-30drm/radeon: gcc fixes for extended dpm tablesAlex Deucher1-24/+50
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon: gcc fixes for kb/kv dpmAlex Deucher1-2/+5
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon: gcc fixes for ci dpmAlex Deucher1-2/+5
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon: gcc fixes for si dpmAlex Deucher1-2/+5
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon: gcc fixes for ni dpmAlex Deucher1-2/+3
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>
2013-08-30drm/radeon: gcc fixes for trinity dpmAlex Deucher1-2/+5
Newer versions of gcc seem to wander off into the weeds when dealing with variable sizes arrays in structs. Rather than indexing the arrays, use pointer arithmetic. See bugs: https://bugs.freedesktop.org/show_bug.cgi?id=66932 https://bugs.freedesktop.org/show_bug.cgi?id=66972 https://bugs.freedesktop.org/show_bug.cgi?id=66945 Signed-off-by: Alex Deucher <[email protected]>