Merge branch 'topic/hdmi-jack' into for-next

          <function>drm_gem_object_init</function>. Storage for private GEM

          objects must be managed by drivers.

        </para>

        <para>

          Drivers that do not need to extend GEM objects with private information

          can call the <function>drm_gem_object_alloc</function> function to

          allocate and initialize a struct <structname>drm_gem_object</structname>

          instance. The GEM core will call the optional driver

          <methodname>gem_init_object</methodname> operation after initializing

          the GEM object with <function>drm_gem_object_init</function>.

          <synopsis>int (*gem_init_object) (struct drm_gem_object *obj);</synopsis>

        </para>

        <para>

          No alloc-and-init function exists for private GEM objects.

        </para>

      </sect3>

      <sect3>

        <title>GEM Objects Lifetime</title>

          acquired and release by <function>calling drm_gem_object_reference</function>

          and <function>drm_gem_object_unreference</function> respectively. The

          caller must hold the <structname>drm_device</structname>

          <structfield>struct_mutex</structfield> lock. As a convenience, GEM

          provides the <function>drm_gem_object_reference_unlocked</function> and

          <function>drm_gem_object_unreference_unlocked</function> functions that

          can be called without holding the lock.

	  <structfield>struct_mutex</structfield> lock when calling

	  <function>drm_gem_object_reference</function>. As a convenience, GEM

	  provides <function>drm_gem_object_unreference_unlocked</function>

	  functions that can be called without holding the lock.

        </para>

        <para>

          When the last reference to a GEM object is released the GEM core calls

        </para>

        <para>

          <synopsis>void (*gem_free_object) (struct drm_gem_object *obj);</synopsis>

          Drivers are responsible for freeing all GEM object resources, including

          the resources created by the GEM core. If an mmap offset has been

          created for the object (in which case

          <structname>drm_gem_object</structname>::<structfield>map_list</structfield>::<structfield>map</structfield>

          is not NULL) it must be freed by a call to

          <function>drm_gem_free_mmap_offset</function>. The shmfs backing store

          must be released by calling <function>drm_gem_object_release</function>

          (that function can safely be called if no shmfs backing store has been

          created).

          Drivers are responsible for freeing all GEM object resources. This includes

          the resources created by the GEM core, which need to be released with

          <function>drm_gem_object_release</function>.

        </para>

      </sect3>

      <sect3>

          DRM identifies the GEM object to be mapped by a fake offset passed

          through the mmap offset argument. Prior to being mapped, a GEM object

          must thus be associated with a fake offset. To do so, drivers must call

          <function>drm_gem_create_mmap_offset</function> on the object. The

          function allocates a fake offset range from a pool and stores the

          offset divided by PAGE_SIZE in

          <literal>obj-&gt;map_list.hash.key</literal>. Care must be taken not to

          call <function>drm_gem_create_mmap_offset</function> if a fake offset

          has already been allocated for the object. This can be tested by

          <literal>obj-&gt;map_list.map</literal> being non-NULL.

          <function>drm_gem_create_mmap_offset</function> on the object.

        </para>

        <para>

          Once allocated, the fake offset value

          (<literal>obj-&gt;map_list.hash.key &lt;&lt; PAGE_SHIFT</literal>)

          must be passed to the application in a driver-specific way and can then

          be used as the mmap offset argument.

        </para>

          abstracted from the client in libdrm.

        </para>

      </sect3>

      <sect3>

    </sect2>

    <sect2>

      <title>GEM Function Reference</title>

!Edrivers/gpu/drm/drm_gem.c

      </sect3>

!Iinclude/drm/drm_gem.h

    </sect2>

    <sect2>

      <title>VMA Offset Manager</title>

      </sect2>

    </sect1>

    <sect1>

      <title>GuC-based Command Submission</title>

      <sect2>

      <title>GuC</title>

      <sect2>

        <title>GuC-specific firmware loader</title>

!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader

!Idrivers/gpu/drm/i915/intel_guc_loader.c

      </sect2>

      <sect2>

        <title>GuC Client</title>

!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison

        <title>GuC-based command submission</title>

!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submission

!Idrivers/gpu/drm/i915/i915_guc_submission.c

      </sect2>

      <sect2>

        <title>GuC Firmware Layout</title>

!Pdrivers/gpu/drm/i915/intel_guc_fwif.h GuC Firmware Layout

      </sect2>

    </sect1>

    <sect1>

The device tree documentation for the keystone machines are located at

        Documentation/devicetree/bindings/arm/keystone/keystone.txt

Known issues & workaround

-------------------------

Some of the device drivers used on keystone are re-used from that from

DaVinci and other TI SoCs. These device drivers may use clock APIs directly.

Some of the keystone specific drivers such as netcp uses run time power

management API instead to enable clock. As this API has limitations on

keystone, following workaround is needed to boot Linux.

   Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise

   clock frameworks will try to disable clocks that are unused and disable

   the hardware. This is because netcp related power domain and clock

   domains are enabled in u-boot as run time power management API currently

   doesn't enable clocks for netcp due to a limitation. This workaround is

   expected to be removed in the future when proper API support becomes

   available. Until then, this work around is needed.

Document Author

---------------

Murali Karicheri <m-karicheri2@ti.com>

     parameter.

  1: The multi-queue block layer is instantiated with a hardware dispatch

     queue for each CPU node in the system.

use_lightnvm=[0/1]: Default: 0

  Register device with LightNVM. Requires blk-mq to be used.

- phy-mode: See ethernet.txt file in the same directory

- clocks: a pointer to the reference clock for this device.

Optional properties:

- tx-csum-limit: maximum mtu supported by port that allow TX checksum.

  Value is presented in bytes. If not used, by default 1600B is set for

  "marvell,armada-370-neta" and 9800B for others.

Example:

ethernet@d0070000 {

	reg = <0xd0070000 0x2500>;

	interrupts = <8>;

	clocks = <&gate_clk 4>;

	tx-csum-limit = <9800>

	status = "okay";

	phy = <&phy0>;

	phy-mode = "rgmii-id";

* Temperature Sensor ADC (TSADC) on rockchip SoCs

Required properties:

- compatible : "rockchip,rk3288-tsadc"

- compatible : should be "rockchip,<name>-tsadc"

   "rockchip,rk3288-tsadc": found on RK3288 SoCs

   "rockchip,rk3368-tsadc": found on RK3368 SoCs

- reg : physical base address of the controller and length of memory mapped

	region.

- interrupts : The interrupt number to the cpu. The interrupt specifier format