diff options
author | Dave Airlie <airlied@redhat.com> | 2015-12-19 04:45:31 +0300 |
---|---|---|
committer | Dave Airlie <airlied@redhat.com> | 2015-12-19 04:45:31 +0300 |
commit | 45ad5ccfa9c72da35905dab4603df0d0f383af8f (patch) | |
tree | dd226fc3d0d4e619bccd90e52ac6418730d8a684 /Documentation | |
parent | 544a14fd222b5dedfa32e9e69c0da9345b996e15 (diff) | |
parent | e112e593b215c394c0303dbf0534db0928e87967 (diff) | |
download | linux-45ad5ccfa9c72da35905dab4603df0d0f383af8f.tar.xz |
Merge tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel into drm-next
Seems I lied in my last drm-misc pull request and suddenly there's a big
pile of random stuff. Boris dug out Thierry's drm-trivial branch and
resubmitted everything since that branch didn't really work out.
On top of that Nicolas' changes to drm_dev_set_unique - this might
conflict with new driver pulls (I double checked and current drm-next
should be fine), so please beware. The -next/-fixes conflict in vmwgfx
will change slightly with this here too.
* tag 'topic/drm-misc-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (36 commits)
drm: use dev_name as default unique name in drm_dev_alloc()
drm: make drm_dev_set_unique() not use a format string
drm/vmwgfx: Constify function pointer structs
drm/udl: Constify function pointer structs
drm/tegra: Constify function pointer structs
drm/rockchip: Constify function pointer structs
drm/nouveau: Constify function pointer structs
drm/mgag200: Constify function pointer structs
drm/imx: Constify function pointer structs
drm/i2c/sil164: Constify function pointer structs
drm/i2c/adv7511: Constify function pointer structs
drm/exynos: Constify function pointer structs
drm/cirrus: Constify function pointer structs
drm/i2c/ch7006: Constify function pointer structs
drm/bridge/nxp-ptn3460: Constify function pointer structs
drm/bridge/dw_hdmi: Constify function pointer structs
drm/bochs: Constify function pointer structs
drm/atmel-hlcdc: Constify function pointer structs
drm/armada: Constify function pointer structs
drm: Constify drm_encoder_slave_funcs
...
Diffstat (limited to 'Documentation')
-rw-r--r-- | Documentation/DocBook/gpu.tmpl | 158 |
1 files changed, 1 insertions, 157 deletions
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl index c66d6412f573..6c6e81a9eaf4 100644 --- a/Documentation/DocBook/gpu.tmpl +++ b/Documentation/DocBook/gpu.tmpl @@ -986,10 +986,7 @@ int max_width, max_height;</synopsis> !Idrivers/gpu/drm/drm_atomic.c </sect2> <sect2> - <title>Frame Buffer Creation</title> - <synopsis>struct drm_framebuffer *(*fb_create)(struct drm_device *dev, - struct drm_file *file_priv, - struct drm_mode_fb_cmd2 *mode_cmd);</synopsis> + <title>Frame Buffer Abstraction</title> <para> Frame buffers are abstract memory objects that provide a source of pixels to scanout to a CRTC. Applications explicitly request the @@ -1008,73 +1005,6 @@ int max_width, max_height;</synopsis> and so expects TTM handles in the create ioctl and not GEM handles. </para> <para> - Drivers must first validate the requested frame buffer parameters passed - through the mode_cmd argument. In particular this is where invalid - sizes, pixel formats or pitches can be caught. - </para> - <para> - 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. 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 initialization 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, - struct drm_file *file_priv, unsigned int *handle);</synopsis> - <para> - Create a handle to the frame buffer underlying memory object. If - the frame buffer uses a multi-plane format, the handle will - reference the memory object associated with the first plane. - </para> - <para> - Drivers call <function>drm_gem_handle_create</function> to create - the handle. - </para> - </listitem> - <listitem> - <synopsis>void (*destroy)(struct drm_framebuffer *framebuffer);</synopsis> - <para> - Destroy the frame buffer object and frees all associated - resources. Drivers must call - <function>drm_framebuffer_cleanup</function> to free resources - allocated by the DRM core for the frame buffer object, and must - make sure to unreference all memory objects associated with the - frame buffer. Handles created by the - <methodname>create_handle</methodname> operation are released by - the DRM core. - </para> - </listitem> - <listitem> - <synopsis>int (*dirty)(struct drm_framebuffer *framebuffer, - struct drm_file *file_priv, unsigned flags, unsigned color, - struct drm_clip_rect *clips, unsigned num_clips);</synopsis> - <para> - This optional operation notifies the driver that a region of the - frame buffer has changed in response to a DRM_IOCTL_MODE_DIRTYFB - ioctl call. - </para> - </listitem> - </itemizedlist> - </para> - <para> The lifetime of a drm framebuffer is controlled with a reference count, drivers can grab additional references with <function>drm_framebuffer_reference</function>and drop them @@ -3570,92 +3500,6 @@ int num_ioctls;</synopsis> <sect2> <title>DPIO</title> !Pdrivers/gpu/drm/i915/i915_reg.h DPIO - <table id="dpiox2"> - <title>Dual channel PHY (VLV/CHV/BXT)</title> - <tgroup cols="8"> - <colspec colname="c0" /> - <colspec colname="c1" /> - <colspec colname="c2" /> - <colspec colname="c3" /> - <colspec colname="c4" /> - <colspec colname="c5" /> - <colspec colname="c6" /> - <colspec colname="c7" /> - <spanspec spanname="ch0" namest="c0" nameend="c3" /> - <spanspec spanname="ch1" namest="c4" nameend="c7" /> - <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> - <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> - <spanspec spanname="ch1pcs01" namest="c4" nameend="c5" /> - <spanspec spanname="ch1pcs23" namest="c6" nameend="c7" /> - <thead> - <row> - <entry spanname="ch0">CH0</entry> - <entry spanname="ch1">CH1</entry> - </row> - </thead> - <tbody valign="top" align="center"> - <row> - <entry spanname="ch0">CMN/PLL/REF</entry> - <entry spanname="ch1">CMN/PLL/REF</entry> - </row> - <row> - <entry spanname="ch0pcs01">PCS01</entry> - <entry spanname="ch0pcs23">PCS23</entry> - <entry spanname="ch1pcs01">PCS01</entry> - <entry spanname="ch1pcs23">PCS23</entry> - </row> - <row> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - </row> - <row> - <entry spanname="ch0">DDI0</entry> - <entry spanname="ch1">DDI1</entry> - </row> - </tbody> - </tgroup> - </table> - <table id="dpiox1"> - <title>Single channel PHY (CHV/BXT)</title> - <tgroup cols="4"> - <colspec colname="c0" /> - <colspec colname="c1" /> - <colspec colname="c2" /> - <colspec colname="c3" /> - <spanspec spanname="ch0" namest="c0" nameend="c3" /> - <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" /> - <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" /> - <thead> - <row> - <entry spanname="ch0">CH0</entry> - </row> - </thead> - <tbody valign="top" align="center"> - <row> - <entry spanname="ch0">CMN/PLL/REF</entry> - </row> - <row> - <entry spanname="ch0pcs01">PCS01</entry> - <entry spanname="ch0pcs23">PCS23</entry> - </row> - <row> - <entry>TX0</entry> - <entry>TX1</entry> - <entry>TX2</entry> - <entry>TX3</entry> - </row> - <row> - <entry spanname="ch0">DDI2</entry> - </row> - </tbody> - </tgroup> - </table> </sect2> <sect2> |