- 18 May, 2010 19 commits
-
-
Alex Deucher authored
set proper wait condition as noted by Rafał Miłecki. Signed-off-by:
Alex Deucher <alexdeucher@gmail.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
Alex Deucher authored
Useful for certain power management operations. You need to wait for the GUI engine (2D, 3D, CP, etc.) to be idle before changing clocks or adjusting engine parameters. (v2) Fix gui idle enable on pre-r6xx asics (v3) The gui idle interrrupt status bit is permanently asserted on pre-r6xx chips, but the interrrupt is still generated. workaround it in the driver. (v4) Add support for evergreen Signed-off-by:
-
Alex Deucher authored
Check to see if the GUI engine and related blocks (2D, 3D, CP, etc) are idle or not. There are a number of cases when we need to know if the drawing engine is busy. Signed-off-by:
-
Dave Airlie authored
Simple cloning rules compared to server: (a) single crtc (b) > 1 connector active (c) check command line mode (d) try and find 1024x768 DMT mode if no command line. (e) fail to clone Signed-off-by: -
Dave Airlie authored
After thinking it over a lot it made more sense for the core to deal with the output polling especially so it can notify X. v2: drop plans for fake connector - per Michel's comments - fix X patch sent to xorg-devel, add intel polled/hpd setting, add initial nouveau polled/hpd settings. v3: add config lock take inside polling, add intel/nouveau poll init/fini calls v4: config lock was a bit agressive, only needed around connector list reading. otherwise it could re-enter. glisse: discard drm_helper_hpd_irq_event v3: Reviewed-by: Michel Dänzer <michel@daenzer.net> Signed-off-by: -
Dan Carpenter authored
m == num_est3_modes is one past the end of the est3_modes[]. Signed-off-by:
Dan Carpenter <error27@gmail.com> Reviewed-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
Marcin Slusarz authored
let vga16fb claim 0xA0000+0x10000 region as its aperture; drm drivers don't use it, so we have to detect it and kick vga16fb manually - but only if drm is driving the primary card Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Cc: James Simmons <jsimmons@infradead.org> Cc: Dave Airlie <airlied@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by:
-
Marcin Slusarz authored
Currently vesafb/efifb/... is kicked when hardware driver is registering framebuffer. To do it hardware must be fully functional, so there's a short window between start of initialisation and framebuffer registration when two drivers touch the hardware. Unfortunately sometimes it breaks nouveau initialisation. Fix it by kicking firmware driver(s) before we start touching the hardware. Reported-by:
Didier Spaier <didier.spaier@epsm.fr> Tested-by:
-
Marcin Slusarz authored
It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by:
-
Kirill Smelkov authored
Recently I've studied my system dmesg and seen this: <lots of stuff before> 1 [ 0.478416] ACPI: Battery Slot [C1B4] (battery present) 2 [ 0.478648] ACPI: Battery Slot [C1B3] (battery absent) 3 [ 0.906678] [drm] initialized overlay support 4 [ 1.762304] Console: switching to colour frame buffer device 128x48 5 [ 1.765211] fb0: inteldrmfb frame buffer device 6 [ 1.765242] registered panic notifier 7 [ 1.765272] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0 8 [ 1.765372] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled <lots of stuff after> and it was not evident who registered that panic notifier on line 6. I'd bought it as some low-level stuff needed by kernel itself, but the time was inappropriate -- too late for such things. So I had to study sources to see it was drm who was registering switch-to-fb on panic. Let's avoid possible confusion and mark this message as going from drm subsystem. (I'm a bit unsure whether to use '[drm]:' or 'drm:' -- the rest of the kernel just uses 'topic:', and even in drm_fb_helper.c we use 'fb%d:' without [] brackets. Either way is ok with me.) Signed-off-by:
Kirill Smelkov <kirr@landau.phys.spbu.ru> Signed-off-by:
-
Jerome Glisse authored
Userspace need to know the hw crtc id (0, 1, 2, ...) from the drm crtc id. Bump the minor version so userspace can enable conditionaly features depend on this. V2 use num_crtc and avoid DRM_ERROR Signed-off-by:
Jerome Glisse <jglisse@redhat.com> Signed-off-by:
-
Adam Jackson authored
Having hsync both start and end on pixel 1072 ain't gonna work very well. Matches the X server's list. Signed-off-by:
Michael Tokarev <mjt@tls.msk.ru> Cc: stable@kernel.org Signed-off-by:
-
Julia Lawall authored
Use kzalloc rather than the combination of kmalloc and memset. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression x,size,flags; statement S; @@ -x = kmalloc(size,flags); +x = kzalloc(size,flags); if (x == NULL) S -memset(x, 0, size); // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Reviewed-by:
Corbin Simpson <MostAwesomeDude@gmail.com> Reviewed-by:
Matt Turner <mattst88@gmail.com> Signed-off-by:
-
Dan Carpenter authored
Smatch complained that we initialize 6 elements in add_detailed_modes() but the timings[] array is declared with 5 elements. Adam Jackson verified that 6 is the correct number of timings. On Mon, May 10, 2010 at 12:08:24PM -0400, Adam Jackson wrote: > > > struct std_timing timings[5]; > > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > This decl is wrong, should be 6. From the 1.4 spec: > > "Six additional Standard Timings may be listed as a display descriptor > (tag #FAh)." > > The 1.3 spec is a little less explicit about it, but does show 6 > standard timing codes in the 0xFA detailed subblock, terminated by 0x0A > in the 18th byte. I don't have the docs for 1.2 or earlier, but we're > paranoid enough about not adding broken timings that we should be fine. This patch is basically a clean up, because timings[] is declared inside a union and increasing the number of elements here doesn't change the overall size of the union. Signed-off-by:
-
Julia Lawall authored
Use kmemdup when some other buffer is immediately copied into the allocated region. A simplified version of the semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression from,to,size,flag; statement S; @@ - to = \(kmalloc\|kzalloc\)(size,flag); + to = kmemdup(from,size,flag); if (to==NULL || ...) S - memcpy(to, from, size); // </smpl> Signed-off-by:
-
Randy Dunlap authored
Fix typos in vga/Kconfig file and use GPU (upper case) consistently. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Dan Carpenter authored
We don't use timing_level any more after: 9cf00977 "drm/edid: Unify detailed block parsing between base and extension blocks". Signed-off-by:
-
Alex Deucher authored
Should work better on some panels. Signed-off-by:
-
Alex Deucher authored
Fixes LVDS issues on some laptops; notably laptops with 2048x1536 panels. Signed-off-by:
-
- 11 May, 2010 1 commit
-
-
Alex Deucher authored
Signed-off-by:
-
- 08 May, 2010 1 commit
-
-
Alex Deucher authored
Previously we just set them to dpms off. This should save additional power. Signed-off-by:
-
- 06 May, 2010 1 commit
-
-
Jerome Glisse authored
If the memory is not iomem we should not try to ioremap it. Should fix : https://bugs.freedesktop.org/show_bug.cgi?id=27822Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
- 26 Apr, 2010 1 commit
-
-
Jerome Glisse authored
Previous reset code leaded to computer hard lockup (need to unplug the power too reboot the computer) on various configuration. This patch change the reset code to avoid hard lockup. The GPU reset is failing most of the time but at least user can log in remotely or properly shutdown the computer. Two issues were leading to hard lockup : - Writting to the scratch register lead to hard lockup most likely because the write back mecanism is in fuzy state after GPU lockup. - Resetting the GPU memory controller and not reinitializing it after leaded to hard lockup. We did only reinitialize in case of successfull reset thus unsuccessfull reset quickly leaded to hard lockup. Signed-off-by:
-
- 23 Apr, 2010 3 commits
-
-
Christian Koenig authored
Implements irq support for HDMI audio output. Now the polling timer is only enabled if irq support isn't available. Signed-off-by:
Christian König <deathsimple@vodafone.de> Signed-off-by:
-
Christian König authored
Rework HDMI audio polling timer, only enable it when at least one HDMI encoder needs it. Preparation for replacing it with irq support. Signed-off-by:
-
Jerome Glisse authored
Convert most AGP chipset to use scratch page as default entries. This help avoiding GPU querying 0 address and trigger computer fault. With KMS and memory manager we bind/unbind AGP memory constantly and it seems that some GPU are still doing AGP traffic even after GPU report being idle with the memory segment. Tested (radeon GPU KMS + Xorg + compiz + glxgears + quake3) on : - SIS 1039:0001 & 1039:0003 - Intel 865 8086:2571 Compile tested for other bridges V2 enable scratch page on uninorth V3 fix unbound check in uninorth insert memory (Michel Dänzer) V4 rebase on top of drm-next branch with the lastest intel AGP changeset (stable should use version V3 of the patch) Signed-off-by:
Michel Dänzer <michel@daenzer.net> Signed-off-by:
-
- 20 Apr, 2010 14 commits
-
-
Jesse Barnes authored
Add a DRM DocBook providing basic information about DRM interfaces, including TTM, GEM, KMS and vblank infrastructure. Intended to provide information to new and existing developers about how to perform driver initialization, implement mode setting and other DRM features. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Dave Airlie authored
On my 945 laptop + radeon GPU, I was getting an oops on boot without this check which seems to have gotten dropped in the rework. Signed-off-by: -
Dave Airlie authored
Eric mentioned on irc this patch was bad, so revert it. This reverts commit fb8b5a39. Acked-by:
Eric Anholt <eric@anholt.net> Signed-off-by:
-
Dave Airlie authored
* drm-ttm-unmappable: drm/radeon/kms: enable use of unmappable VRAM V2 drm/ttm: remove io_ field from TTM V6 drm/vmwgfx: add support for new TTM fault callback V5 drm/nouveau/kms: add support for new TTM fault callback V5 drm/radeon/kms: add support for new fault callback V7 drm/ttm: ttm_fault callback to allow driver to handle bo placement V6 drm/ttm: split no_wait argument in 2 GPU or reserve wait Conflicts: drivers/gpu/drm/nouveau/nouveau_bo.c
-
Jerome Glisse authored
This patch enable the use of unmappable VRAM thanks to previous TTM infrastructure change. V2 update after io_mem_reserve/io_mem_free callback balancing Signed-off-by:
-
Jerome Glisse authored
All TTM driver have been converted to new io_mem_reserve/free interface which allow driver to choose and return proper io base, offset to core TTM for ioremapping if necessary. This patch remove what is now deadcode. V2 adapt to match with change in first patch of the patchset V3 update after io_mem_reserve/io_mem_free callback balancing V4 adjust to minor cleanup V5 remove the needs ioremap flag V6 keep the ioremapping facility in TTM [airlied- squashed driver removals in here also] Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by:
-
Jerome Glisse authored
This add the support for the new fault callback, does change anything from driver point of view. Improvement: store the aperture base in a variable so that we don't call a function to get it on each fault. Patch hasn't been tested. V2 don't derefence bo->mem.mm_node as it's not NULL only for VRAM or GTT V3 update after io_mem_reserve/io_mem_free callback balancing V4 callback has to ioremap V5 ioremap is done by TTM Signed-off-by:
-
Jerome Glisse authored
This add the support for the new fault callback, does change anything from driver point of view, thought it should allow nouveau to add support for unmappable VRAM. Improvement: store the aperture base in a variable so that we don't call a function to get it on each fault. Patch hasn't been tested on any hw. V2 don't derefence bo->mem.mm_node as it's not NULL only for VRAM or GTT V3 update after io_mem_reserve/io_mem_free callback balancing V4 callback has to ioremap V5 ioremap is done by ttm Signed-off-by:
-
Jerome Glisse authored
This add the support for the new fault callback and also the infrastructure for supporting unmappable VRAM. V2 validate BO with no_wait = true V3 don't derefence bo->mem.mm_node as it's not NULL only for VRAM or GTT V4 update to splitted no_wait ttm change V5 update to new balanced io_mem_reserve/free change V6 callback is responsible for iomapping memory V7 move back iomapping to ttm Signed-off-by:
-
Jerome Glisse authored
On fault the driver is given the opportunity to perform any operation it sees fit in order to place the buffer into a CPU visible area of memory. This patch doesn't break TTM users, nouveau, vmwgfx and radeon should keep working properly. Future patch will take advantage of this infrastructure and remove the old path from TTM once driver are converted. V2 return VM_FAULT_NOPAGE if callback return -EBUSY or -ERESTARTSYS V3 balance io_mem_reserve and io_mem_free call, fault_reserve_notify is responsible to perform any necessary task for mapping to succeed V4 minor cleanup, atomic_t -> bool as member is protected by reserve mecanism from concurent access V5 the callback is now responsible for iomapping the bo and providing a virtual address this simplify TTM and will allow to get rid of TTM_MEMTYPE_FLAG_NEEDS_IOREMAP V6 use the bus addr data to decide to ioremap or this isn't needed but we don't necesarily need to ioremap in the callback but still allow driver to use static mapping Signed-off-by:
-
Daniel Vetter authored
Luckily the change is quite a little bit less invasive than I've feared. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
-
Daniel Vetter authored
Thanks to the to_intel_bo helper, this change is rather trivial. Signed-off-by:
-
Daniel Vetter authored
Just embed it and adjust the pointers, No other changes (that's for later patches). Signed-off-by:
-
Daniel Vetter authored
Just preparation, no functional change. Signed-off-by:
-
