[PATCH] hdmi: audio infoframe log: corrected channel count
Audio channel count should start from 2.
Reference: CEA-861-F Table 27.
Cc: Hans Verkuil <hverk...@xs4all.nl>
Reported-by: Ahung Cheng <ahch...@nvidia.com>
Signed-off-by: Martin Bugge <marbu...@cisco.com>
---
drivers/video/hdmi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1cf907e..35c0408 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -884,7 +884,7 @@ static void hdmi_audio_infoframe_log(const char *level,
(struct hdmi_any_infoframe *)frame);
if (frame->channels)
- hdmi_log("channels: %u\n", frame->channels - 1);
+ hdmi_log("channels: %u\n", frame->channels + 1);
else
hdmi_log("channels: Refer to stream header\n");
hdmi_log("coding type: %s\n",
--
2.9.4
[PATCH] [media] v4l2-dv-timings.h: CEA-861-F 4K timings have positive sync polarities
Corrected sync polarities for CEA-861-F timings
3840x2160p24/25/30/50/60 and 4096x2160p24/25/30/50/60.
Cc: Hans Verkuil <hans.verk...@cisco.com>
Signed-off-by: Martin Bugge <marbu...@cisco.com>
---
include/uapi/linux/v4l2-dv-timings.h | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/include/uapi/linux/v4l2-dv-timings.h
b/include/uapi/linux/v4l2-dv-timings.h
index c039f1d..086168e 100644
--- a/include/uapi/linux/v4l2-dv-timings.h
+++ b/include/uapi/linux/v4l2-dv-timings.h
@@ -183,7 +183,8 @@
#define V4L2_DV_BT_CEA_3840X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1276, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -191,14 +192,16 @@
#define V4L2_DV_BT_CEA_3840X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_3840X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -206,14 +209,16 @@
#define V4L2_DV_BT_CEA_3840X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 1056, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_3840X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(3840, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(3840, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 176, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -221,7 +226,8 @@
#define V4L2_DV_BT_CEA_4096X2160P24 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 1020, 88, 296, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -229,14 +235,16 @@
#define V4L2_DV_BT_CEA_4096X2160P25 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_4096X2160P30 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
29700, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
@@ -244,14 +252,16 @@
#define V4L2_DV_BT_CEA_4096X2160P50 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 968, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, V4L2_DV_FL_IS_CE_VIDEO) \
}
#define V4L2_DV_BT_CEA_4096X2160P60 { \
.type = V4L2_DV_BT_656_1120, \
- V4L2_INIT_BT_TIMINGS(4096, 2160, 0, V4L2_DV_HSYNC_POS_POL, \
+ V4L2_INIT_BT_TIMINGS(4096, 2160, 0, \
+ V4L2_DV_HSYNC_POS_POL | V4L2_DV_VSYNC_POS_POL, \
59400, 88, 88, 128, 8, 10, 72, 0, 0, 0, \
V4L2_DV_BT_STD_CEA861, \
V4L2_DV_FL_CAN_REDUCE_FPS | V4L2_DV_FL_IS_CE_VIDEO) \
--
2.4.11
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord..
[PATCH 2/3] [media] adv7842: Source Product Description (SPD) InfoFrame
Decode and display any received SPD InfoFrame in log-status.
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;
+ 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;
}
--
1.8.5.3
--
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
[PATCH 1/3] [media] adv7842: update RGB quantization range on HDMI/DVI-D mode irq.
This was the reason for enabling the HDMI/DVI-D mode irq in the first place.
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 636ac08..5d79c57 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2000,6 +2000,7 @@ static int adv7842_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
if (irq_status[5] 0x08) {
v4l2_dbg(1, debug, sd, %s: irq %s mode\n, __func__,
(io_read(sd, 0x65) 0x08) ? HDMI : DVI);
+ set_rgb_quantization_range(sd);
if (handled)
*handled = true;
}
--
1.8.5.3
--
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
[PATCH 3/3] [media] adv7842: Disable access to EDID DDC lines before chip power up.
In core_init make sure access to EDID DDC lines are disabled
before chip is powered up. Also DISABLE_AUTO_EDID before power up.
The correct setting is applied later when setting the EDID.
Some sources (MAC) kept on reading EDID even when Hotplug was low
and in the short period in core_init before the DDC lines was enabled
read a corrupt EDID.
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 805a117..3b3bd42 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2687,6 +2687,12 @@ static int adv7842_core_init(struct v4l2_subdev *sd)
disable_input(sd);
+ /*
+* Disable I2C access to internal EDID ram from HDMI DDC ports
+* Disable auto edid enable when leaving powerdown mode
+*/
+ rep_write_and_or(sd, 0x77, 0xd3, 0x20);
+
/* power */
io_write(sd, 0x0c, 0x42); /* Power up part and power down VDP */
io_write(sd, 0x15, 0x80); /* Power up pads */
@@ -2767,9 +2773,6 @@ static int adv7842_core_init(struct v4l2_subdev *sd)
enable_input(sd);
- /* disable I2C access to internal EDID ram from HDMI DDC ports */
- rep_write_and_or(sd, 0x77, 0xf3, 0x00);
-
if (pdata-hpa_auto) {
/* HPA auto, HPA 0.5s after Edid set and Cable detect */
hdmi_write(sd, 0x69, 0x5c);
--
1.8.5.3
--
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
[PATCH 0/3] [media] adv7842 fixes
This patch series applies a few fixes for adv7842 from Cisco's internal tree. -- 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: [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
[PATCH 0/3] [media] ths8200 fixes
This patch series applies a few fixes for ths8200 from Cisco's internal tree. -- 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
[PATCH 1/3] [media] ths8200: Zero blanking level for RGB.
Currently only RGB444 input data is supported so set to zero. Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/i2c/ths8200.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c index 04139ee..5c7dca3 100644 --- a/drivers/media/i2c/ths8200.c +++ b/drivers/media/i2c/ths8200.c @@ -217,8 +217,8 @@ static void ths8200_core_init(struct v4l2_subdev *sd) /* Disable embedded syncs on the output by setting * the amplitude to zero for all channels. */ - ths8200_write(sd, THS8200_DTG1_Y_SYNC_MSB, 0x2a); - ths8200_write(sd, THS8200_DTG1_CBCR_SYNC_MSB, 0x2a); + ths8200_write(sd, THS8200_DTG1_Y_SYNC_MSB, 0x00); + ths8200_write(sd, THS8200_DTG1_CBCR_SYNC_MSB, 0x00); } static void ths8200_setup(struct v4l2_subdev *sd, struct v4l2_bt_timings *bt) -- 1.8.1.4 -- 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
[PATCH 3/3] [media] ths8200: Format adjustment.
Closer inspection on excact transmitted format showed that
we needed to add 1 on vertical sync.
Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/ths8200.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c
index bcacf52..f72561e 100644
--- a/drivers/media/i2c/ths8200.c
+++ b/drivers/media/i2c/ths8200.c
@@ -318,15 +318,15 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct
v4l2_bt_timings *bt)
(htotal(bt) 8) 0x1f);
ths8200_write(sd, THS8200_DTG2_HLENGTH_HDLY_LSB, htotal(bt));
- /* v sync width transmitted */
- ths8200_write(sd, THS8200_DTG2_VLENGTH1_LSB, (bt-vsync) 0xff);
+ /* v sync width transmitted (must add 1 to get correct output) */
+ ths8200_write(sd, THS8200_DTG2_VLENGTH1_LSB, (bt-vsync + 1) 0xff);
ths8200_write_and_or(sd, THS8200_DTG2_VLENGTH1_MSB_VDLY1_MSB, 0x3f,
-((bt-vsync) 2) 0xc0);
+((bt-vsync + 1) 2) 0xc0);
- /* The pixel value v sync is asserted on */
+ /* The pixel value v sync is asserted on (must add 1 to get correct
output) */
ths8200_write_and_or(sd, THS8200_DTG2_VLENGTH1_MSB_VDLY1_MSB, 0xf8,
-(vtotal(bt)8) 0x7);
- ths8200_write(sd, THS8200_DTG2_VDLY1_LSB, vtotal(bt));
+((vtotal(bt) + 1) 8) 0x7);
+ ths8200_write(sd, THS8200_DTG2_VDLY1_LSB, vtotal(bt) + 1);
/* For progressive video vlength2 must be set to all 0 and vdly2 must
* be set to all 1.
@@ -336,11 +336,11 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct
v4l2_bt_timings *bt)
ths8200_write(sd, THS8200_DTG2_VDLY2_LSB, 0xff);
/* Internal delay factors to synchronize the sync pulses and the data */
- /* Experimental values delays (hor 4, ver 1) */
- ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_MSB, (htotal(bt)8) 0x1f);
- ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_LSB, (htotal(bt) - 4) 0xff);
+ /* Experimental values delays (hor 0, ver 0) */
+ ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_MSB, 0);
+ ths8200_write(sd, THS8200_DTG2_HS_IN_DLY_LSB, 0);
ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_MSB, 0);
- ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_LSB, 1);
+ ths8200_write(sd, THS8200_DTG2_VS_IN_DLY_LSB, 0);
/* Polarity of received and transmitted sync signals */
if (bt-polarities V4L2_DV_HSYNC_POS_POL) {
--
1.8.1.4
--
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
[PATCH 2/3] [media] ths8200: Corrected sync polarities setting.
HS_IN/VS_IN was always set to positive. Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/i2c/ths8200.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/ths8200.c b/drivers/media/i2c/ths8200.c index 5c7dca3..bcacf52 100644 --- a/drivers/media/i2c/ths8200.c +++ b/drivers/media/i2c/ths8200.c @@ -356,7 +356,7 @@ static void ths8200_setup(struct v4l2_subdev *sd, struct v4l2_bt_timings *bt) /* Timing of video input bus is derived from HS, VS, and FID dedicated * inputs */ - ths8200_write(sd, THS8200_DTG2_CNTL, 0x47 | polarity); + ths8200_write(sd, THS8200_DTG2_CNTL, 0x44 | polarity); /* leave reset */ ths8200_s_stream(sd, true); -- 1.8.1.4 -- 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
[PATCH] [media] adv7842: Composite free-run platfrom-data fix
Incorrectly setting of free-run for Composite. Copy/paste regression fix. Should go to kernel 3.14. Cc: Hans Verkuil hansv...@cisco.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/i2c/adv7842.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c index 1effc21..9bbd665 100644 --- a/drivers/media/i2c/adv7842.c +++ b/drivers/media/i2c/adv7842.c @@ -2554,7 +2554,7 @@ static int adv7842_core_init(struct v4l2_subdev *sd) sdp_write_and_or(sd, 0xdd, 0xf0, pdata-sdp_free_run_force | (pdata-sdp_free_run_cbar_en 1) | (pdata-sdp_free_run_man_col_en 2) | -(pdata-sdp_free_run_force 3)); +(pdata-sdp_free_run_auto 3)); /* TODO from platform data */ cp_write(sd, 0x69, 0x14); /* Enable CP CSC */ -- 1.8.1.4 -- 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
[PATCH 3/4] [media] adv7842: log-status for Audio Video Info frames (AVI)
Clear any pending AVI checksum-errors.
To be able to display last received AVI.
Cc: Mats Randgaard matra...@cisco.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 3aa1a7c..209b175 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2191,7 +2191,8 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
{
int i;
uint8_t buf[14];
- uint8_t avi_inf_len;
+ u8 avi_len;
+ u8 avi_ver;
struct avi_info_frame avi;
if (!(hdmi_read(sd, 0x05) 0x80)) {
@@ -2204,18 +2205,20 @@ static void print_avi_infoframe(struct v4l2_subdev *sd)
}
if (io_read(sd, 0x88) 0x10) {
- /* Note: the ADV7842 calculated incorrect checksums for
InfoFrames
- with a length of 14 or 15. See the ADV7842 Register Settings
- Recommendations document for more details. */
- v4l2_info(sd, AVI infoframe checksum error\n);
- return;
+ v4l2_info(sd, AVI infoframe checksum error has occurred
earlier\n);
+ io_write(sd, 0x8a, 0x10); /* clear AVI_INF_CKS_ERR_RAW */
+ if (io_read(sd, 0x88) 0x10) {
+ v4l2_info(sd, AVI infoframe checksum error still
present\n);
+ io_write(sd, 0x8a, 0x10); /* clear AVI_INF_CKS_ERR_RAW
*/
+ }
}
- avi_inf_len = infoframe_read(sd, 0xe2);
+ avi_len = infoframe_read(sd, 0xe2);
+ avi_ver = infoframe_read(sd, 0xe1);
v4l2_info(sd, AVI infoframe version %d (%d byte)\n,
- infoframe_read(sd, 0xe1), avi_inf_len);
+ avi_ver, avi_len);
- if (infoframe_read(sd, 0xe1) != 0x02)
+ if (avi_ver != 0x02)
return;
for (i = 0; i 14; i++)
--
1.8.1.4
--
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
[PATCH 4/4] [media] adv7842: platform-data for Hotplug Active (HPA) manual/auto
This apply to HDMI-map register 0x69.
So far we have been using HPA manual mode.
This way we had control of HPA which could be
set after EDID had been programmed.
Using a Mac Mini with mini-displayport to DVI-D converter as source
caused the adv7842 to lock up and fail to detect any further signals.
After experimenting with different configurations it was found that
using the HPA auto mode and in addition letting RX-termination
be controlled by HPA prevented this error from occuring.
I was not able to re-create this problem on the adv7604.
Cc: Mats Randgaard matra...@cisco.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 12 +---
include/media/adv7842.h | 3 +++
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 209b175..e04fe3f 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -2693,9 +2693,15 @@ static int adv7842_core_init(struct v4l2_subdev *sd)
/* disable I2C access to internal EDID ram from HDMI DDC ports */
rep_write_and_or(sd, 0x77, 0xf3, 0x00);
- hdmi_write(sd, 0x69, 0xa3); /* HPA manual */
- /* HPA disable on port A and B */
- io_write_and_or(sd, 0x20, 0xcf, 0x00);
+ if (pdata-hpa_auto) {
+ /* HPA auto, HPA 0.5s after Edid set and Cable detect */
+ hdmi_write(sd, 0x69, 0x5c);
+ } else {
+ /* HPA manual */
+ hdmi_write(sd, 0x69, 0xa3);
+ /* HPA disable on port A and B */
+ io_write_and_or(sd, 0x20, 0xcf, 0x00);
+ }
/* LLC */
io_write(sd, 0x19, 0x80 | pdata-llc_dll_phase);
diff --git a/include/media/adv7842.h b/include/media/adv7842.h
index 3932209..924cbb8 100644
--- a/include/media/adv7842.h
+++ b/include/media/adv7842.h
@@ -220,6 +220,9 @@ struct adv7842_platform_data {
unsigned sdp_free_run_cbar_en:1;
unsigned sdp_free_run_force:1;
+ /* HPA manual (0) or auto (1), affects HDMI register 0x69 */
+ unsigned hpa_auto:1;
+
struct adv7842_sdp_csc_coeff sdp_csc_coeff;
struct adv7842_sdp_io_sync_adjustment sdp_io_sync_625;
--
1.8.1.4
--
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
[PATCH 1/4] [media] adv7842: adjust gain and offset for DVI-D signals
If the input signal is DVI-D and quantization range is RGB full range,
gain and offset must be adjusted to get the right range on the output.
Copied and adopted from adv7604.
Cc: Mats Randgaard matra...@cisco.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 109
1 file changed, 99 insertions(+), 10 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index 1effc21..f7a4d79 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -546,6 +546,14 @@ static void main_reset(struct v4l2_subdev *sd)
/* --- */
+static inline bool is_analog_input(struct v4l2_subdev *sd)
+{
+ struct adv7842_state *state = to_state(sd);
+
+ return ((state-mode == ADV7842_MODE_RGB) ||
+ (state-mode == ADV7842_MODE_COMP));
+}
+
static inline bool is_digital_input(struct v4l2_subdev *sd)
{
struct adv7842_state *state = to_state(sd);
@@ -1027,12 +1035,72 @@ static void configure_custom_video_timings(struct
v4l2_subdev *sd,
cp_write(sd, 0xac, (height 0x0f) 4);
}
+static void adv7842_set_offset(struct v4l2_subdev *sd, bool auto_offset, u16
offset_a, u16 offset_b, u16 offset_c)
+{
+ struct adv7842_state *state = to_state(sd);
+ u8 offset_buf[4];
+
+ if (auto_offset) {
+ offset_a = 0x3ff;
+ offset_b = 0x3ff;
+ offset_c = 0x3ff;
+ }
+
+ v4l2_dbg(2, debug, sd, %s: %s offset: a = 0x%x, b = 0x%x, c = 0x%x\n,
+__func__, auto_offset ? Auto : Manual,
+offset_a, offset_b, offset_c);
+
+ offset_buf[0]= (cp_read(sd, 0x77) 0xc0) | ((offset_a 0x3f0) 4);
+ offset_buf[1] = ((offset_a 0x00f) 4) | ((offset_b 0x3c0) 6);
+ offset_buf[2] = ((offset_b 0x03f) 2) | ((offset_c 0x300) 8);
+ offset_buf[3] = offset_c 0x0ff;
+
+ /* Registers must be written in this order with no i2c access in
between */
+ if (adv_smbus_write_i2c_block_data(state-i2c_cp, 0x77, 4, offset_buf))
+ v4l2_err(sd, %s: i2c error writing to CP reg 0x77, 0x78, 0x79,
0x7a\n, __func__);
+}
+
+static void adv7842_set_gain(struct v4l2_subdev *sd, bool auto_gain, u16
gain_a, u16 gain_b, u16 gain_c)
+{
+ struct adv7842_state *state = to_state(sd);
+ u8 gain_buf[4];
+ u8 gain_man = 1;
+ u8 agc_mode_man = 1;
+
+ if (auto_gain) {
+ gain_man = 0;
+ agc_mode_man = 0;
+ gain_a = 0x100;
+ gain_b = 0x100;
+ gain_c = 0x100;
+ }
+
+ v4l2_dbg(2, debug, sd, %s: %s gain: a = 0x%x, b = 0x%x, c = 0x%x\n,
+__func__, auto_gain ? Auto : Manual,
+gain_a, gain_b, gain_c);
+
+ gain_buf[0] = ((gain_man 7) | (agc_mode_man 6) | ((gain_a
0x3f0) 4));
+ gain_buf[1] = (((gain_a 0x00f) 4) | ((gain_b 0x3c0) 6));
+ gain_buf[2] = (((gain_b 0x03f) 2) | ((gain_c 0x300) 8));
+ gain_buf[3] = ((gain_c 0x0ff));
+
+ /* Registers must be written in this order with no i2c access in
between */
+ if (adv_smbus_write_i2c_block_data(state-i2c_cp, 0x73, 4, gain_buf))
+ v4l2_err(sd, %s: i2c error writing to CP reg 0x73, 0x74, 0x75,
0x76\n, __func__);
+}
+
static void set_rgb_quantization_range(struct v4l2_subdev *sd)
{
struct adv7842_state *state = to_state(sd);
+ bool rgb_output = io_read(sd, 0x02) 0x02;
+ bool hdmi_signal = hdmi_read(sd, 0x05) 0x80;
+
+ v4l2_dbg(2, debug, sd, %s: RGB quantization range: %d, RGB out: %d,
HDMI: %d\n,
+ __func__, state-rgb_quantization_range,
+ rgb_output, hdmi_signal);
- v4l2_dbg(2, debug, sd, %s: rgb_quantization_range = %d\n,
- __func__, state-rgb_quantization_range);
+ adv7842_set_gain(sd, true, 0x0, 0x0, 0x0);
+ adv7842_set_offset(sd, true, 0x0, 0x0, 0x0);
switch (state-rgb_quantization_range) {
case V4L2_DV_RGB_RANGE_AUTO:
@@ -1050,7 +1118,7 @@ static void set_rgb_quantization_range(struct v4l2_subdev
*sd)
break;
}
- if (hdmi_read(sd, 0x05) 0x80) {
+ if (hdmi_signal) {
/* Receiving HDMI signal
* Set automode */
io_write_and_or(sd, 0x02, 0x0f, 0xf0);
@@ -1066,24 +1134,45 @@ static void set_rgb_quantization_range(struct
v4l2_subdev *sd)
} else {
/* RGB full range (0-255) */
io_write_and_or(sd, 0x02, 0x0f, 0x10);
+
+ if (is_digital_input(sd) rgb_output) {
+ adv7842_set_offset(sd, false, 0x40, 0x40, 0x40);
+ } else
[PATCH 0/4] [media] adv7842 fixes
This patch series applies a few fixes for adv7842 from Cisco's internal tree. -- 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
[PATCH 2/4] [media] adv7842: pixelclock read-out
Incorrect registers used for pixelclock read-out.
Same registers as for adv7604 which actually gave an almost
correct read-out, even they are not documented for adv7842.
Corrected deep-color pixel-clock correction.
Cc: Mats Randgaard matra...@cisco.com
Cc: Hans Verkuil hans.verk...@cisco.com
Signed-off-by: Martin Bugge marbu...@cisco.com
---
drivers/media/i2c/adv7842.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/media/i2c/adv7842.c b/drivers/media/i2c/adv7842.c
index f7a4d79..3aa1a7c 100644
--- a/drivers/media/i2c/adv7842.c
+++ b/drivers/media/i2c/adv7842.c
@@ -1449,12 +1449,11 @@ static int adv7842_query_dv_timings(struct v4l2_subdev
*sd,
bt-width = (hdmi_read(sd, 0x07) 0x0f) * 256 + hdmi_read(sd,
0x08);
bt-height = (hdmi_read(sd, 0x09) 0x0f) * 256 + hdmi_read(sd,
0x0a);
- freq = (hdmi_read(sd, 0x06) * 100) +
- ((hdmi_read(sd, 0x3b) 0x30) 4) * 25;
-
+ freq = ((hdmi_read(sd, 0x51) 1) + (hdmi_read(sd, 0x52)
7)) * 100;
+ freq += ((hdmi_read(sd, 0x52) 0x7f) * 7813);
if (is_hdmi(sd)) {
/* adjust for deep color mode */
- freq = freq * 8 / (((hdmi_read(sd, 0x0b) 0xc0) 5)
+ 8);
+ freq = freq * 8 / (((hdmi_read(sd, 0x0b) 0xc0) 6)
* 2 + 8);
}
bt-pixelclock = freq;
bt-hfrontporch = (hdmi_read(sd, 0x20) 0x03) * 256 +
--
1.8.1.4
--
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
[PATCH] [media] v4l2-dv-timings: fix GTF calculation
Round off image width to nearest 8 (GTF_CELL_GRAN) A source sending a GTF (Generalized Timing Formula) format have no means of signalling image width. The assumed aspect ratio may result in an odd image width but according to the standard image width should be in multiple of 8. Cc: Mats Randgaard matra...@cisco.com Cc: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Martin Bugge marbu...@cisco.com --- drivers/media/v4l2-core/v4l2-dv-timings.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/v4l2-core/v4l2-dv-timings.c b/drivers/media/v4l2-core/v4l2-dv-timings.c index ee52b9f4..f7902fe 100644 --- a/drivers/media/v4l2-core/v4l2-dv-timings.c +++ b/drivers/media/v4l2-core/v4l2-dv-timings.c @@ -515,6 +515,7 @@ bool v4l2_detect_gtf(unsigned frame_height, aspect.denominator = 9; } image_width = ((image_height * aspect.numerator) / aspect.denominator); + image_width = (image_width + GTF_CELL_GRAN/2) ~(GTF_CELL_GRAN - 1); /* Horizontal */ if (default_gtf) -- 1.8.1.4 -- 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
CEA-861-D table 11 for details. * Q1, Q0Quantization range (Full vs. Limited, etc.). See CEA-861-D table 11 for details. * ITC IT Content. See CEA-861-D table 11 for details. * M0, M1Picture Aspect Ratio (4:3, 16:9). See CEA-861-D table 9 for details. * R0...R3 Active Format Aspect Ratio. See CEA-861-D table 10 and Annex H for details. * VIC0...VIC6 Video Format Identification Code. When transmitting any video format in section 6.2.4, above, an HDMI Source shall set the VIC field to the Video Code for that format. See CEA-861-D section 6.4 for details. * PR0...PR3 Pixel Repetition factor. See CEA-861-D table 13 for details. * SC1, SC0 Non-uniform Picture Scaling. See CEA-861-D table 11. A lot of these handle colorspace information. It is not clear yet whether this should be set up using S_FMT/mediabus APIs, or by explicit controls. 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
[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
