aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm
Commit message (Collapse)AuthorAge
* Merge tag 'v3.5-rc7' into drm-nextDave Airlie2012-07-20
|\ | | | | | | | | | | | | | | | | | | | | | | Merge Linus tree into drm to fixup conflicts in radeon code for further testing before upstream merge. Signed-off-by: Dave Airlie <airlied@redhat.com> Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/radeon/radeon_gart.c
| * drm/i915: kick any firmware framebuffers before claiming the gttDaniel Vetter2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Especially vesafb likes to map everything as uc- (yikes), and if that mapping hangs around still while we try to map the gtt as wc the kernel will downgrade our request to uc-, resulting in abyssal performance. Unfortunately we can't do this as early as readon does (i.e. as the first thing we do when initializing the hw) because our fb/mmio space region moves around on a per-gen basis. So I've had to move it below the gtt initialization, but that seems to work, too. The important thing is that we do this before we set up the gtt wc mapping. Now an altogether different question is why people compile their kernels with vesafb enabled, but I guess making things just work isn't bad per se ... v2: - s/radeondrmfb/inteldrmfb/ - fix up error handling v3: Kill #ifdef X86, this is Intel after all. Noticed by Ben Widawsky. v4: Jani Nikula complained about the pointless bool primary initialization. v5: Don't oops if we can't allocate, noticed by Chris Wilson. v6: Resolve conflicts with agp rework and fixup whitespace. This is commit e188719a2891f01b3100d in drm-next. Backport to 3.5 -fixes queue requested by Dave Airlie - due to grub using vesa on fedora their initrd seems to load vesafb before loading the real kms driver. So tons more people actually experience a dead-slow gpu. Hence also the Cc: stable. Cc: stable@vger.kernel.org Reported-and-tested-by: "Kilarski, Bernard R" <bernard.r.kilarski@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm: edid: Don't add inferred modes with higher resolutionTakashi Iwai2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When a monitor EDID doesn't give the preferred bit, driver assumes that the mode with the higest resolution and rate is the preferred mode. Meanwhile the recent changes for allowing more modes in the GFT/CVT ranges give actually more modes, and some modes may be over the native size. Thus such a mode would be picked up as the preferred mode although it's no native resolution. For avoiding such a problem, this patch limits the addition of inferred modes by checking not to be greater than other modes. Also, it checks the duplicated mode entry at the same time. Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: fix rare segfaultJerome Glisse2012-07-03
| | | | | | | | | | | | | | | | | | | | | | | | In gem idle/busy ioctl the radeon object was derefenced after drm_gem_object_unreference_unlocked which in case the object have been destroyed lead to use of a possibly free pointer with possibly wrong data. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon: fix VM page table setup on SIAlex Deucher2012-06-29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Cayman and trinity allow for variable sized VM page tables, but SI requires that all page tables be the same size. The current code assumes variablely sized VM page tables so SI may end up with part of each page table overlapping with other memory which could end up being interpreted by the VM hw as garbage. Change the code to better accomodate SI. Allocate enough space for at least 2 full page tables and always set last_pfn to max_pfn on SI so each VM is backed by a full page table. This limits us to only 2 VMs active at any given time on SI. This will be rectified and the code can be reunified once we move to two level page tables. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * Merge branch 'drm-intel-fixes' of ↵Dave Airlie2012-06-27
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Daniel writes: "Two tiny patches and one revert: - Kill a bogus error message introduced in 3.4, further Bspec reading indicates that this is how the hw is supposed to work. - Reorder one backlight register restore, fixing broken backlight on some machines after resume. - Revert a hack from Jesse for ivb backlight control - it breaks the backlight controls on my shiny new ivb laptop." * 'drm-intel-fixes' of git://people.freedesktop.org/~danvet/drm-intel: Revert "drm/i915: allow PCH PWM override on IVB" drm/i915: Fix eDP blank screen after S3 resume on HP desktops drm/i915: rip out the PM_IIR WARN
| | * Revert "drm/i915: allow PCH PWM override on IVB"Daniel Vetter2012-06-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit f82cfb6bcda164ef3a66b8c3fc549b1f9bdd09ad. This breaks the backlight controls on my IVB asus zenbook with an eDP panel. I guess the right fix would be to read this bit and use either the pch or the cpu register to frob the backlight values. But that is stuff for -next. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: Fix eDP blank screen after S3 resume on HP desktopsTakashi Iwai2012-06-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes the problem on some HP desktop machines with eDP which give blank screens after S3 resume. It turned out that BLC_PWM_CPU_CTL must be written after BLC_PWM_CPU_CTL2. Otherwise it doesn't take effect on these SNB machines. Tested with 3.5-rc3 kernel. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49233 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * drm/i915: rip out the PM_IIR WARNDaniel Vetter2012-06-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After banging my head against this for the past few months, I still don't see how this could possible race under the premise that once an irq bit is masked in PM_IMR and reset in PM_IIR it won't show up again until we unmask it in PM_IMR. Still, we have reports of this being seen in the wild. Now Bspec has this little bit of lovely language in the PMIIR register: Public SNB Docs, Vol3Part2, 2.5.14 "PMIIR": "For each bit, the IIR can store a second pending interrupt if two or more of the same interrupt conditions occur before the first condition is cleared. Upon clearing the interrupt, the IIR bit will momentarily go low, then return high to indicate there is another interrupt pending." Now if we presume that PMIMR only prevent new interrupts from being queued, we could easily end up masking an interrupt and clearing it, but the 2nd pending interrupt setting the bit in PMIIR right away again. Which leads, the next time the irq handler runs, to hitting the WARN. Also, no bad side effects of this have ever been reported. And we've tracked down our issues with the gpu turbo getting stuck to bogus interrupt generation limits in th RPLIMIT register. So let's just rip out this WARN as bogus and call it a day. The only shallow thing here is that this 2-deep irq queue in the hw makes you wonder how racy the windows irq handler is ... Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=42907 Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/nouveau: add license header to prime.Dave Airlie2012-06-27
| | | | | | | | | | | | | | | | | | | | | Just forgot this when I posted it, and yes I'm the only person to have changed the file since. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/nouveau/fbcon: using nv_two_heads is not a good ideaBen Skeggs2012-06-26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | nv_two_heads() was never meant to be used outside of pre-nv50 code. The code checks for >= NV_10 for 2 CRTCs, then downgrades a few specific chipsets to 1 CRTC based on (pci_device & 0x0ff0). The breakage example seen is on GTX 560Ti, with a pciid of 0x1200, which gets detected as an NV20 (0x020x) with 1 CRTC by nv_two_heads(), causing memory corruption because there's actually 2 CRTCs.. This switches fbcon to use the CRTC count directly from the mode_config structure, which will also fix the same issue on Kepler boards which have 4 CRTCs. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | drm/udl: Make sure to get correct endian keys from vendor descriptorDave Airlie2012-06-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a port of commit b49f184b640dcfab7ede394cf2a1ff4fe3d154f5 Author: Ben Collins <bcollins@ubuntu.com> from udlfb to udl kms driver. The driver was not using le16_to_cpu when reading keys from the vendor descriptor, causing incorrect parsing. Mainly, sku_pixel_limit was not being parsed on big-endian systems. This would result in a blank screen on big-endian CPUs where the DL chips's max mode was smaller than the monitor's native mode. Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/sis: fixup sis_mm ioctl structsDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Userspace uses long in quite a few places more than the kernel. Which gives me neat proof that I'm the only guy on this side of the galaxy who ever tried to run glxgears on a 64bit machine with sis graphics on linux. Note that the longs in drm_sis_mem_t aren't aligned properly, so this won't even work with 32bit userspace on 64bit kernel as-is. Hence the patch can't break that, either. Nope, I'm not nuts enough to write the 32bit ioctl compat layer for this and test it with some wine app. Even though hunting the ebay dungeons for a sis card actually supported by the mesa drivers casts some doubts on this ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: unconditionally clean up dma buffers of closing clientsDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the last patch to ditch DMA_QUEUE support, we should be able to call the dma cleanup uncoditionally, even when the master has disappeared. Do so because it just makes more sense. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: kill dma queue supportDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | Absolutely unused. All the values are only ever initialized and then used at most in some debug printout functions. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: ditch strange DRIVER_DMA_QUEUE only error bail-outDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only one driver (i810) even sets that flag. Now the actual locking code uncoditionally promotes lock->context to an unsigned int. Closer inspection of the userspace reveals that the drm lock context is defined as an unsigned int (at least on linux). I suspect we just have a strange case of signedness confusion going on. Tested on my i815, doesn't seem to break anything. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: kill reclaim_buffers callbackDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All leftover users either haven't set DRIVER_HAVE_DMA, in which case this will never be called, or use the drm_core implementation. Call that directly in the only callsite. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/savage: clean up reclaim_buffersDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The reclaim_buffers function of the savage driver actually wants to run with the hw_lock held - at least there are printks in the call-chain to that effect. But the drm core only calls reclaim_buffers as used by savage _after_ forcefully dropping the hwlock (in case it's still hold by the closing fd). So do the same idlelock dance as for the other dma drivers and hope that papers over any issues. v2: Don't let the idlelock linger around. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Tested-by: Tormod Volden <debian.tormod@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: kill reclaim_buffers_lockedDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | i810 was the last user of this code, with that gone, kill it. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | Revert "Revert "drm/i810: cleanup reclaim_buffers""Daniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 6e877b576ddf7cde5db2e9a6dcb56fef0ea77e64, reinstating the original commit: commit 87499ffdcb1c70f66988cd8febc4ead0ba2f9118 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Oct 25 23:51:24 2011 +0200 drm/i810: cleanup reclaim_buffers My dear old i815 always hits the deadlocked on reclaim_buffers warning. Switch over to the idlelock duct-tape on hope that works better. I've fired up my i815 and now closing glxgears doesn't take 5 seconds anymore. \o/ The original problem with that was that I've moved it ahead in the series so that it could be included despite some patches not being ready quite yet. The little problem is that this patch required some of the previous rework to work correctly. Now that everything is in the right order again, this actually works on my i810 and does speed up closing gl apps as the original commit claimed. Without hanging the machine, as the revert says. Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: kill reclaim_buffers_idlelocked functionsDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | The only two users are now folded into the drivers preclose functions, so this is unused. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/sis: clean up reclaim_buffersDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Like for via. v2: Actually drop the idlelock again if taken. v3: Fixup. v4: Fixup the "has master" vs. "is master" confusion the refactor introduced. v5: Drop the idlelock in the early return path. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/via: clean up reclaim_buffersDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A few things - kill reclaim_buffers, it's never ever called because via does not set DRIVER_HAVE_DMA - inline the idlelock dance into the buffer reclaim logic and make it a simple preclose cleanup function - directly call the the dma_quiescent function and kill the needless if check. v2: Actually drop the idlelock when we take it. Reported by James Simmons. v3: Rebased onto latest drm-next. v4: Fixup the refactor. v5: More fixup the refactor - I've accidentally changed the check for any master to checking whether the closing fd is the master. v6: Don't forget to drop the idlelock in the early return path, too. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/udl: port over blanking code from udlfb.Dave Airlie2012-07-19
| | | | | | | | | | | | | | | | | | | | | This ports over the dpms code from udlfb, and should mean a better chance of turning on some udl devices. Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon/kms: auto detect pcie link speed from root portDave Airlie2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | This check the root ports supported link speeds and enables GEN2 mode if the 5.0 GT link speed is available. The first 3.0 cards are SI so they will probably need more investigation. Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/pci: add support for getting the supported link bw.Dave Airlie2012-07-19
| | | | | | | | | | | | | | | | | | This should work for PCIE3.0 as well. Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon: improve GPU lockup debugging info on r6xx/r7xx/r8xx/r9xxJerome Glisse2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Print various CP register that have valuable informations regarding GPU lockup. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/mgag200: fix null pointer dereferenceDevendra Naga2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | we are referencing the pointer after doing alloc_apertures, as alloc_apertures kzallocs, the kzalloc may fail and we get a NULL. so we need to check for NULL before we dereference this pointer Signed-off-by: Devendra Naga <devendra.aaru@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon: Try harder to avoid HW cursor ending on a multiple of 128 columns.Michel Dänzer2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This could previously fail if either of the enabled displays was using a horizontal resolution that is a multiple of 128, and only the leftmost column of the cursor was (supposed to be) visible at the right edge of that display. The solution is to move the cursor one pixel to the left in that case. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=33183 Cc: stable@vger.kernel.org Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: Make the .mode_fixup() operations mode argument a const pointerLaurent Pinchart2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | The passed mode must not be modified by the operation, make it const. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/fb helper: don't call drm_crtc_helper_set_configDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | Go through the interface vtable instead, because not everyone might be using the crtc helper code. Cc: dri-devel@lists.freedesktop.org Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/fb-helper: delay hotplug handling when partially boundDaniel Vetter2012-07-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Ok, this requires quite a dance to actually hit: 1) We plug in a 2nd screen, enable it in both X and (by vt-switching) in the fbcon. 2) We disable that screen again in with xrandr. 3) We vt-switch again, so that fbcon displays on the 2nd screen, but X on the first screen. This obviously needs a driver that doesn't switch off unused functions when regaining the VT. 3) When X controls the vt, we unplug that screen. Now drm_fb_helper_hotplug_event we noticed that that some crtcs are bound, but because we still have the fbcon on the 2nd screeen we also have bound set. Which means the fbcon wrongly assumes it's in control of everything an happily disables the output on the 2nd screen, but enables its fb on the first screen. Work around this issue by counting how many crtcs are bound and how many are bound to fbcon and assuming that when fbcon isn't bound to all of them, it better not touch the output configuration. Conceptually this is the same as only restoring the fbcon output configuration on the driver's ->lastclose, when we're sure that no one else is using kms. So this should be consistent with existing kms drivers. Chris has created a separate patch for the intel ddx, but I think we should fix this issue here regardless - the fbcon messing with the output config while it's not fully in control simply isn't a too polite behaviour. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50772 Tested-by: Maxim A. Nikulin <M.A.Nikulin@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/radeon: fix SS setup for DCPLLAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | Need to actually set the SS parameters rather than just 0. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: fix up pll selection on DCE5/6Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Selecting ATOM_PPLL_INVALID should be equivalent as the DCPLL or PPLL0 are already programmed for the DISPCLK, but the preferred method is to always specify the PLL selected. SetPixelClock will check the parameters and skip the programming if the PLL is already set up. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: start to document evergreen.cAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | Still a lot to do. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: start to document the functions r100.cAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | Still a lot more to do. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document VM functions in radeon_gart.c (v3)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Document the VM functions in radeon_gart.c v2: adjust per Christian's suggestions v3: adjust to Christians's latest changes Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document non-VM functions in radeon_gart.c (v2)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Document the non-VM functions in radeon_gart.c v2: adjust per Christian's suggestions Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_ring.c (v4)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_ring.c v2: adjust per Christian's suggestions v3: adjust per Christian's latest patches v4: adjust per my latest changes Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_fence.c (v2)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_fence.c v2: address Christian's comments: - split common concept description into it's own comment - fix description of intr parameter - Improve description of -EDEADLK error Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_asic.cAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_asic.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_irq_kms.cAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_irq_kms.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_kms.cAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_kms.c Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: document radeon_device.c (v2)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Adds documentation to most of the functions in radeon_device.c v2: split out general descriptions as per Christian's comments. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: add rptr save support for r1xx-r5xxAlex Deucher2012-07-18
| | | | | | | | | | | | | | | Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: update rptr saving logic for memory buffersAlex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for using memory buffers rather than scratch registers. Some rings may not be able to write to scratch registers. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: remove radeon_ring_index()Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | Just store the index in the ring structure. Idea taken from one of Jerome's wip rptr patches. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: update ib_execute for SI (v2)Alex Deucher2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When submitting a CONST_IB, emit a SWITCH_BUFFER packet before the CONST_IB. This isn't strictly necessary (the driver will work fine without it), but is good practice and allows for more flexible DE/CE sychronization options in the future. Current userspace drivers do not take advantage of the CE yet. v2: - clean up code flow a bit - no need to flush caches for CONST IB Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | | drm/radeon: fix const IB handling v2Christian König2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Const IBs are executed on the CE not the CP, so we can't fence them in the normal way. So submit them directly before the IB instead, just as the documentation says. v2: keep the extra documentation Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: let sa manager block for fences to wait for v2Christian König2012-07-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we can encounter out of memory situations under extreme load. v2: add documentation for the new function Signed-off-by: Christian König <deathsimple@vodafone.de> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
generated by cgit v1.2.2 (git 2.25.0) at 2025-02-04 08:47:35 -0500