Okay we have crtc, encoder and connectors.
No more outputs exposed beyond driver internals
I've broken intel tv connector stuff.
Really for TV we should have one TV connector, with a sub property for the
type of signal been driven over it
Use subclassing from the drivers to allocate the objects. This saves
two objects being allocated for each crtc/output and generally makes
exit paths cleaner.
This splits a lot of the core modesetting code out into a file of
helper functions, that are only called from themselves and/or the driver.
The driver gets called into more often or can call these functions from itself
if it is a helper using driver.
I've broken framebuffer resize doing this but I didn't like the API for that
in any case.
TV out needs to do load detection, which means we have to find an
available pipe to use for the detection. Port over the pipe reservation
code for this purpose.
This patch ties outputs, output properties and hotplug events into the
DRM core. Each output has a corresponding directory under the primary
DRM device (usually card0) containing dpms, edid, modes, and connection
status files.
New hotplug change events occur when outputs are added or hotplug events
are detected.
Allow mode to be set with fb_id set to -1, meaning set
the mode with the current fb (if we have one bound).
Allow intelfb to hook back up it's fb if modesetting
clears it (maybe temporary).
Move any crtc->fb related register changes to set_base
in intel_fb.
General intelfb cleanups.
This allow the user to retrieve a list of properties for an output.
Properties can either be 32-bit values or an enum with an associated name.
Range properties are to be supported.
This API is probably not all correct, I may make properties part of the general
resource get when I think about it some more.
So basically you can create properties and attached them to whatever outputs you want,
so it should be possible to create some generics and just attach them to every output.
This way driver can get_edid in output status detection
(using all workaround which are in get_edid) and then provide
this edid data in get_mode callback of output.
Conflicts:
linux-core/drmP.h
linux-core/drm_bo.c
linux-core/drm_drv.c
linux-core/drm_objects.h
shared-core/drm.h
shared-core/i915_dma.c
shared-core/i915_drv.h
shared-core/i915_irq.c
Mostly removing typedefs that snuck into the modesetting code and
updating to the latest TTM APIs. As of today, the i915 driver builds,
but there are likely to be problems, so debugging and bugfixes will
come next.
held across any operations that modify mode lists, crtc config, output
config, etc. It should be taken at high level entry points (currently just
initial config and user IOCTL).
Seems to work ok on my system, but needs more testing (with lockdep) and
review from some fresh eyes.
Dave Airlie
Jesse Barnes
Jakob Bornecrantz
Dave Airlie
Jesse Barnes
Alan Hourihane
Jesse Barnes
Jakob Bornecrantz
Jerome Glisse
Jesse Barnes
Jesse Barnes
Alan Hourihane