eb858e23a8aa132d068aa639f617ba38e008d077 |
|
25-Jun-2012 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau/fbcon: using nv_two_heads is not a good idea commit 9bd0c15fcfb42f6245447c53347d65ad9e72080b upstream. 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> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
fb2a99e15ff0d342de4ba58c84a791224a96a01a |
|
06-Feb-2012 |
Sascha Hauer <s.hauer@pengutronix.de> |
drm: do not set fb_info->pixmap fields The drm drivers set the fb_info->pixmap fields without setting fb_info->pixmap.addr. If this is not set the fb core will overwrite these all fb_info->pixmap fields anyway, so there is not much point in setting them in the first place. [airlied: dropped nvidiafb piece - not mine] Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
cf41d53bf5b95d77673b185cc3b20ae3257f79e2 |
|
09-Nov-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: re-jig fbcon suspend/resume process a little Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1fbe6f625f69e48c4001051dc1431afc704acfaa |
|
20-Dec-2011 |
Dave Airlie <airlied@redhat.com> |
Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-next Merge in the upstream tree to bring in the mainline fixes. Conflicts: drivers/gpu/drm/exynos/exynos_drm_fbdev.c drivers/gpu/drm/nouveau/nouveau_sgdma.c
|
01f2c7730e188077026c5f766f85f329c7000c54 |
|
19-Dec-2011 |
Ville Syrjälä <ville.syrjala@linux.intel.com> |
drm: Replace pitch with pitches[] in drm_framebuffer Otherwise each driver would need to keep the information inside their own framebuffer object structure. Also add offsets[]. BOs on the other hand are driver specific, so those can be kept in driver specific structures. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
308e5bcbdb10452e8aba31aa21432fb67ee46d72 |
|
14-Nov-2011 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
drm: add an fb creation ioctl that takes a pixel format v5 To properly support the various plane formats supported by different hardware, the kernel must know the pixel format of a framebuffer object. So add a new ioctl taking a format argument corresponding to a fourcc name from the new drm_fourcc.h header file. Implement the fb creation hooks in terms of the new mode_fb_cmd2 using helpers where the old bpp/depth values are needed. v2: create DRM specific fourcc header file for sharing with libdrm etc v3: fix rebase failure and use DRM fourcc codes in intel_display.c and update commit message v4: make fb_cmd2 handle field into an array for multi-object formats pull in Ville's fix for the memcpy in drm_plane_init apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb v5: add 'flags' field for interlaced support (from Ville) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk> Reviewed-by: Rob Clark <rob.clark@linaro.org> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1e482f75f169861e992eb6b5602dc73a9e0b63a2 |
|
06-Nov-2011 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
drm/nouveau: by default use low bpp framebuffer on low memory cards Framebuffer's BPP is not that important but can waste significant part of memory on low-VRAM cards. Lower it to 8bpp on < 32MB cards and to 16bpp on 64MB cards. It can still be overridden by video= option. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
45143cb53c793b11b875d555eb96ca32bcbea1c7 |
|
07-Jun-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv50-nvc0: explicitly map fbcon fb into channel vm Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
f6d4e62145b597c6249c1dc9c1c3ecd66ba165f0 |
|
06-Jun-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: remove 'chan' argument from nouveau_gem_new Userspace hasn't passed us a channel_hint for a long long time now, and there isn't actually a need to do so anymore anyway. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
a18d89ca026140eb8ac4459bf70a01c571dd9a32 |
|
19-Apr-2011 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
drm/nouveau: fix notifier memory corruption bug nouveau_bo_wr32 expects offset to be in words, but we pass value in bytes, so after commit 73412c3854c877e5f37ad944ee8977addde4d35a ("drm/nouveau: allocate kernel's notifier object at end of block") we started to overwrite some memory after notifier buffer object (previously m2mf_ntfy was always 0, so it didn't matter it was a value in bytes). Reported-by: Dominik Brodowski <linux@dominikbrodowski.net> Reported-by: Nigel Cunningham <lkml@nigelcunningham.com.au> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Pekka Paalanen <pq@iki.fi> Cc: stable@kernel.org [2.6.38] Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
6ba9a68317781537d6184d3fdb2d0f20c97da3a4 |
|
10-Feb-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: pass domain rather than ttm flags to gem_new() Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
d550c41e4ff11fe69b5f92868157253d27937d1f |
|
15-Feb-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: remove no_vm/mappable flags from nouveau_bo 'mappable' isn't really used at all, nor is it necessary anymore as the bo code is capable of moving buffers to mappable vram as required. 'no_vm' isn't necessary anymore either, any places that don't want to be mapped into a GPU address space should allocate the VRAM directly instead. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
51fda92223f5b668cccffd51bf3d7bedc93609ff |
|
16-Jan-2011 |
Dave Airlie <airlied@redhat.com> |
Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-fixes * 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: drm/nouveau: fix gpu page faults triggered by plymouthd drm/nouveau: greatly simplify mm, killing some bugs in the process drm/nvc0: enable protection of system-use-only structures in vm drm/nv40: initialise 0x17xx on all chipsets that have it drm/nv40: make detection of 0x4097-ful chipsets available everywhere
|
f01a9720cb149e76155dc6e0e051058450305f4f |
|
17-Jan-2011 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: fix gpu page faults triggered by plymouthd The switch to separate BAR and channel address spaces made the fbcon memory address calculation incorrect on NV50+ boards, this commit fixes that. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
3632ef8909118db9584e1bed9538dc180adb32f8 |
|
15-Jan-2011 |
Dave Airlie <airlied@redhat.com> |
Revert "drm: Update fbdev fb_fix_screeninfo" This reverts commit dfe63bb0ad9810db13aab0058caba97866e0a681. This commit was causing nouveau not to work properly, for -rc1 I'd prefer it worked and we can look if this is useful for 2.6.39. Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
dfe63bb0ad9810db13aab0058caba97866e0a681 |
|
23-Dec-2010 |
James Simmons <jsimmons@infradead.org> |
drm: Update fbdev fb_fix_screeninfo If you change the color depth via fbset or some other framebuffer aware userland application struct fb_fix_screeninfo is not updated to this new information. This patch fixes this issue. Also the function is changed to just pass in struct drm_framebuffer so in the future we could use more fields. I'm hoping some day fix->smem* could be set here :-) Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1d99e5c57255d188773fb437391df24fe8faf575 |
|
22-Dec-2010 |
Dave Airlie <airlied@redhat.com> |
Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next into drm-core-next * 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next: drm/nvc0: accelerate ttm buffer moves drm/nvc0: initial support for tiled buffer objects drm/nvc0: implement fbcon acceleration drm/nvc0: implement pgraph engine hooks drm/nvc0: implement pfifo engine hooks drm/nvc0: implement fencing drm/nvc0: fix channel dma init paths drm/nvc0: skip dma object creation for drm channel drm/nvc0: implement channel structure initialisation drm/nvc0: gpuobj_new need only check validity and init the relevant engine drm/nvc0: reject the notifier_alloc ioctl drm/nvc0: create shared channel vm drm/nvc0: initial vm implementation, use for bar1/bar3 management drm/nvc0: import initial vm backend drm/nouveau: modify vm to accomodate dual page tables for nvc0 drm/nv50: add missing license header to nv50_fbcon.c drm/nv50: fix smatch warning in nv50_vram.c drm/nouveau: sizeof() vs ARRAY_SIZE()
|
ddbaf79a8b047dcccf766d0518626cdc0f43d58e |
|
24-Nov-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nvc0: implement fbcon acceleration Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
57084d05379fe5c081d024006129b0565a11855f |
|
20-Dec-2010 |
James Simmons <jsimmons@infradead.org> |
drm/fb: Don't expose mmio for fbdev emulation layer For the fbdev api if the struct fb_var_screeninfo accel_flags field is set to FB_ACCELF_TEXT then userland applications can not mmap the mmio region. Since it is a bad idea for DRM drivers to expose the mmio region via the fbdev layer we always set the accel_flags to prevent this. Please apply. Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
4c1361429841344ce4d164492ee7620cf3286eb7 |
|
15-Nov-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nv50: implement global channel address space on new VM code As of this commit, it's guaranteed that if an object is in VRAM that its GPU virtual address will be constant. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
9acc8100cb14b91d446a482fdd0cf7e3ccbcf930 |
|
14-Oct-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: fallback to sw fbcon if we can't get mutex immediately Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
6a6b73f254123851f7f73ab5e57344a569d6a0ab |
|
05-Oct-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: add per-channel mutex, use to lock access to drm's channel This fixes a race condition between fbcon acceleration and TTM buffer moves. To reproduce: - start X - switch to vt and "while (true); do dmesg; done" - switch to another vt and "sleep 2 && cat /path/to/debugfs/dri/0/evict_vram" - switch back to vt running dmesg We don't make use of this on any other channel yet, they're currently protected by drm_global_mutex. This will change in the near future. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
ceed5f30bf0f515b52246230e5faacf89983fd8f |
|
05-Oct-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: disallow fbcon accel if running in interrupt context A future commit will add locking to the DRM's channel, and there's numerous problems that come up if we allow printk from an interrupt context to be accelerated. It seems saner to just disallow it completely. As a nice side-effect, all the "to accel or not to accel" logic gets moved out of the chipset-specific code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
b7ae5056c94a8191c1fd0b5697707377516c0c5d |
|
19-Oct-2010 |
Dave Airlie <airlied@redhat.com> |
Merge branch 'drm-fixes' of /home/airlied/kernel/linux-2.6 into drm-core-next Conflicts: drivers/gpu/drm/i915/intel_fb.c drivers/gpu/drm/radeon/r600_blit_kms.c drivers/gpu/drm/ttm/ttm_bo.c
|
dab8dcfa3c8e3b021a138bee7c17791b4991ba55 |
|
07-Oct-2010 |
Dave Airlie <airlied@redhat.com> |
drm: don't drop handle reference on unload since the handle references are all tied to a file_priv, and when it disappears all the handle refs go with it. The fbcon ones we'd only notice on unload, but the nouveau notifier one would would happen on reboot. nouveau: Reported-by: Marc Dionne <marc.c.dionne@gmail.com> nouveau: Tested-by: Marc Dionne <marc.c.dionne@gmail.com> i915 unload: Reported-by: Keith Packard <keithp@keithp.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
be64c2bb4731b0e6223a496eed615b816ac879ec |
|
26-Sep-2010 |
Chris Ball <cjb@laptop.org> |
drm/nouveau/kms: Implement KDB debug hooks for nouveau KMS. Tested on nv50 and nv04 HW. Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Jason Wessel <jason.wessel@windriver.com> CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: dri-devel@lists.freedesktop.org Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
29d08b3efddca628b0360411ab2b85f7b1723f48 |
|
27-Sep-2010 |
Dave Airlie <airlied@redhat.com> |
drm/gem: handlecount isn't really a kref so don't make it one. There were lots of places being inconsistent since handle count looked like a kref but it really wasn't. Fix this my just making handle count an atomic on the object, and have it increase the normal object kref. Now i915/radeon/nouveau drivers can drop the normal reference on userspace object creation, and have the handle hold it. This patch fixes a memory leak or corruption on unload, because the driver had no way of knowing if a handle had been actually added for this object, and the fbcon object needed to know this to clean itself up properly. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
aa9f56b66d278aba2f278c75761b7e19fbaca97a |
|
12-Aug-2010 |
Linus Torvalds <torvalds@linux-foundation.org> |
Merge branch 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6 * 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (55 commits) io-mapping: move asm include inside the config option vgaarb: drop vga.h include drm/radeon: Add probing of clocks from device-tree drm/radeon: drop old and broken mesa warning drm/radeon: Fix pci_map_page() error checking drm: Remove count_lock for calling lastclose() after 58474713 (v2) drm/radeon/kms: allow FG_ALPHA_VALUE on r5xx drm/radeon/kms: another r6xx/r7xx CS checker fix DRM: Replace kmalloc/memset combos with kzalloc drm: expand gamma_set drm/edid: Split mode lists out to their own header for readability drm/edid: Rewrite mode parse to use the generic detailed block walk drm/edid: Add detailed block walk for VTB extensions drm/edid: Add detailed block walk for CEA extensions drm: Remove unused fields from drm_display_info drm: Use ENOENT consistently for the error return for an unmatched handle. drm/radeon/kms: mark 3D power states as performance drm: Only set DPMS once on the CRTC not after every encoder. drm/radeon/kms: add additional quirk for Acer rv620 laptop drm: Propagate error code from fb_create() ... Fix up trivial conflicts in drivers/gpu/drm/drm_edid.c
|
8fd4bd22350784d5b2fe9274f6790ba353976415 |
|
23-Jun-2010 |
Jesse Barnes <jbarnes@virtuousgeek.org> |
vt/console: try harder to print output when panicing Jesse's initial patch commit said: "At panic time (i.e. when oops_in_progress is set) we should try a bit harder to update the screen and make sure output gets to the VT, since some drivers are capable of flipping back to it. So make sure we try to unblank and update the display if called from a panic context." I've enhanced this to add a flag to the vc that console layer can set to indicate they want this behaviour to occur. This also adds support to fbcon for that flag and adds an fb flag for drivers to indicate they want to use the support. It enables this for KMS drivers. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Acked-by: James Simmons <jsimmons@infradead.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
4b223eefe43d201c323d120a01dbd0dcbba64e6d |
|
03-Aug-2010 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nvc0: starting point for GF100 support, everything stubbed Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
77144554de9af353795698161af26e36f7cdbbef |
|
10-Jul-2010 |
Francisco Jerez <currojerez@riseup.net> |
drm/nouveau: Fix crashes during fbcon init on single head cards. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
6e86e0419471d11ed3d4d46039ee90e8cb85806c |
|
03-Jul-2010 |
Francisco Jerez <currojerez@riseup.net> |
drm/nouveau: Fix a couple of sparse warnings. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
5a79395b2791cc70442ab8434aed1b5206683e7c |
|
06-Jun-2010 |
Chris Wilson <chris@chris-wilson.co.uk> |
drm: Propagate error from drm_fb_helper_init(). The previous commit fixes the problem, these commits make sure we actually fail properly if it happens again. I've squashed the commits from Chris since they are all fixing one issue. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
eb1f8e4f3be898df808e2dfc131099f5831d491d |
|
07-May-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fbdev: rework output polling to be back in the core. (v4) 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: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
06415c564fb98562a4d6b6215615deb2d1cc0dae |
|
16-May-2010 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
fbmem, drm/nouveau: kick firmware framebuffers as soon as possible 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: Didier Spaier <didier.spaier@epsm.fr> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1471ca9aa71cd37b6a7476bb6f06a3a8622ea1bd |
|
16-May-2010 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
fbdev: allow passing more than one aperture for handoff It removes a hack from nouveau code which had to detect which region to pass to kick vesafb/efifb. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Cc: Eric Anholt <eric@anholt.net> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
7fff400be6fbf64f10abca9939718aaf1d61c255 |
|
20-Apr-2010 |
Dave Airlie <airlied@redhat.com> |
Merge branch 'drm-fbdev-cleanup' into drm-core-next * drm-fbdev-cleanup: drm/fb: remove drm_fb_helper_setcolreg drm/kms/fb: use slow work mechanism for normal hotplug also. drm/kms/fb: add polling support for when nothing is connected. drm/kms/fb: provide a 1024x768 fbcon if no outputs found. drm/kms/fb: separate fbdev connector list from core drm connectors drm/kms/fb: move to using fb helper crtc grouping instead of core crtc list drm/fb: fix fbdev object model + cleanup properly. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/nouveau/nouveau_drv.h
|
b1f201980eb4a7a59277a13cf18acdbb46167ad5 |
|
07-Apr-2010 |
James Simmons <jsimmons@infradead.org> |
drm/fb: remove drm_fb_helper_setcolreg This patch is against the drm-fbdevfix1 branch. It removes the drm_fb_helper_setcolreg function. The reason is that fb_setcolreg is only used in the case where fb_setcmap is called and no fb_ops->fb_setcmap is used. In the drm case we always need a fb_setcmap hook to handle multiple crtcs so we don't need a fb_setcolreg hook. Please apply. Signed-off-by: James Simmons <jsimmons@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
4abe35204af82a018ca3ce6db4102aa09719698e |
|
30-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: use slow work mechanism for normal hotplug also. a) slow work is always used now for any fbcon hotplug, as its not a fast task and is more suited to being ran under slow work. b) attempt to not do any fbdev changes when X is running as we'll just mess it up. This hooks set_par to hopefully do the changes once X hands control to fbdev. This also adds the nouveau/intel hotplug support. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
0b4c0f3f0eceacb691e2b5570d9b16d751ce1b48 |
|
30-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: separate fbdev connector list from core drm connectors This breaks the connection between the core drm connector list and the fbdev connector usage, and allows them to become disjoint in the future. It also removes the untype void* that was in the connector struct to support this. All connectors are added to the fbdev now but this could be changed in the future. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
8be48d924c307e72e3797ab5bde81b07a1ccc52d |
|
30-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/kms/fb: move to using fb helper crtc grouping instead of core crtc list This move to using the list of crtcs in the fb helper and cleans up the whole picking code, now we store the crtc/connectors we want directly into the modeset and we use the modeset directly to set the mode. Fixes from James Simmons and Ben Skeggs. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
386516744ba45d50f42c6999151cc210cb4f96e4 |
|
30-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
drm/fb: fix fbdev object model + cleanup properly. The fbdev layer in the kms code should act like a consumer of the kms services and avoid having relying on information being store in the kms core structures in order for it to work. This patch a) removes the info pointer/psuedo palette from the core drm_framebuffer structure and moves it to the fbdev helper layer, it also removes the core drm keeping a list of kernel kms fbdevs. b) migrated all the fb helper functions out of the crtc helper file into the fb helper file. c) pushed the fb probing/hotplug control into the driver d) makes the surface sizes into a structure for ease of passing This changes the intel/radeon/nouveau drivers to use the new helper. Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
5a0e3ad6af8660be21ca98a971cd00f331318c05 |
|
24-Mar-2010 |
Tejun Heo <tj@kernel.org> |
include cleanup: Update gfp.h and slab.h includes to prepare for breaking 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>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1c62233508ef7104f8a78e571fdf5c72d0dc0200 |
|
01-Mar-2010 |
Dave Airlie <airlied@redhat.com> |
Merge branch 'gpu-switcher' of /ssd/git//linux-2.6 into drm-next-stage * 'gpu-switcher' of /ssd/git//linux-2.6: vga_switcheroo: initial implementation (v15) fb: for framebuffer handover don't exit the loop early. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/radeon/Makefile drivers/gpu/drm/radeon/radeon.h
|
6a9ee8af344e3bd7dbd61e67037096cdf7f83289 |
|
01-Feb-2010 |
Dave Airlie <airlied@linux.ie> |
vga_switcheroo: initial implementation (v15) Many new laptops now come with 2 gpus, one to be used for low power modes and one for gaming/on-ac applications. These GPUs are typically wired to the laptop panel and VGA ports via a multiplexer unit which is controlled via ACPI methods. 4 combinations of systems typically exist - with 2 ACPI methods. Intel/ATI - Lenovo W500/T500 - use ATPX ACPI method ATI/ATI - some ASUS - use ATPX ACPI Method Intel/Nvidia - - use _DSM ACPI method Nvidia/Nvidia - - use _DSM ACPI method. TODO: This patch adds support for the ATPX method and initial bits for the _DSM methods that need to written by someone with access to the hardware. Add a proper non-debugfs interface - need to get some proper testing first. v2: add power up/down support for both devices on W500 puts i915/radeon into D3 and cuts power to radeon. v3: redo probing methods, no DMI list, drm devices call to register with switcheroo, it tries to find an ATPX method on any device and once there is two devices + ATPX it inits the switcher. v4: ATPX msg handling using buffers - should work on more machines v5: rearchitect after more mjg59 discussion - move ATPX handling to radeon driver. v6: add file headers + initial nouveau bits (to be filled out). v7: merge delayed switcher code. v8: avoid suspend/resume of gpu that is off v9: rearchitect - mjg59 is always right. - move all ATPX code to radeon, should allow simpler DSM also proper ATRM handling v10: add ATRM support for radeon BIOS, add mutex to lock vgasr_priv v11: fix bug in resuming Intel for 2nd time. v12: start fixing up nvidia code blindly. v13: blindly guess at finishing nvidia code v14: remove radeon audio hacks - fix up intel resume more like upstream v15: clean up printks + remove unnecessary igd/dis pointers mount debugfs /sys/kernel/debug/vgaswitcheroo/switch - should exist if ATPX detected + 2 cards. DIS - immediate change to discrete IGD - immediate change to IGD DDIS - delayed change to discrete DIGD - delayed change to IGD ON - turn on not in use OFF - turn off not in use Tested on W500 (Intel/ATI) and T500 (Intel/ATI) Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
bc9025bdc4e2b591734cca17697093845007b63d |
|
09-Feb-2010 |
Luca Barbieri <luca@luca-barbieri.com> |
Use drm_gem_object_[handle_]unreference_unlocked where possible Mostly obvious simplifications. The i915 pread/pwrite ioctls, intel_overlay_put_image and nouveau_gem_new were incorrectly using the locked versions without locking: this is also fixed in this patch. Signed-off-by: Luca Barbieri <luca@luca-barbieri.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
126b5440565a1fa0cb49fd30041525d5a9a848f5 |
|
27-Jan-2010 |
Marcin Kościelnicki <koriakin@0x04.net> |
drm/nouveau: Fix fbcon on mixed pre-NV50 + NV50 multicard. We used single shared fbops struct and patched it at fb init time with pointers to the right variant. On mixed multicard, this meant that it was either sending NV50-style commands to all cards, or NV04-style commands to all cards. Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
a32ed69d7bb3cd259d813d71281d62993b9a70fd |
|
26-Jan-2010 |
Marcin Kościelnicki <koriakin@0x04.net> |
drm/nouveau: Add module options to disable acceleration. noaccel=1 disables all acceleration and doesn't even attempt initialising PGRAPH+PFIFO, nofbaccel=1 only makes fbcon unaccelerated. Signed-off-by: Marcin Kościelnicki <koriakin@0x04.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
846975a97b098bbbf1232a01a3a5723a4bddd9e7 |
|
04-Jan-2010 |
Marcin Slusarz <marcin.slusarz@gmail.com> |
drm/nouveau: create function for "dealing" with gpu lockup It's mostly a cleanup, but in nv50_fbcon_accel_init gpu lockup message was printed, but HWACCEL_DISBALED flag was not set. Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
1c7059e4f36e76c72cefbb6c9bd2bcf45c12e777 |
|
25-Dec-2009 |
Maarten Maathuis <madman2003@gmail.com> |
drm/nouveau: better alignment of bo sizes and use roundup instead of ALIGN - Aligning to block size should ensure that the extra size is enough. - Using roundup, because not all sizes are powers of two. Signed-off-by: Maarten Maathuis <madman2003@gmail.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
0735f62e116fae1e4f36237a97de28e8a56b4c2c |
|
16-Dec-2009 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: prevent all channel creation if accel not available Previously, if there was no firmware available, the DRM would just disable channel creation from userspace, but still use a single channel for its own purposes. With a bit of care it should actually be possible to do this, due to the DRM's very limited use of the engine. It currently doesn't work correctly however, resulting in corrupted fbcon and hangs on a number of cards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
ef2bb506687a5f1cc8ef2fef370bb168b2808106 |
|
13-Dec-2009 |
Maarten Maathuis <madman2003@gmail.com> |
drm/nouveau: use drm debug levels - Use driver level (0x2) for NV_DEBUG instead of all levels - Create a NV_DEBUG_KMS for KMS level (0x4) and use them in modesetting code - Remove a few odd NV_TRACE calls and replace some of them with NV_DEBUG_KMS or NV_INFO Signed-off-by: Maarten Maathuis <madman2003@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|
6ee738610f41b59733f63718f0bdbcba7d3a3f12 |
|
11-Dec-2009 |
Ben Skeggs <bskeggs@redhat.com> |
drm/nouveau: Add DRM driver for NVIDIA GPUs This adds a drm/kms staging non-API stable driver for GPUs from NVIDIA. This driver is a KMS-based driver and requires a compatible nouveau userspace libdrm and nouveau X.org driver. This driver requires firmware files not available in this kernel tree, interested parties can find them via the nouveau project git archive. This driver is reverse engineered, and is in no way supported by nVidia. Support for nearly the complete range of nvidia hw from nv04->g80 (nv50) is available, and the kms driver should support driving nearly all output types (displayport is under development still) along with supporting suspend/resume. This work is all from the upstream nouveau project found at nouveau.freedesktop.org. The original authors list from nouveau git tree is: Anssi Hannula <anssi.hannula@iki.fi> Ben Skeggs <bskeggs@redhat.com> Francisco Jerez <currojerez@riseup.net> Maarten Maathuis <madman2003@gmail.com> Marcin Kościelnicki <koriakin@0x04.net> Matthew Garrett <mjg@redhat.com> Matt Parnell <mparnell@gmail.com> Patrice Mandin <patmandin@gmail.com> Pekka Paalanen <pq@iki.fi> Xavier Chantry <shiningxc@gmail.com> along with project founder Stephane Marchesin <marchesin@icps.u-strasbg.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
/drivers/gpu/drm/nouveau/nouveau_fbcon.c
|