[media] cec: documentation fixes

``request``

    CEC ioctl request code as defined in the cec.h header file, for

    example :c:func:`CEC_ADAP_G_CAPS`.

    example :ref:`CEC_ADAP_G_CAPS <CEC_ADAP_G_CAPS>`.

``argp``

    Pointer to a request-specific structure.

    Open flags. Access mode must be ``O_RDWR``.

    When the ``O_NONBLOCK`` flag is given, the

    :ref:`CEC_RECEIVE <CEC_RECEIVE>` and :c:func:`CEC_DQEVENT` ioctls

    :ref:`CEC_RECEIVE <CEC_RECEIVE>` and :ref:`CEC_DQEVENT <CEC_DQEVENT>` ioctls

    will return the ``EAGAIN`` error code when no message or event is available, and

    ioctls :ref:`CEC_TRANSMIT <CEC_TRANSMIT>`,

    :ref:`CEC_ADAP_S_PHYS_ADDR <CEC_ADAP_S_PHYS_ADDR>` and

   List of FD events to be watched

``nfds``

   Number of FD efents at the \*ufds array

   Number of FD events at the \*ufds array

``timeout``

   Timeout to wait for events

the ``revents`` field if there are messages in the receive queue. If the

transmit queue has room for new messages, the ``POLLOUT`` and

``POLLWRNORM`` flags are set. If there are events in the event queue,

then the ``POLLPRI`` flag is set. When the function timed out it returns

then the ``POLLPRI`` flag is set. When the function times out it returns

a value of zero, on failure it returns -1 and the ``errno`` variable is

set appropriately.

queue, then it will return -1 and set errno to the ``EBUSY`` error code.

The transmit queue has enough room for 18 messages (about 1 second worth

of 2-byte messages). Note that the CEC kernel framework will also reply

to core messages (see :ref:cec-core-processing), so it is not a good

to core messages (see :ref:`cec-core-processing`), so it is not a good

idea to fully fill up the transmit queue.

If the file descriptor is in non-blocking mode then the transmit will