aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-07-01drm/radeon/dpm: add debugfs support for rv6xxAlex Deucher3-0/+28
This allows you to look at the current DPM state via debugfs. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon/dpm: add infrastructure to support debugfs infoAlex Deucher2-13/+29
This lays the frameworks to report realtime power level feedback. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon/dpm: re-enable state transitions for CaymanAlex Deucher1-5/+0
Was disabled due to stability issues on certain boards caused by the a bug in the parsing of the atom mc reg tables. That's fixed now so re-enable. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon/dpm: re-enable state transitions for BTCAlex Deucher1-3/+0
Was disabled due to stability issues on certain boards caused by the a bug in the parsing of the atom mc reg tables. That's fixed now so re-enable. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon: fix typo in radeon_atom_init_mc_reg_table()Alex Deucher1-1/+2
Bad pointer math. Fixes hangs in state transitions with BTC+ asics. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon/atom: fix endian bug in radeon_atom_init_mc_reg_table()Alex Deucher1-1/+1
Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/radeon: remove sumo dpm/uvd bringup leftoversAlex Deucher1-17/+0
Function doesn't do anything useful. Signed-off-by: Alex Deucher <[email protected]>
2013-07-01drm/i915: Break up the large vsnprintf() in print_error_buffers()Chris Wilson1-30/+79
So it appears that I have encountered some bogosity when trying to call i915_error_printf() with many arguments from print_error_buffers(). The symptom is that the vsnprintf parser tries to interpret an integer arg as a character string, the resulting OOPS indicating stack corruption. Replacing the single call with its 13 format specifiers and arguments with multiple calls to i915_error_printf() worked fine. This patch goes one step further and introduced i915_error_puts() to pass the strings simply. It may not fix the root cause, but it does prevent my box from dying and I think helps make print_error_buffers() more friendly. Signed-off-by: Chris Wilson <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66077 Cc: Mika Kuoppala <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Refactor the wait_rendering completion into a common routineChris Wilson1-25/+23
Harmonise the completion logic between the non-blocking and normal wait_rendering paths, and move that logic into a common function. In the process, we note that the last_write_seqno is by definition the earlier of the two read/write seqnos and so all successful waits will have passed the last_write_seqno. Therefore we can unconditionally clear the write seqno and its domains in the completion logic. v2: Add the missing ring parameter, because sometimes it is good to have things compile. Signed-off-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Only clear write-domains after a successful wait-seqnoChris Wilson1-1/+2
In the introduction of the non-blocking wait, I cut'n'pasted the wait completion code from normal locked path. Unfortunately, this neglected that the normal path returned early if the wait returned early. The result is that read-only waits may return whilst the GPU is still writing to the bo. Fixes regression from commit 3236f57a0162391f84b93f39fc1882c49a8998c7 [v3.7] Author: Chris Wilson <[email protected]> Date: Fri Aug 24 09:35:09 2012 +0100 drm/i915: Use a non-blocking wait for set-to-domain ioctl Signed-off-by: Chris Wilson <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66163 Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: correct intel_dp_get_config() function for DevCPTXiong Zhang2-11/+27
On DevCPT, the control register for Transcoder DP Sync Polarity is TRANS_DP_CTL, not DP_CTL. Without this patch, Many call trace occur on CPT machine with DP monitor. The call trace is like: *ERROR* mismatch in adjusted_mode.flags(expected X,found X) v2: use intel-crtc to simple patch, suggested by Daniel. Signed-off-by: Xiong Zhang <[email protected]> [danvet: Extend the encoder->get_config comment to specify that we now also depend upon intel_encoder->base.crtc being correct. Also bikeshed s/intel_crtc/crtc/.] Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65287 Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fix hpd interrupt register lockingDaniel Vetter1-5/+10
Our interrupt handler (in hardirq context) could race with the timer (in softirq context), hence we need to hold the spinlock around the call to ->hdp_irq_setup in intel_hpd_irq_handler, too. But as an optimization (and more so to clarify things) we don't need to do the irqsave/restore dance in the hardirq context. Note also that on ilk+ the race isn't just against the hotplug reenable timer, but also against the fifo underrun reporting. That one also modifies the SDEIMR register (again protected by the same dev_priv->irq_lock). To lock things down again sprinkle a assert_spin_locked. But exclude the functions touching SDEIMR for now, I want to extract them all into a new helper function (like we do already for pipestate, display interrupts and all the various gt interrupts). v2: Add the missing 't' Egbert spotted in a comment. v3: Actually fix the right misspelled comment (Paulo). Cc: Egbert Eich <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fold the no-irq check into intel_hpd_irq_handlerDaniel Vetter1-16/+17
The usual pattern for our sub-function irq_handlers is that they check for the no-irq case themselves. This results in more streamlined code in the upper irq handlers. v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <[email protected]> Reviewed-by: Egbert Eich <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fold the queue_work into intel_hpd_irq_handlerDaniel Vetter1-8/+3
Everywhere the same. Note that this patch leaves unnecessary braces behind, but the next patch will kill those all anyway (including the if itself) so I've figured I can keep the diff a bit smaller. v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <[email protected]> Reviewed-by: Egbert Eich <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fold the hpd_irq_setup call into intel_hpd_irq_handlerDaniel Vetter1-18/+11
We already have a vfunc for this (and other parts of the hpd storm handling code already use it). v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <[email protected]> Reviewed-by: Egbert Eich <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: s/hotplug_irq_storm_detect/intel_hpd_irq_handler/Daniel Vetter1-8/+8
The combination of Paulo's fifo underrun detection code and Egbert's hpd storm handling code unfortunately made the hpd storm handling code racy. To avoid duplicating tricky interrupt locking code over all platforms start with a bit of refactoring. This patch is the very first step since in the end the irq storm handling code will handle all hotplug logic (and so also encapsulate the locking nicely). v2: Rebase on top of the i965g/gm sdvo hpd fix. Cc: Egbert Eich <[email protected]> Reviewed-by: Egbert Eich <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: close tiny race in the ilk pcu even interrupt setupDaniel Vetter1-6/+5
By the time we write DEIER in the postinstall hook the interrupt handler could run any time. And it does modify DEIER to handle interrupts. Hence the DEIER read-modify-write cycle for enabling the PCU event source is racy. Close this races the same way we handle vblank interrupts: Unconditionally enable the interrupt in the IER register, but conditionally mask it in IMR. The later poses no such race since the interrupt handler does not touch DEIMR. Also update the comment, the clearing has already happened unconditionally above. v2: Actually shove the updated comment into the right train^W commit, as spotted by Paulo. Cc: Paulo Zanoni <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fix locking around ironlake_enable|disable_display_irqDaniel Vetter1-3/+24
The haswell unclaimed register handling code forgot to take the spinlock. Since this is in the context of the non-rentrant interupt handler and we only have one interrupt handler it is sufficient to just grab the spinlock - we do not need to exclude any other interrupts from running on the same cpu. To prevent such gaffles in the future sprinkle assert_spin_locked over these functions. Unfornately this requires us to hold the spinlock in the ironlake postinstall hook where it is not strictly required: Currently that is run in single-threaded context and with userspace exlcuded from running concurrent ioctls. Add a comment explaining this. v2: ivb_can_enable_err_int also needs to be protected by the spinlock. To ensure this won't happen in the future again also sprinkle a spinlock assert in there. v3: Kill the 2nd call to ivb_can_enable_err_int I've accidentally left behind, spotted by Paulo. Cc: Paulo Zanoni <[email protected]> Reviewed-by: Paulo Zanoni <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Fix context sizes on HSWBen Widawsky2-9/+8
With updates to the spec, we can actually see the context layout, and how many dwords are allocated. That table suggests we need 70720 bytes per HW context. Rounded up, this is 18 pages. Looking at what lives after the current 4 pages we use, I can't see too much important (mostly it's d3d related), but there are a couple of things which look scary. I am hopeful this can explain some of our odd HSW failures. v2: Make the context only 17 pages. The power context space isn't used ever, and execlists aren't used in our driver, making the actual total 66944 bytes. v3: Add a comment to the code. (Jesse & Paulo) Reported-by: "Azad, Vinit" <[email protected]> Cc: [email protected] Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Ben Widawsky <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Fix VLV sprite register offsetsVille Syrjälä1-25/+25
We forgot to add VLV_DISPLAY_BASE to the VLV sprite registers, which caused the sprites to not work at all. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01Revert "drm/i915: Don't use the HDMI port color range bit on Valleyview"Ville Syrjälä1-1/+1
The PIPECONF color range bit doesn't appear to be effective, on HDMI outputs at least. The color range bit in the port register works though, so let's use it. I have not yet verified whether the PIPECONF bit works on DP outputs. This reverts commit 83a2af88f80ebf8104c9e083b786668b00f5b9ce. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: s/LFP/LPF in DPIO PLL register namesVille Syrjälä3-9/+9
LPF is short for "low pass filter". Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Fix VLV PLL LPF coefficients for DACVille Syrjälä1-0/+1
The current PLL settings produce a rather unstable picture when I hook up a VLV to my HP ZR24w display via a VGA cable. According to VLV2A0_DP_eDP_HDMI_DPIO_driver_vbios_notes_9, we should use the the same LPF coefficients for DAC as we do for HDMI and RBR DP. And indeed that seems to cure the shivers. v2: Add the name of the relevant document to the commit message Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Jump to at least RPe on VLV when increasing the GPU frequencyVille Syrjälä1-2/+10
If the current GPU frquency is below RPe, and we're asked to increase it, just go directly to RPe. This should provide better performance faster than letting the frequency trickle up in response to the up threshold interrupts. For now just do it for VLV, since that matches quite closely how VLV used to operate when the rps delayed timer kept things at RPe always. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Don't increase the GPU frequency from the delayed VLV rps timerVille Syrjälä1-1/+2
There's little point in increasing the GPU frequency from the delayed rps work on VLV. Now when the GPU is idle, the GPU frequency actually keeps dropping gradually until it hits the minimum, whereas previously it just ping-ponged constantly between RPe and RPe-1. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: GEN6_RP_INTERRUPT_LIMITS doesn't seem to exist on VLVVille Syrjälä1-6/+2
I can't find GEN6_RP_INTERRUPT_LIMITS (0xA014) anywhere in VLV docs. Reading it always returns zero from what I can tell, and eliminating it doesn't seem to make any difference to the behaviour of the system. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Make the rps new_delay comparison more readableVille Syrjälä1-2/+2
Eliminate the weird inverted logic from the rps new_delay comparison. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Don't wait for Punit after each freq change on VLVVille Syrjälä1-18/+35
It seems that even though Punit reports the frequency change to have been completed, it still reports the old frequency in the status register for some time. So rather than polling for Punit to complete the frequency change after each request, poll before. This gets rid of the spurious "Punit overrode GPU freq" messages. This also lets us continue working while Punit is performing the actual frequency change. As a result, openarena demo088-test1 timedemo average fps is increased by ~5 fps, and the slowest frame duration is reduced by ~25%. The sysfs cur_freq file always reads the current frequency from Punit anyway, so having rps.cur_delay be slightly off at times doesn't matter. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Clean up VLV rps code a bitVille Syrjälä1-20/+30
Always print both the MHz value and raw register value for rps stuff. Also kill a somewhat pointless local 'rpe' variable and just use dev_priv->rps.rpe_delay. While at it clean up the caps in "GPU" and "Punit" debug messages. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Jesse Barnes <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Detect invalid scanout pitchesChris Wilson1-4/+21
Report back the user error of attempting to setup a CRTC with an invalid framebuffer pitch. This is trickier than it should be as on gen4, there is a restriction that tiled surfaces must have a stride less than 16k - which is less than the largest supported CRTC size. v2: Fix the limits for gen3 v3: Move check into intel_framebuffer_init() and fix VLV limits. (vsyrjala) v4: Use idiomatic '>=' for generation checks References: https://bugs.freedesktop.org/show_bug.cgi?id=65099 Signed-off-by: Chris Wilson <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Remove duplicated WaForceL3Serialization:vlvVille Syrjälä1-4/+0
No need to apply WaForceL3Serialization:vlv twice. Signed-off-by: Ville Syrjälä <[email protected]> Reviewed-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: don't scream into dmesg when a modeset failsDaniel Vetter1-2/+2
There are legit cases, e.g. when userspace asks for something impossible. So tune it down to debug output like we do with all other userspace-triggerable warnings. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66111#c5 Reviewed-by: Chris Wilson <[email protected]> [danvet: Rebased.] Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Fix up sdvo hpd pins for i965g/gmDaniel Vetter2-18/+8
Bspec seems to be full of lies, at least it disagress with reality: Two systems corrobated that SDVO hpd bits are the same as on gen3. v2: Update comment a bit. Cc: Arthur Ranyan <[email protected]> Cc: Chris Wilson <[email protected]> Tested-by: Chris Wilson <[email protected]> Reported-and-tested-by: Alex Fiestas <[email protected]> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=58405 Cc: [email protected] Acked-by: Chris Wilson <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Introduce an HAS_IPS() macroDamien Lespiau3-3/+5
Follow the trend and don't code conditions with platforms but with features. Signed-off-by: Damien Lespiau <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: fix build warning on format specifier mismatchJani Nikula1-1/+1
drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_object_bind_to_gtt’: drivers/gpu/drm/i915/i915_gem.c:3002:3: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘size_t’ [-Wformat] v2: Use %zu instead of %d. Two char patch, and 100% wrong. (Ville) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: tune down DIDL warning about too many outputsDaniel Vetter1-4/+4
Nothing the user (nor we) really can do about this, but upsets a nice quiet boot. Note that this happens mostly on SDVs where OEMs obviously haven't had a chance yet to appropriately trim the output list. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65988 Reviewed-by: Damien Lespiau <[email protected]> [danvet: Amend commit message a bit to clarify a question from Paulo.] Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: make compact dma scatter lists creation work with SWIOTLB backend.Konrad Rzeszutek Wilk1-3/+12
Git commit 90797e6d1ec0dfde6ba62a48b9ee3803887d6ed4 ("drm/i915: create compact dma scatter lists for gem objects") makes certain assumptions about the under laying DMA API that are not always correct. On a ThinkPad X230 with an Intel HD 4000 with Xen during the bootup I see: [drm:intel_pipe_set_base] *ERROR* pin & fence failed [drm:intel_crtc_set_config] *ERROR* failed to set mode on [CRTC:3], err = -28 Bit of debugging traced it down to dma_map_sg failing (in i915_gem_gtt_prepare_object) as some of the SG entries were huge (3MB). That unfortunately are sizes that the SWIOTLB is incapable of handling - the maximum it can handle is a an entry of 512KB of virtual contiguous memory for its bounce buffer. (See IO_TLB_SEGSIZE). Previous to the above mention git commit the SG entries were of 4KB, and the code introduced by above git commit squashed the CPU contiguous PFNs in one big virtual address provided to DMA API. This patch is a simple semi-revert - were we emulate the old behavior if we detect that SWIOTLB is online. If it is not online then we continue on with the new compact scatter gather mechanism. An alternative solution would be for the the '.get_pages' and the i915_gem_gtt_prepare_object to retry with smaller max gap of the amount of PFNs that can be combined together - but with this issue discovered during rc7 that might be too risky. Reported-and-Tested-by: Konrad Rzeszutek Wilk <[email protected]> CC: Chris Wilson <[email protected]> CC: Imre Deak <[email protected]> CC: Daniel Vetter <[email protected]> CC: David Airlie <[email protected]> CC: <[email protected]> Signed-off-by: Konrad Rzeszutek Wilk <[email protected]> Cc: [email protected] Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: Fix PCH detect with multiple ISA bridges in VMRui Guo1-2/+16
In some virtualized environments (e.g. XEN), there is irrelevant ISA bridge in the system. To work reliably, we should scan trhough all the ISA bridge devices and check for the first match, instead of only checking the first one. Signed-off-by: Rui Guo <[email protected]> [danvet: Fixup conflict with the num_pch_pll removal. And add subsystem header to the commit message headline.] Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01drm/i915: rename intel_dp_destroy to intel_dp_connector_destroyPaulo Zanoni1-2/+2
Because it's the function that destroys the connector, not the encoder. And we already have intel_dp_encoder_destroy. This has annoyed me for a long time. Signed-off-by: Paulo Zanoni <[email protected]> Reviewed-by: Zoltan Nyul <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-07-01Merge branch 'drm-nouveau-next' of ↵Dave Airlie138-5449/+7058
git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next - Various fixes that make surviving concurrent piglit more possible. - Buffer object deletion no longer synchronous - Context/register initialisation updates that have been reported to solve some stability issues (particularly on some problematic GF119 chips) - Kernel side support for VP2 video decoding engines * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (44 commits) drm/nvd0-/disp: handle case where display engine is missing/disabled drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4 drm/nouveau/bsp/nv84: initial vp2 engine implementation drm/nouveau/vp/nv84: initial vp2 engine implementation drm/nouveau/core: xtensa engine base class implementation drm/nouveau/vdec: fork vp3 implementations from vp2 drm/nouveau/core: move falcon class to engine/ drm/nouveau/kms: don't fail if there's no dcb table entries drm/nouveau: remove limit on gart drm/nouveau/vm: perform a bar flush when flushing vm drm/nvc0/gr: cleanup register lists, and add nvce/nvcf to switches drm/nvc8/gr: update initial register/context values drm/nvc4/gr: update initial register/context values drm/nvc1/gr: update initial register/context values drm/nvc3/gr: update initial register/context values drm/nvc0/gr: update initial register/context values drm/nvd9/gr: update initial register/context values drm/nve4/gr: update initial register/context values drm/nvc0-/gr: bump maximum gpc/tpc limits drm/nvf0/gr: initial register/context setup ...
2013-07-01drm/nvd0-/disp: handle case where display engine is missing/disabledMaarten Lankhorst6-7/+17
Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4Ben Skeggs14-2587/+1270
No code changes, proven by envyas producing identical binaries. Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/bsp/nv84: initial vp2 engine implementationIlia Mirkin3-14/+16
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/vp/nv84: initial vp2 engine implementationIlia Mirkin4-14/+17
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/core: xtensa engine base class implementationIlia Mirkin3-0/+209
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/vdec: fork vp3 implementations from vp2Ilia Mirkin6-14/+204
Signed-off-by: Ilia Mirkin <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/core: move falcon class to engine/Ben Skeggs11-24/+21
Not really "core" per-se. About to merge Ilia's work adding another similar class for the VP2 xtensa engines, so, seems like a good time to move all these to engine/. Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/kms: don't fail if there's no dcb table entriesBen Skeggs2-7/+9
Fixes module not loading on Tesla K20. Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau: remove limit on gartMaarten Lankhorst1-5/+0
Most graphics cards nowadays have a multiple of this limit as their vram, so limiting GART doesn't seem to make much sense. Signed-off-by: Maarten >Lnkhorst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
2013-07-01drm/nouveau/vm: perform a bar flush when flushing vmMaarten Lankhorst2-0/+8
Appears to fix the regression from "drm/nvc0/vm: handle bar tlb flushes internally". nvidia always seems to do this flush after writing values. Signed-off-by: Maarten Lankhorst <[email protected]> Signed-off-by: Ben Skeggs <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.