Commit fffddfd6 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

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

Pull drm merge from Dave Airlie:
 "Highlights:

   - TI LCD controller KMS driver

   - TI OMAP KMS driver merged from staging

   - drop gma500 stub driver

   - the fbcon locking fixes

   - the vgacon dirty like zebra fix.

   - open firmware videomode and hdmi common code helpers

   - major locking rework for kms object handling - pageflip/cursor
     won't block on polling anymore!

   - fbcon helper and prime helper cleanups

   - i915: all over the map, haswell power well enhancements, valleyview
     macro horrors cleaned up, killing lots of legacy GTT code,

   - radeon: CS ioctl unification, deprecated UMS support, gpu reset
     rework, VM fixes

   - nouveau: reworked thermal code, external dp/tmds encoder support
     (anx9805), fences sleep instead of polling,

   - exynos: all over the driver fixes."

Lovely conflict in radeon/evergreen_cs.c between commit de0babd6
("drm/radeon: enforce use of radeon_get_ib_value when reading user cmd")
and the new changes that modified that evergreen_dma_cs_parse()
function.

* 'drm-next' of git://people.freedesktop.org/~airlied/linux: (508 commits)
  drm/tilcdc: only build on arm
  drm/i915: Revert hdmi HDP pin checks
  drm/tegra: Add list of framebuffers to debugfs
  drm/tegra: Fix color expansion
  drm/tegra: Split DC_CMD_STATE_CONTROL register write
  drm/tegra: Implement page-flipping support
  drm/tegra: Implement VBLANK support
  drm/tegra: Implement .mode_set_base()
  drm/tegra: Add plane support
  drm/tegra: Remove bogus tegra_framebuffer structure
  drm: Add consistency check for page-flipping
  drm/radeon: Use generic HDMI infoframe helpers
  drm/tegra: Use generic HDMI infoframe helpers
  drm: Add EDID helper documentation
  drm: Add HDMI infoframe helpers
  video: Add generic HDMI infoframe helpers
  drm: Add some missing forward declarations
  drm: Move mode tables to drm_edid.c
  drm: Remove duplicate drm_mode_cea_vic()
  gma500: Fix n, m1 and m2 clock limits for sdvo and lvds
  ...
parents 69086a78 be88298b

Documentation/DocBook/drm.tmpl

+64 −14
Original line number Diff line number Diff line
@@ -743,6 +743,10 @@ char *date;</synopsis> 
          These two operations are mandatory for GEM drivers that support DRM

          PRIME.

        </para>

        <sect4>

          <title>DRM PRIME Helper Functions Reference</title>

!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers

        </sect4>

      </sect3>

      <sect3 id="drm-gem-objects-mapping">

        <title>GEM Objects Mapping</title>
@@ -978,10 +982,25 @@ int max_width, max_height;</synopsis> 
        If the parameters are deemed valid, drivers then create, initialize and

        return an instance of struct <structname>drm_framebuffer</structname>.

        If desired the instance can be embedded in a larger driver-specific

        structure. The new instance is initialized with a call to

        <function>drm_framebuffer_init</function> which takes a pointer to DRM

        frame buffer operations (struct

        <structname>drm_framebuffer_funcs</structname>). Frame buffer operations are

	structure. Drivers must fill its <structfield>width</structfield>,

	<structfield>height</structfield>, <structfield>pitches</structfield>,

        <structfield>offsets</structfield>, <structfield>depth</structfield>,

        <structfield>bits_per_pixel</structfield> and

        <structfield>pixel_format</structfield> fields from the values passed

        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They

        should call the <function>drm_helper_mode_fill_fb_struct</function>

        helper function to do so.

      </para>



      <para>

	The initailization of the new framebuffer instance is finalized with a

	call to <function>drm_framebuffer_init</function> which takes a pointer

	to DRM frame buffer operations (struct

	<structname>drm_framebuffer_funcs</structname>). Note that this function

	publishes the framebuffer and so from this point on it can be accessed

	concurrently from other threads. Hence it must be the last step in the

	driver's framebuffer initialization sequence. Frame buffer operations

	are

        <itemizedlist>

          <listitem>

            <synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis> 
        </itemizedlist>

      </para>

      <para>

        After initializing the <structname>drm_framebuffer</structname>

        instance drivers must fill its <structfield>width</structfield>,

        <structfield>height</structfield>, <structfield>pitches</structfield>,

        <structfield>offsets</structfield>, <structfield>depth</structfield>,

        <structfield>bits_per_pixel</structfield> and

        <structfield>pixel_format</structfield> fields from the values passed

        through the <parameter>drm_mode_fb_cmd2</parameter> argument. They

        should call the <function>drm_helper_mode_fill_fb_struct</function>

        helper function to do so.

      </para>

	The lifetime of a drm framebuffer is controlled with a reference count,

	drivers can grab additional references with

	<function>drm_framebuffer_reference</function> </para> and drop them

	again with <function>drm_framebuffer_unreference</function>. For

	driver-private framebuffers for which the last reference is never

	dropped (e.g. for the fbdev framebuffer when the struct

	<structname>drm_framebuffer</structname> is embedded into the fbdev

	helper struct) drivers can manually clean up a framebuffer at module

	unload time with

	<function>drm_framebuffer_unregister_private</function>.

    </sect2>

    <sect2>

      <title>Output Polling</title>
@@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis> 
        operation.

      </para>

    </sect2>

    <sect2>

      <title>Locking</title>

      <para>

        Beside some lookup structures with their own locking (which is hidden

	behind the interface functions) most of the modeset state is protected

	by the <code>dev-&lt;mode_config.lock</code> mutex and additionally

	per-crtc locks to allow cursor updates, pageflips and similar operations

	to occur concurrently with background tasks like output detection.

	Operations which cross domains like a full modeset always grab all

	locks. Drivers there need to protect resources shared between crtcs with

	additional locking. They also need to be careful to always grab the

	relevant crtc locks if a modset functions touches crtc state, e.g. for

	load detection (which does only grab the <code>mode_config.lock</code>

	to allow concurrent screen updates on live crtcs).

      </para>

    </sect2>

  </sect1>



  <!-- Internals: kms initialization and cleanup -->
@@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis> 
            without waiting for rendering or page flip to complete and must block

            any new rendering to the frame buffer until the page flip completes.

          </para>

          <para>

            If a page flip can be successfully scheduled the driver must set the

            <code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to

            by <code>fb</code>. This is important so that the reference counting

            on framebuffers stays balanced.

          </para>

          <para>

            If a page flip is already pending, the

            <methodname>page_flip</methodname> operation must return
@@ -1609,6 +1650,10 @@ void intel_crt_init(struct drm_device *dev) 
        make its properties available to applications.

      </para>

    </sect2>

    <sect2>

      <title>KMS API Functions</title>

!Edrivers/gpu/drm/drm_crtc.c

    </sect2>

  </sect1>



  <!-- Internals: kms helper functions -->
@@ -2104,6 +2149,7 @@ void intel_crt_init(struct drm_device *dev) 
      <title>fbdev Helper Functions Reference</title>

!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers

!Edrivers/gpu/drm/drm_fb_helper.c

!Iinclude/drm/drm_fb_helper.h

    </sect2>

    <sect2>

      <title>Display Port Helper Functions Reference</title>
@@ -2111,6 +2157,10 @@ void intel_crt_init(struct drm_device *dev) 
!Iinclude/drm/drm_dp_helper.h

!Edrivers/gpu/drm/drm_dp_helper.c

    </sect2>

    <sect2>

      <title>EDID Helper Functions Reference</title>

!Edrivers/gpu/drm/drm_edid.c

    </sect2>

  </sect1>



  <!-- Internals: vertical blanking -->

Documentation/EDID/HOWTO.txt

+23 −4
Original line number Diff line number Diff line
@@ -28,11 +28,30 @@ Makefile environment are given here. 
To create binary EDID and C source code files from the existing data

material, simply type "make".



If you want to create your own EDID file, copy the file 1024x768.S and

replace the settings with your own data. The CRC value in the last line

If you want to create your own EDID file, copy the file 1024x768.S,

replace the settings with your own data and add a new target to the

Makefile. Please note that the EDID data structure expects the timing

values in a different way as compared to the standard X11 format.



X11:

HTimings:  hdisp hsyncstart hsyncend htotal

VTimings:  vdisp vsyncstart vsyncend vtotal



EDID:

#define XPIX hdisp

#define XBLANK htotal-hdisp

#define XOFFSET hsyncstart-hdisp

#define XPULSE hsyncend-hsyncstart



#define YPIX vdisp

#define YBLANK vtotal-vdisp

#define YOFFSET (63+(vsyncstart-vdisp))

#define YPULSE (63+(vsyncend-vsyncstart))



The CRC value in the last line

  #define CRC 0x55

is a bit tricky. After a first version of the binary data set is

created, it must be be checked with the "edid-decode" utility which will

also is a bit tricky. After a first version of the binary data set is

created, it must be checked with the "edid-decode" utility which will

most probably complain about a wrong CRC. Fortunately, the utility also

displays the correct CRC which must then be inserted into the source

file. After the make procedure is repeated, the EDID data set is ready

Documentation/devicetree/bindings/drm/tilcdc/panel.txt

0 → 100644
+59 −0
Original line number Diff line number Diff line 
Device-Tree bindings for tilcdc DRM generic panel output driver



Required properties:

 - compatible: value should be "ti,tilcdc,panel".

 - panel-info: configuration info to configure LCDC correctly for the panel

   - ac-bias: AC Bias Pin Frequency

   - ac-bias-intrpt: AC Bias Pin Transitions per Interrupt

   - dma-burst-sz: DMA burst size

   - bpp: Bits per pixel

   - fdd: FIFO DMA Request Delay

   - sync-edge: Horizontal and Vertical Sync Edge: 0=rising 1=falling

   - sync-ctrl: Horizontal and Vertical Sync: Control: 0=ignore

   - raster-order: Raster Data Order Select: 1=Most-to-least 0=Least-to-most

   - fifo-th: DMA FIFO threshold

 - display-timings: typical videomode of lcd panel.  Multiple video modes

   can be listed if the panel supports multiple timings, but the 'native-mode'

   should be the preferred/default resolution.  Refer to

   Documentation/devicetree/bindings/video/display-timing.txt for display

   timing binding details.



Recommended properties:

 - pinctrl-names, pinctrl-0: the pincontrol settings to configure

   muxing properly for pins that connect to TFP410 device



Example:



	/* Settings for CDTech_S035Q01 / LCD3 cape: */

	lcd3 {

		compatible = "ti,tilcdc,panel";

		pinctrl-names = "default";

		pinctrl-0 = <&bone_lcd3_cape_lcd_pins>;

		panel-info {

			ac-bias           = <255>;

			ac-bias-intrpt    = <0>;

			dma-burst-sz      = <16>;

			bpp               = <16>;

			fdd               = <0x80>;

			sync-edge         = <0>;

			sync-ctrl         = <1>;

			raster-order      = <0>;

			fifo-th           = <0>;

		};

		display-timings {

			native-mode = <&timing0>;

			timing0: 320x240 {

				hactive         = <320>;

				vactive         = <240>;

				hback-porch     = <21>;

				hfront-porch    = <58>;

				hsync-len       = <47>;

				vback-porch     = <11>;

				vfront-porch    = <23>;

				vsync-len       = <2>;

				clock-frequency = <8000000>;

				hsync-active    = <0>;

				vsync-active    = <0>;

			};

		};

	};

Documentation/devicetree/bindings/drm/tilcdc/slave.txt

0 → 100644
+18 −0
Original line number Diff line number Diff line 
Device-Tree bindings for tilcdc DRM encoder slave output driver



Required properties:

 - compatible: value should be "ti,tilcdc,slave".

 - i2c: the phandle for the i2c device the encoder slave is connected to



Recommended properties:

 - pinctrl-names, pinctrl-0: the pincontrol settings to configure

   muxing properly for pins that connect to TFP410 device



Example:



	hdmi {

		compatible = "ti,tilcdc,slave";

		i2c = <&i2c0>;

		pinctrl-names = "default";

		pinctrl-0 = <&nxp_hdmi_bonelt_pins>;

	};

Documentation/devicetree/bindings/drm/tilcdc/tfp410.txt

0 → 100644
+21 −0
Original line number Diff line number Diff line 
Device-Tree bindings for tilcdc DRM TFP410 output driver



Required properties:

 - compatible: value should be "ti,tilcdc,tfp410".

 - i2c: the phandle for the i2c device to use for DDC



Recommended properties:

 - pinctrl-names, pinctrl-0: the pincontrol settings to configure

   muxing properly for pins that connect to TFP410 device

 - powerdn-gpio: the powerdown GPIO, pulled low to power down the

   TFP410 device (for DPMS_OFF)



Example:



	dvicape {

		compatible = "ti,tilcdc,tfp410";

		i2c = <&i2c2>;

		pinctrl-names = "default";

		pinctrl-0 = <&bone_dvi_cape_dvi_00A1_pins>;

		powerdn-gpio = <&gpio2 31 0>;

	};

CRA Git | Maintained and supported by SUSTech CRA and CCSE