doc-rst: dev-subdev: fix some format issues

The conversion from DocBook made somethings look ugly.
Improve them.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

Documentation/linux_tv/media/v4l/dev-subdev.rst

@@ -118,14 +118,14 @@ every point in the pipeline explicitly.
 Drivers that implement the :ref:`media API <media-controller-intro>`
 can expose pad-level image format configuration to applications. When
 they do, applications can use the
-:ref:`VIDIOC_SUBDEV_G_FMT` and
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
 :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls. to
 negotiate formats on a per-pad basis.
 
 Applications are responsible for configuring coherent parameters on the
 whole pipeline and making sure that connected pads have compatible
 formats. The pipeline is checked for formats mismatch at
-:ref:`VIDIOC_STREAMON` time, and an ``EPIPE`` error
+:ref:`VIDIOC_STREAMON <VIDIOC_STREAMON>` time, and an ``EPIPE`` error
 code is then returned if the configuration is invalid.
 
 Pad-level image format configuration support can be tested by calling
@@ -145,8 +145,8 @@ formats enumeration only. A format negotiation mechanism is required.
 
 Central to the format negotiation mechanism are the get/set format
 operations. When called with the ``which`` argument set to
-``V4L2_SUBDEV_FORMAT_TRY``, the
-:ref:`VIDIOC_SUBDEV_G_FMT` and
+:ref:`V4L2_SUBDEV_FORMAT_TRY <VIDIOC_SUBDEV_G_FMT>`, the
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` and
 :ref:`VIDIOC_SUBDEV_S_FMT <VIDIOC_SUBDEV_G_FMT>` ioctls operate on
 a set of formats parameters that are not connected to the hardware
 configuration. Modifying those 'try' formats leaves the device state
@@ -155,7 +155,7 @@ and the hardware state stored in the device itself).
 
 While not kept as part of the device state, try formats are stored in
 the sub-device file handles. A
-:ref:`VIDIOC_SUBDEV_G_FMT` call will return
+:ref:`VIDIOC_SUBDEV_G_FMT <VIDIOC_SUBDEV_G_FMT>` call will return
 the last try format set *on the same sub-device file handle*. Several
 applications querying the same sub-device at the same time will thus not
 interact with each other.
@@ -443,7 +443,7 @@ selection will refer to the sink pad format dimensions instead.
     :alt:    subdev-image-processing-crop.svg
     :align:  center
 
-    Image processing in subdevs: simple crop example
+    **Figure 4.5. Image processing in subdevs: simple crop example**
 
 In the above example, the subdev supports cropping on its sink pad. To
 configure it, the user sets the media bus format on the subdev's sink
@@ -460,7 +460,7 @@ pad.
     :alt:    subdev-image-processing-scaling-multi-source.svg
     :align:  center
 
-    Image processing in subdevs: scaling with multiple sources
+    **Figure 4.6. Image processing in subdevs: scaling with multiple sources**
 
 In this example, the subdev is capable of first cropping, then scaling
 and finally cropping for two source pads individually from the resulting
@@ -476,7 +476,7 @@ an area at location specified by the source crop rectangle from it.
     :alt:    subdev-image-processing-full.svg
     :align:  center
 
-    Image processing in subdevs: scaling and composition with multiple sinks and sources
+    **Figure 4.7. Image processing in subdevs: scaling and composition with multiple sinks and sources**
 
 The subdev driver supports two sink pads and two source pads. The images
 from both of the sink pads are individually cropped, then scaled and