summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nouveau_fbcon.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2014-10-141-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "This is the main git pull for the drm, I pretty much froze major pulls at -rc5/6 time, and haven't had much fallout, so will probably continue doing that. Lots of changes all over, big internal header cleanup to make it clear drm features are legacy things and what are things that modern KMS drivers should be using. Also big move to use the new generic fences in all the TTM drivers. core: atomic prep work, vblank rework changes, allows immediate vblank disables major header reworking and cleanups to better delinate legacy interfaces from what KMS drivers should be using. cursor planes locking fixes ttm: move to generic fences (affects all TTM drivers) ppc64 caching fixes radeon: userptr support, uvd for old asics, reset rework for fence changes better buffer placement changes, dpm feature enablement hdmi audio support fixes intel: Cherryview work, 180 degree rotation, skylake prep work, execlist command submission full ppgtt prep work cursor improvements edid caching, vdd handling improvements nouveau: fence reworking kepler memory clock work gt21x clock work fan control improvements hdmi infoframe fixes DP audio ast: ppc64 fixes caching fix rcar: rcar-du DT support ipuv3: prep work for capture support msm: LVDS support for mdp4, new panel, gpu refactoring exynos: exynos3250 SoC support, drop bad mmap interface, mipi dsi changes, and component match support" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (640 commits) drm/mst: rework payload table allocation to conform better. drm/ast: Fix HW cursor image drm/radeon/kv: add uvd/vce info to dpm debugfs output drm/radeon/ci: add uvd/vce info to dpm debugfs output drm/radeon: export reservation_object from dmabuf to ttm drm/radeon: cope with foreign fences inside the reservation object drm/radeon: cope with foreign fences inside display drm/core: use helper to check driver features drm/radeon/cik: write gfx ucode version to ucode addr reg drm/radeon/si: print full CS when we hit a packet 0 drm/radeon: remove unecessary includes drm/radeon/combios: declare legacy_connector_convert as static drm/radeon/atombios: declare connector convert tables as static drm/radeon: drop btc_get_max_clock_from_voltage_dependency_table drm/radeon/dpm: drop clk/voltage dependency filters for BTC drm/radeon/dpm: drop clk/voltage dependency filters for CI drm/radeon/dpm: drop clk/voltage dependency filters for SI drm/radeon/dpm: drop clk/voltage dependency filters for NI drm/radeon: disable audio when we disable hdmi (v2) drm/radeon: split audio enable between eg and r600 (v2) ...
| * drm/nouveau: use container_of to resolve nouveau_fbdev from drm_fb_helperFabian Frederick2014-09-241-1/+2
| | | | | | | | | | | | | | Use container_of instead of casting first structure member. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/nouveau: Display Nouveau boot options at launchPierre Moreau2014-09-151-1/+1
| | | | | | | | | | | | | | | | | | It can help to remove any ambiguity about which options were passed to Nouveau, especially in case the user had some options set in /etc/modprobe.d/*.conf that he forgot about, as they won't appear in a dmesg. Signed-off-by: Pierre Moreau <pierre.morrow@free.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: punt fbcon resume out to a workqueueBen Skeggs2014-10-021-6/+17
|/ | | | | | | | | | | | | | | Preparation for some runtime pm fixes. Currently we skip over fbcon suspend/resume in the runtime path, which causes issues on resume if fbcon tries to write to the framebuffer before the BAR subdev has been resumed to restore the BAR1 VM setup. As we might be woken up via a sysfs connector, we are unable to call fb_set_suspend() in the resume path as it could make its way down to a modeset and cause all sorts of locking hilarity. To solve this, we'll just delay the fbcon resume to a workqueue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/kms: nouveau_fbcon_accel_fini can be staticFengguang Wu2014-08-151-2/+2
| | | | | Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: use ram info from nvif_deviceBen Skeggs2014-08-101-3/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: remove as much direct use of core headers as possibleBen Skeggs2014-08-101-3/+0
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: port to nvif client/device/objectsBen Skeggs2014-08-101-3/+8
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: initial pass at moving to struct nvif_deviceBen Skeggs2014-08-101-14/+14
| | | | | | | This is an attempt at isolating some of the changes necessary to port to NVIF in a separate commit. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/kms: restore acceleration before fb_set_suspend() resumesBen Skeggs2014-08-101-3/+3
| | | | | | This *should* be safe these days. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/kms: take more care when pulling down accelerated fbconBen Skeggs2014-08-101-35/+57
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* Merge tag 'v3.16' into drm-nextDave Airlie2014-08-051-10/+3
|\ | | | | | | | | | | | | | | | | | | Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
| * drm/nouveau/kms: restore fbcon after display has been resumedBen Skeggs2014-07-081-10/+3
| | | | | | | | | | | | | | | | | | | | | | | | Under some complicated circumstances (boot, suspend, resume, attach second display, suspend, resume, suspend, detach second display, resume, suspend, attach second display, resume), the fb_set_suspend() call can somehow result in a modeset being attempted before we're ready for it and things blow up in fun ways. Running display init first fixes the issue. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm: Introduce drm_fb_helper_prepare()Thierry Reding2014-07-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To implement hotplug detection in a race-free manner, drivers must call drm_kms_helper_poll_init() before hotplug events can be triggered. Such events can be triggered right after any of the encoders or connectors are initialized. At the same time, if the drm_fb_helper_hotplug_event() helper is used by a driver, then the poll helper requires some parts of the FB helper to be initialized to prevent a crash. At the same time, drm_fb_helper_init() requires information that is not necessarily available at such an early stage (number of CRTCs and connectors), so it cannot be used yet. Add a new helper, drm_fb_helper_prepare(), that initializes the bare minimum needed to allow drm_kms_helper_poll_init() to execute and any subsequent hotplug events to be processed properly. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm: Constify struct drm_fb_helper_funcsThierry Reding2014-07-081-1/+1
|/ | | | | | | | | | There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thierry Reding <treding@nvidia.com> Acked-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau: fix fbcon not being accelerated after suspendBen Skeggs2014-03-261-2/+2
| | | | | | | | | | | This does *not* (and is not intended to) fix the issue reported by Christoph Rudorff on the nouveau mailinglist. The patch proposed (which is similar to this one, but also reorders whether we disable accel or call fb_set_suspend first), papers over another problem entirely by avoiding touching the framebuffer. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/fbcon: bracket entrypoints with a per-device enabled checkBen Skeggs2013-11-081-16/+27
| | | | | | | | We don't necessarily have fbcon on all devices these days. Fixes suspend on (at least) Quadro NVS 450. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: embed gem object in nouveau_boDavid Herrmann2013-10-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no reason to keep the gem object separately allocated. nouveau is the last user of gem_obj->driver_private, so if we embed it, we can get rid of 8bytes per gem-object. The implementation follows the radeon driver. bo->gem is only valid, iff the bo was created via the gem helpers _and_ iff the user holds a valid gem reference. That is, as the gem object holds a reference to the nouveau_bo. If you use nouveau_ref() to gain a bo reference, you are not guaranteed to also hold a gem reference. The gem object might get destroyed after the last user drops the gem-ref via drm_gem_object_unreference(). Use drm_gem_object_reference() to gain a gem-reference. For debugging, we can use bo->gem.filp != NULL to test whether a gem-bo is valid. However, this shouldn't be used for real functionality to avoid gem-internal dependencies. Note that the implementation follows the previous style. However, we no longer can check for bo->gem != NULL to test for a valid gem object. This wasn't done before, so we should be safe now. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/kms: enable for non-vga pci classesBen Skeggs2013-09-181-1/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix null pointer dereference in poll_changedMaarten Lankhorst2013-07-301-1/+2
| | | | | | | Fixes vgaswitcheroo on a card without display. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: fix some error-path leaks in fbcon handling codeMaarten Lankhorst2013-07-101-0/+1
| | | | | Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* Merge branch 'drm-nouveau-next' of ↵Dave Airlie2013-07-011-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/git/nouveau/linux-2.6 into drm-next - Various fixes that make surviving concurrent piglit more possible. - Buffer object deletion no longer synchronous - Context/register initialisation updates that have been reported to solve some stability issues (particularly on some problematic GF119 chips) - Kernel side support for VP2 video decoding engines * 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6: (44 commits) drm/nvd0-/disp: handle case where display engine is missing/disabled drm/gr/nvc0-: merge nvc0/nve0 ucode, and use cpp instead of m4 drm/nouveau/bsp/nv84: initial vp2 engine implementation drm/nouveau/vp/nv84: initial vp2 engine implementation drm/nouveau/core: xtensa engine base class implementation drm/nouveau/vdec: fork vp3 implementations from vp2 drm/nouveau/core: move falcon class to engine/ drm/nouveau/kms: don't fail if there's no dcb table entries drm/nouveau: remove limit on gart drm/nouveau/vm: perform a bar flush when flushing vm drm/nvc0/gr: cleanup register lists, and add nvce/nvcf to switches drm/nvc8/gr: update initial register/context values drm/nvc4/gr: update initial register/context values drm/nvc1/gr: update initial register/context values drm/nvc3/gr: update initial register/context values drm/nvc0/gr: update initial register/context values drm/nvd9/gr: update initial register/context values drm/nve4/gr: update initial register/context values drm/nvc0-/gr: bump maximum gpc/tpc limits drm/nvf0/gr: initial register/context setup ...
| * drm/nouveau/fb: initialise vram controller as pfb sub-objectBen Skeggs2013-07-011-2/+2
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: fixup fbcon failure pathsMaarten Lankhorst2013-06-281-9/+14
|/ | | | | | | | Add missing calls, and fix a leak from forgetting to call the unpin function. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/<drivers>: simplify ->fb_probe callbackDaniel Vetter2013-02-141-19/+3
| | | | | | | | The fb helper lost its support for reallocating an fb completely, so no need to return special success values any more. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/fb-helper: don't disable everything in initial_configDaniel Vetter2013-02-141-0/+3
| | | | | | | | | | | | | | This should be done in the drivers for two reasons: - it gets in the way of fastboot efforts - it links the fb helpers with the crtc helpers instead of going through the real interface vfuncs, forcing i915 to fake all the ->disable callbacks used by the crtc helper to avoid ugly Oopsen v2: Resolve conflicts since drivers still call drm_fb_helper_single_add_all_connectors. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: revamp framebuffer cleanup interfacesDaniel Vetter2013-01-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have two classes of framebuffer - Created by the driver (atm only for fbdev), and the driver holds onto the last reference count until destruction. - Created by userspace and associated with a given fd. These framebuffers will be reaped when their assoiciated fb is closed. Now these two cases are set up differently, the framebuffers are on different lists and hence destruction needs to clean up different things. Also, for userspace framebuffers we remove them from any current usage, whereas for internal framebuffers it is assumed that the driver has done this already. Long story short, we need two different ways to cleanup such drivers. Three functions are involved in total: - drm_framebuffer_remove: Convenience function which removes the fb from all active usage and then drops the passed-in reference. - drm_framebuffer_unregister_private: Will remove driver-private framebuffers from relevant lists and drop the corresponding references. Should be called for driver-private framebuffers before dropping the last reference (or like for a lot of the drivers where the fbdev is embedded someplace else, before doing the cleanup manually). - drm_framebuffer_cleanup: Final cleanup for both classes of fbs, should be called by the driver's ->destroy callback once the last reference is gone. This patch just rolls out the new interfaces and updates all drivers (by adding calls to drm_framebuffer_unregister_private at all the right places)- no functional changes yet. Follow-on patches will move drm core code around and update the lifetime management for framebuffers, so that we are no longer required to keep framebuffers alive by locking mode_config.mutex. I've also updated the kerneldoc already. vmwgfx seems to again be a bit special, at least I haven't figured out how the fbdev support in that driver works. It smells like it's external though. v2: The i915 driver creates another private framebuffer in the load-detect code. Adjust its cleanup code, too. Reviewed-by: Rob Clark <rob@ti.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-10-031-108/+118
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
| * drm/nouveau: port remainder of drm code, and rip out compat layerBen Skeggs2012-10-031-14/+13
| | | | | | | | | | | | | | | | v2: Ben Skeggs <bskeggs@redhat.com> - fill in nouveau_pm.dev to prevent oops - fix ppc issues (build + OF shadow) Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau: port all engines to new engine module formatBen Skeggs2012-10-031-107/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a HUGE commit, but it's not nearly as bad as it looks - any problems can be isolated to a particular chipset and engine combination. It was simply too difficult to port each one at a time, the compat layers are *already* ridiculous. Most of the changes here are simply to the glue, the process for each of the engine modules was to start with a standard skeleton and copy+paste the old code into the appropriate places, fixing up variable names etc as needed. v2: Marcin Slusarz <marcin.slusarz@gmail.com> - fix find/replace bug in license header v3: Ben Skeggs <bskeggs@redhat.com> - bump indirect pushbuf size to 8KiB, 4KiB barely enough for userspace and left no space for kernel's requirements during GEM pushbuf submission. - fix duplicate assignments noticed by clang v4: Marcin Slusarz <marcin.slusarz@gmail.com> - add sparse annotations to nv04_fifo_pause/nv04_fifo_start - use ioread32_native/iowrite32_native for fifo control registers v5: Ben Skeggs <bskeggs@redhat.com> - rebase on v3.6-rc4, modified to keep copy engine fix intact - nv10/fence: unmap fence bo before destroying - fixed fermi regression when using nvidia gr fuc - fixed typo in supported dma_mask checking Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau/fb: merge fb/vram and port to subdev interfacesBen Skeggs2012-10-031-2/+2
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
| * drm/nouveau: implement module init functions in nouveau_drm.cBen Skeggs2012-10-031-1/+1
| | | | | | | | | | | | | | | | These currently just call the existing ones in nouveau_drv.c, but will be extended in upcoming commits. This needed to be separated from the current code as there will be some header clashes until things are ported. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | UAPI: (Scripted) Convert #include "..." to #include <path/...> in drivers/gpu/David Howells2012-10-021-5/+5
| | | | | | | | | | | | | | | | | | | | | | Convert #include "..." to #include <path/...> in drivers/gpu/. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* | UAPI: (Scripted) Remove redundant DRM UAPI header #inclusions from drivers/gpu/.David Howells2012-10-021-1/+0
|/ | | | | | | | | | | | | | | | | | | | | Remove redundant DRM UAPI header #inclusions from drivers/gpu/. Remove redundant #inclusions of core DRM UAPI headers (drm.h, drm_mode.h and drm_sarea.h). They are now #included via drmP.h and drm_crtc.h via a preceding patch. Without this patch and the patch to make include the UAPI headers from the core headers, after the UAPI split, the DRM C sources cannot find these UAPI headers because the DRM code relies on specific -I flags to make #include "..." work on headers in include/drm/ - but that does not work after the UAPI split without adding more -I flags. Signed-off-by: David Howells <dhowells@redhat.com> Acked-by: Dave Airlie <airlied@redhat.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Acked-by: Dave Jones <davej@redhat.com>
* drm/nouveau/fbcon: using nv_two_heads is not a good ideaBen Skeggs2012-06-261-1/+1
| | | | | | | | | | | | | | | | | | 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> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/fbcon: use fence for sync, rather than notifierBen Skeggs2012-05-241-32/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: use the same packet header macros as userspaceBen Skeggs2012-05-241-4/+4
| | | | | | Cosmetic cleanup only. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm: do not set fb_info->pixmap fieldsSascha Hauer2012-02-091-5/+1
| | | | | | | | | | | | 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>
* drm/nouveau: re-jig fbcon suspend/resume process a littleBen Skeggs2011-12-211-0/+7
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* Merge tag 'v3.2-rc6' of /home/airlied/devel/kernel/linux-2.6 into drm-core-nextDave Airlie2011-12-201-1/+10
|\ | | | | | | | | | | | | | | 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
| * drm/nouveau: by default use low bpp framebuffer on low memory cardsMarcin Slusarz2011-11-101-1/+10
| | | | | | | | | | | | | | | | | | 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>
* | drm: Replace pitch with pitches[] in drm_framebufferVille Syrjälä2011-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* | drm: add an fb creation ioctl that takes a pixel format v5Jesse Barnes2011-11-151-6/+7
|/ | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/nv50-nvc0: explicitly map fbcon fb into channel vmBen Skeggs2011-06-231-0/+11
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: remove 'chan' argument from nouveau_gem_newBen Skeggs2011-06-231-2/+2
| | | | | | | 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>
* drm/nouveau: fix notifier memory corruption bugMarcin Slusarz2011-04-201-2/+2
| | | | | | | | | | | | | | | | 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>
* drm/nouveau: pass domain rather than ttm flags to gem_new()Ben Skeggs2011-02-251-2/+2
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau: remove no_vm/mappable flags from nouveau_boBen Skeggs2011-02-251-1/+1
| | | | | | | | | | '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>
* Merge remote branch 'nouveau/drm-nouveau-next' of /ssd/git/drm-nouveau-next ↵Dave Airlie2011-01-171-2/+2
|\ | | | | | | | | | | | | | | | | | | | | 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
| * drm/nouveau: fix gpu page faults triggered by plymouthdBen Skeggs2011-01-171-2/+2
| | | | | | | | | | | | | | 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>
OpenPOWER on IntegriCloud