* Re: About RFC of HDMI-CEC
[not found] ` <4DDCF95C.1020705@cisco.com>
@ 2011-05-26 5:09 ` vipul kumar samar
2011-05-26 6:35 ` Hans Verkuil
0 siblings, 1 reply; 4+ messages in thread
From: vipul kumar samar @ 2011-05-26 5:09 UTC (permalink / raw)
To: Martin Bugge (marbugge)
Cc: hdegoede@redhat.com, mchehab@infradead.org, Hans Verkuil,
linux-media@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]
Hello,
On 05/25/2011 06:13 PM, Martin Bugge (marbugge) wrote:
> Hello
>
> To be honest I became a bit disengaded after all the discussion.
>
> What caused me a lot of problems was the request for AV link support
> (which is used in SCART connectors).
> Something I never plan to implement.
>
> But after the "v4l2 Warsaw Brainstroming meeting" it was sort of approved.
>
> It only need to be reworked to be a subdev level api.
> (for that I need some help from Hans Verkuil)
>
> But it is great that someone else also need an API for this.
> I include the latest version here so you can see if you agree, and
> together we will get it in.
>
Yes, sure.
> We currently have two drivers which uses this API for CEC.
>
> * Analog Devices adv7604
>
> * TMS320DM8x
>
i want to see source code of these two drivers.From where i can get
source code of these drivers??
Thanks and Regards
Vipul Kumar Samar
> At least the adv7604 is planned to be upstreamed.
>
> Best regards
> Martin Bugge
>
>
> On 05/25/2011 01:52 PM, vipul kumar samar wrote:
>> Hello,
>>
>> I am working on HDMI-CEC and planning to implement it in v4l2
>> framework.I came to know that a RFC is going on for the same driver.
>>
>> I want to know is their any friezed version of that RFC or discussion
>> is still going on?? Is it included in kernel??
>>
>> Thanks and Regards
>> Vipul Kumar Samar
>
>
--
You won't skid if you stay in a rut. -- Frank Hubbard
[-- Attachment #2: RFC-v3.txt --]
[-- Type: text/plain, Size: 7814 bytes --]
Author: Martin Bugge <marbugge@cisco.com>
Date: Thu, 17th of March 2011
==============================
This is a proposal for adding a Consumer Electronic Control (CEC) API to V4L2.
This document describes the changes and new ioctls needed.
Version 1.
Initial version.
Version 2.
Added support for AV.link EN 50157-2-[123].
Version 3.
Rework of mode 1.
Mode 3 is to be decided (TDB).
Minor cleanup.
Background
==========
CEC is a protocol that provides high-level control functions between various audiovisual products.
It is an optional supplement to the High-Definition Multimedia Interface Specification (HDMI).
In short: CEC uses pin 13 on the HDMI connector to transmit and receive small data-packets
(maximum 16 bytes including a 1 byte header) at low data rates (~400 bits/s).
A CEC device may have any of 15 logical addresses (0 - 14).
(address 15 is broadcast and some addresses are reserved)
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link, see [3].
Due to this the proposed ioctls and events are meant to cover expansion for the protocols in [3].
Note that AV.link mode 3 is still TBD.
References
==========
[1] High-Definition Multimedia Interface Specification version 1.3a,
Supplement 1 Consumer Electronic Control (CEC).
http://www.hdmi.org/manufacturer/specification.aspx
[2] http://www.hdmi.org/pdf/whitepaper/DesigningCECintoYourNextHDMIProduct.pdf
[3] Domestic and similar electronic equipment interconnection requirements
AV.link. EN 50157-2-[123]
Proposed solution
=================
Two new ioctls:
VIDIOC_AV_LINK_CAP (read)
VIDIOC_AV_LINK_CMD (read/write)
VIDIOC_AV_LINK_CAP:
-------------------
#define AV_LINK_CAP_MODE_CEC (1 << 0)
#define AV_LINK_CAP_MODE_1 (1 << 1)
#define AV_LINK_CAP_MODE_2 (1 << 2)
#define AV_LINK_CAP_MODE_3 (1 << 3)
Note about AV.Link Mode 3: TBD
Different manufactures might have different implementations and an option is to
have a mode per implementation.
struct vl2_av_link_cap {
__u32 capabilities;
__u32 logicaldevices;
__u32 reserved[14];
};
The capabilities field will indicate which protocols/formats this HW supports.
* AV link mode CEC:
logicaldevices: 1 -> 14, this HW supports n logical devices simultaneously.
* AV link mode 1:
logicaldevices: not used.
* AV link mode 2:
Same as AV link mode CEC.
* AV link mode 3: TBD
reserved: for future use.
VIDIOC_AV_LINK_CMD:
-------------------
The command ioctl is used both for configuration and to receive/transmit data.
/* mode 1 */
struct avl_mode1_conf {
__u32 enable;
__u32 upstream_arb_mask;
__u32 downstream_arb_mask;
};
struct avl_mode1 {
__u32 ctrl_signal_frame;
__u32 tx_frame_arb;
__u32 tx_status;
};
/* mode 2, CEC and possible mode 3 */
struct avl_conf {
__u32 enable;
__u32 index;
__u32 addr;
};
struct avl {
__u32 len;
__u8 msg[16];
__u32 tx_status;
};
struct v4l2_av_link_cmd {
__u32 command;
__u32 mode;
__u32 reserved[2];
union {
struct avl_mode1_conf avlm1_conf;
struct avl_mode1 avlm1;
struct avl_conf conf;
struct avl avl;
__u32 raw[12];
};
};
/* command */
#define V4L2_AV_LINK_CMD_CONF (1)
#define V4L2_AV_LINK_CMD_TX (2)
#define V4L2_AV_LINK_CMD_RX (3)
/* mode */
#define AV_LINK_CMD_MODE_CEC (1)
#define AV_LINK_CMD_MODE_1 (2)
#define AV_LINK_CMD_MODE_2 (3)
#define AV_LINK_CMD_MODE_3 (4)
/* Tx status */
#define V4L2_AV_LINK_STAT_TX_OK (0)
#define V4L2_AV_LINK_STAT_TX_ARB_LOST (1)
#define V4L2_AV_LINK_STAT_TX_RETRY_TIMEOUT (2)
#define V4L2_AV_LINK_STAT_TX_BROADCAST_REJECT (3)
Not every tx status is applicable for all modes, see table 1.
|-------------------------------------------------------|
| Av link Mode | CEC | 1 | 2 | 3 |
|-------------------------------------------------------|
| Status | | | | |
|-------------------------------------------------------|
| TX_OK | a | a* | a | a** |
|-------------------------------------------------------|
| TX_ARB_LOST | a | a | a | a** |
|-------------------------------------------------------|
| TX_RETRY_TIMEOUT | a | n/a | a | a** |
|-------------------------------------------------------|
| TX_BROADCAST_REJECT | a | n/a | a | a** |
|-------------------------------------------------------|
Table 1: tx status versus mode.
a: applicable
n/a: not applicable
*: TX_OK for mode 1 only imply transmit complete, no ack bit
**: mode 3 is TBD
Configuration command:
----------------------
* AV link mode CEC:
Must be done for each logical device address which is to be
enabled on this HW. Maximum number of logical devices
is found with the capability ioctl.
conf:
index: 0 -> number_of_logical_devices-1
enable: true/false
addr: logical address
* AV link mode 1:
In mode 1 the message frame length is fixed to 20 bits (excluding the START and ESC bit).
Some of these bits (Qty 1 - 6) and /PAS and /DES can be arbitrated by
the receiver to signal modes and supported formats/standards.
conf:
enable: true/false
upstream_arb_mask:
downstream_arb_mask:
A "0" in a bit position will pull down that bit during reveive,
if that bit is allowed to be arbitrated.
|--------------------------------------------------------------------|
| Bits: | 31 - 21 | 19 | 18 | 17 | 16 | 15 -> 0 |
|--------------------------------------------------------------------|
| head bits: | x | DIR | /PAS | /NAS | /DES | Qty-1 -> Qty-16 |
|--------------------------------------------------------------------|
Table 2: Mode 1 Control signal frame (x: not used)
* AV link mode 2:
Same as AV link mode CEC.
* AV link mode 3: TBD
Tx/Rx command:
--------------
* AV link mode CEC:
len: length of message in bytes (data + header).
msg: the raw message received/transmitted.
tx_status: tx status in blocking mode.
* AV link mode 1:
Frame received/transmitted:
ctrl_signal_frame: See Table 2.
In blocking mode only:
tx_frame_arb: The resulting frame as transmitted. Will indicate which
bits was arbitrated during transmit, see Table 2.
tx_status: tx status, see Table 1.
* AV link mode 2:
len: length of message in bytes (data + command block).
msg: the raw message received/transmitted (without the start sequence).
tx_status: tx status in blocking mode.
* AV link mode 3: TBD.
len: length of message in bits, maximum 100 bits.
msg: the raw message received/transmitted. (without the start sequence).
tx_status: tx status in blocking mode.
Events
------
In the case of non-blocking mode the driver will issue the following events:
V4L2_EVENT_AV_LINK_TX
V4L2_EVENT_AV_LINK_RX
V4L2_EVENT_AV_LINK_TX
-----------------
* transmit is complete with the following status:
Add an additional struct to the struct v4l2_event
struct v4l2_event_av_link_tx {
__u32 status;
__u32 tx_mode1_frame_arb;
};
* The status field is the same as in blocking mode described above.
* The tx_mode1_frame_arb apply only to mode 1.
V4L2_EVENT_AV_LINK_RX
-----------------
* received a complete message
Use the VIDIOC_AV_LINK_CMD to read the message.
Comments ?
Martin Bugge
--
Martin Bugge - Tandberg (now a part of Cisco)
--
^ permalink raw reply [flat|nested] 4+ messages in thread