Commit Graph

27 Commits

Author SHA1 Message Date
Dave Airlie
eb1f8e4f3b 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>
2010-05-18 17:40:11 +10:00
Dave Airlie
5c4426a782 drm/kms/fb: add polling support for when nothing is connected.
When we are running in a headless environment we have no idea what
output the user might plug in later, we only have hotplug detect
from the digital outputs. So if we detect no connected outputs at
initialisation, start a slow work operation to poll every 5 seconds
for an output.

this is only hooked up for radeon so far, on hw where we have full
hotplug detection there is no need for this.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-04-07 10:29:52 +10:00
Dave Airlie
f71d018798 drm/radeon/kms: move radeon KMS on/off switch out of staging.
We are happy enough that the KMS driver is stable enough for enough people
for the kms enable/disable to leave staging. Distros can now contemplate
turning this on.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2010-02-01 11:35:47 +10:00
Chris Wilson
ca9ab10033 drm/i915: Select CONFIG_SHMEM
The driver requires shmfs as the backing filesystem to handle the buffer
objects, so ensure it is selected if the user chooses to build our
driver.

Fixes: Bug 14662 - Dell E5500 kernel panic with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=14662

The revealing nature of the panic is the NULL function pointer
dereference in read_cache_page_async().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-and-tested-by: Mateusz Kaduk <mateusz.kaduk@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Cc: stable@kernel.org
2009-11-25 12:27:42 -08:00
Jesse Barnes
c1c7af6089 drm/i915: force mode set at lid open time
Some laptop platforms will disable pipes and/or planes at lid close time
and not restore them when the lid is opened again.  So catch the lid
event, and if the lid was opened, force a mode restore.

Fixes fdo bug #21230.

Acked-by: Matthew Garrett <mjg@redhat.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
2009-09-10 16:10:00 -07:00
Dave Airlie
a0cdc6495b drm/kms/radeon: make kms default a runtime option
This makes the kms/enable disable a runtime not a build time
option.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08 11:15:59 +10:00
Dave Airlie
6fcefd56f5 drm/kms: fix kms helper license + Kconfig
Allow the KMS module to work properly, and also rename
it to KMS_HELPER so its clearer what its for.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-08 11:15:58 +10:00
Dave Airlie
13a8195b14 drm: split crtc/fb helpers into a separate module
I really don't want to have core drm module rely on CONFIG_FB,
so this is the easiest answer.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-09-07 15:45:33 +10:00
Ben Hutchings
70967ab9c0 radeon: Use request_firmware()
Loosely based on a patch by
Jaswinder Singh Rajput <jaswinderlinux@gmail.com>.

KMS support by Dave Airlie <airlied@redhat.com>.

For Radeon 100- to 500-series, firmware blobs look like:
    struct {
        __be32 datah;
        __be32 datal;
    } cp_ucode[256];

For Radeon 600-series, there are two separate firmware blobs:
    __be32 me_ucode[PM4_UCODE_SIZE * 3];
    __be32 pfp_ucode[PFP_UCODE_SIZE];

For Radeon 700-series, likewise:
    __be32 me_ucode[R700_PM4_UCODE_SIZE];
    __be32 pfp_ucode[R700_PFP_UCODE_SIZE];

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-08-31 09:09:30 +10:00
Ben Hutchings
52f97df5da drm/r128: Use request_firmware() to load CCE microcode
Firmware blob looks like this:
    __be32 datah
    __be32 datal

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-08-27 10:47:00 +10:00
Ben Hutchings
ece2be7993 drm/mga: Use request_firmware() to load microcode
Image format is IHEX, one record for each pipe in order (record
addresses are ignored).

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-08-27 10:46:54 +10:00
Eric Anholt
8c52da503b drm/i915: Add missing dependency on Intel AGP support.
Users could accidentally enable AGP but not the Intel AGP support, and get
a DRM that doesn't probe as a result.

Bug #22358.

Signed-off-by: Eric Anholt <eric@anholt.net>
2009-06-21 22:13:38 -07:00
Jerome Glisse
771fe6b912 drm/radeon: introduce kernel modesetting for radeon hardware
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: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-15 12:01:53 +10:00
Thomas Hellstrom
ba4e7d973d drm: Add the TTM GPU memory manager subsystem.
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: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-15 09:37:57 +10:00
Len Brown
31db5645bd ACPI, i915: build fix (v2)
drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

v2: move under DRM_I915 from DRM_I915_KMS

Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
2009-05-29 21:26:38 -04:00
Len Brown
4e3507f718 Merge branches 'release', 'bugzilla-13032', 'bugzilla-13041+', 'bugzilla-13121', 'bugzilla-13165', 'bugzilla-13243', 'bugzilla-13259', 'resume-sci-en-regression', 'thermal-regression', 'tsc-regression' and 'asus-2.6.30' into release 2009-05-16 01:55:59 -04:00
Len Brown
ecb4aed78d ACPI, i915: build fix
drivers/built-in.o: In function `intel_opregion_init':
(.text+0x9d540): undefined reference to `acpi_video_register'

http://bugzilla.kernel.org/show_bug.cgi?id=13165

Signed-off-by: Len Brown <len.brown@intel.com>
2009-05-15 22:52:21 -04:00
Jesse Barnes
f29ce72795 drm/i915: automatically select FRAMEBUFFER_CONSOLE if !EMBEDDED
People keep getting bitten by this, so just auto-select it by default,
assuming most configurations will actually want a console.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
2009-05-12 09:08:31 -07:00
Krzysztof Helt
a1a5c3b923 fbdev/drm: fix Kconfig submenu mess in "Graphics support"
Submenus of the graphics support "Support for frame buffer devices" and
"Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)" are
broken in half after latest changes for Intel 915 mode setting support.

The DRM subsection is broken because one option is put outside the choice
section it depends on.

The frame buffers part is broken then due to circular dependency.  Fix
this by make Intel frame buffers depend on CONFIG_INTEL_AGP.

Kconfigs are broken by d2f5935770
("drm/i915: select framebuffer support automatically").

This is probably not only way to fix this.

Signed-off-by: Krzysztof Helt <krzysztof.h1@wp.pl>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-02-18 15:37:56 -08:00
Ingo Molnar
d2f5935770 drm/i915: select framebuffer support automatically
Migration helper.

The i915 driver recently added a 'depends on FB' rule to its
Kconfig entry - which silently turns off DRM_I915 if someone
has a working config but no CONFIG_FB selected, and upgrades
to the latest upstream kernel.

Norbert Preining reported this problem:

   Bug-Entry   : http://bugzilla.kernel.org/show_bug.cgi?id=12599
   Subject     : dri /dev node disappeared with 2.6.29-rc1

So change it to "select FB", which auto-selects framebuffer
support. This way the driver keeps working, regardless of
whether FB was enabled before or not.

Kconfig select's of interactive options can be problematic to
dependencies and can cause build breakages - but in this case
it's safe because it's a leaf entry with no dependencies of its
own.

( There is some minor circular dependency fallout as FB_I810
  and FB_INTEL also used 'depends on FB' constructs - update
  those to "select FB" too. )

Reported-by: Norbert Preining <preining@logic.at>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-02-08 21:53:05 +10:00
Dave Airlie
57a6297e52 drm: kconfig have drm core select i2c for kms
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29 17:47:24 +10:00
Eric Anholt
06d9f33ceb drm/i915: Register module dependencies for the modesetting code.
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29 17:47:23 +10:00
Jesse Barnes
79e539453b DRM: i915: add mode setting support
This commit adds i915 driver support for the DRM mode setting APIs.
Currently, VGA, LVDS, SDVO DVI & VGA, TV and DVO LVDS outputs are
supported.  HDMI, DisplayPort and additional SDVO output support will
follow.

Support for the mode setting code is controlled by the new 'modeset'
module option.  A new config option, CONFIG_DRM_I915_KMS controls the
default behavior, and whether a PCI ID list is built into the module for
use by user level module utilities.

Note that if mode setting is enabled, user level drivers that access
display registers directly or that don't use the kernel graphics memory
manager will likely corrupt kernel graphics memory, disrupt output
configuration (possibly leading to hangs and/or blank displays), and
prevent panic/oops messages from appearing.  So use caution when
enabling this code; be sure your user level code supports the new
interfaces.

A new SysRq key, 'g', provides emergency support for switching back to
the kernel's framebuffer console; which is useful for testing.

Co-authors: Dave Airlie <airlied@linux.ie>, Hong Liu <hong.liu@intel.com>

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29 17:47:23 +10:00
Hugh Dickins
e798ba57e9 Export tiny shmem_file_setup for DRM-GEM
We're trying to keep the !CONFIG_SHMEM tiny-shmem.c (using ramfs without
swap) in synch with CONFIG_SHMEM shmem.c (and mpm is preparing patches
to combine them).  I was glad to see EXPORT_SYMBOL_GPL(shmem_file_setup)
go into shmem.c, but why not support DRM-GEM when !CONFIG_SHMEM too?
But caution says still depend on MMU, since !CONFIG_MMU is.. different.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Acked-by: Matt Mackall <mpm@selenic.com>
Acked-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-10-20 16:17:42 -07:00
Dave Airlie
9e0b97e37f drm: make CONFIG_DRM depend on CONFIG_SHMEM.
This can be removed later when DRM doesn't depend on shmem.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-10-18 07:10:54 +10:00
Adrian Bunk
dfcf96d09c FB_SIS=m, DRM_SIS=y is not a legal configuration.
Reported-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-10-18 07:10:11 +10:00
Dave Airlie
c0e09200dc drm: reorganise drm tree to be more future proof.
With the coming of kernel based modesetting and the memory manager stuff,
the everything in one directory approach was getting very ugly and
starting to be unmanageable.

This restructures the drm along the lines of other kernel components.

It creates a drivers/gpu/drm directory and moves the hw drivers into
subdirectores. It moves the includes into an include/drm, and
sets up the unifdef for the userspace headers we should be exporting.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-07-14 10:45:01 +10:00