Re: [PATCH 2/3] [media] adv7842: Source Product Description (SPD) InfoFrame
Thank you Hans
On 19/03/14 11:13, Hans Verkuil wrote:
Hi Martin,
On 03/19/14 10:43, Martin Bugge wrote:
Decode and display any received SPD InfoFrame in log-status.
This is really quite standardized data. I looked around in the kernel
and I found this very nice header: include/linux/hdmi.h and source
drivers/video/hdmi.c.
I would suggest that the adv7842 driver fills the hdmi_spd_infoframe
struct and calls a function in v4l2_dv_timings.c to log the contents.
That way it can also be used by e.g. adv7604. We really should be using
this header for other frame types as well.
Actually, I think you should ask on the dri-devel mailinglist (with a
CC to the active maintainers of the hdmi.c source, see 'git log') whether
creating an hdmi_spd_infoframe_log function would be useful to add to
hdmi.c. If they don't like it, then we stick it in v4l2_dv_timings.c. If
they do like it, we can just add it to hdmi.c. It's something that is
primarily useful for receivers, and not so much for transmitters, so they
might not want it in the hdmi.c source.
Yes you are right, it could be nice to have decoding of these Packets in
a common place.
I have added the same code to adv7604 as well so its already duplicated.
I will look into it.
I think the two other patches should apply ok. They are bug fixes.
Regards,
Martin
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 76 +
1 file changed, 76 insertions(+)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 5d79c57..805a117 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2243,6 +2243,81 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
v4l2_info(sd, \t%s %s\n, y10_txt[avi.y10], q10_txt[avi.q10]);
}
+static const char *sdi_txt(u8 code)
+{
+ switch (code) {
+ case 0x00: return unknown;
unknown - Unknown
to be consistent with the others.
Regards,
Hans
+ case 0x01: return Digital STB;
+ case 0x02: return DVD player;
+ case 0x03: return D-VHS;
+ case 0x04: return HDD Videorecorder;
+ case 0x05: return DVC;
+ case 0x06: return DSC;
+ case 0x07: return Video CD;
+ case 0x08: return Game;
+ case 0x09: return PC general;
+ case 0x0a: return Blu-Ray Disc (BD);
+ case 0x0b: return Super Audio CD;
+ }
+ return Reserved;
+}
+
+static void print_spd_info_frame(struct v4l2_subdev *sd)
+{
+ int i;
+ u8 spd_type;
+ u8 spd_ver;
+ u8 spd_len;
+ u8 spd_crc;
+ u8 buf[32];
+ u8 vn[8];
+ u8 pd[16];
+ u8 sdi;
+
+ if (!(hdmi_read(sd, 0x05) 0x80)) {
+ v4l2_info(sd, receive DVI-D signal (SDP infoframe not
supported)\n);
+ return;
+ }
+ if (!(io_read(sd, 0x60) 0x04)) {
+ v4l2_info(sd, SDP infoframe not received\n);
+ return;
+ }
+
+ if (io_read(sd, 0x88) 0x40) {
+ v4l2_info(sd, SPD infoframe checksum error has occurred
earlier\n);
+ io_write(sd, 0x8a, 0x40); /* clear SPD_INF_CKS_ERR_RAW */
+ if (io_read(sd, 0x88) 0x40) {
+ v4l2_info(sd, SPD infoframe checksum error still
present\n);
+ io_write(sd, 0x8a, 0x40); /* clear SPD_INF_CKS_ERR_RAW
*/
+ }
+ }
+
+ spd_type = infoframe_read(sd, 0xe6) 0x7f;
+ spd_ver = infoframe_read(sd, 0xe7);
+ spd_len = infoframe_read(sd, 0xe8);
+ spd_crc = infoframe_read(sd, 0x2a);
+
+ v4l2_info(sd, SPD infoframe type %d, version %d, crc 0x%x, len %d\n,
+ spd_type, spd_ver, spd_crc, spd_len);
+
+ if (spd_type != 0x03)
+ return;
+ if (spd_ver != 0x01)
+ return;
+
+ memset(buf, 0, sizeof(buf));
+ for (i = 0; i 25 i spd_len; i++)
+ buf[i] = infoframe_read(sd, i + 0x2b);
+
+ snprintf(vn, 8, buf);
+ snprintf(pd, 16, buf + 8);
+ sdi = buf[24];
+
+ v4l2_info(sd, \tVendor Name: %s\n, vn);
+ v4l2_info(sd, \tProduct Description: %s\n, pd);
+ v4l2_info(sd, \tSource Device Information: %s (%d)\n, sdi_txt(sdi),
sdi);
+}
+
static const char * const prim_mode_txt[] = {
SDP,
Component,
@@ -2455,6 +2530,7 @@ static int adv7842_cp_log_status(struct v4l2_subdev *sd)
deep_color_mode_txt[hdmi_read(sd, 0x0b) 6]);
print_avi_infoframe(sd);
+ print_spd_info_frame(sd);
return 0;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Preliminary proposal, new APIs for HDMI and DVI control in v4l2
Hi Soby On 05/27/2012 07:30 PM, Soby Mathew wrote: Martin Bugge (marbuggemarbuggeat cisco.com writes: This is a preliminary proposal for an extension to the v4l2 api. To be discussed at the V4L2 'brainstorming' meeting in Warsaw, March 2011 Purpose: Provide basic controls for HDMI and DVI devices. reposting the query since the earlier post did not appear in mailing list. Hi Martin, We are also in requirement of these controls as described by you. I did a search in the archives but could not find a suitable conclusion to the RFC. I could find that the dv_timings structure has been modified as a result of further discussions. But for many items like S_EDID, DV_CABLE_DETECT, Info frames etc , I could not find the logical conclusion to this RFC. Could please let me know the further updates on these requirements? It has been on hold for a very long time, but just last week Hans Verkuil posted a RFC which is a follow up on this subject. http://www.spinics.net/lists/linux-media/msg47671.html So that thread has taken over. Thanks in Advance Best Regards Soby Mathew Best regards Martin Bugge -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal, ver 2
Hi Daniel and thank you, On 03/12/2011 01:42 AM, Daniel Glöckner wrote: Hi Martin, On Fri, Mar 11, 2011 at 12:36:09PM +0100, Martin Bugge (marbugge) wrote: Not every tx status is applicable for all modes, see table 1. |-| |Av link Mode | CEC | 1 | 2 | 3 | |-| | Status | | | | | |-| | TX_OK | a | n/a | a | n/a | |-| | TX_ARB_LOST| a | n/a | a | a | |-| | TX_RETRY_TIMEOUT| a | n/a | a | a | |-| | TX_BROADCAST_REJECT | a | n/a | a | n/a | |-| TX_ARB_LOST is applicable to mode 1. Arbitration loss will also be caused by receivers detecting a bad pulse. You are correct, a typo. However, it looks like also TX_OK will be used for Mode 3. And maybe also TX_BROADCAST_REJECT. In particular with reference to your link in below. * AV link mode 1: In mode 1 the frame length is fixed to 21 bits (including the start sequence). Some of these bits (Qty 1 - 6) can be arbitrated by the receiver to signal supported formats/standards. conf: enable: true/false upstream_Qty: QTY bits 1-6 downstream_Qty: QTY bits 1-6 || | Bits: | 31 - 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | || | Qty bits | x| x | 6 | 5 | 4 | 3 | 2 | 1 | || Qty bits 1-6 mapping (x: not used) If the Linux system is a video source, it must stop arbitrating those Qty bits as soon as another video source wants to become active. As this includes the message where the new source announces itself, this can't be handled by reconfiguration after reception of the message. If the Linux system is a video sink, the announcement of a new source should not affect the Qty bits to arbitrate. And don't get me startet about systems capable of being a video source and sink at the same time, capturing their own signal until a new source becomes active... I assume this must be handled by logic in the driver if it supports this mode. * AV link mode 1: Frame received/transmitted: head: |-| | Bits: | 31 - 4 | 3 | 2 | 1 | 0 | |-| | head bits: |x | DIR | /PAS | /NAS | /DES | |-| Qty: Quality bits 1 - 16; |---| | Bits: | 31 - 16 | 15 | 14 - 1 | 0 | |---| | Qty bits |x| 16 | 15 - 2 | 1 | |---| x: not used Is Qty-1 or Qty-16 the bit sent after /DES? Even though I find it a bit confusing in the standard, the plan was to send Qty-1 just after the /DES bit. It was an attempt to make the configuration and status the same. Such that we could use the same bit masks. In blocking mode only: tx_status: tx status. tx_status_Qty: which Qty bits 1 - 6 bits was arbitrated during transmit. It may be interesting to know what other devices did to the /PAS and /DES bits when they were sent as 1. Maybe I should change this such that we actually send up the whole frame as tx_status. In that way we will avoid the confusion of the Qty bit orders also. But then this should apply to the configuration as well. * AV link mode 3: TBD. Chances are that nobody ever used this len: length of message in bits, maximum 96 bits. msg: the raw message received/transmitted. (without the start sequence). tx_status: tx status in blocking mode. Google turned up this: http://fmt.cs.utwente.nl/publications/files/111_heerink.pdf It suggests that at least Philips' variant of AV.link mode 3 - EasyLink - is even closer to CEC than mode 2. Yes I see that. However CEC don't have the start sequence (to differenciate between mode 1 - 3), and the application id. In addition can't I see that mode 3 describe the ACK and EOM bits. It might be difficult to force easylink into the mode 3 as it is. If we could use the application id it might be possible for the driver to change behaviour. Or we will end up with #define AV_LINK_CAP_MODE_EASY_LINK (1 4) And so on, which might be ok also. Daniel
Preliminary proposal, new APIs for HDMI and DVI control in v4l2
This is a preliminary proposal for an extension to the v4l2 api.
To be discussed at the V4L2 'brainstorming' meeting in Warsaw, March 2011
Purpose: Provide basic controls for HDMI and DVI devices.
sink : HDMI/DVI/VGA receiver
source: HDMI/DVI/VGA transmitter
New Controls:
=
These controls rely on control events to be able to notify the
application of any change.
The idea is to create an event that will be triggered by the control
framework whenever a control changes value.
TX source:
--
Control: V4L2_CID_DV_TX_HOTPLUG
type: bitmask (output), read only
name: Hotplug
Hotplug is present on each output.
The hotplug is issued by the sink to indicate that an
edid exists and should be read by the source.
Not applicable for VGA connectors.
Control: V4L2_CID_DV_TX_RXSENSE
type: bitmask (output), read only
name: Rx Sense
Rx sense is present on each output.
Rx Sense is detection of pull-ups on the TMDS clock lines.
Normally means that the sink has left/entered standby.
Not applicable for VGA connectors.
Control: V4L2_CID_DV_TX_EDID_SEGMENT0_PRESENT
type: bitmask (output), read only
name: Edid segment 0
The source driver has read edid segment 0 from the sink.
Control: V4L2_CID_DV_TX_DVI_HDMI_MODE
type: menu, read and write
name: Hdmi/Dvi mode
Settings:
HDMI
DVI-D
RX sink:
Control: V4L2_CID_DV_RX_5V
type: bitmask (input), read only
name: Rx 5V
The source must supply the sink with a +5v via the HDMI/DVI cable.
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.
Control: V4L2_CID_DV_CABLE_DETECT
type: bitmask (input), read only
name: Cable detect
This is not a part of the HDMI/DVI standards.
But many sinks (read monitors) uses a + 5v pull-up on a
ground pin (typically pin 15 on dvi) to detect if a cable is
is connected and terminated at the source end.
Control: V4L2_CID_DV_FORMAT_STATUS
type: menu, read only
name: Format status
Format status for the current selected input.
Statuses:
No signal
Unknown
Unsupported
Encrypted
Valid/supported
The input signal has changed format or status.
In the case of a valid signal use the
vidioc_query_dv_preset to read the new format.
Alternatively this could also be implemented as a bitmask with bits
for: 'signal present', 'encrypted', 'supported format'.
Or as three separate boolean controls.
New Events:
===
V4L2_EVENT_TX_EDID
struct v4l2_event_tx_edid {
__u32 output;
__u32 present;
__u32 segment;
}
The source driver has read an edid segment from the sink.
One segment is 256 bytes and will contain one or two 128
bytes blocks. Most HDMI and DVI sinks will have only segment 0.
The driver should read segment 0 when hotplug is detected and
report this to userspace. The application can then use the
V4L2_G_EDID ioctl to get the actual edid data.
If the EDID data indicates the presence of further extension blocks the
userspace application can use the V4L2_REQ_EDID ioctl to trigger a read.
When the driver has read that extended segment it will generate a
V4L2_EVENT_TX_EDID event.
New Ioctls:
===
TX source:
--
V4L2_REQ_EDID
struct v4l2_req_edid {
__u32 output;
__u32 segment;
}
Trigger a read of a 256 bytes segment. Normally the driver will
read segment 0 by itself when hotplug is detected, But this ioctl
may also be used to trigger a re-read of segment 0.
V4L2_G_EDID
struct v4l2_g_edid {
__u32 output;
__u32 segment;
__u8 edid[256];
}
Get the edid segment indicated in the V4L2_EVENT_TX_EDID
RX sink:
V4L2_S_EDID
struct v4l2_s_edid {
__u32 input;
__u32 segment;
__u8 _edid[256];
}
Set the edid information in the source.
Additional Controls and Status:
===
Controls and statuses we want to add.
Currently based on HDMI version 1.3a, must be updated
From Info frames
* Y0, Y1 RGB or YCBCR indicator.
* A0Active Information Present. Indicates whether field
R0...R3 is valid. See
CEA-861-D table 8 for details.
* B0, B1Bar Info data valid. See CEA-861-D table 8 for details.
HDMI Licensing, LLC Page 113 of 156
High-Definition Multimedia Interface
Specification Version 1.3a
* S0, S1Scan Information (i.e. overscan, underscan). See
CEA-861-D table 8 for
details.
* C0, C1Colorimetry (ITU BT.601, BT.709 etc.). See CEA-861-D
table 9 for
details.
* EC0, EC1, EC2 Extended Colorimetry (IEC 61966-2-4 etc.). See
[RFC] HDMI-CEC proposal, ver 2
Hi
This is an updated version of the proposal for adding an api for
HDMI-CEC to V4L2.
Main difference is the support of AV.link EN 50157-2-[123]. (thanks to
Daniel Glöckner)
Author: Martin Bugge marbu...@cisco.com
Date: Fri, 11th of March 2010
=
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].
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].
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)
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:
logicaldevices: not used.
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_Qty;
__u32 downstream_Qty;
};
struct avl_mode1 {
__u32 head;
__u32 Qty;
__u32 tx_status;
__u32 tx_status_Qty;
};
/* mode 2, 3 and CEC */
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 | n/a | a | n/a |
|-|
| TX_ARB_LOST| a | n/a | a | a |
|-|
| TX_RETRY_TIMEOUT| a | n/a | a | a |
|-|
| TX_BROADCAST_REJECT | a | n/a | a | n/a |
|-|
Table 1: tx status versus mode.
a: applicable
n/a: not applicable
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
Re: [RFC] HDMI-CEC proposal
On 03/03/2011 11:37 AM, Laurent Pinchart wrote:
Hi Martin,
On Tuesday 01 March 2011 10:59:07 Martin Bugge (marbugge) wrote:
Author: Martin Buggemarbu...@cisco.com
Date: Tue, 1 March 2010
==
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.0 (This is first version)
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).
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link protocol.
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)
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
Proposed solution
=
Two new ioctls:
VIDIOC_CEC_CAP (read)
VIDIOC_CEC_CMD (read/write)
VIDIOC_CEC_CAP:
---
struct vl2_cec_cap {
__u32 logicaldevices;
__u32 reserved[7];
};
The capability ioctl will return the number of logical devices/addresses
which can be
simultaneously supported on this HW.
0: This HW don't support CEC.
1 - 14: This HW supports n logical devices simultaneously.
VIDIOC_CEC_CMD:
---
struct v4l2_cec_cmd {
__u32 cmd;
__u32 reserved[7];
union {
struct {
__u32 index;
__u32 enable;
__u32 addr;
} conf;
struct {
__u32 len;
__u8 msg[16];
__u32 status;
} data;
__u32 raw[8];
};
};
Alternatively the data struct could be:
struct {
__u8 initiator;
__u8 destination;
__u8 len;
__u8 msg[15];
__u32 status;
} data;
Commands:
#define V4L2_CEC_CMD_CONF (1)
#define V4L2_CEC_CMD_TX(2)
#define V4L2_CEC_CMD_RX(3)
Tx status field:
#define V4L2_CEC_STAT_TX_OK(0)
#define V4L2_CEC_STAT_TX_ARB_LOST (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
The command ioctl is used both for configuration and to receive/transmit
data.
* The configuration command 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
By default all logical devices are disabled.
* Tx/Rx command
data:
len:length of message (data + header)
msg:the raw CEC message received/transmitted
status: when the driver is in blocking mode it gives the
result for transmit.
Events
--
In the case of non-blocking mode the driver will issue the following
events:
V4L2_EVENT_CEC_TX
V4L2_EVENT_CEC_RX
V4L2_EVENT_CEC_TX
-
* transmit is complete with the following status:
Add an additional struct to the struct v4l2_event
struct v4l2_event_cec_tx {
__u32 status;
}
In non-blocking mode, will applications be able to send several messages
without waiting for a transmission done event between each of them ? If so,
maybe some kind of ID to correlate TX events with TX commands would be useful.
Hi Laurent and thank you,
No it wasn't the plan to be able to send several messages without
waiting for
the previous to complete.
In the first test driver we have written for this, a new send while
previous transmission is not complete in non-blocking mode will return
-EAGAIN;
Regards
Martin
V4L2_EVENT_CEC_RX
-
* received a complete message
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On 03/02/2011 12:38 AM, Daniel Glöckner wrote: On Tue, Mar 01, 2011 at 10:59:07AM +0100, Martin Bugge (marbugge) wrote: 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). Physical layer is a one-wire bidirectional serial bus that uses the industry-standard AV.link protocol. Apart from CEC being twice as fast as AV.link and using 3.6V instead of 5V, CEC does look like an extension to the frame format defined in EN 50157-2-2 for multiple data bytes. So, how about adding support for EN 50157-2-* messages as well? SCART isn't dead yet. EN 50157-2-1 is tricky in that it requires devices to override data bits like it is done for ack bits to announce their status. There is a single message type with 21 bits. For EN 50157-2-2 the only change necessary would be to tell the application that it has to use AV.link commands instead of CEC commands. In theory one could mix AV.link and CEC on a single wire as they can be distinguished by their start bits. EN 50157-2-3 allows 7 vendors to register their own applications with up to 100 data bits per message. I doubt we can support these if they require bits on the wire to be modified. As they still didn't make use of the reserved value to extend the application number space beyond 7, chances are no vendor ever applied for a number. Just my 2 cents. Daniel Hi Daniel and thank you. I haven't read these standards myself but will do so as soon as I get hold of them. But this sounds like a good idea since cec is based on these protocols. I will look into it. Regards, Martin -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] HDMI-CEC proposal
Author: Martin Bugge marbu...@cisco.com
Date: Tue, 1 March 2010
==
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.0 (This is first version)
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).
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link protocol.
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)
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
Proposed solution
=
Two new ioctls:
VIDIOC_CEC_CAP (read)
VIDIOC_CEC_CMD (read/write)
VIDIOC_CEC_CAP:
---
struct vl2_cec_cap {
__u32 logicaldevices;
__u32 reserved[7];
};
The capability ioctl will return the number of logical devices/addresses
which can be
simultaneously supported on this HW.
0: This HW don't support CEC.
1 - 14: This HW supports n logical devices simultaneously.
VIDIOC_CEC_CMD:
---
struct v4l2_cec_cmd {
__u32 cmd;
__u32 reserved[7];
union {
struct {
__u32 index;
__u32 enable;
__u32 addr;
} conf;
struct {
__u32 len;
__u8 msg[16];
__u32 status;
} data;
__u32 raw[8];
};
};
Alternatively the data struct could be:
struct {
__u8 initiator;
__u8 destination;
__u8 len;
__u8 msg[15];
__u32 status;
} data;
Commands:
#define V4L2_CEC_CMD_CONF (1)
#define V4L2_CEC_CMD_TX(2)
#define V4L2_CEC_CMD_RX(3)
Tx status field:
#define V4L2_CEC_STAT_TX_OK(0)
#define V4L2_CEC_STAT_TX_ARB_LOST (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
The command ioctl is used both for configuration and to receive/transmit
data.
* The configuration command 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
By default all logical devices are disabled.
* Tx/Rx command
data:
len:length of message (data + header)
msg:the raw CEC message received/transmitted
status: when the driver is in blocking mode it gives the
result for transmit.
Events
--
In the case of non-blocking mode the driver will issue the following events:
V4L2_EVENT_CEC_TX
V4L2_EVENT_CEC_RX
V4L2_EVENT_CEC_TX
-
* transmit is complete with the following status:
Add an additional struct to the struct v4l2_event
struct v4l2_event_cec_tx {
__u32 status;
}
V4L2_EVENT_CEC_RX
-
* received a complete message
Comments ?
Martin Bugge
--
Martin Bugge - Tandberg (now a part of Cisco)
--
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] HDMI-CEC proposal
On 03/01/2011 02:47 PM, Andy Walls wrote:
On Tue, 2011-03-01 at 10:59 +0100, Martin Bugge (marbugge) wrote:
Author: Martin Buggemarbu...@cisco.com
Date: Tue, 1 March 2010
==
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.0 (This is first version)
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).
Physical layer is a one-wire bidirectional serial bus that uses the
industry-standard AV.link protocol.
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)
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
Hi Martin,
After reading the whitepaper, and the the general purpose nature of your
proposed API calls, I'm wondering if a socket interface wouldn't be
appropriate.
The CEC bus seems to be designed as a network. A broadcast medium, with
multiport devices (switches), physical (MAC) addresses in dotted decimal
notation (1.0.0.0), dynamic logical address assignment, arbitration
(Media Access Control), etc. The whitepaper even suggests OSI layers,
using the term PHY in a few places.
A network interface could be implemented something like what is done for
SLIP in figure 2 here (compare with figure 1):
http://www.linux.it/~rubini/docs/serial/serial.html
Using that diagram as a guide, a socket interface would need a CEC tty
line discipline, CEC network device, and code to hook the CEC serial
device to the tty layer. Multiple CEC serial devices would show up as
multiple network interfaces.
Once a network device is available, user-space could then use AF_PACKET
sockets. If CEC's layers are standardized enough, a new address family
could be added to the kernel, I guess.
Of course, all that is a lot of work. Since Cisco should have some
networking experts hanging around, maybe it wouldn't be too hard. ;)
Regards,
Andy
Hi Andy and thank you.
I agree its always nice to strive for a generic solution, but I don't
think I'm able to
get hold of the resources required.
In CEC the physical address is determined by the edid information from
the HDMI sink,
or for the HDMI sink its HDMI port number.
While the logical address describes the type of device, TV, Recorder,
Tuner, etc.
From that point of view I do think that the CEC protocol is closly
connected to the HDMI connector,
such that it belongs together with a video device.
But I will ask my mentor for advice.
Regards,
Martin
Proposed solution
=
Two new ioctls:
VIDIOC_CEC_CAP (read)
VIDIOC_CEC_CMD (read/write)
VIDIOC_CEC_CAP:
---
struct vl2_cec_cap {
__u32 logicaldevices;
__u32 reserved[7];
};
The capability ioctl will return the number of logical devices/addresses
which can be
simultaneously supported on this HW.
0: This HW don't support CEC.
1 - 14: This HW supports n logical devices simultaneously.
VIDIOC_CEC_CMD:
---
struct v4l2_cec_cmd {
__u32 cmd;
__u32 reserved[7];
union {
struct {
__u32 index;
__u32 enable;
__u32 addr;
} conf;
struct {
__u32 len;
__u8 msg[16];
__u32 status;
} data;
__u32 raw[8];
};
};
Alternatively the data struct could be:
struct {
__u8 initiator;
__u8 destination;
__u8 len;
__u8 msg[15];
__u32 status;
} data;
Commands:
#define V4L2_CEC_CMD_CONF (1)
#define V4L2_CEC_CMD_TX(2)
#define V4L2_CEC_CMD_RX(3)
Tx status field:
#define V4L2_CEC_STAT_TX_OK(0)
#define V4L2_CEC_STAT_TX_ARB_LOST (1)
#define V4L2_CEC_STAT_TX_RETRY_TIMEOUT (2)
The command ioctl is used both for configuration and to receive/transmit
data.
* The configuration command 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
By default all logical devices are disabled.
* Tx/Rx command
data:
len:length of message (data + header
