Radeon UMS is the last user of drm_buffer. Move it out of sight so radeon
can drop it together with UMS.
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NThierry Reding <treding@nvidia.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Everyone agrees we should do this,
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDavid Herrmann <dh.herrmann@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

All that is left in drm_drv.c is ioctl management. Merge it into
drm_ioctl.c so we have all ioctl management in one file (and the name is
much more fitting).

Maybe we should now rename drm_stub.c to drm_drv.c again?
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>

Video Time Generator drivers are used to synchronize the compositor
and tvout hardware IPs by providing line count, sample count,
synchronization signals (HSYNC, VSYNC) and top and bottom fields
indication.
VTG are used by pair for each data path (main or auxiliary)
one for master and one for slave.
Signed-off-by: NBenjamin Gaignard <benjamin.gaignard@linaro.org>
Reviewed-by: NRob Clark <robdclark@gmail.com>

Add a helper to allow encoders to find their possible CRTCs from the
OF graph without having to re-implement this functionality.  We add a
device_node to drm_crtc which corresponds with the port node in the
DT description of the CRTC device.

We can then scan the DRM device list for CRTCs to find their index,
matching the appropriate CRTC using the port device_node, thus building
up the possible CRTC mask.
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

This is the initial import of the helper for displayport multistream.

It consists of a topology manager, init/destroy/set mst state

It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs

connector detect and edid retrieval interface.

It supports i2c device over DP 1.2 sideband msg protocol (EDID reads only)

bandwidth manager API via vcpi allocation and payload updating,
along with a helper to check the ACT status.

Objects:
MST topology manager - one per toplevel MST capable GPU port - not sure if this should be higher level again
MST branch unit - one instance per plugged branching unit - one at top of hierarchy - others hanging from ports
MST port - one port per port reported by branching units, can have MST units hanging from them as well.

Changes since initial posting:
a) add a mutex responsbile for the queues, it locks the sideband and msg slots, and msgs to transmit state
b) add worker to handle connection state change events, for MST device chaining and hotplug
c) add a payload spinlock
d) add path sideband msg support
e) fixup enum path resources transmit
f) reduce max dpcd msg to 16, as per DP1.2 spec.
g) separate tx queue kicking from irq processing and move irq acking back to drivers.

Changes since v0.2:
a) reorganise code,
b) drop ACT forcing code
c) add connector naming interface using path property
d) add topology dumper helper
e) proper reference counting and lookup for ports and mstbs.
f) move tx kicking into a workq
g) add aux locking - this should be redone
h) split teardown into two parts
i) start working on documentation on interface.

Changes since v0.3:
a) vc payload locking and tracking fixes
b) add hotplug callback into driver - replaces crazy return 1 scheme
c) txmsg + mst branch device refcount fixes
d) don't bail on mst shutdown if device is gone
e) change irq handler to take all 4 bytes of SINK_COUNT + ESI vectors
f) make DP payload updates timeout longer - observed on docking station redock
g) add more info to debugfs dumper

Changes since v0.4:
a) suspend/resume support
b) more debugging in debugfs

Changes since v0.5:
a) use byte * to avoid unnecessary stack usage
b) fix num_sdp_streams interpretation.
c) init payload state for unplug events
d) remove lenovo dock sink count hack
e) drop aux lock - post rebase
f) call hotplug on port destroy

TODO:
misc features
Reviewed-by: NTodd Previte <tprevite@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

For atomic, it will be quite necessary to not need to care so much
about locking order.  And 'state' gives us a convenient place to stash a
ww_ctx for any sort of update that needs to grab multiple crtc locks.

Because we will want to eventually make locking even more fine grained
(giving locks to planes, connectors, etc), split out drm_modeset_lock
and drm_modeset_acquire_ctx to track acquired locks.

Atomic will use this to keep track of which locks have been acquired
in a transaction.

v1: original
v2: remove a few things not needed until atomic, for now
v3: update for v3 of connection_mutex patch..
v4: squash in docbook
v5: doc tweaks/fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

The drm core shouldn't depend upon any helpers, and we make sure this
doesn't accidentally happen by moving them into the helper-only
drm_kms_helper.ko module.

v2: Don't break the build for vmwgfx, spotted by Matt.

v3: Unbreak the depency loop around CONFIG_FB (not actually a loop
since it involves select). Reported by Chris.

Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is leftover stuff from my previous doc round which I kinda wanted
to do but didn't yet due to rebase hell.

The modeset helpers and the probing helpers a independent and e.g.
i915 uses the probing stuff but has its own modeset infrastructure. It
hence makes to split this up. While at it add a DOC: comment for the
probing libraray.

It would be rather neat to pull some of the DocBook documenting these
two helpers into in-line DOC: comments. But unfortunately kerneldoc
doesn't support markdown or something similar to make nice-looking
documentation, so the current state is better.
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

When we expose non-overlay planes to userspace, they will become
accessible via standard userspace plane API's.  We should be able to
handle the standard plane operations against primary planes in a generic
way via the modeset handler.

Drivers that can program primary planes more efficiently, that want to
use their own primary plane structure to track additional information,
or that don't have the limitations assumed by the helpers are free to
provide their own implementation of some or all of these handlers.

v3: Tweak kerneldoc formatting slightly to avoid ugliness
v2:
 - Move plane helpers to a new file (drm_plane_helper.c)
 - Tighten checks on update handler (check for scaling, CRTC coverage,
   subpixel positioning)
 - Pass proper panning parameters to modeset interface
 - Disallow disabling primary plane (and thus CRTC) if other planes are
   still active on the CRTC.
 - Use a minimal format list that should work on all hardware/drivers.
   Drivers may call this function with a more accurate plane list to
   enable additional formats they can support.
Signed-off-by: NMatt Roper <matthew.d.roper@intel.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>

This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: NSean Paul <seanpaul@chromium.org>
Signed-off-by: NInki Dae <inki.dae@samsung.com>

DRM driver for (virtual) vga cards using the bochs dispi
interface, such as the qemu standard vga (qemu -vga std).

Don't bother supporting anything but 32bpp for now, even
though the virtual hardware is able to do that.

Known issue: mmap(/dev/fb0) doesn't work.
Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Add a driver for simple panels. Such panels can have a regulator that
provides the supply voltage and a separate GPIO to enable the panel.
Optionally the panels can have a backlight associated with them so it
can be enabled or disabled according to the panel's power management
mode.

Support is added for two panels: An AU Optronics 10.1" WSVGA and a
Chunghwa Picture Tubes 10.1" WXGA panel.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add a very simple framework to register and lookup panels. Panel drivers
can initialize a DRM panel and register it with the framework, allowing
them to be retrieved and used by display drivers. Currently only support
for DPMS and obtaining panel modes is provided. However it should be
sufficient to enable a large number of panels. The framework should also
be easily extensible to support more sophisticated kinds of panels such
as DSI.

The framework hasn't been tied into the DRM core, even though it should
be easily possible to do so if that's what we want. In the current
implementation, display drivers can simple make use of it to retrieve a
panel, obtain its modes and control its DPMS mode.

Note that this is currently only tested on systems that boot from a
device tree. No glue code has been written yet for systems that use
platform data, but it should be easy to add.
Signed-off-by: NThierry Reding <treding@nvidia.com>

MIPI DSI bus allows to model DSI hosts and DSI peripherals using the
Linux driver model. DSI hosts are registered by the DSI host drivers.
During registration DSI peripherals will be created from the children
of the DSI host's device tree node. Support for registration from
board-setup code will be added later when needed.

DSI hosts expose operations which can be used by DSI peripheral drivers
to access associated devices.
Signed-off-by: NAndrzej Hajda <a.hajda@samsung.com>
Signed-off-by: NKyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

In order to make subsystem-wide changes easier, move the Tegra DRM
driver back into the DRM tree.
Signed-off-by: NThierry Reding <treding@nvidia.com>

This patch adds support for the pair of LCD controllers on the Marvell
Armada 510 SoCs.  This driver supports:
- multiple contiguous scanout buffers for video and graphics
- shm backed cacheable buffer objects for X pixmaps for Vivante GPU
  acceleration
- dual lcd0 and lcd1 crt operation
- video overlay on each LCD crt via DRM planes
- page flipping of the main scanout buffers
- DRM prime for buffer export/import

This driver is trivial to extend to other Armada SoCs.

Included in this commit is the core driver with no output support; output
support is platform and encoder driver dependent.
Tested-by: NSebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

For drivers which might want to disable fbdev legacy support.

Select the new option in all drivers for now, so this shouldn't result
in any change. Drivers need some work anyway to make fbdev support
optional (if they have it implemented, that is), so the recommended
way to expose this is by adding per-driver options. At least as long
as most drivers don't support disabling the fbdev support.

v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm
driver can already take advantage of this, which allows us to build
msm without any fbdev depencies in the kernel!

v3: Move the MODULE_* stuff from the fbdev helper file to
drm_crtc_helper.c.

Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
Reviewed-by: NRob Clark <robdclark@gmail.com>
Acked-by: NDave Airlie <airlied@linux.ie>
Reviewed-by: NChon Ming Lee <chon.ming.lee@intel.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The snapdragon chips have multiple different display controllers,
depending on which chip variant/version.  (As far as I can tell, current
devices have either MDP3 or MDP4, and upcoming devices have MDSS.)  And
then external to the display controller are HDMI, DSI, etc. blocks which
may be shared across devices which have different display controller
blocks.

To more easily add support for different display controller blocks, the
display controller specific bits are split out into a "kms" module,
which provides the kms plane/crtc/encoder objects.

The external HDMI, DSI, etc. blocks are part encoder, and part connector
currently.  But I think I will pull in the drm_bridge patches from
chromeos tree, and split them into a bridge+connector, with the
registers that need to be set in modeset handled by the bridge.  This
would remove the 'msm_connector' base class.  But some things need to be
double checked to make sure I could get the correct ON/OFF sequencing..

This patch adds support for mdp4 crtc (including hw cursor), dtv encoder
(part of MDP4 block), and hdmi.
Signed-off-by: NRob Clark <robdclark@gmail.com>

So almost two years ago I've tried to nuke the procfs code already
once before:

http://lists.freedesktop.org/archives/dri-devel/2011-October/015707.html

The conclusion was that userspace drivers (specifically libdrm device
node detection) stopped relying on procfs in 2001. But after some
digging it turned out that the drmstat tool in libdrm is still using
those files (but only when certain options are set). So we've decided
to keep profcs.

But I when I've started to dig around again what exactly this tool
does I've noticed that it tries to read the "mem", "vm", and "vma"
files from procfs. Now as far my git history digging shows "mem" never
did anything useful (at least in the version that first showed up in
upstream history in 2004) and the file was remove in

commit 955b12de
Author: Ben Gamari <bgamari@gmail.com>
Date:   Tue Feb 17 20:08:49 2009 -0500

    drm: Convert proc files to seq_file and introduce debugfs

Which means that for over 4 years drmstat has been broken, and no one
cared. In my opinion that's proof enough that no one is actually using
drmstat, and so that we can savely nuke the procfs support from drm.

While at it fix up the error case cleanup for debugfs in drm_get_minor.

v2: Fix dates, libdrm stopped relying on procfs for drm node detection
in 2001.

v3: fixup compilation warning for !CONFIG_DEBUG_FS, reported by
Fengguang Wu.

Cc: kbuild test robot <fengguang.wu@intel.com>
Cc: Dave Airlie <airlied@linux.ie>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A small helper to queue up work to do, from workqueue context, after a
flip.  Typically useful to defer unreffing buffers that may be read by
the display controller until vblank.

v1: original
v2: wire up docbook + couple docbook fixes
Signed-off-by: NRob Clark <robdclark@gmail.com>
Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@redhat.com>

If we want to map GPU memory into user-space, we need to linearize the
addresses to not confuse mm-core. Currently, GEM and TTM both implement
their own offset-managers to assign a pgoff to each object for user-space
CPU access. GEM uses a hash-table, TTM uses an rbtree.

This patch provides a unified implementation that can be used to replace
both. TTM allows partial mmaps with a given offset, so we cannot use
hashtables as the start address may not be known at mmap time. Hence, we
use the rbtree-implementation of TTM.

We could easily update drm_mm to use an rbtree instead of a linked list
for it's object list and thus drop the rbtree from the vma-manager.
However, this would slow down drm_mm object allocation for all other
use-cases (rbtree insertion) and add another 4-8 bytes to each mm node.
Hence, use the separate tree but allow for later migration.

This is a rewrite of the 2012-proposal by David Airlie <airlied@linux.ie>

v2:
 - fix Docbook integration
 - drop drm_mm_node_linked() and use drm_mm_node_allocated()
 - remove unjustified likely/unlikely usage (but keep for rbtree paths)
 - remove BUG_ON() as drm_mm already does that
 - clarify page-based vs. byte-based addresses
 - use drm_vma_node_reset() for initialization, too
v4:
 - allow external locking via drm_vma_offset_un/lock_lookup()
 - add locked lookup helper drm_vma_offset_lookup_locked()
v5:
 - fix drm_vma_offset_lookup() to correctly validate range-mismatches
   (fix (offset > start + pages))
 - fix drm_vma_offset_exact_lookup() to actually do what it says
 - remove redundant vm_pages member (add drm_vma_node_size() helper)
 - remove unneeded goto
 - fix documentation
Signed-off-by: NDavid Herrmann <dh.herrmann@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: NDave Airlie <airlied@gmail.com>

The R-Car Display Unit (DU) DRM driver supports both superposition
processors and all eight planes in RGB and YUV formats with alpha
blending.

Only VGA and LVDS encoders and connectors are currently supported.
Signed-off-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

struct drm_rect represents a simple rectangle. The utility
functions are there to help driver writers.

v2: Moved the region stuff into its own file, made the smaller funcs
    static inline, used 64bit maths in the scaled clipping function to
    avoid overflows (instead it will saturate to INT_MIN or INT_MAX).
v3: Renamed drm_region to drm_rect, drm_region_clip to
    drm_rect_intersect, and drm_region_subsample to drm_rect_downscale.
v4: Renamed some function parameters, improve kernel-doc comments a bit,
    and actually generate documentation for drm_rect.[ch].
v5: s/RETUTRNS/RETURNS/
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

Make drm part of host1x driver.
Signed-off-by: NArto Merilainen <amerilainen@nvidia.com>
Signed-off-by: NTerje Bergstrom <tbergstrom@nvidia.com>
Reviewed-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NErik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>

QXL is a paravirtual graphics device used by the Spice virtual desktop
interface.

The drivers uses GEM and TTM to manage memory, the qxl hw fencing however
is quite different than normal TTM expects, we have to keep track of a number
of non-linear fence ids per bo that we need to have released by the hardware.

The releases are freed from a workqueue that wakes up and processes the
release ring.

releases are suballocated from a BO, there are 3 release categories, drawables,
surfaces and cursor cmds. The hw also has 3 rings for commands, cursor and release handling.

The hardware also have a surface id tracking mechnaism and the driver encapsulates it completely inside the kernel, userspace never sees the actual hw surface
ids.

This requires a newer version of the QXL userspace driver, so shouldn't be
enabled until that has been placed into your distro of choice.

Authors: Dave Airlie, Alon Levy

v1.1: fixup some issues in the ioctl interface with padding
v1.2: add module device table
v1.3: fix nomodeset, fbcon leak, dumb bo create, release ring irq,
      don't try flush release ring (broken hw), fix -modesetting.
v1.4: fbcon cpu usage reduction + suitable accel flags.
Signed-off-by: NAlon Levy <alevy@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

A simple DRM/KMS driver for the TI LCD Controller found in various
smaller TI parts (AM33xx, OMAPL138, etc).  This driver uses the
CMA helpers.  Currently only the TFP410 DVI encoder is supported
(tested with beaglebone + DVI cape).  There are also various LCD
displays, for which support can be added (as I get hw to test on),
and an external i2c HDMI encoder found on some boards.

The display controller supports a single CRTC.  And the encoder+
connector are split out into sub-devices.  Depending on which LCD
or external encoder is actually present, the appropriate output
module(s) will be loaded.

v1: original
v2: fix fb refcnting and few other cleanups
v3: get +/- vsync/hsync from timings rather than panel-info, add
    option DT max-bandwidth field so driver doesn't attempt to
    pick a display mode with too high memory bandwidth, and other
    small cleanups
v4: remove some unneeded stuff from panel-info struct, properly
    set high bits for hfp/hsw/hbp for rev 2, add DT bindings docs
Signed-off-by: NRob Clark <robdclark@gmail.com>
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: NKoen Kooi <koen@dominion.thruhere.net>

Now that the omapdss interface has been reworked so that omapdrm can use
dispc directly, we have been able to fix the remaining functional kms
issues with omapdrm.  And in the mean time the PM sequencing and many
other of that open issues have been solved.  So I think it makes sense
to finally move omapdrm out of staging.
Signed-off-by: NRob Clark <robdclark@gmail.com>

Prevent ati_pcigart.c being built unless PCI is enabled. The exported
functions in this file are only used by drivers which depend on PCI
(namely r128 and radeon), and it tries to use PCI specific functions
(pci_unmap_page, pci_map_page, and pci_dma_mapping_error) that cause
compiler errors when PCI is disabled.
Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This commit adds a KMS driver for the Tegra20 SoC. This includes basic
support for host1x and the two display controllers found on the Tegra20
SoC. Each display controller can drive a separate RGB/LVDS output.
Signed-off-by: NThierry Reding <thierry.reding@avionic-design.de>
Tested-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NMark Zhang <markz@nvidia.com>
Reviewed-by: NMark Zhang <markz@nvidia.com>
Tested-by: NMark Zhang <markz@nvidia.com>
Tested-and-acked-by: NAlexandre Courbot <acourbot@nvidia.com>
Acked-by: NTerje Bergstrom <tbergstrom@nvidia.com>
Tested-by: NTerje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

I want to move some dp link training helpers into this place, so in
the future this won't be just about i2c any longer.
Reviewed-by: NAlex Deucher <alexander.deucher@amd.com>
Acked-by: NDave Airlie <airlied@gmail.com>
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>

The SH Mobile LCD controller (LCDC) DRM driver supports the main
graphics plane in RGB and YUV formats, as well as the overlay planes (in
alpha-blending mode only).

Only flat panel outputs using the parallel interface are supported.
Support for SYS panels, HDMI and DSI is currently not implemented.
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: NSascha Hauer <s.hauer@pengutronix.de>

This patchset introduces a set of helper function for implementing the KMS
framebuffer layer for drivers which use the DRM GEM CMA helper function.
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Tested-by: NSascha Hauer <s.hauer@pengutronix.de>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
[Make DRM_KMS_CMA_HELPER a boolean Kconfig option]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

Many embedded drm devices do not have a IOMMU and no dedicated
memory for graphics. These devices use CMA (Contiguous Memory
Allocator) backed graphics memory. This patch provides helper
functions to be able to share the code. The code technically does
not depend on CMA as the backend allocator, the name has been chosen
because CMA makes for a nice, short but still descriptive function
prefix.
Signed-off-by: NSascha Hauer <s.hauer@pengutronix.de>
Tested-by: NLars-Peter Clausen <lars@metafoo.de>
[Make DRM_GEM_CMA_HELPER a boolean Kconfig option]
Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>

This is the initial driver for emulated cirrus GPU found in qemu.
This driver only supports the emulated GPU and doesn't attempt
to bind to any real cirrus GPUs.

This driver is intended to be used with xf86-video-modesetting in userspace.
It requires at least version 0.3.0

This follow the same design as ast and mgag200, and is based on work
done by Matthew Garrett previously.

This GPU has no hw cursor, and it can't scanout 32-bpp, only packed 24-bpp.
i.e. it sucks.
Reviewed-by: NAdam Jackson <ajax@redhat.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is a driver for the G200 server engines chips,
it doesn't driver any of the Matrix G series desktop cards.

It will bind to G200 SE A,B, G200EV, G200WB, G200EH and G200ER cards.

Its based on previous work done my Matthew Garrett but remodelled
to follow the same style and flow as the AST server driver. It also
works along the same lines as the AST server driver wrt memory management.

There is no userspace driver planned, xf86-video-modesetting should be used.
It also appears these GPUs have no ARGB hw cursors.

v2: add missing tagfifo reset + G200 SE memory bw setup pieces.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This is the initial driver for the Aspeed Technologies chips found in
servers. This driver supports the AST 2000, 2100, 2200, 2150 and 2300. It
doesn't support the AST11xx due to lack of hw to test it on, and them requiring
different codepaths.

This driver is intended to be used with xf86-video-modesetting in userspace.

This driver has a slightly different design than other KMS drivers, but
future server chips will probably share similiar setup. As these GPUs commonly
have low video RAM, it doesn't make sense to put the kms console in VRAM
always. This driver places the kms console into system RAM, and does dirty
updates to a copy in video RAM. When userspace sets a new scanout buffer,
it forcefully evicts the video RAM console, and X can create a framebuffer
that can use all of of video RAM.

This driver uses TTM but in a very simple fashion to control the eviction
to system RAM of the console, and multiple servers.

v2: add s/r support, fix Kconfig.
Signed-off-by: NDave Airlie <airlied@redhat.com>

This adds the basic drm dma-buf interface layer, called PRIME. This
commit doesn't add any driver support, it is simply and agreed upon starting
point so we can work towards merging driver support for the next merge window.

Current drivers with work done are nouveau, i915, udl, exynos and omap.

The main APIs exposed to userspace allow translating a 32-bit object handle
to a file descriptor, and a file descriptor to a 32-bit object handle.

The flags value is currently limited to O_CLOEXEC.

Acknowledgements:
Daniel Vetter: lots of review
Rob Clark: cleaned up lots of the internals and did lifetime review.

v2: rename some functions after Chris preferred a green shed
fix IS_ERR_OR_NULL -> IS_ERR
v3: Fix Ville pointed out using buffer + kmalloc
v4: add locking as per ickle review
v5: allow re-exporting the original dma-buf (Daniel)
Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: NRob Clark <rob.clark@linaro.org>
Reviewed-by: NSumit Semwal <sumit.semwal@linaro.org>
Reviewed-by: NInki Dae <inki.dae@samsung.com>
Acked-by: NBen Widawsky <benjamin.widawsky@intel.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Broken monitors and/or broken graphic boards may send erroneous or no
EDID data. This also applies to broken KVM devices that are unable to
correctly forward the EDID data of the connected monitor but invent
their own fantasy data.

This patch allows to specify an EDID data set to be used instead of
probing the monitor for it. It contains built-in data sets of frequently
used screen resolutions. In addition, a particular EDID data set may be
provided in the /lib/firmware directory and loaded via the firmware
interface. The name is passed to the kernel as module parameter of the
drm_kms_helper module either when loaded
  options drm_kms_helper edid_firmware=edid/1280x1024.bin
or as kernel commandline parameter
  drm_kms_helper.edid_firmware=edid/1280x1024.bin

It is also possible to restrict the usage of a specified EDID data set
to a particular connector. This is done by prepending the name of the
connector to the name of the EDID data set using the syntax
  edid_firmware=[<connector>:]<edid>
such as, for example,
  edid_firmware=DVI-I-1:edid/1920x1080.bin
in which case no other connector will be affected.

The built-in data sets are
Resolution    Name
--------------------------------
1024x768      edid/1024x768.bin
1280x1024     edid/1280x1024.bin
1680x1050     edid/1680x1050.bin
1920x1080     edid/1920x1080.bin

They are ignored, if a file with the same name is available in the
/lib/firmware directory.

The built-in EDID data sets are based on standard timings that may not
apply to a particular monitor and even crash it. Ideally, EDID data of
the connected monitor should be used. They may be obtained through the
drm/cardX/cardX-<connector>/edid entry in the /sys/devices PCI directory
of a correctly working graphics adapter.

It is even possible to specify the name of an EDID data set on-the-fly
via the /sys/module interface, e.g.
echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware
The new screen mode is considered when the related kernel function is
called for the first time after the change. Such calls are made when the
X server is started or when the display settings dialog is opened in an
already running X server.
Signed-off-by: NCarsten Emde <C.Emde@osadl.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In order to satisfy all the various Kconfig options between
USB and DRM, we need to split the USB code out into a separate module
and export symbols to it.

This fixes build problems in -next reported by sfr.
Signed-off-by: NDave Airlie <airlied@redhat.com>