- 03 Dec, 2014 34 commits
-
-
Chris Wilson authored
Before suspending, we wait upon the outstanding GPU requests and flush our pending idle handlers. This should downclock the GPU to its lowest power state. Add a WARN to check that the delayed tasks were run and did their job properly. Suggested-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now unused. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Dave Gordon authored
The logical ring code was updating the software ring 'head' value by reading the hardware 'HEAD' register. In LRC mode, this is not valid as the hardware is not necessarily executing the same context that is being processed by the software. Thus reading the h/w HEAD could put an unrelated (undefined, effectively random) value into the s/w 'head' -- A Bad Thing for the free space calculations. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dave Gordon authored
The request queue is per-engine, and may therefore contain requests from several different contexts/ringbuffers. In determining which request to wait for, this function should only consider requests from the ringbuffer that it's checking for space, and ignore any that it finds that belong to other contexts. Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
This patch is the last in series of VLV/CHV PSR, that finally enable PSR by adding it to HAS_PSR and calling the proper enable and disable functions on the right places. Although it is still disabled by default. v2: Rebase over intel_psr and merge Durgadoss's fixes. v3: Fix typo. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Add debugfs support for Valleyview and Cherryview considering that we have PSR per pipe and we don't have any kind of performance counter as we have on other platforms that support PSR. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
This patch introduces exit/activate functions for PSR on VLV+. Since on VLV+ HW cannot track frame updates and force PSR exit let's use fully SW tracking available. v2: Rebase over intel_psr.c; Remove Single Frame update transitioning from state 3 to 5 directly; Fake a software invalidation for sprites and cursor so we don't miss any screen update; v3: As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int, so let's use 1 instead. Althought the 1/4 of this is needed for the transition let's use 1 for simplicity; Also fix comments as suggested by Durgadoss Cc: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
The biggest difference from HSW/BDW PSR here is that VLV enable_source function enables PSR but let it in Inactive state. So it might be called on early stage along with setup and enable_sink ones. v2: Rebase over intel_psr.c; Remove docs from static functions; Merge vlv_psr_active_on_pipe; Timeout for psr transition is 250us; Remove SRC_TRASMITTER_STATE; v3: Rebase after is_psr_enabled function got removed; Get SRC_TRANSMITTER_STATE back to be on the safe side since default for panels is to require link training on exit when main link off; As pointed out by Durgadoss msecs_to_jiffies used on wait_for only uses int, so let's use 1 instead. Althought the 1/4 of this is needed for the transition let's use 1 for simplicity; Cc: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Baytrail (Valleyview) and Braswell (Cherryview) uses a complete different implementation of PSR that we currently have supported for Haswell and Broadwell. So let's start by adding registers definitions. I usually don't like commit that adds just registers without using, but after I put all in one commit I realized that no one would want to take the AR to review it so I decided to split in order to make reviewer's life easier. Only last commit in this series will actually enable the PSR on intel enable panel path. But as it happens currently with HSW/BDW the plan is to let it disabled by default (protected by kernel parameter) while we are able to fully validate it. v2: Remove a unused bit definition that isn't used on vlv and reserved on chv as pointed out by Durgadoss. Cc: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
This function was in use to check if PSR feature got enabled. However on HSW and BDW we currently force psr exit by disabling EDP_PSR_ENABLE bit at EDP_PSR_CTL(dev). So this function was actually returning the active/inactive state that is different from the enable/disable meaning and had the risk of false negative. But anyway this check with DRRS was dangerous, since DRRS could try to get enabled before PSR gets there. So let's just remove it for now. A proper synchronization mechanism must be implemented later probably using pipe config. Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Single frame update is a feature available on BDW for PSR that allows Source to send Sink only one frame and get it updated. Usually useful when page flipping. However with our frontbuffer tracking where we force psr exit on flips we don't need this feature. Also after it got added here many workaround was added to documentation to mask some bits when using single frame update. So the safest thing is to just stop using it. v2: Rebase after removing skip aux one and fixing typo on commit message. Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
OEMs can specify if full_link might be always enabled, i.e. only_standby over VBT. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
Let's use VBT + 1 now we parse it. v2: fix subject v3: rebase over intel_psr and without counting on previous fix Cc: Arthur Runyan <arthur.j.runyan@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Rodrigo Vivi authored
PSR (aka SRD) block is defined at VBT and currently being used. Mainly/At-least to configure the amount of idle_frames require to get back to PSR Entry. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Durgadoss R <durgadoss.r@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Because the plane registers are different in Skylake we need to adapt the MMIO code as well. v2: Don't introduce yet another vfunc when the direction is do consolidate the plane updates to use the same code path (Daniel) v3: - Use enum pipe instead of int (Ville) - Also update PLANE_STRIDE when the tiling has changed (Ville) - Put intel_mark_page_flip_active() in the shared code (Damien) v4: - Remove unused variable v5: - Fix whitespace Vs tabs (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
v2: Put the DPLL0 state readout in skylake_get_ddi_pll(), closer to where the PLL assignement read out is done rather than the frequency readout function. (Daniel) v3: Remove stray new line (Damien) Add Paulo's r-b tag for v1 Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (v1) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
On pre-HSW we have two encoders per digital port: one HDMI, one DP. However they are the same physical port in hardware and we can't enable both at the same time. Reject the modeset if the user attempts this. So far we've been saved by the fact that we never see both HDMI and DP connectors as connected. But if the user decides to force a mode anyway, all kinds of funny stuff might happen. Unfortunately we don't seem to have any way to inform userspace that such configurations are invalid except by returning an error from setcrtc. possible_clones only covers real cloning situations, and looking at the connector names doesn't work either since we don't always register both connectors for the same port. I suppose the only way to fix that would be to expose only a single encoder per digital port like we do on HSW+ but that would be a fairly large undertaking for little gain. kms_setmode hits this since it forces modes on non-connected VGA and HDMI connectors. Previosuly it just resulted in weirdness such as failed link training. With this patch it will now get an error back from the kernel and will die with an assert since it thinks that the configuration should be fine. v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo) Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Atm, igt/gem_reset_stats can trigger the recently added WARN on left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two reasons for this: 1. we call intel_enable_gt_powersave() without a preceeding intel_disable_gt_powersave() 2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR 1. means RPS interrupts will remain enabled and can be serviced during the HW initialization after a GPU reset. 2. means even if we called gen6_disable_rps_interrupts() any new RPS interrupt during RPS initialization would still propagate to PM_IIR too early (though wouldn't be serviced). This patch solves the 2. issue by also masking interrupts in PM_IMR, the following patch fixes 1. getting rid of the WARN. This also makes intel_enable_gt_powersave() and intel_disable_gt_powersave() more symmetric. Since gen6_disable_rps_interrupts() is called during driver loading with i915 interrupts disabled add a new version of gen6_disable_pm_irq() that doesn't WARN for this. Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR programming sequence and make sure that any queued PM_IIR bit is also cleared. The WARN was caught by PRTS after I sent my previous RPS sanitizing patchset and I could easily reproduce it on HSW. To actually fix it we also need the next patch. Reported-by: He, Shuang <shuang.he@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We don't really synchronously turn them off from debugfs. We try to avoid hitting them too badly by waiting one vblank, but apparently the irq handler can still race through that gap. Since this isn't really all that important for testcases, only for debugging CRC issues let's tune it down to a debug message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602 Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Thomas Daniel authored
Dynamic context pinning for LRCs introduced a leak in legacy mode. Reinstate context unreference in i915_gem_free_request for legacy contexts. Leak reported by i-g-t/drv_module_reload fixed by this patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: John Harrison<John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Akash Goel authored
Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Egbert Eich authored
Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker will be triggered with a delay from the last time edp_panel_vdd_schedule_off() is called, not the first time. This avoids unnecessary overhead. https://bugs.freedesktop.org/show_bug.cgi?id=86201 v2: use cancel_delayed_work() instead of cancel_delayed_work_sync() as the pps_mutexes will provide the required serialization with edp_panel_vdd_work() while the sync variant may deadlock. Suggested by Ville Syrjälä <ville.syrjala@linux.intel.com>. Made commit message a bit clearer. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. v3: There's really no need for rpm get/put since power_is_enabled only checks software state (Damien). References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Cc: Damien Lespiau <damien.lespiau@intel.com> (v2) Tested-by: lu hua <huax.lu@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
915/945 have the same reset registers as 965, so share the code. 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 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ä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
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: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 <daniel.vetter@ffwll.ch>
-
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: Daniel Vetter <daniel.vetter@intel.com>
-
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: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Clint Taylor authored
CHV infoframes were not being enabled. Signed-off-by: Clint Taylor <clinton.a.taylor@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
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 Dec, 2014 6 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: Daniel Vetter <daniel.vetter@ffwll.ch>
-
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 <bskeggs@redhat.com>
-