Some PowerMac firmwares set up a tiling surface at the beginning of VRAM
which messes us up otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

Might lure userspace into trying silly things otherwise.
Signed-off-by: NMichel Dänzer <daenzer@vmware.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

smem.start is a physical address which kernel can remap to access
video memory of the fb buffer. We now pin the fb buffer into vram
by doing so we are loosing vram but fbdev need to be reworked to
allow change in framebuffer address.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@linux.ie>

In theory now that the AGP subsystem is using struct page, we should
have on problems enabling GEM on PAE systems.
Signed-off-by: NDave Airlie <airlied@redhat.com>

just remove i variable left over from previous code.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This switches AGP to use an array of pages for tracking the
pages allocated to the GART. This should enable GEM on PAE to work
a lot better as we can pass highmem pages to the PAT code and it will
do the right thing with them.
Signed-off-by: NDave Airlie <airlied@redhat.com>

For security purpose we want to make sure the userspace process doesn't
access memory beyond buffer it owns. To achieve this we need to check
states the userspace program. For color buffer and zbuffer we check that
the clipping register will discard access beyond buffers set as color
or zbuffer. For vertex buffer we check that no vertex fetch will happen
beyond buffer end. For texture we check various texture states (number
of mipmap level, texture size, texture depth, ...) to compute the amount
of memory the texture fetcher might access.

The command stream checking impact the performances so far quick benchmark
shows an average of 3% decrease in fps of various applications. It can
be optimized a bit more by caching result of checking and thus avoid a
full recheck if no states changed since last check.

Note that this patch is still incomplete on checking side as it doesn't
check 2d rendering states.
Signed-off-by: NJerome Glisse <jglisse@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This makes the panel on my PowerBook light up.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Optimise the powerpc flushing path for TTM.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NDave Airlie <airlied@redhat.com>

Some AGP devices can't map the aperture, radeon needs to tell TTM this.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Mostly replacing bitfields with explicit masks and shifts.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Its quite valid to have VRAM < aperture size.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Just a goto instead of a direct exit.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

also for the atomic path by using a common code-path.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A bug caused the ttm code to just terminate the wait when a signal
was received while waiting for the GPU to release a buffer object that
was to be evicted.
Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

It hasn't been used in ages, and having the user tell your how much
memory is being freed at free time is a recipe for disaster even if it
was ever used.
Signed-off-by: NEric Anholt <eric@anholt.net>

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>

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>

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>

Signed-Off-By: NBen Gamari <bgamari.foss@gmail.com>
Signed-off-by: NEric Anholt <eric@anholt.net>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

This adds the PCI IDs for the rv790 which are equiv to the rv770.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds drm support for the RV740 family of chips to the r600 support code.
Signed-off-by: NDave Airlie <airlied@redhat.com>

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>

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>

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>

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>