- 19 6月, 2009 5 次提交
-
-
由 Keith Packard 提交于
Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
Some machines say 'Apple Inc.' while others say 'Apple Computer, Inc'. Switch the test to just look for 'Apple' instead. Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Keith Packard 提交于
HDMI and DVI both require DDC/EDID on monitors, so use that to know when a monitor is connected as the hot-plug pins are shared with SDVO and DisplayPort Signed-off-by: NKeith Packard <keithp@keithp.com>
-
由 Chris Wilson 提交于
The fence register value also depends upon the stride of the object, so we need to clear the fence if that is changed as well. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [anholt: Added 8xx and 965 paths, and renamed the confusing i915_gem_object_tiling_ok function to i915_gem_object_fence_offset_ok] Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
With the work by Jesse Barnes to eliminate allocation of fences during execbuffer, it becomes possible to write to the scan-out buffer with it never acquiring a fence (simply by only ever writing to the object using tiled GPU commands and never writing to it via the GTT). So for pre-i965 chipsets which require fenced access for tiled scan-out buffers, we need to obtain a fence register. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
- 18 6月, 2009 4 次提交
-
-
由 Chris Wilson 提交于
After performing an operation over the page list for a buffer retrieved by i915_gem_object_get_pages() the pages need to be returned with i915_gem_object_put_pages(). This was not being observed for the phys objects which were thus leaking references to their backing pages. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> CC: Dave Airlie <airlied@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Ben Gamari 提交于
Signed-Off-By: NBen Gamari <bgamari.foss@gmail.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Ben Gamari 提交于
While sifting through the inteldrmfb code trying to solve #22040 I found that the fb restore path doesn't check the return value of drm_crtc_helper_set_config(), which seems to have all sorts of potential failure modes. We should warn someone if one of these is triggered. Signed-Off-By: NBen Gamari <bgamari.foss@gmail.com> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> [anholt: hand-applied, failures are mine] Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Dave Airlie 提交于
This causes an issue since we fixed the drm mappings to do the right thing, so its just a copy and pasto. Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 17 6月, 2009 2 次提交
-
-
由 Dave Airlie 提交于
With KMS we have ran into an issue where we really want the KMS fb driver to be the one running the console, so panics etc can be shown by switching out of X etc. However with vesafb/efifb built-in, we end up with those on fb0 and the KMS fb driver on fb1, driving the same piece of hw, so this adds an fb info flag to denote a firmware fbdev, and adds a new aperture base/size range which can be compared when the hw drivers are installed to see if there is a conflict with a firmware driver, and if there is the firmware driver is unregistered and the hw driver takes over. It uses new aperture_base/size members instead of comparing on the fix smem_start/length, as smem_start/length might for example only cover the first 1MB of the PCI aperture, and we could allocate the kms fb from 8MB into the aperture, thus they would never overlap. [akpm@linux-foundation.org: coding-style fixes] Signed-off-by: NDave Airlie <airlied@redhat.com> Acked-by: NPeter Jones <pjones@redhat.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Krzysztof Helt <krzysztof.h1@poczta.fm> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Dave Airlie 提交于
This fixes an issue where we get inited before fbcon when built-in. Ideally this should work as a non late_initcall, but this fixes it for now. We also don't suggest people build this in (at least distro maintainers). Reported-by: NRyan Hope <rmh3093@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 16 6月, 2009 2 次提交
-
-
由 GeunSik Lim 提交于
Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/" directory name to mount debugfs filesystem for ftrace according to ./Documentation/tracers/ftrace.txt file. And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is existed in kernel source like ftrace, DRM, Wireless, Documentation, Network[sky2]files to mount debugfs filesystem. debugfs means debug filesystem for debugging easy to use by greg kroah hartman. "/sys/kernel/debug/" name is suitable as directory name of debugfs filesystem. - debugfs related reference: http://lwn.net/Articles/334546/ Fix inconsistency of directory name to mount debugfs filesystem. * From Steven Rostedt - find_debugfs() and tracing_files() in this patch. Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com> Acked-by : Inaky Perez-Gonzalez <inaky@linux.intel.com> Reviewed-by : Steven Rostedt <rostedt@goodmis.org> Reviewed-by : James Smart <james.smart@emulex.com> CC: Jiri Kosina <trivial@kernel.org> CC: David Airlie <airlied@linux.ie> CC: Peter Osterlund <petero2@telia.com> CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com> CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com> CC: Masami Hiramatsu <mhiramat@redhat.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Kay Sievers 提交于
This adds support to the drm core to report the proper device name to userspace for the drm devices. Signed-off-by: NKay Sievers <kay.sievers@vrfy.org> Signed-off-by: NJan Blunck <jblunck@suse.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 15 6月, 2009 4 次提交
-
-
由 Alex Deucher 提交于
COMBIOS - fallback to table values if there are no tv dac or lvds bios tables ATOMBIOS - add support for looking up these values from the bios table Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jerome Glisse 提交于
Add kernel modesetting support to radeon driver, use the ttm memory manager to manage memory and DRM/GEM to provide userspace API. In order to avoid backward compatibility issue and to allow clean design and code the radeon kernel modesetting use different code path than old radeon/drm driver. When kernel modesetting is enabled the IOCTL of radeon/drm driver are considered as invalid and an error message is printed in the log and they return failure. KMS enabled userspace will use new API to talk with the radeon/drm driver. The new API provide functions to create/destroy/share/mmap buffer object which are then managed by the kernel memory manager (here TTM). In order to submit command to the GPU the userspace provide a buffer holding the command stream, along this buffer userspace have to provide a list of buffer object used by the command stream. The kernel radeon driver will then place buffer in GPU accessible memory and will update command stream to reflect the position of the different buffers. The kernel will also perform security check on command stream provided by the user, we want to catch and forbid any illegal use of the GPU such as DMA into random system memory or into memory not owned by the process supplying the command stream. This part of the code is still incomplete and this why we propose that patch as a staging driver addition, future security might forbid current experimental userspace to run. This code support the following hardware : R1XX,R2XX,R3XX,R4XX,R5XX (radeon up to X1950). Works is underway to provide support for R6XX, R7XX and newer hardware (radeon from HD2XXX to HD4XXX). Authors: Jerome Glisse <jglisse@redhat.com> Dave Airlie <airlied@redhat.com> Alex Deucher <alexdeucher@gmail.com> Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com> Signed-off-by: NAlex Deucher <alexdeucher@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Thomas Hellstrom 提交于
TTM is a GPU memory manager subsystem designed for use with GPU devices with various memory types (On-card VRAM, AGP, PCI apertures etc.). It's essentially a helper library that assists the DRM driver in creating and managing persistent buffer objects. TTM manages placement of data and CPU map setup and teardown on data movement. It can also optionally manage synchronization of data on a per-buffer-object level. TTM takes care to provide an always valid virtual user-space address to a buffer object which makes user-space sub-allocation of big buffer objects feasible. TTM uses a fine-grained per buffer-object locking scheme, taking care to release all relevant locks when waiting for the GPU. Although this implies some locking overhead, it's probably a big win for devices with multiple command submission mechanisms, since the lock contention will be minimal. TTM can be used with whatever user-space interface the driver chooses, including GEM. It's used by the upcoming Radeon KMS DRM driver and is also the GPU memory management core of various new experimental DRM drivers. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NJerome Glisse <jglisse@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Chris Wilson 提交于
If the block needs an alignment but otherwise fits exactly into the tail, then the split-off block from the start would remain marked as non-free. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 12 6月, 2009 9 次提交
-
-
由 Jerome Glisse 提交于
add exports so TTM module can use these functions. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Jerome Glisse 提交于
this is a TTM preparation patch, it rearranges the mm and add operations needed to do mm operations in atomic context. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
This adds the PCI IDs for the rv790 which are equiv to the rv770. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Alex Deucher 提交于
This adds drm support for the RV740 family of chips to the r600 support code. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Keith Packard 提交于
This code depends on the underlying I2C adapter using the bit-banging algo, which may not be the case. If specific encoders require this mechanism, they should build a custom I2C algo that implements this workaround, rather than having it in the general path. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
duplicate the mode into fbcon storage, so when we free modes later we don't just lose this. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Figo.zhang 提交于
vfree() does it's own NULL checking, no need for explicit check before calling it. Signed-off-by: NFigo.zhang <figo1802@gmail.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 yakui_zhao 提交于
Replace the DRM_DEBUG with the DRM_DEBUG_DRIVER to print the debug info in i915 driver. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 yakui_zhao 提交于
Replace the DRM_DEBUG with DRM_DEBUG_MODE macro to print the info in drm_mode. airlied:- fixed up to remove a conflicting #define Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 11 6月, 2009 7 次提交
-
-
由 yakui_zhao 提交于
Use the DRM_DEBUG_KMS/DEBUG_LOG_KMS to print the debug info for SDVO device. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 yakui_zhao 提交于
Use the DRM_DEBUG_KMS macro definition to print the debug info for the LVDS. Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 yakui_zhao 提交于
Now all the DRM debug info will be reported if the boot option of "drm.debug=1" is added. Sometimes it is inconvenient to get the debug info in KMS mode. We will get too much unrelated info. This will separate several DRM debug levels and the debug level can be used to print the different debug info. And the debug level is controlled by the module parameter of drm.debug In this patch it is divided into four debug levels; drm_core, drm_driver, drm_kms, drm_mode. At the same time we can get the different debug info by changing the debug level. This can be done by adding the module parameter. Of course it can be changed through the /sys/module/drm/parameters/debug after the system is booted. Four debug macro definitions are provided. DRM_DEBUG(fmt, args...) DRM_DEBUG_DRIVER(prefix, fmt, args...) DRM_DEBUG_KMS(prefix, fmt, args...) DRM_DEBUG_MODE(prefix, fmt, args...) When the boot option of "drm.debug=4" is added, it will print the debug info using DRM_DEBUG_KMS macro definition. When the boot option of "drm.debug=6" is added, it will print the debug info using DRM_DEBUG_KMS/DRM_DEBUG_DRIVER. Sometimes we expect to print the value of an array. For example: SDVO command, In such case the following four DRM debug macro definitions are added: DRM_LOG(fmt, args...) DRM_LOG_DRIVER(fmt, args...) DRM_LOG_KMS(fmt, args...) DRM_LOG_MODE(fmt, args...) Signed-off-by: NZhao Yakui <yakui.zhao@intel.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Dave Airlie 提交于
This shouldn't be there and is what broke r600 late in the 2.6.30 release cycle with Ben's patch. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Ben Skeggs 提交于
A driver will use the _DRM_DRIVER map flag to indicate that it wants to be responsible for removing the map itself, bypassing the DRM's automagic cleanup code. Since the multi-master changes this has been broken, resulting in some drivers having their registers unmapped before it's finished with them. Signed-off-by: NBen Skeggs <bskeggs@redhat.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Robert P. J. Day 提交于
Calls to kcalloc() for a single element can be simplified to calls to kzalloc(). Signed-off-by: NRobert P. J. Day <rpjday@crashcourse.ca> Cc: Dave Airlie <airlied@linux.ie> Cc: Eric Anholt <eric@anholt.net> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
由 Pavel Roskin 提交于
Signed-off-by: NPavel Roskin <proski@gnu.org> Cc: Eric Anholt <eric@anholt.net> Cc: Dave Airlie <airlied@linux.ie> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 10 6月, 2009 7 次提交
-
-
由 Keith Packard 提交于
With the DRM-driven DPMS code, encoders are considered idle unless a connector is hooked to them, so mode setting is skipped. This makes load detection fail as none of the hardware is enabled. Signed-off-by: NKeith Packard <keithp@keithp.com> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
To differentiate between encountering an out-of-memory error with running out of space in the aperture, use ENOSPC for the later. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
Ensure that the drm_vblank_pre_modeset() is always balanced by drm_vblank_post_modeset() within intel_crtc_mode_set(). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
The batch buffer may be shared with another read buffer, so we should not ignore any previously set domains, but just or in the command domain (and check that the buffer is not writable). Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-
由 Chris Wilson 提交于
By sending a broken execbuffer (its length was not suitably aligned) I triggered an operation upon a freed object. The invalid alignment was discovered after updating the write_domain on the object but before the object was placed on the active queue. So during the unwind process following the error, the now freed object attempts to flush its non-existent, but outstanding, GPU writes causing this use-after-free. [drm:i915_dispatch_gem_execbuffer] *ERROR* alignment [drm:i915_gem_execbuffer] *ERROR* dispatch failed -22 WARNING: at lib/kref.c:43 warn_slowpath_null+0x10/0x15() Modules linked in: Pid: 4552, comm: lt-csi-drm Not tainted 2.6.30-rc6 #423 Call Trace: [<c0119ef3>] warn_slowpath_fmt+0x57/0x6d [<c014de24>] ? get_pageblock_migratetype+0x18/0x1e [<c014e8fd>] ? free_hot_page+0xa/0xc [<c014e915>] ? __free_pages+0x16/0x1f [<c0153ebf>] ? shmem_truncate_range+0x63e/0x656 [<c015fb2f>] ? slob_page_alloc+0x146/0x1c8 [<c0119f19>] warn_slowpath_null+0x10/0x15 [<c01f55f2>] kref_get+0x1b/0x21 [<c02605db>] i915_gem_object_move_to_active+0x1f/0x56 [<c0261302>] i915_add_request+0x156/0x19a [<c026136e>] i915_gem_object_flush_gpu_write_domain+0x28/0x3f [<c0261eca>] i915_gem_object_unbind+0x4a/0x124 [<c0261fd7>] i915_gem_free_object+0x33/0x9b [<c0250d6b>] drm_gem_object_free+0x28/0x4a [<c0250d43>] ? drm_gem_object_free+0x0/0x4a [<c01f55ce>] kref_put+0x38/0x41 [<c0250cbf>] drm_gem_object_unreference+0x11/0x13 [<c0250d06>] drm_gem_object_handle_unreference+0x1e/0x21 [<c0250d13>] drm_gem_object_release_handle+0xa/0xe [<c01f3e6b>] idr_for_each+0x5f/0x98 [<c0250d09>] ? drm_gem_object_release_handle+0x0/0xe [<c0250daf>] drm_gem_release+0x22/0x34 [<c025046f>] drm_release+0x1e8/0x3c4 [<c0162d25>] __fput+0xaf/0x146 [<c0162dce>] fput+0x12/0x14 [<c01605ef>] filp_close+0x48/0x52 [<c011b182>] put_files_struct+0x57/0x9b [<c011b1e4>] exit_files+0x1e/0x20 [<c011c6b6>] do_exit+0x16d/0x511 [<c03704ab>] ? __schedule+0x3d4/0x3e5 [<c0103f0d>] ? handle_irq+0xd/0x69 [<c011caa7>] do_group_exit+0x4d/0x73 [<c011cae0>] sys_exit_group+0x13/0x17 [<c010268c>] sysenter_do_call+0x12/0x2b Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NEric Anholt <eric@anholt.net>
-