Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linux

              will become a fatal error.

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_USE_MTRR</term>

            <listitem><para>

              Driver uses MTRR interface for mapping memory, the DRM core will

              manage MTRR resources. Deprecated.

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_PCI_DMA</term>

            <listitem><para>

              support shared IRQs (note that this is required of PCI  drivers).

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_IRQ_VBL</term>

            <listitem><para>Unused. Deprecated.</para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_DMA_QUEUE</term>

            <listitem><para>

              Should be set if the driver queues DMA requests and completes them

              asynchronously.  Deprecated.

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_FB_DMA</term>

            <listitem><para>

              Driver supports DMA to/from the framebuffer, mapping of frambuffer

              DMA buffers to userspace will be supported. Deprecated.

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_IRQ_VBL2</term>

            <listitem><para>Unused. Deprecated.</para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_GEM</term>

            <listitem><para>

              Driver implements DRM PRIME buffer sharing.

            </para></listitem>

          </varlistentry>

          <varlistentry>

            <term>DRIVER_RENDER</term>

            <listitem><para>

              Driver supports dedicated render nodes.

            </para></listitem>

          </varlistentry>

        </variablelist>

      </sect3>

      <sect3>

!Iinclude/drm/drm_rect.h

!Edrivers/gpu/drm/drm_rect.c

    </sect2>

    <sect2>

      <title>Flip-work Helper Reference</title>

!Pinclude/drm/drm_flip_work.h flip utils

!Iinclude/drm/drm_flip_work.h

!Edrivers/gpu/drm/drm_flip_work.c

    </sect2>

    <sect2>

      <title>VMA Offset Manager</title>

!Pdrivers/gpu/drm/drm_vma_manager.c vma offset manager

!Edrivers/gpu/drm/drm_vma_manager.c

!Iinclude/drm/drm_vma_manager.h

    </sect2>

  </sect1>

  <!-- Internals: kms properties -->

      </abstract>

      <para>

        The <methodname>firstopen</methodname> method is called by the DRM core

	when an application opens a device that has no other opened file handle.

	Similarly the <methodname>lastclose</methodname> method is called when

	the last application holding a file handle opened on the device closes

	it. Both methods are mostly used for UMS (User Mode Setting) drivers to

	acquire and release device resources which should be done in the

	<methodname>load</methodname> and <methodname>unload</methodname>

	methods for KMS drivers.

	for legacy UMS (User Mode Setting) drivers only when an application

	opens a device that has no other opened file handle. UMS drivers can

	implement it to acquire device resources. KMS drivers can't use the

	method and must acquire resources in the <methodname>load</methodname>

	method instead.

      </para>

      <para>

        Note that the <methodname>lastclose</methodname> method is also called

	at module unload time or, for hot-pluggable devices, when the device is

	unplugged. The <methodname>firstopen</methodname> and

	Similarly the <methodname>lastclose</methodname> method is called when

	the last application holding a file handle opened on the device closes

	it, for both UMS and KMS drivers. Additionally, the method is also

	called at module unload time or, for hot-pluggable devices, when the

	device is unplugged. The <methodname>firstopen</methodname> and

	<methodname>lastclose</methodname> calls can thus be unbalanced.

      </para>

      <para>

      <para>

        The <methodname>lastclose</methodname> method should restore CRTC and

	plane properties to default value, so that a subsequent open of the

	device will not inherit state from the previous user.

	device will not inherit state from the previous user. It can also be

	used to execute delayed power switching state changes, e.g. in

	conjunction with the vga-switcheroo infrastructure. Beyond that KMS

	drivers should not do any further cleanup. Only legacy UMS drivers might

	need to clean up device state so that the vga console or an independent

	fbdev driver could take over.

      </para>

    </sect2>

    <sect2>

	<programlisting>

	.poll = drm_poll,

	.read = drm_read,

	.fasync = drm_fasync,

	.llseek = no_llseek,

	</programlisting>

      </para>

      info, since man pages should cover the rest.

    </para>

  <!-- External: render nodes -->

    <sect1>

      <title>Render nodes</title>

      <para>

        DRM core provides multiple character-devices for user-space to use.

        Depending on which device is opened, user-space can perform a different

        set of operations (mainly ioctls). The primary node is always created

        and called <term>card&lt;num&gt;</term>. Additionally, a currently

        unused control node, called <term>controlD&lt;num&gt;</term> is also

        created. The primary node provides all legacy operations and

        historically was the only interface used by userspace. With KMS, the

        control node was introduced. However, the planned KMS control interface

        has never been written and so the control node stays unused to date.

      </para>

      <para>

        With the increased use of offscreen renderers and GPGPU applications,

        clients no longer require running compositors or graphics servers to

        make use of a GPU. But the DRM API required unprivileged clients to

        authenticate to a DRM-Master prior to getting GPU access. To avoid this

        step and to grant clients GPU access without authenticating, render

        nodes were introduced. Render nodes solely serve render clients, that

        is, no modesetting or privileged ioctls can be issued on render nodes.

        Only non-global rendering commands are allowed. If a driver supports

        render nodes, it must advertise it via the <term>DRIVER_RENDER</term>

        DRM driver capability. If not supported, the primary node must be used

        for render clients together with the legacy drmAuth authentication

        procedure.

      </para>

      <para>

        If a driver advertises render node support, DRM core will create a

        separate render node called <term>renderD&lt;num&gt;</term>. There will

        be one render node per device. No ioctls except  PRIME-related ioctls

        will be allowed on this node. Especially <term>GEM_OPEN</term> will be

        explicitly prohibited. Render nodes are designed to avoid the

        buffer-leaks, which occur if clients guess the flink names or mmap

        offsets on the legacy interface. Additionally to this basic interface,

        drivers must mark their driver-dependent render-only ioctls as

        <term>DRM_RENDER_ALLOW</term> so render clients can use them. Driver

        authors must be careful not to allow any privileged ioctls on render

        nodes.

      </para>

      <para>

        With render nodes, user-space can now control access to the render node

        via basic file-system access-modes. A running graphics server which

        authenticates clients on the privileged primary/legacy node is no longer

        required. Instead, a client can open the render node and is immediately

        granted GPU access. Communication between clients (or servers) is done

        via PRIME. FLINK from render node to legacy node is not supported. New

        clients must not use the insecure FLINK interface.

      </para>

      <para>

        Besides dropping all modeset/global ioctls, render nodes also drop the

        DRM-Master concept. There is no reason to associate render clients with

        a DRM-Master as they are independent of any graphics server. Besides,

        they must work without any running master, anyway.

        Drivers must be able to run without a master object if they support

        render nodes. If, on the other hand, a driver requires shared state

        between clients which is visible to user-space and accessible beyond

        open-file boundaries, they cannot support render nodes.

      </para>

    </sect1>

  <!-- External: vblank handling -->

    <sect1>

* Samsung Image Rotator

Required properties:

  - compatible : value should be one of the following:

	(a) "samsung,exynos4210-rotator" for Rotator IP in Exynos4210

	(b) "samsung,exynos4212-rotator" for Rotator IP in Exynos4212/4412

	(c) "samsung,exynos5250-rotator" for Rotator IP in Exynos5250

  - reg : Physical base address of the IP registers and length of memory

	  mapped region.

  - interrupts : Interrupt specifier for rotator interrupt, according to format

		 specific to interrupt parent.

  - clocks : Clock specifier for rotator clock, according to generic clock

	     bindings. (See Documentation/devicetree/bindings/clock/exynos*.txt)

  - clock-names : Names of clocks. For exynos rotator, it should be "rotator".

Example:

	rotator@12810000 {

		compatible = "samsung,exynos4210-rotator";

		reg = <0x12810000 0x1000>;

		interrupts = <0 83 0>;

		clocks = <&clock 278>;

		clock-names = "rotator";

	};

#

menuconfig DRM

	tristate "Direct Rendering Manager (XFree86 4.1.0 and higher DRI support)"

	depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU

	depends on (AGP || AGP=n) && !EMULATED_CMPXCHG && MMU && HAS_DMA

	select HDMI

	select I2C

	select I2C_ALGOBIT

	  the driver to bind to PCI devices, which precludes loading things

	  like intelfb.

config DRM_I915_PRELIMINARY_HW_SUPPORT

	bool "Enable preliminary support for prerelease Intel hardware by default"

	depends on DRM_I915

	help

	  Choose this option if you have prerelease Intel hardware and want the

	  i915 driver to support it by default.  You can enable such support at

	  runtime with the module option i915.preliminary_hw_support=1; this

	  option changes the default for that module option.

	  If in doubt, say "N".

config DRM_MGA

	tristate "Matrox g200/g400"

	depends on DRM && PCI

source "drivers/gpu/drm/tilcdc/Kconfig"

source "drivers/gpu/drm/qxl/Kconfig"

source "drivers/gpu/drm/msm/Kconfig"

drm-y       :=	drm_auth.o drm_buffer.o drm_bufs.o drm_cache.o \

		drm_context.o drm_dma.o \

		drm_drv.o drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \

		drm_lock.o drm_memory.o drm_proc.o drm_stub.o drm_vm.o \

		drm_lock.o drm_memory.o drm_stub.o drm_vm.o \

		drm_agpsupport.o drm_scatter.o drm_pci.o \

		drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \

		drm_crtc.o drm_modes.o drm_edid.o \

		drm_info.o drm_debugfs.o drm_encoder_slave.o \

		drm_trace_points.o drm_global.o drm_prime.o \

		drm_rect.o

		drm_rect.o drm_vma_manager.o drm_flip_work.o

drm-$(CONFIG_COMPAT) += drm_ioc32.o

drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o

obj-$(CONFIG_DRM_OMAP)	+= omapdrm/

obj-$(CONFIG_DRM_TILCDC)	+= tilcdc/

obj-$(CONFIG_DRM_QXL) += qxl/

obj-$(CONFIG_DRM_MSM) += msm/

obj-y			+= i2c/

	.unlocked_ioctl = drm_ioctl,

	.mmap = ast_mmap,

	.poll = drm_poll,

	.fasync = drm_fasync,

#ifdef CONFIG_COMPAT

	.compat_ioctl = drm_compat_ioctl,

#endif

};

static struct drm_driver driver = {

	.driver_features = DRIVER_USE_MTRR | DRIVER_MODESET | DRIVER_GEM,

	.driver_features = DRIVER_MODESET | DRIVER_GEM,

	.dev_priv_size = 0,

	.load = ast_driver_load,

	.gem_free_object = ast_gem_free_object,

	.dumb_create = ast_dumb_create,

	.dumb_map_offset = ast_dumb_mmap_offset,

	.dumb_destroy = ast_dumb_destroy,

	.dumb_destroy = drm_gem_dumb_destroy,

};