- 03 Sep, 2013 17 commits
-
-
Alex Williamson authored
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 <alex.williamson@redhat.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> [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 <daniel.vetter@ffwll.ch> fixup 2
-
Alex Williamson authored
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:
Dave Airlie <airlied@redhat.com> Reviewed-by:
-
Alex Williamson authored
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:
-
Chris Wilson authored
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 <chris@chris-wilson.co.uk> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Paulo Zanoni authored
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 <arthur.j.runyan@intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
Jesse Barnes authored
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 <mingo@kernel.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by:
H. Peter Anvin <hpa@zytor.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66726 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66844Signed-off-by:
-
Jesse Barnes authored
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: -
Joe Perches authored
The helper exists, might as well use it instead of __GFP_ZERO. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Chris Wilson authored
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=67600Signed-off-by:
Stephane Marchesin <marchesin@icps.u-strasbg.fr> Cc: Stephane Marchesin <marchesin@icps.u-strasbg.fr> Cc: Ben Widawsky <ben@bwidawsk.net> Tested-by:
Stéphane Marchesin <marcheu@chromium.org> Signed-off-by:
-
Chris Wilson authored
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:
-
Imre Deak authored
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 135c81b8 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 21:37:09 2013 +0200 drm/i915: clean up crtc timings computation Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Daniel Vetter authored
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 05407ff8 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Thu May 30 09:04:29 2013 +0300 drm/i915: detect hang using per ring hangcheck_score Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68641Signed-off-by:
-
Chris Wilson authored
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:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Chris Wilson authored
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 <kobe.qin@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67733Tested-by:
-
Chris Wilson authored
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=67734Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Mika Kuoppala authored
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:
-
Mika Kuoppala authored
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 <vinit.azad@intel.com> 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 <vinit.azad@intel.com> Signed-off-by:Vinit Azad <vinit.azad@intel.com> Signed-off-by:
-
- 02 Sep, 2013 6 commits
-
-
Christian König authored
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 <christian.koenig@amd.com> Signed-off-by:
David Herrmann <dh.herrmann@gmail.com> Signed-off-by:
-
Martin Peres authored
Enable support for drm render nodes for nouveau by flagging the ioctls that are safe and just needed for rendering. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by:
Martin Peres <martin.peres@labri.fr> Signed-off-by:
-
Kristian Høgsberg authored
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 <krh@bitplanet.net> Signed-off-by:
-
David Herrmann authored
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 a14b1b42 Author: Mandeep Singh Baines <mandeep.baines@gmail.com> 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: <stable@vger.kernel.org> Signed-off-by:
-
Rob Clark authored
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 <robdclark@gmail.com> Signed-off-by:
-
Sean Paul authored
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 <seanpaul@chromium.org> Acked-by:
-
- 01 Sep, 2013 3 commits
-
-
Dave Airlie authored
Noticed by kbuild test robot. Signed-off-by: -
Dave Airlie authored
This was one level away from where I'd grepped. Signed-off-by: -
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
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
-
- 30 Aug, 2013 14 commits
-
-
Alex Deucher authored
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=68708Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
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 authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Alex Deucher authored
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=66945Signed-off-by:
-
Christian König authored
The same as on evergreen. Signed-off-by:
FrankR Huang <FrankR.Huang@amd.com> Signed-off-by:
-
Alex Deucher authored
The vram scratch buffer needs to be initialized before the mc is programmed otherwise we program 0 as the GPU address of the default GPU fault page. In most cases we put vram at zero anyway and reserve a page for the legacy vga buffer so in practice this shouldn't cause any problems, but better to make it correct. Was changed in: 6fab3febReported-by:
-
