aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/radeon/rv515.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge remote-tracking branch 'kernelorg/linux-3.0.y' into 3_0_64Andrew Dodd2013-02-271-13/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Conflicts: arch/arm/Kconfig arch/arm/include/asm/hwcap.h arch/arm/kernel/smp.c arch/arm/plat-samsung/adc.c drivers/gpu/drm/i915/i915_reg.h drivers/gpu/drm/i915/intel_drv.h drivers/mmc/core/sd.c drivers/net/tun.c drivers/net/usb/usbnet.c drivers/regulator/max8997.c drivers/usb/core/hub.c drivers/usb/host/xhci.h drivers/usb/serial/qcserial.c fs/jbd2/transaction.c include/linux/migrate.h kernel/sys.c kernel/time/timekeeping.c lib/genalloc.c mm/memory-failure.c mm/memory_hotplug.c mm/mempolicy.c mm/page_alloc.c mm/vmalloc.c mm/vmscan.c mm/vmstat.c scripts/Kbuild.include Change-Id: I91e2d85c07320c7ccfc04cf98a448e89bed6ade6
| * drm/radeon: do not reenable crtc after moving vram start addressJerome Glisse2012-08-261-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5 upstream. It seems we can not update the crtc scanout address. After disabling crtc, update to base address do not take effect after crtc being reenable leading to at least frame being scanout from the old crtc base address. Disabling crtc display request lead to same behavior. So after changing the vram address if we don't keep crtc disabled we will have the GPU trying to read some random system memory address with some iommu this will broke the crtc engine and will lead to broken display and iommu error message. So to avoid this, disable crtc. For flicker less boot we will need to avoid moving the vram start address. This patch should also fix : https://bugs.freedesktop.org/show_bug.cgi?id=42373 Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | samsung update 1codeworkx2012-06-021-44/+71
|/
* drm: Fix printk typo 'failled'Paul Bolle2011-02-171-2/+2
| | | | | Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* drm/radeon/kms: clean up some magic numbersAlex Deucher2011-01-271-5/+5
| | | | | Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@gmail.com>
* drm/radeon/kms: enable writeback (v2)Alex Deucher2010-10-061-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | When writeback is enabled, the GPU shadows writes to certain registers into a buffer in memory. The driver can then read the values from the shadow rather than reading back from the register across the bus. Writeback can be disabled by setting the no_wb module param to 1. On r6xx/r7xx/evergreen, the following registers are shadowed: - CP scratch registers - CP read pointer - IH write pointer On r1xx-rr5xx, the following registers are shadowed: - CP scratch registers - CP read pointer v2: - Combine wb patches for r6xx-evergreen and r1xx-r5xx - Writeback is disabled on AGP boards since it tends to be unreliable on AGP using the gart. - Check radeon_wb_init return values properly. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: handle the case of no active displays properly in the ↵Alex Deucher2010-08-041-14/+9
| | | | | | | | | | | | | | | | | | | | | | | | bandwidth code Logic was: if (mode0 && mode1) else if (mode0) else Should be: if (mode0 && mode1) else if (mode0) else if (mode1) Otherwise we may end up calculating the priority regs with unitialized values. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=16492 Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Cc: stable@kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'v2.6.35-rc6' into drm-radeon-nextDave Airlie2010-08-021-0/+1
|\ | | | | | | Need this to avoid conflicts with future radeon fixes
| * drm/radeon/kms: fix gtt MC base alignment on rs4xx/rs690/rs740 asicsAlex Deucher2010-07-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The asics in question have the following requirements with regard to their gart setups: 1. The GART aperture size has to be in the form of 2^X bytes, where X is from 25 to 31 2. The GART aperture MC base has to be aligned to a boundary equal to the size of the aperture. 3. The GART page table has to be aligned to the boundary equal to the size of the table. 4. The GART page table size is: table_entry_size * (aperture_size / page_size) 5. The GART page table has to be allocated in non-paged, non-cached, contiguous system memory. This patch takes care 2. The rest should already be handled properly. This fixes a regression noticed by: Torsten Kaiser <just.for.lkml@googlemail.com> Tested-by: Torsten Kaiser <just.for.lkml@googlemail.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/radeon/kms: check/restore sanity before doing anything else with GPU.Dave Airlie2010-08-021-0/+2
|/ | | | | | | | | | On systems using kexec, the new kernel is booted straight from the old kernel, without any warning to the graphics driver. So the GPU is basically left as-is in a running state, however the CPU side is completly reset. Without stating the saneness of anyone using kexec on live systems, we should at least try not to crash the GPU. This patch resets 3 registers to 0 that could cause bad things to happen to the running system. This allows kexec to work on a Power6/RN50 system. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms/pm: rework power managementAlex Deucher2010-05-181-3/+0
| | | | | | | | | | | | | | | | | | | | | | | - Separate dynpm and profile based power management methods. You can select the pm method by echoing the selected method ("dynpm" or "profile") to power_method in sysfs. - Expose basic 4 profile in profile method "default" - default clocks "auto" - select between low and high based on ac/dc state "low" - DC, low power mode "high" - AC, performance mode The current base profile is "default", but it should switched to "auto" once we've tested on more systems. Switching the state is a matter of echoing the requested profile to power_profile in sysfs. The lowest power states are selected automatically when dpms turns the monitors off in all states but default. - Remove dynamic fence-based reclocking for the moment. We can revisit this later once we have basic pm in. - Move pm init/fini to modesetting path. pm is tightly coupled with display state. Make sure display side is initialized before pm. - Add pm suspend/resume functions to make sure pm state is properly reinitialized on resume. - Remove dynpm module option. It's now selectable via sysfs. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: move radeon_fixed.h to shared drm_fixed.h headerBen Skeggs2010-05-181-94/+94
| | | | | | | Will be used by nouveau driver also in the near future. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge branch 'drm-radeon-lockup' into drm-core-nextDave Airlie2010-04-201-93/+3
|\ | | | | | | | | | | | | | | | | | | * drm-radeon-lockup: drm/radeon/kms: simplify & improve GPU reset V2 drm/radeon/kms: rename gpu_reset to asic_reset drm/radeon/kms: fence cleanup + more reliable GPU lockup detection V4 Conflicts: drivers/gpu/drm/radeon/r300.c
| * drm/radeon/kms: simplify & improve GPU reset V2Jerome Glisse2010-04-061-90/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This simplify and improve GPU reset for R1XX-R6XX hw, it's not 100% reliable here are result: - R1XX/R2XX works bunch of time in a row, sometimes it seems it can work indifinitly - R3XX/R3XX the most unreliable one, sometimes you will be able to reset few times, sometimes not even once - R5XX more reliable than previous hw, seems to work most of the times but once in a while it fails for no obvious reasons (same status than previous reset just no same happy ending) - R6XX/R7XX are lot more reliable with this patch, still it seems that it can fail after a bunch (reset every 2sec for 3hour bring down the GPU & computer) This have been tested on various hw, for some odd reasons i wasn't able to lockup RS480/RS690 (while they use to love locking up). Note that on R1XX-R5XX the cursor will disapear after lockup haven't checked why, switch to console and back to X will restore cursor. Next step is to record the bogus command that leaded to the lockup. V2 Fix r6xx resume path to avoid reinitializing blit module, use the gpu_lockup boolean to avoid entering inifinite waiting loop on fence while reiniting the GPU Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon/kms: rename gpu_reset to asic_resetJerome Glisse2010-04-061-4/+4
| | | | | | | | | | | | | | | | Patch rename gpu_reset to asic_reset in prevision of having gpu_reset doing more stuff than just basic asic reset. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge branch 'master' into export-slabhTejun Heo2010-04-051-17/+28
|\ \ | |/
| * drm/radeon/kms: display watermark updates (v2)Alex Deucher2010-03-311-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add module option to force the display priority 0 = auto, 1 = normal, 2 = high - Default to high on r3xx/r4xx/rv515 chips Fixes flickering problems during heavy acceleration due to underflow to the display controllers - Fill in minimal support for RS600 v2 - update display priority when bandwidth is updated so the user can change the parameter at runtime and it will take affect on the next modeset. Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon/kms: display watermark fixesAlex Deucher2010-03-311-7/+1
| | | | | | | | | | | | | | | | | | | | - rs780/880 were using the wrong bandwidth functions - convert r1xx-r4xx to use the same pm sclk/mclk structs as r5xx+ - move bandwidth setup to a common function Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/radeon/kms: expose thermal/fan i2c busesAlex Deucher2010-03-311-0/+1
| | | | | | | | | | | | | | | | Look up i2c bus in the power table and expose it. You'll need to load a hwmon driver for any chips on the bus, this patch just exposes the bus. Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
| * drm/radeon: include radeon_asic.h in the asic specific filesDaniel Vetter2010-03-151-0/+1
| | | | | | | | | | | | | | | | In essence this creates a home for all asic specific declarations in radeon_asic.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | include cleanup: Update gfp.h and slab.h includes to prepare for breaking ↵Tejun Heo2010-03-301-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
* drm/radeon/kms: simplify memory controller setup V2Jerome Glisse2010-02-181-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Get rid of _location and use _start/_end also simplify the computation of vram_start|end & gtt_start|end. For R1XX-R2XX we place VRAM at the same address of PCI aperture, those GPU shouldn't have much memory and seems to behave better when setup that way. For R3XX and newer we place VRAM at 0. For R6XX-R7XX AGP we place VRAM before or after AGP aperture this might limit to limit the VRAM size but it's very unlikely. For IGP we don't change the VRAM placement. Tested on (compiz,quake3,suspend/resume): PCI/PCIE:RV280,R420,RV515,RV570,RV610,RV710 AGP:RV100,RV280,R420,RV350,RV620(RPB*),RV730 IGP:RS480(RPB*),RS690,RS780(RPB*),RS880 RPB: resume previously broken V2 correct commit message to reflect more accurately the bug and move VRAM placement to 0 for most of the GPU to avoid limiting VRAM. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: don't call suspend path before cleaning up GPUJerome Glisse2010-02-051-3/+1
| | | | | | | | | | | | | | In suspend path we unmap the GART table while in cleaning up path we will unbind buffer and thus try to write to unmapped GART leading to oops. In order to avoid this we don't call the suspend path in cleanup path. Cleanup path is clever enough to desactive GPU like the suspend path is doing, thus this was redondant. Tested on: RV370, R420, RV515, RV570, RV610, RV770 (all PCIE) Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: Schedule host path read cache flush through the ring V2Jerome Glisse2010-01-081-0/+1
| | | | | | | | | | | | | | | | | R300 family will hard lockup if host path read cache flush is done through MMIO to HOST_PATH_CNTL. But scheduling same flush through ring seems harmless. This patch remove the hdp_flush callback and add a flush after each fence emission which means a flush after each IB schedule. Thus we should have same behavior without the hard lockup. Tested on R100,R200,R300,R400,R500,R600,R700 family. V2: Adjust fence counts in r600_blit_prepare_copy() Signed-off-by: Jerome Glisse <jglisse@redhat.com> Reviewed-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: restore surface registers on resume.Dave Airlie2009-12-101-0/+2
| | | | | | | | | | | On resume on my rv530 laptop surface cntl was left disabled, so wierd stuff would happen with rendering to a tiled front buffer. This checks if the surface regs are assigned to bos and reprograms the surface registers on resume using the same path that clears them all on init. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms/avivo: fix some bugs in the display bandwidth setupAlex Deucher2009-12-101-3/+6
| | | | | Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm/radeon/kms: Rework radeon object handlingJerome Glisse2009-12-021-3/+3
| | | | | | | | | | | | | | | The locking & protection of radeon object was somewhat messy. This patch completely rework it to now use ttm reserve as a protection for the radeon object structure member. It also shrink down the various radeon object structure by removing field which were redondant with the ttm information. Last it converts few simple functions to inline which should with performances. airlied: rebase on top of r600 and other changes. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: add irq mitigation code for sw interrupt.Dave Airlie2009-12-021-1/+0
| | | | | | | | | We really don't need to process every irq that comes in, we only really want to do SW irq processing when we are actually waiting for a fence to pass. I'm not 100% sure this is race free esp on non-MSI systems so it needs some testing. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: ignore unposted GPUs with no BIOS.Dave Airlie2009-12-021-4/+2
| | | | | | | If we find a GPU but we can't find its BIOS and it isn't posted, then ignore it. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: fix handling of d1/d2 vgaDave Airlie2009-11-241-5/+4
| | | | | | | | An rv515 laptop I got wouldn't startup with a montior plugged in, found the proper bug hopefully with us not turning off D2VGA here when we should. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: add debugfs for power management for AtomBIOS devicesRafał Miłecki2009-11-061-0/+2
| | | | | Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: disable D1VGA and D2VGA if enabledDave Airlie2009-11-041-0/+2
| | | | | | | | Once kms is enabled we don't need these, and it causes a problem with the Lenovo W500 ACPI brightness implementation, it hangs in a loop inside an SMI. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: Fix irq handling on AVIVO hwJerome Glisse2009-10-021-2/+2
| | | | | | | | | Avivo hw have vblank interrupt in different place, fixes irq handling (especialy irq disabling while suspending or shuting down the module). Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: Remove old init path as no hw use it anymoreJerome Glisse2009-10-021-1/+0
| | | | | | | | | This remove old init path and allow code cleanup, now all hw use the new init path, see top of radeon.h for description of this. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: Convert R520 to new init path and associated cleanupJerome Glisse2009-09-291-1/+1
| | | | | | | | | Convert the r520 asic support to new init path, change are smaller than previous one as most of the architecture is now in place and more code sharing can happen btw various asics. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm/radeon/kms: Convert RV515 to new init path and associated cleanupJerome Glisse2009-09-291-104/+260
| | | | | | | | | | Convert the rv515 asic support to new init path also add an explanation in radeon.h about the new init path. There is also few cleanups associated with this change (others asic calling rv515 helper functions). Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@linux.ie>
* drm/radeon/kms: clear confusion in GART init/deinit pathJerome Glisse2009-09-151-5/+0
| | | | | | | | | | | | | | | | GART static one time initialization was mixed up with GART enabling/disabling which could happen several time for instance during suspend/resume cycles. This patch splits all GART handling into 4 differents function. gart_init is for one time initialization, gart_deinit is called upon module unload to free resources allocated by gart_init, gart_enable enable the GART and is intented to be call after first initialization and at each resume cycle or reset cycle. Finaly gart_disable stop the GART and is intended to be call at suspend time or when unloading the module. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: cleanup - remove radeon_share.hJerome Glisse2009-09-141-1/+0
| | | | | | | | | | radeon_share.h was begining to give problem with include order in respect of radeon.h. It's easier and also i think cleaner to move what was in radeon_share.h into radeon.h. At the same time use the extern keyword for function shared accross the module. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: add r600 KMS supportJerome Glisse2009-09-081-1/+1
| | | | | | | | | | | | | | | | | | | | This adds the r600 KMS + CS support to the Linux kernel. The r600 TTM support is quite basic and still needs more work esp around using interrupts, but the polled fencing should work okay for now. Also currently TTM is using memcpy to do VRAM moves, the code is here to use a 3D blit to do this, but isn't fully debugged yet. Authors: Alex Deucher <alexdeucher@gmail.com> Dave Airlie <airlied@redhat.com> Jerome Glisse <jglisse@redhat.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: add initial radeon tv-out support.Dave Airlie2009-09-081-225/+227
| | | | | | | | This ports the tv-out code from the DDX to KMS. adds a radeon.tv module option, radeon.tv=0 to disable tv Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: generate the safe register tables.Dave Airlie2009-08-211-61/+3
| | | | | | | | | | Previously we just made these offline and included them, but no reason we can't generate them at build time. TODO: add rs690 + r100/r200 when done. should we do rs480/rs690 no tcl version? Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: cut down indirects in register accesses.Dave Airlie2009-08-161-19/+0
| | | | | | | | We really don't want to be doing all these indirects, updating the GPU gart table is something we do often so the less overhead the better. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: fix rv515 VRAM initialisation.Dave Airlie2009-08-041-0/+1
| | | | | | This got missed in the VRAM init re-workings. Signed-of-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: vram sizing on certain r100 chips needs workaround.Dave Airlie2009-07-291-5/+2
| | | | | | | | | | | If an rn50/r100/m6/m7 GPU has < 64MB RAM, i.e. 8/16/32, the aperture used to calculate the MC_FB_LOCATION needs to be worked out from the CONFIG_APER_SIZE register, and not the actual vram size. TTM VRAM size was also being initialised wrong, use actual vram size to initialise it. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: fix bandwidth computation on avivo hardwareJerome Glisse2009-07-291-122/+652
| | | | | | | | | Fix bandwidth computation and crtc priority in memory controller so that crtc memory request are fullfill in time to avoid display artifact. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon/kms: fix VRAM sizing like DDX does it.Dave Airlie2009-07-151-4/+2
| | | | | | | | | | Doing this like the DDX seems like the most sure fire way to avoid having to reinvent it slowly and painfully. At the moment we keep getting things wrong with aper vs vram, so we know the DDX does it right. booted on PCI r100, PCIE rv370, IGP rs400. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: fix support for vline relocations.Dave Airlie2009-07-151-5/+18
| | | | | | | | | | | | Userspace sends us a special relocation type to sync video/exa to vlines to avoid tearing, this deals with the relocation in the kernel, it picks the correct crtc and avoids issues where crtcs are disabled. This version also parses the wait until to make sure it isn't trying to do anything evil. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: command stream checker for r3xx-r5xx hardwareJerome Glisse2009-06-191-0/+58
| | | | | | | | | | | | | | | | | | | | | | For security purpose we want to make sure the userspace process doesn't access memory beyond buffer it owns. To achieve this we need to check states the userspace program. For color buffer and zbuffer we check that the clipping register will discard access beyond buffers set as color or zbuffer. For vertex buffer we check that no vertex fetch will happen beyond buffer end. For texture we check various texture states (number of mipmap level, texture size, texture depth, ...) to compute the amount of memory the texture fetcher might access. The command stream checking impact the performances so far quick benchmark shows an average of 3% decrease in fps of various applications. It can be optimized a bit more by caching result of checking and thus avoid a full recheck if no states changed since last check. Note that this patch is still incomplete on checking side as it doesn't check 2d rendering states. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/radeon: introduce kernel modesetting for radeon hardwareJerome Glisse2009-06-151-0/+504
Add kernel modesetting support to radeon driver, use the ttm memory manager to manage memory and DRM/GEM to provide userspace API. In order to avoid backward compatibility issue and to allow clean design and code the radeon kernel modesetting use different code path than old radeon/drm driver. When kernel modesetting is enabled the IOCTL of radeon/drm driver are considered as invalid and an error message is printed in the log and they return failure. KMS enabled userspace will use new API to talk with the radeon/drm driver. The new API provide functions to create/destroy/share/mmap buffer object which are then managed by the kernel memory manager (here TTM). In order to submit command to the GPU the userspace provide a buffer holding the command stream, along this buffer userspace have to provide a list of buffer object used by the command stream. The kernel radeon driver will then place buffer in GPU accessible memory and will update command stream to reflect the position of the different buffers. The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory not owned by the process supplying the command stream. This part of the code is still incomplete and this why we propose that patch as a staging driver addition, future security might forbid current experimental userspace to run. This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX (radeon up to X1950). Works is underway to provide support for R6XX, R7XX and newer hardware (radeon from HD2XXX to HD4XXX). Authors: Jerome Glisse <jglisse@redhat.com> Dave Airlie <airlied@redhat.com> Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexdeucher@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
generated by cgit v1.1 at 2024-05-17 14:35:17 +0000