Граф коммитов

10 Коммитов

Автор SHA1 Сообщение Дата
Keith Packard c9fb15f60e drm: Hook up DPMS property handling in drm_crtc.c. Add drm_helper_connector_dpms.
Making the drm_crtc.c code recognize the DPMS property and invoke the
connector->dpms function doesn't remove any capability from the driver while
reducing code duplication.

That just highlighted the problem with the existing DPMS functions which
could turn off the connector, but failed to turn off any relevant crtcs. The
new drm_helper_connector_dpms function manages all of that, using the
drm_helper-specific crtc and encoder dpms functions, automatically computing
the appropriate DPMS level for each object in the system.

This fixes the current troubles in the i915 driver which left PLLs, pipes
and planes running while in DPMS_OFF mode or even while they were unused.

Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-06-04 09:32:12 +10:00
Ma Ling f23c20c83d drm: detect hdmi monitor by hdmi identifier (v3)
Sometime we need to communicate with HDMI monitor by sending audio or video
info frame, so we have to know monitor type. However if user utilize HDMI-DVI adapter to connect DVI monitor, hardware detection will incorrectly show the monitor is HDMI. HDMI spec tell us that any device containing IEEE registration Identifier will be treated as HDMI device.  The patch intends to detect HDMI monitor by this rule.

Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-03-29 18:31:49 +10:00
Ma Ling 167f3a04d7 drm: read EDID extensions from monitor
Usually drm read basic EDID, that is enough for us, but since igital display
were introduced i.e. HDMI monitor, sometime we need to interact with monitor by
EDID extension information,

EDID extensions include audio/video data block, speaker allocation and vendor specific data blocks.

This patch intends to read EDID extensions from digital monitor for users.

Signed-off-by: Ma Ling <ling.ma@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-03-29 18:31:41 +10:00
Benjamin Herrenschmidt d883f7f1b7 drm: Use resource_size_t for drm_get_resource_{start, len}
The DRM uses its own wrappers to obtain resources from PCI devices,
which currently convert the resource_size_t into an unsigned long.

This is broken on 32-bit platforms with >32-bit physical address
space.

This fixes them, along with a few occurences of unsigned long used
to store such a resource in drivers.

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-03-13 14:23:56 +10:00
Kristian Høgsberg ea39f83516 drm: Release user fbs in drm_release
Avoids leaking fbs and associated buffers on release.

Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Tested-by: Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-02-20 12:21:11 +10:00
Jesse Barnes ad2563c2e4 drm: create mode_config idr lock
Create a separate mode_config IDR lock for simplicity.  The core DRM
config structures (connector, mode, etc. lists) are still protected by
the mode_config mutex, but the CRTC IDR (used for the various identifier
IDs) is now protected by the mode_config idr_mutex.  Simplifies the
locking a bit and removes a warning.

All objects are protected by the config mutex, we may in the future,
split the object further to have reference counts.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2009-01-22 17:53:05 +10:00
Jesse Barnes 40a518d9f1 drm: initial KMS config fixes
When mode setting is first initialized, the driver will call into
drm_helper_initial_config() to set up an initial output and framebuffer
configuration.  This routine is responsible for probing the available
connectors, encoders, and crtcs, looking for modes and putting together
something reasonable (where reasonable is defined as "allows kernel
messages to be visible on as many displays as possible").

However, the code was a bit too aggressive in setting default modes when
none were found on a given connector.  Even if some connectors had modes,
any connectors found lacking modes would have the default 800x600 mode added
to their mode list, which in some cases could cause problems later down the
line.  In my case, the LVDS was perfectly available, but the initial config
code added 800x600 modes to both of the detected but unavailable HDMI
connectors (which are on my non-existent docking station).  This ended up
preventing later code from setting a mode on my LVDS, which is bad.

This patch fixes that behavior by making the initial config code walk
through the connectors first, counting the available modes, before it decides
to add any default modes to a possibly connected output.  It also fixes the
logic in drm_target_preferred() that was causing zeroed out modes to be set
as the preferred mode for a given connector, even if no modes were available.

Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Dave Airlie <airlied@linux.ie>
2009-01-16 18:40:54 +10:00
Kristian H�gsberg 0c7c266475 drm: drop DRM_IOCTL_MODE_REPLACEFB, add+remove works just as well.
The replace fb ioctl replaces the backing buffer object for a modesetting
framebuffer object.  This can be acheived by just creating a new
framebuffer backed by the new buffer object, setting that for the crtcs
in question and then removing the old framebuffer object.

Signed-off-by: Kristian Hogsberg <krh@redhat.com>
Acked-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29 17:47:25 +10:00
Jakob Bornecrantz e0c8463a8b drm: sanitise drm modesetting API + remove unused hotplug
The initially merged modesetting API has some uglies in it, this
cleans up the struct members and ioctl ordering for initial submission.

It also removes the unneeded hotplug infrastructure.

airlied:- I've pulled this patch in from git modesetting-gem tree.

Signed-off-by: Dave Airlie <airlied@redhat.com>
2008-12-29 17:47:25 +10:00
Dave Airlie f453ba0460 DRM: add mode setting support
Add mode setting support to the DRM layer.

This is a fairly big chunk of work that allows DRM drivers to provide
full output control and configuration capabilities to userspace.  It was
motivated by several factors:
  - the fb layer's APIs aren't suited for anything but simple
    configurations
  - coordination between the fb layer, DRM layer, and various userspace
    drivers is poor to non-existent (radeonfb excepted)
  - user level mode setting drivers makes displaying panic & oops
    messages more difficult
  - suspend/resume of graphics state is possible in many more
    configurations with kernel level support

This commit just adds the core DRM part of the mode setting APIs.
Driver specific commits using these new structure and APIs will follow.

Co-authors: Jesse Barnes <jbarnes@virtuousgeek.org>, Jakob Bornecrantz <jakob@tungstengraphics.com>
Contributors: Alan Hourihane <alanh@tungstengraphics.com>, Maarten Maathuis <madman2003@gmail.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