- 03 Dec, 2014 11 commits
-
-
Ville Syrjälä authored
The GPU reset also resets the display on gen3/4. The g33 docs say we should disable all planes before flipping the reset switch. Just disable all the crtcs instead. That seems a nicer thing to do anyway. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Ville Syrjälä authored
g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by:
-
Ville Syrjälä authored
915/945 have the same reset registers as 965, so share the code. Signed-off-by:
-
Ville Syrjälä authored
On pre-ctg GPU reset also resets the display hardware. Force a mode restore after the GPU reset, and also re-init clock gating. v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating() in case more relevant stuff gets added there at some point Restore interrupts after the reset as well Tested-by:Kenneth Graunke <kenneth@whitecape.org> Signed-off-by:
-
Ville Syrjälä authored
On pre-ctg the reset bit directly controls the reset signal. We must assert it for >=20usec and then deassert it. Bit 1 is a RO status bit which should also go down when the reset is no longer asserted. Tested-by:
-
Daniel Vetter authored
There's quite a few bug reports with error states where the error reasons makes just about no sense at all. Like dying on tlbs for a display plane that's not even there. Also users don't really report a lot of bad side effects generally, just the error states. Furthermore we don't even enable these interrupts any more on gen5+ (though the handling code is still there). So this mostly concerns old platforms. Given all that lets make our lives a bit easier and stop capturing error states, in the hopes that we can just ignore them. In case that's not true and the gpu indeed dies the hangcheck should eventually kick in. And I've left some debug log in to make this case noticeble. Referenced bug is just an example. v2: Fix missing \n Jani spotted. References: https://bugs.freedesktop.org/show_bug.cgi?id=82095 References: https://bugs.freedesktop.org/show_bug.cgi?id=85944Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Signed-off-by:
-
Daniel Vetter authored
The problem here is that SNA pins batchbuffers to etch out a bit more performance. Iirc it started out as a w/a for i830M (which we've implemented in the kernel since a long time already). The problem is that the pin ioctl wasn't added in commit d23db88c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 23 08:48:08 2014 +0200 drm/i915: Prevent negative relocation deltas from wrapping Fix this by simply disallowing pinning from userspace so that the kernel is in full control of batch placement again. Especially since distros are moving towards running X as non-root, so most users won't even be able to see any benefits. UMS support is dead now, but we need this minimal patch for backporting. Follow-up patch will remove the pin ioctl code completely. Note to backporters: You must have both commit b45305fc Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 which laned in 3.8 and commit c4d69da1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 8 14:25:41 2014 +0100 drm/i915: Evict CS TLBs between batches which is also marked cc: stable. Otherwise this could introduce a regression by disabling the userspace w/a without the kernel w/a being fully functional on i830/45. References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116 Cc: stable@vger.kernel.org # requires c4d69da1 and v3.8 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Chris Wilson authored
In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142c Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Clint Taylor authored
CHV infoframes were not being enabled. Signed-off-by:
Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by:
-
Ville Syrjälä authored
When doing a nop modeset we currently leave crtc->new_config point at the already freed temporary pipe_config. That will anger the sanity checks in intel_modeset_update_state() when the nop modeset gets followed by a GPU reset on gen3/4 where the display block gets fully reinitialized during the reset. So leave crtc->new_config alone until we know a modeset is actually required. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
- 02 Dec, 2014 29 commits
-
-
Laurent Pinchart authored
The DRM connector's encoder pointer is managed internally by the DRM core and set to NULL when the DRM connector is disconnected from the CRTC it was attached to. This results in a NULL pointer dereference in the HDMI connector functions when trying to call the associated slave encoder's operations. Fix this by retrieving the slave encoder pointer from the R-Car connector structure instead of the DRM connector structure. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Dave Airlie authored
Merge tag 'drm-intel-next-2014-11-21-fixed' of git://anongit.freedesktop.org/drm-intel into drm-next drm-intel-next-2014-11-21: - infoframe tracking (for fastboot) from Jesse - start of the dri1/ums support removal - vlv forcewake timeout fixes (Imre) - bunch of patches to polish the rps code (Imre) and improve it on bdw (Tom O'Rourke) - on-demand pinning for execlist contexts - vlv/chv backlight improvements (Ville) - gen8+ render ctx w/a work from various people - skl edp programming (Satheeshakrishna et al.) - psr docbook (Rodrigo) - piles of little fixes and improvements all over, as usual * tag 'drm-intel-next-2014-11-21-fixed' of git://anongit.freedesktop.org/drm-intel: (117 commits) drm/i915: Don't pin LRC in GGTT when dumping in debugfs drm/i915: Update DRIVER_DATE to 20141121 drm/i915/g4x: fix g4x infoframe readout drm/i915: Only call mod_timer() if not already pending drm/i915: Don't rely upon encoder->type for infoframe hw state readout drm/i915: remove the IRQs enabled WARN from intel_disable_gt_powersave drm/i915: Use ggtt error obj capture helper for gen8 semaphores drm/i915: vlv: increase timeout when setting idle GPU freq drm/i915: vlv: fix cdclk setting during modeset while suspended drm/i915: Dump hdmi pipe_config state drm/i915: Gen9 shadowed registers drm/i915/skl: Gen9 multi-engine forcewake drm/i915: Read power well status before other registers for drpc info drm/i915: Pin tiled objects for L-shaped configs drm/i915: Update ring freq for full gpu freq range drm/i915: change initial rps frequency for gen8 drm/i915: Keep min freq above floor on HSW/BDW drm/i915: Use efficient frequency for HSW/BDW drm/i915: Can i915_gem_init_ioctl drm/i915: Sanitize ->lastclose ...
-
Thomas Daniel authored
LRC object does not need to be mapped into the GGTT when dumping. A side-effect of this patch is that a compiler warning goes away (not checking return value of i915_gem_obj_ggtt_pin). v2: Broke out individual context dumping into a new function as the indentation was getting a bit crazy. Added notification of contexts with no gem object for debugging purposes. Removed unnecessary pin_pages and unpin_pages, replaced with explicit get_pages for the context object as there may be no backing store allocated at this time (Comment for get_pages says "Ensure that the associated pages are gathered from the backing storage and pinned into our object"). Improved error checking - get_pages and get_page are checked for failure. Signed-off-by:
Thomas Daniel <thomas.daniel@intel.com> [danvet: Align paramter continuation lines properly. Also add some braces to the nested loops again for readability.] Signed-off-by:
-
git://anongit.freedesktop.org/git/nouveau/linux-2.6Dave Airlie authored
- Tegra K1 voltage support, and coherency improvements - GM204 support (modesetting, still waiting on NVIDIA for signed fw to proceed further), and a lot of bios/i2c/devinit adjustments needed to support it - GT21x memory reclocking work - Various other bits and pieces, most of which are prep-work for a couple of bigger projects I didn't get finished in time * 'linux-3.19' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (73 commits) drm/nv50/kms: drop requirement that framebuffer bos be contig up-front drm/nv50/kms: directly use cursor image from userspace buffer drm/nouveau/kms: when pinning display-related buffers, force contig vram drm/nouveau: teach nouveau_bo_pin() how to force a contig vram allocation drm/nouveau/volt: add support for GK20A drm/nouveau/platform: add GPU speedo information to nouveau platform drm/nouveau/volt: allow non-bios voltage scaling drm/gf100-/gr: return non-fatal error code when fw not present drm/nouveau/devinit: bump priv ring timeouts before executing scripts drm/nouveau/bios: translate ramcfg strap through M0203 drm/nouveau/fb: make use of M0203 routines for ram type determination drm/nouveau/bios: add parsing of BIT M(v2) +0x03 table drm/nouveau/core: allow vbios parsing without knowing chipset type drm/nouveau/lib: add null backend drm/nouveau/device: store revision drm/nouveau/core: add some forgotten subdevs to disable mask drm/gk20a/clk: fix max VCO value drm/nouveau: we need pin_refcnt for nouveau_bo_placement_set() drm/nv50-/kms: add some evo tracing ability for debugging drm/nv50/kms: use sclass() instead of trial-and-error ...
-
Ben Skeggs authored
We'll move them at pin() time if necessary. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Ben Skeggs authored
Preparation for transition to planes, which use framebuffers for the cursor image. We've always done copies from the userspace buffer up until now for legacy reasons, there's no good reason to do so on the chipsets this code covers. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We have the ability to move buffers around in the kernel if necessary, and should probably use it rather than failing if userspace passes us a non-contig buffer for a plane. The NOUVEAU_GEM_TILE_NONCONTIG flag from userspace will become a mere initial placement hint once all the relevant paths have been updated. Signed-off-by: -
Vince Hsu authored
The voltage value are calculated by the hardware characterized result. Signed-off-by:
Vince Hsu <vinceh@nvidia.com> Reviewed-by:
Alexandre Courbot <acourbot@nvidia.com> Acked-by:
Martin Peres <martin.peres@free.fr> Signed-off-by:
-
Vince Hsu authored
For GK20A we need the GPU speedo value to calculate voltage levels. Signed-off-by:
-
Vince Hsu authored
Move the vbios parsing out of init() and call it conditionally if the platform has a vbios. Non-vbios platforms can use the ctor() to init the data structures. Signed-off-by:
-
Ben Skeggs authored
This allows the module to load without acceleration. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
A machine has been spotted where the ramcfg strap is "8", and the ramcfg xlat table goes 0-7,0-7, resulting in us selecting config 0 for memory items. On this particular system, config "8" is available and supposed to be used. It appears that starting from GT21x (where Mv2 appears), we're supposed to use the value in this table instead. One concern here is that not all the places we currently use ramcfg xlat are supposed to be treated the same now. The strap xlat table wasn't removed from the vbios either, presumably for some kind of good reason. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
We only support one kind of matching here (ramcfg strap), but it appears alternate methods are possible. I wrote a tool to scan our vbios repo for other types, but did not see any used. Hopefully this means there aren't any in the wild that will now break. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
For the moment, just used to speed up vbios-only testing. Have some ideas for extending in the future. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
For some reason max_vco was set to a lower value that it can support, which prevented some clock states to be applied. Fix this by setting it to the same value as downstream. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Alexandre Courbot authored
On architectures for which access to GPU memory is non-coherent, caches need to be flushed and invalidated explicitly when BO control changes between CPU and GPU. This patch adds buffer synchronization functions which invokes the correct API (PCI or DMA) to ensure synchronization is effective. Based on the TTM DMA cache helper patches by Lucas Stach. Signed-off-by:
Lucas Stach <dev@lynxeye.de> Signed-off-by:
-
Alexandre Courbot authored
Specify TTM_PL_FLAG_UNCACHED when allocating GPFIFOs and fences to allow them to be safely accessed by the kernel without being synced on non-coherent architectures. Signed-off-by:
-
Alexandre Courbot authored
Allow nouveau_bo_new() to recognize the TTM_PL_FLAG_UNCACHED flag, which means that we want the allocated BO to be perfectly coherent between the CPU and GPU. This is useful on non-coherent architectures for which we do not want to manually sync some rarely-accessed buffers: typically, fences and pushbuffers. A TTM BO allocated with the TTM_PL_FLAG_UNCACHED on a non-coherent architecture will be populated using the DMA API, and accesses to it performed using the coherent mapping performed by dma_alloc_coherent(). Signed-off-by:
-
