drm/doc: Switch to sphinx/rst fixed-width quoting

Just fallout from switching from asciidoc to sphinx/rst.

v2: Found more. Also s/\//#/ in the vgpu ascii-art - sphinx treats
those as comments and switch to variable-width, which wreaks the
layout.

v3: Undo some of the hacks, rebasing onto latest version of Jani's
series fixed it.

Acked-by: Liviu Dudau <Liviu.Dudau@arm.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
This commit is contained in:
Daniel Vetter 2016-05-31 22:55:13 +02:00
parent 00edbe196d
commit da5335b8bd
9 changed files with 24 additions and 18 deletions

View File

@ -36,7 +36,7 @@
* encoder chain.
*
* A bridge is always attached to a single &drm_encoder at a time, but can be
* either connected to it directly, or through an intermediate bridge:
* either connected to it directly, or through an intermediate bridge::
*
* encoder ---> bridge B ---> bridge A
*

View File

@ -52,7 +52,7 @@ struct drm_fbdev_cma {
* will be set up automatically. dirty() is called by
* drm_fb_helper_deferred_io() in process context (struct delayed_work).
*
* Example fbdev deferred io code:
* Example fbdev deferred io code::
*
* static int driver_fbdev_fb_dirty(struct drm_framebuffer *fb,
* struct drm_file *file_priv,

View File

@ -67,7 +67,7 @@ DEFINE_MUTEX(drm_global_mutex);
* specific implementations. For GEM-based drivers this is drm_gem_mmap().
*
* No other file operations are supported by the DRM userspace API. Overall the
* following is an example #file_operations structure:
* following is an example #file_operations structure::
*
* static const example_drm_fops = {
* .owner = THIS_MODULE,

View File

@ -553,7 +553,8 @@ EXPORT_SYMBOL(drm_gtf_mode_complex);
* I also refer to the function of fb_get_mode in the file of
* drivers/video/fbmon.c
*
* Standard GTF parameters:
* Standard GTF parameters::
*
* M = 600
* C = 40
* K = 128

View File

@ -37,7 +37,7 @@
*
* For basic principles of &ww_mutex, see: Documentation/locking/ww-mutex-design.txt
*
* The basic usage pattern is to:
* The basic usage pattern is to::
*
* drm_modeset_acquire_init(&ctx)
* retry:

View File

@ -127,6 +127,9 @@ EXPORT_SYMBOL(drm_vma_offset_manager_destroy);
* used to implement weakly referenced lookups using kref_get_unless_zero().
*
* Example:
*
* ::
*
* drm_vma_offset_lock_lookup(mgr);
* node = drm_vma_offset_lookup_locked(mgr);
* if (node)

View File

@ -886,7 +886,7 @@ enum skl_disp_power_wells {
* PLLs can be routed to any transcoder A/B/C.
*
* Note: DDI0 is digital port B, DD1 is digital port C, and DDI2 is
* digital port D (CHV) or port A (BXT).
* digital port D (CHV) or port A (BXT). ::
*
*
* Dual channel PHY (VLV/CHV/BXT)

View File

@ -150,28 +150,28 @@ static int vgt_balloon_space(struct drm_mm *mm,
* of its graphic space being zero. Yet there are some portions ballooned out(
* the shadow part, which are marked as reserved by drm allocator). From the
* host point of view, the graphic address space is partitioned by multiple
* vGPUs in different VMs.
* vGPUs in different VMs. ::
*
* vGPU1 view Host view
* 0 ------> +-----------+ +-----------+
* ^ |///////////| | vGPU3 |
* | |///////////| +-----------+
* | |///////////| | vGPU2 |
* ^ |###########| | vGPU3 |
* | |###########| +-----------+
* | |###########| | vGPU2 |
* | +-----------+ +-----------+
* mappable GM | available | ==> | vGPU1 |
* | +-----------+ +-----------+
* | |///////////| | |
* v |///////////| | Host |
* | |###########| | |
* v |###########| | Host |
* +=======+===========+ +===========+
* ^ |///////////| | vGPU3 |
* | |///////////| +-----------+
* | |///////////| | vGPU2 |
* ^ |###########| | vGPU3 |
* | |###########| +-----------+
* | |###########| | vGPU2 |
* | +-----------+ +-----------+
* unmappable GM | available | ==> | vGPU1 |
* | +-----------+ +-----------+
* | |///////////| | |
* | |///////////| | Host |
* v |///////////| | |
* | |###########| | |
* | |###########| | Host |
* v |###########| | |
* total GM size ------> +-----------+ +-----------+
*
* Returns:

View File

@ -169,6 +169,8 @@ enum drm_mode_status {
*
* The horizontal and vertical timings are defined per the following diagram.
*
* ::
*
*
* Active Front Sync Back
* Region Porch Porch