History log of /drivers/gpu/drm/nouveau/nouveau_fbcon.c
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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