summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/radeon/r300d.h
AgeCommit message (Collapse)Author
2013-01-31drm/radeon: consolidate redundant macros and constantsIlija Hadzic
After refactoring the _cs logic, we ended up with many macros and constants that #define the same thing. Clean'em up. Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com> Reviewed-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2011-01-06drm/radeon/kms: manage r300 CMASK RAM access and allow CMASK clearMarek Olšák
The CMASK RAM is for colorbuffer compression (used in conjunction with MSAA). Only one user (filp) can access it. The CMASK RAM access is managed in the same way as Hyper-Z, but there is a separate ioctl, because an app that uses MSAA does not necessarily have to use zbuffering. Signed-off-by: Marek Olšák <maraeo@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-08-02drm/radeon: add basic zmask/hiz support (v4)Dave Airlie
This interface allows userspace to request hyperz support, it probably needs more locking, and really reporting that you can have hyperz is racy since someone else might get it before you do. v2: modify so we pass 0 valued packets to let DDX/r300c keep working. also fixed incorrect 0x4f1c reference. v3: fixup zb_bw_cntl so older drivers keep working v4: add locking, fixup SC_HYPERZ_EN - patch stream to disable hiz Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-06drm/radeon/kms: simplify & improve GPU reset V2Jerome Glisse
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>
2009-10-02drm/radeon/kms: Convert R300 to new init pathJerome Glisse
Also cleanup register specific to R300. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-10-02drm/radeon/kms: Convert RS400/RS480 to new init path & fix legacy VGA (V3)Jerome Glisse
Also cleanup register specific to RS400/RS480. This patch also fix legacy VGA register used to disable VGA access we were programming wrong register. Now we should properly disable VGA on r100 up to rs400 asics. Note that RS400/RS480 resume is broken, it hangs the computer while reprogramming dynamic clock, doesn't work either without that patch. We need to spend more time investigating this issue. Version 2 of the patch remove dead code that was left commented out in the previous version. Version 3 correct the placement on IGP of the VRAM inside GPU address space to match the stollen RAM placement of IGP. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-14drm/radeon/kms: convert r4xx to new init pathJerome Glisse
This convert r4xx to new init path it also fix few bugs. Signed-off-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08drm/radeon/kms: add r600 KMS supportJerome Glisse
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>