From patchwork Thu Jul 5 14:26:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hans Verkuil X-Patchwork-Id: 1161021 Return-Path: X-Original-To: patchwork-linux-media@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork2.kernel.org (Postfix) with ESMTP id A6871DFB7C for ; Thu, 5 Jul 2012 14:36:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932980Ab2GEOgH (ORCPT ); Thu, 5 Jul 2012 10:36:07 -0400 Received: from ams-iport-4.cisco.com ([144.254.224.147]:2793 "EHLO ams-iport-4.cisco.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756189Ab2GEOgE (ORCPT ); Thu, 5 Jul 2012 10:36:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=hans.verkuil@cisco.com; l=14203; q=dns/txt; s=iport; t=1341498964; x=1342708564; h=from:to:cc:subject:date:message-id; bh=AcoR5tujD9Hu8+IPzcZWja2k2lnqQekYbSTOmZ13j7o=; b=lVMaFvp+fdA/Mw5t7Bt8g3hjtuX5G85x+xX7TfDmbXvMYEoEK+usb4mz gVmZcTORfd+hvNBNGsru6b60IcNY61H43mDXk84WJfxwWWmC6hq/aOXuG ilXOtDd5ZLzbd9wYYufXPbLd2iMiZ+fLQt893bNUd0xKRq6Rd4m5Bsq7s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFqj9U+Q/khL/2dsb2JhbABFtyaBB4IZAQEEEgFUBwsQUVcZIodpmXafb4tUhiMDlTeOHYFmgmE X-IronPort-AV: E=Sophos;i="4.77,531,1336348800"; d="scan'208";a="6437100" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 05 Jul 2012 14:26:19 +0000 Received: from cobaltpc1.cisco.com (dhcp-10-54-92-107.cisco.com [10.54.92.107]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q65EQJ5G019352; Thu, 5 Jul 2012 14:26:19 GMT From: Hans Verkuil To: linux-media@vger.kernel.org Cc: hverkuil@xs4all.nl, device-drivers-devel@blackfin.uclinux.org Subject: [RFCv1 PATCH 2/7] V4L2 spec: document the new DV controls and ioctls. Date: Thu, 5 Jul 2012 16:26:10 +0200 Message-Id: <0d555ef8a2ac4d86cd67181e4a035f21ed4db66d.1341497271.git.hans.verkuil@cisco.com> X-Mailer: git-send-email 1.7.10 In-Reply-To: <1341498375-9411-1-git-send-email-hans.verkuil@cisco.com> References: <1341498375-9411-1-git-send-email-hans.verkuil@cisco.com> In-Reply-To: References: Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-media@vger.kernel.org Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/controls.xml | 149 +++++++++++++++++++ Documentation/DocBook/media/v4l/v4l2.xml | 1 + .../DocBook/media/v4l/vidioc-subdev-g-edid.xml | 152 ++++++++++++++++++++ 3 files changed, 302 insertions(+) create mode 100644 Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 8994132..da41504 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -4269,4 +4269,153 @@ interface and may change in the future. + +
+ Digital Video Control Reference + + + Experimental + + This is an experimental interface and may + change in the future. + + + + The Digital Video control class is intended to control receivers + and transmitters for VGA, DVI, HDMI and DisplayPort. These controls + are generally expected to be private to the receiver or transmitter + subdevice that implements them, so they are only exposed on the + /dev/v4l-subdev* device node. + + + Note that these devices can have multiple input or output pads which are + hooked up to e.g. HDMI connectors. Even though the subdevice will receive or + transmit video from/to only one of those pads, the other pads can still be + active when it comes to EDID and HDCP processing, allowing the device + to do the fairly slow EDID/HDCP handling in advance. This allows for quick + switching between connectors. + + These pads appear in several of the controls in this section as + bitmasks, one bit for each pad starting at bit 0. The maximum value of + the control is the set of valid pads. + + + Digital Video Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_DV_CLASS + class + + + The DV class descriptor. + + + V4L2_CID_DV_TX_HOTPLUG + bitmask + + + Many connectors have a hotplug pin which is high + if EDID information is available from the source. This control shows the + state of the hotplug pin as seen by the transmitter. + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_RXSENSE + bitmask + + + Rx Sense is the detection of pull-ups on the TMDS + clock lines. This normally means that the sink has left/entered standby (i.e. + the transmitter can sense that the receiver is ready to receive video). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to DVI-D and HDMI devices. + + + + V4L2_CID_DV_TX_EDID_PRESENT + bitmask + + + When the transmitter sees the hotplug signal from the + receiver it will attempt to read the EDID. If set, then the transmitter has read + at least the first block (= 128 bytes). + Each bit corresponds to an output pad on the transmitter. + This read-only control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_TX_MODE + enum v4l2_dv_tx_mode + + + HDMI transmitters can transmit in DVI-D mode (just video) + or in HDMI mode (video + audio + auxiliary data). This control selects which mode + to use: V4L2_DV_TX_MODE_DVI_D or V4L2_DV_TX_MODE_HDMI. + This control is applicable to HDMI connectors. + + + + V4L2_CID_DV_TX_RGB_RANGE + enum v4l2_dv_rgb_range + + + Select the quantization range for RGB output. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. CEA-861 for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sinks that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_RX_POWER_PRESENT + bitmask + + + Detects whether the receiver receives power from the source + (e.g. HDMI carries 5V on one of the pins). This is often used to power an eeprom + which contains EDID information, such that the source can read the EDID even if + the sink is in standby/power off. + Each bit corresponds to an input pad on the receiver. + This read-only control is applicable to DVI-D, HDMI and DisplayPort connectors. + + + + V4L2_CID_DV_RX_RGB_RANGE + enum v4l2_dv_rgb_range + + + Select the quantization range for RGB input. V4L2_DV_RANGE_AUTO + follows the RGB quantization range specified in the standard for the video interface + (ie. CEA-861 for HDMI). V4L2_DV_RANGE_LIMITED and V4L2_DV_RANGE_FULL override the standard + to be compatible with sources that have not implemented the standard correctly + (unfortunately quite common for HDMI and DVI-D). + This control is applicable to VGA, DVI-A/D, HDMI and DisplayPort connectors. + + + + + +
+ +
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index 008c2d7..51395f7 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -575,6 +575,7 @@ and discussions on the V4L mailing list. &sub-subdev-enum-frame-size; &sub-subdev-enum-mbus-code; &sub-subdev-g-crop; + &sub-subdev-g-edid; &sub-subdev-g-fmt; &sub-subdev-g-frame-interval; &sub-subdev-g-selection; diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml new file mode 100644 index 0000000..05371db --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml @@ -0,0 +1,152 @@ + + + ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID + &manvol; + + + + VIDIOC_SUBDEV_G_EDID + VIDIOC_SUBDEV_S_EDID + Get or set the EDID of a video receiver/transmitter + + + + + + int ioctl + int fd + int request + struct v4l2_subdev_edid *argp + + + + + int ioctl + int fd + int request + const struct v4l2_subdev_edid *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID + + + + argp + + + + + + + + + Description + These ioctls can be used to get or set an EDID associated with an input pad + from a receiver or an output pad of a transmitter subdevice. + + To get the EDID data the application has to fill in the pad, + start_block, blocks and edid + fields and call VIDIOC_SUBDEV_G_EDID. The current EDID from block + start_block and of size blocks + will be placed in the memory edid points to. The edid + pointer must point to memory at least blocks * 128 bytes + large (the size of one block is 128 bytes). + + If there are fewer blocks than specified, then the driver will set blocks + to the actual number of blocks. If there are no EDID blocks available at all, then the error code + ENODATA is set. + + If blocks have to be retrieved from the sink, then this call will block until they + have been read. + + To set the EDID blocks of a receiver the application has to fill in the pad, + blocks and edid fields and set + start_block to 0. It is not possible to set part of an EDID, + it is always all or nothing. Setting the EDID data is only valid for receivers as it makes + no sense for a transmitter. + + The driver assumes that the full EDID is passed in. If there are more EDID blocks than + the hardware can handle then the EDID is not written, but instead the error code E2BIG is set + and blocks is set to the maximum that the hardware supports. + If start_block is any + value other than 0 then the error code EINVAL is set. + + To disable an EDID you set blocks to 0. Depending on the + hardware this will drive the hotplug pin low and/or block the source from reading the EDID + data in some way. In any case, the end result is the same: the EDID is no longer available. + + + + struct <structname>v4l2_subdev_edid</structname> + + &cs-str; + + + __u32 + pad + Pad for which to get/set the EDID blocks. + + + __u32 + start_block + Read the EDID from starting with this block. Must be 0 when setting + the EDID. + + + __u32 + blocks + The number of blocks to get or set. Must be less or equal to 255 (the + maximum block number defined by the standard). When you set the EDID and + blocks is 0, then the EDID is disabled or erased. + + + __u8 * + edid + Pointer to memory that contains the EDID. The minimum size is + blocks * 128. + + + __u32 + reserved[5] + Reserved for future extensions. Applications and drivers must + set the array to zero. + + + +
+ + + + &return-value; + + + + ENODATA + + The EDID data is not available. + + + + E2BIG + + The EDID data you provided is more than the hardware can handle. + + + + +