- 09 Apr, 2010 9 commits
-
-
Dave Airlie authored
Pointed out by Dave Witbrodt. Signed-off-by:Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
Hot plug detect (hpd) for digital monitors Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
The command processor (CP) fetches command buffers and feeds the GPU. This patch requires the evergreen family me and pfp ucode files. Signed-off-by:
-
Alex Deucher authored
This initializes the gfx engine so accel can eventually be used. Signed-off-by:
-
Alex Deucher authored
Works pretty similarly to r6xx/r7xx. Signed-off-by:
-
Alex Deucher authored
Gart setup is more or less like r7xx. Copy rv770d.h to evergreend.h and fix up changes. Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
- 06 Apr, 2010 3 commits
-
-
Jerome Glisse authored
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:
-
Jerome Glisse authored
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 authored
This patch cleanup the fence code, it drops the timeout field of fence as the time to complete each IB is unpredictable and shouldn't be bound. The fence cleanup lead to GPU lockup detection improvement, this patch introduce a callback, allowing to do asic specific test for lockup detection. In this patch the CP is use as a first indicator of GPU lockup. If CP doesn't make progress during 1second we assume we are facing a GPU lockup. To avoid overhead of testing GPU lockup frequently due to fence taking time to be signaled we query the lockup callback every 500msec. There is plenty code comment explaining the design & choise inside the code. This have been tested mostly on R3XX/R5XX hw, in normal running destkop (compiz firefox, quake3 running) the lockup callback wasn't call once (1 hour session). Also tested with forcing GPU lockup and lockup was reported after the 1s CP activity timeout. V2 switch to 500ms timeout so GPU lockup get call at least 2 times in less than 2sec. V3 store last jiffies in fence struct so on ERESTART, EBUSY we keep track of how long we already wait for a given fence V4 make sure we got up to date cp read pointer so we don't have false positive Signed-off-by:
-
- 05 Apr, 2010 2 commits
-
-
Alex Deucher authored
The GPIO_I2C_INFO table does not always have ATOM_MAX_SUPPORTED_DEVICE entries. Limit the number of indices to the size of the table. Should fix Novell bug 589022. v2: fix typo Signed-off-by:
-
Michel Dänzer authored
Gleaned from the Mesa code. Fixes https://bugs.freedesktop.org/show_bug.cgi?id=27355 . Signed-off-by:
Michel Dänzer <daenzer@vmware.com> Cc: stable@kernel.org Signed-off-by:
-
- 01 Apr, 2010 4 commits
-
-
Dave Airlie authored
Some GPUs have an APM/ACPI PM mode selection switch and some BIOSes set this to APM. We really want this in ACPI mode for Linux. Signed-off-by: -
Dave Airlie authored
These GPUs should be setting these registers up also. Signed-off-by: -
Dave Airlie authored
If we resume in a bad way, we'll get 0xffffffff in wptr, and then oops with no console. This just adds a sanity check so that we can avoid the oops and hopefully get more details out of people's systems. Signed-off-by: -
Alex Deucher authored
Need to enable the VID stream after link training Signed-off-by:
-
- 31 Mar, 2010 22 commits
-
-
Alex Deucher authored
Turn off hw i2c by default except for mm i2c which is hw only until we sort out the remaining prescale issues on older chips. hw i2c can be enabled with hw_i2c=1. Signed-off-by:
-
Alex Deucher authored
This allows us to remove the internal bit algo bus used by the radeon i2c algo. We now register a radeon algo adapter if the gpio line is hw capable and the hw inplementation is available, otherwise we register a bit algo adapter. Signed-off-by:
-
Dave Airlie authored
-
Alex Deucher authored
Doesn't seem to work reliably and the pci quirks don't always work. Signed-off-by:
-
Alex Deucher authored
- 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 authored
Seems to have gotten lost in the evergreen merge. Signed-off-by:
-
Alex Deucher authored
Some systems have LCD* rather than DFP* device tags in the bios for eDP connectors; notably the new apple iMac. This fixes things up so eDP connectors with either tag will work. v2: fix typo Signed-off-by:
-
Alex Deucher authored
Looks like a copy/paste typo from when evergreen support was added. Signed-off-by:
-
Alex Deucher authored
- 8 lane links are not valid for DP - remove unused num var Signed-off-by:
-
Michel Dänzer authored
This prevented radeon.test=1 from testing transfers from/to GTT beyond the visible VRAM size. Signed-off-by:
-
Randy Dunlap authored
Fix build error when CONFIG_MAGIC_SYSRQ is not enabled: drivers/gpu/drm/drm_fb_helper.c:915: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function) drivers/gpu/drm/drm_fb_helper.c:929: error: 'sysrq_drm_fb_helper_restore_op' undeclared (first use in this function) Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
- remove a few more drm only regs - remove sampler, alu, bool, loop constant regs. They are set via separate packet3's already Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
- Drop some more safe regs taht userspace shouldn't hit - Constant base regs need relocs. This allows us to use constant buffers rather than the constant register file. Also we don't want userspace to be able to set arbitrary mc base values for the const caches. - Track SQ_CONFIG so we know whether userspace is using the cfile or constant buffers. Signed-off-by:
-
Alex Deucher authored
Signed-off-by:
-
Alex Deucher authored
Only the drm should be touching them. Signed-off-by:
-
Chris Wilson authored
Replace a BUG_ON with an error code in the event that the inode mapping changes between calls to drm_open. This may happen for instance if udev is loaded subsequent to the original opening of the device: [ 644.291870] kernel BUG at drivers/gpu/drm/drm_fops.c:146! [ 644.291876] invalid opcode: 0000 [#1] SMP [ 644.291882] last sysfs file: /sys/kernel/uevent_seqnum [ 644.291888] [ 644.291895] Pid: 7276, comm: lt-cairo-test-s Not tainted 2.6.34-rc1 #2 N150/N210/N220 /N150/N210/N220 [ 644.291903] EIP: 0060:[<c11c70e3>] EFLAGS: 00210283 CPU: 0 [ 644.291912] EIP is at drm_open+0x4b1/0x4e2 [ 644.291918] EAX: f72d8d18 EBX: f790a400 ECX: f73176b8 EDX: 00000000 [ 644.291923] ESI: f790a414 EDI: f790a414 EBP: f647ae20 ESP: f647adfc [ 644.291929] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 644.291937] Process lt-cairo-test-s (pid: 7276, ti=f647a000 task=f73f5c80 task.ti=f647a000) [ 644.291941] Stack: [ 644.291945] 00000000 f7bb7400 00000080 f6451100 f73176b8 f6479214 f6451100 f73176b8 [ 644.291957] <0> c1297ce0 f647ae34 c11c6c04 f73176b8 f7949800 00000000 f647ae54 c1080ac5 [ 644.291969] <0> f7949800 f6451100 00000000 f6451100 f73176b8 f6452780 f647ae70 c107d1e6 [ 644.291982] Call Trace: [ 644.291991] [<c11c6c04>] ? drm_stub_open+0x8a/0xb8 [ 644.292000] [<c1080ac5>] ? chrdev_open+0xef/0x106 [ 644.292008] [<c107d1e6>] ? __dentry_open+0xd4/0x1a6 [ 644.292015] [<c107d35b>] ? nameidata_to_filp+0x31/0x45 [ 644.292022] [<c10809d6>] ? chrdev_open+0x0/0x106 [ 644.292030] [<c10864e2>] ? do_last+0x346/0x423 [ 644.292037] [<c108789f>] ? do_filp_open+0x190/0x415 [ 644.292046] [<c1071eb5>] ? handle_mm_fault+0x214/0x710 [ 644.292053] [<c107d008>] ? do_sys_open+0x4d/0xe9 [ 644.292061] [<c1016462>] ? do_page_fault+0x211/0x23f [ 644.292068] [<c107d0f0>] ? sys_open+0x23/0x2b [ 644.292075] [<c1002650>] ? sysenter_do_call+0x12/0x26 [ 644.292079] Code: 89 f0 89 55 dc e8 8d 96 0a 00 8b 45 e0 8b 55 dc 83 78 04 01 75 28 8b 83 18 02 00 00 85 c0 74 0f 8b 4d ec 3b 81 ac 00 00 00 74 13 <0f> 0b eb fe 8b 4d ec 8b 81 ac 00 00 00 89 83 18 02 00 00 89 f0 [ 644.292143] EIP: [<c11c70e3>] drm_open+0x4b1/0x4e2 SS:ESP 0068:f647adfc [ 644.292175] ---[ end trace 2ddd476af89a60fa ]--- Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@kernel.org Signed-off-by:
-
Pauli Nieminen authored
When there is allocation failure in radeon_cs_parser_relocs parser->nrelocs is not cleaned. This causes NULL pointer defeference in radeon_cs_parser_fini when clean up code is trying to loop over the relocation array and free the objects. Fix adds a check for a possible NULL pointer in clean up code. Signed-off-by:
Pauli Nieminen <suokkos@gmail.com> Cc: stable@kernel.org Signed-off-by:
-
Jerome Glisse authored
radeon_gart_fini might call GART unbind callback function which might try to access GART table but if gart_disable is call first the GART table will be unmapped so any access to it will oops. Signed-off-by:
-
Dave Airlie authored
We can get this if the user moves the mouse when we are waiting to move some stuff around in the validate. Don't fail. Cc: stable@kernel.org Signed-off-by:
-
