Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
Hi Olli, in saa716x_budget.c I've also got (for TBS6285) si2168_config.i2c_adapter = i2cadapter; si2168_config.fe = adapter-fe; si2168_config.ts_mode = SI2168_TS_SERIAL; memset(info, 0, sizeof(struct i2c_board_info)); Should I just add it like this? si2168_config.ts_mode = SI2168_TS_SERIAL; si2168_config.ts_clock_gapped = true; memset(info, 0, sizeof(struct i2c_board_info)); Kind regards, Tycho. Op 23-04-15 om 23:11 schreef Olli Salonen: Change the dvbsky driver to support gapped clock instead of the current hack. Signed-off-by: Olli Salonen olli.salo...@iki.fi --- drivers/media/usb/dvb-usb-v2/dvbsky.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index cdf59bc..0f73b1d 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -615,7 +615,8 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap) memset(si2168_config, 0, sizeof(si2168_config)); si2168_config.i2c_adapter = i2c_adapter; si2168_config.fe = adap-fe[0]; - si2168_config.ts_mode = SI2168_TS_PARALLEL | 0x40; + si2168_config.ts_mode = SI2168_TS_PARALLEL; + si2168_config.ts_clock_gapped = true; memset(info, 0, sizeof(struct i2c_board_info)); strlcpy(info.type, si2168, I2C_NAME_SIZE); info.addr = 0x64; -- 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] [media] vivid: add 1080p capture at 2 fps and 5 fps to webcam emulation
Hi Philipp,
Thank you for the patch, but I have one question:
On 04/23/2015 03:52 PM, Philipp Zabel wrote:
Use the VIVID_WEBCAM_SIZES constant where appropriate and add a 1920x1080
pixel
frame size setting with frame rates of 2 fps and 5 fps.
Why add both 2 and 5 fps? Is there a reason why you want both of those fps
values?
Just wondering.
Regards,
Hans
Signed-off-by: Philipp Zabel p.za...@pengutronix.de
---
drivers/media/platform/vivid/vivid-vid-cap.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-vid-cap.c
b/drivers/media/platform/vivid/vivid-vid-cap.c
index 867a29a..468b8b5 100644
--- a/drivers/media/platform/vivid/vivid-vid-cap.c
+++ b/drivers/media/platform/vivid/vivid-vid-cap.c
@@ -60,7 +60,7 @@ static const struct vivid_fmt formats_ovl[] = {
};
/* The number of discrete webcam framesizes */
-#define VIVID_WEBCAM_SIZES 3
+#define VIVID_WEBCAM_SIZES 4
/* The number of discrete webcam frameintervals */
#define VIVID_WEBCAM_IVALS (VIVID_WEBCAM_SIZES * 2)
@@ -69,6 +69,7 @@ static const struct v4l2_frmsize_discrete
webcam_sizes[VIVID_WEBCAM_SIZES] = {
{ 320, 180 },
{ 640, 360 },
{ 1280, 720 },
+ { 1920, 1080 },
};
/*
@@ -76,6 +77,8 @@ static const struct v4l2_frmsize_discrete
webcam_sizes[VIVID_WEBCAM_SIZES] = {
* elements in this array as there are in webcam_sizes.
*/
static const struct v4l2_fract webcam_intervals[VIVID_WEBCAM_IVALS] = {
+ { 1, 2 },
+ { 1, 5 },
{ 1, 10 },
{ 1, 15 },
{ 1, 25 },
@@ -715,8 +718,8 @@ int vivid_s_fmt_vid_cap(struct file *file, void *priv,
webcam_sizes[i].height == mp-height)
break;
dev-webcam_size_idx = i;
- if (dev-webcam_ival_idx = 2 * (3 - i))
- dev-webcam_ival_idx = 2 * (3 - i) - 1;
+ if (dev-webcam_ival_idx = 2 * (VIVID_WEBCAM_SIZES - i))
+ dev-webcam_ival_idx = 2 * (VIVID_WEBCAM_SIZES - i) - 1;
vivid_update_format_cap(dev, false);
} else {
struct v4l2_rect r = { 0, 0, mp-width, mp-height };
@@ -1684,7 +1687,7 @@ int vidioc_enum_frameintervals(struct file *file, void
*priv,
break;
if (i == ARRAY_SIZE(webcam_sizes))
return -EINVAL;
- if (fival-index = 2 * (3 - i))
+ if (fival-index = 2 * (VIVID_WEBCAM_SIZES - i))
return -EINVAL;
fival-type = V4L2_FRMIVAL_TYPE_DISCRETE;
fival-discrete = webcam_intervals[fival-index];
@@ -1714,7 +1717,7 @@ int vivid_vid_cap_s_parm(struct file *file, void *priv,
struct v4l2_streamparm *parm)
{
struct vivid_dev *dev = video_drvdata(file);
- unsigned ival_sz = 2 * (3 - dev-webcam_size_idx);
+ unsigned ival_sz = 2 * (VIVID_WEBCAM_SIZES - dev-webcam_size_idx);
struct v4l2_fract tpf;
unsigned i;
--
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] cx18: add missing caps for the PCM video device
The cx18 PCM video device didn't have any capabilities set, which caused a
warnings
in the v4l2 core:
[6.229393] [ cut here ]
[6.229414] WARNING: CPU: 1 PID: 593 at
drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70
[videodev]()
[6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi
x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel
snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel
snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt
snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul
crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel
videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat
dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev
mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis
mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper
[6.229444] drm ptp pps_core video
[6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted
3.19.3-200.fc21.x86_64 #1
[6.229447] Hardware name: Gigabyte Technology Co., Ltd.
Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014
[6.229448] d12b1131 88042dacfc28
8176e215
[6.229449] 88042dacfc68
8109bc1a
[6.229451] a0594000 88042dacfd90
a04e2140
[6.229452] Call Trace:
[6.229466] [8176e215] dump_stack+0x45/0x57
[6.229469] [8109bc1a] warn_slowpath_common+0x8a/0xc0
[6.229472] [8109bd4a] warn_slowpath_null+0x1a/0x20
[6.229474] [a04ca401] v4l_querycap+0x41/0x70 [videodev]
[6.229477] [a04ca6cc] __video_do_ioctl+0x29c/0x320 [videodev]
[6.229479] [81227131] ? do_last+0x2f1/0x1210
[6.229491] [a04cc776] video_usercopy+0x366/0x5d0 [videodev]
[6.229494] [a04ca430] ? v4l_querycap+0x70/0x70 [videodev]
[6.229497] [a04cc9f5] video_ioctl2+0x15/0x20 [videodev]
[6.229499] [a04c6794] v4l2_ioctl+0x164/0x180 [videodev]
[6.229501] [8122e298] do_vfs_ioctl+0x2f8/0x500
[6.229502] [8122e521] SyS_ioctl+0x81/0xa0
[6.229505] [81774a09] system_call_fastpath+0x12/0x17
[6.229506] ---[ end trace dacd80d4b19277ea ]---
Added the necessary capabilities to stop this warning.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Laura Abbott labb...@redhat.com
Cc: sta...@vger.kernel.org # for v3.19 and up
---
diff --git a/drivers/media/pci/cx18/cx18-streams.c
b/drivers/media/pci/cx18/cx18-streams.c
index c82d25d..c986084 100644
--- a/drivers/media/pci/cx18/cx18-streams.c
+++ b/drivers/media/pci/cx18/cx18-streams.c
@@ -90,6 +90,7 @@ static struct {
encoder PCM audio,
VFL_TYPE_GRABBER, CX18_V4L2_ENC_PCM_OFFSET,
PCI_DMA_FROMDEVICE,
+ V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
},
{ /* CX18_ENC_STREAM_TYPE_IDX */
encoder IDX,
--
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: Missing additional V4L2 caps in cx18
Hi Laura,
Thanks for the report. I've made a patch and CC-ed you on it.
The TS and IDX streams are internal (i.e., they do not map to a V4L2
device node), but the PCM stream isn't, and that's the one causing the
warning.
Regards,
Hans
On 04/23/2015 07:57 PM, Laura Abbott wrote:
Hi,
We received a report of a backtrace from v4l2 with
the cx18 module:
[6.229393] [ cut here ]
[6.229414] WARNING: CPU: 1 PID: 593 at
drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70
[videodev]()
[6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi
x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel
snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel
snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt
snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul
crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel
videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat
dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev
mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis
mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper
[6.229444] drm ptp pps_core video
[6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted
3.19.3-200.fc21.x86_64 #1
[6.229447] Hardware name: Gigabyte Technology Co., Ltd.
Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014
[6.229448] d12b1131 88042dacfc28
8176e215
[6.229449] 88042dacfc68
8109bc1a
[6.229451] a0594000 88042dacfd90
a04e2140
[6.229452] Call Trace:
[6.229466] [8176e215] dump_stack+0x45/0x57
[6.229469] [8109bc1a] warn_slowpath_common+0x8a/0xc0
[6.229472] [8109bd4a] warn_slowpath_null+0x1a/0x20
[6.229474] [a04ca401] v4l_querycap+0x41/0x70 [videodev]
[6.229477] [a04ca6cc] __video_do_ioctl+0x29c/0x320 [videodev]
[6.229479] [81227131] ? do_last+0x2f1/0x1210
[6.229491] [a04cc776] video_usercopy+0x366/0x5d0 [videodev]
[6.229494] [a04ca430] ? v4l_querycap+0x70/0x70 [videodev]
[6.229497] [a04cc9f5] video_ioctl2+0x15/0x20 [videodev]
[6.229499] [a04c6794] v4l2_ioctl+0x164/0x180 [videodev]
[6.229501] [8122e298] do_vfs_ioctl+0x2f8/0x500
[6.229502] [8122e521] SyS_ioctl+0x81/0xa0
[6.229505] [81774a09] system_call_fastpath+0x12/0x17
[6.229506] ---[ end trace dacd80d4b19277ea ]---
This is the warning about querycap not filling device_caps properly.
The tree has dfdf780b4651cf4932b96d3fe296230afacc360a
('[media] cx18: add device_caps support') present already but
I noticed several of the streams types are missing capabilities
in cx18-streams.c (CX18_ENC_STREAM_TYPE_TS, CX18_ENC_STREAM_TYPE_PCM,
CX18_ENC_STREAM_TYPE_IDX)
Do these need to have proper capabilities added as well to silence
this warning?
Thanks,
Laura
--
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: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
One more question: cx23885-dvb.c (and maybe others) contains a couple of instances of si2168_config.ts_mode = SI2168_TS_PARALLEL; and si2168_config.ts_mode = SI2168_TS_SERIAL; But you don't patch them with si2168_config.ts_clock_gapped = true; Is this intentional? Kind regards, Tycho Op 23-04-15 om 23:11 schreef Olli Salonen: Change the dvbsky driver to support gapped clock instead of the current hack. Signed-off-by: Olli Salonen olli.salo...@iki.fi --- drivers/media/usb/dvb-usb-v2/dvbsky.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index cdf59bc..0f73b1d 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -615,7 +615,8 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap) memset(si2168_config, 0, sizeof(si2168_config)); si2168_config.i2c_adapter = i2c_adapter; si2168_config.fe = adap-fe[0]; - si2168_config.ts_mode = SI2168_TS_PARALLEL | 0x40; + si2168_config.ts_mode = SI2168_TS_PARALLEL; + si2168_config.ts_clock_gapped = true; memset(info, 0, sizeof(struct i2c_board_info)); strlcpy(info.type, si2168, I2C_NAME_SIZE); info.addr = 0x64; -- 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 v2 1/2] gspca: sn9c2028: Add support for Genius Videocam Live v2
This cam seems to return different values on long commands, so make status check
in sn9c2028_long_command() more tolerant. Anyway, read value isn't used anywhere
later.
Signed-off-by: Vasily Khoruzhick anars...@gmail.com
---
v2: update commit message to explain change in sn9c2028_long_command()
drivers/media/usb/gspca/sn9c2028.c | 120 -
1 file changed, 119 insertions(+), 1 deletion(-)
diff --git a/drivers/media/usb/gspca/sn9c2028.c
b/drivers/media/usb/gspca/sn9c2028.c
index 39b6b2e..317b02c 100644
--- a/drivers/media/usb/gspca/sn9c2028.c
+++ b/drivers/media/usb/gspca/sn9c2028.c
@@ -2,6 +2,7 @@
* SN9C2028 library
*
* Copyright (C) 2009 Theodore Kilgore kilg...@auburn.edu
+ * Copyright (C) 2015 Vasily Khoruzhick anars...@gmail.com
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
@@ -128,7 +129,7 @@ static int sn9c2028_long_command(struct gspca_dev
*gspca_dev, u8 *command)
status = -1;
for (i = 0; i 256 status 2; i++)
status = sn9c2028_read1(gspca_dev);
- if (status != 2) {
+ if (status 0) {
pr_err(long command status read error %d\n, status);
return (status 0) ? status : -EIO;
}
@@ -178,6 +179,9 @@ static int sd_config(struct gspca_dev *gspca_dev,
case 0x7005:
PDEBUG(D_PROBE, Genius Smart 300 camera);
break;
+ case 0x7003:
+ PDEBUG(D_PROBE, Genius Videocam Live v2);
+ break;
case 0x8000:
PDEBUG(D_PROBE, DC31VC);
break;
@@ -530,6 +534,116 @@ static int start_genius_cam(struct gspca_dev *gspca_dev)
ARRAY_SIZE(genius_start_commands));
}
+static int start_genius_videocam_live(struct gspca_dev *gspca_dev)
+{
+ int r;
+ struct sd *sd = (struct sd *) gspca_dev;
+ struct init_command genius_vcam_live_start_commands[] = {
+ {{0x0c, 0x01, 0x00, 0x00, 0x00, 0x00}, 0},
+ {{0x16, 0x01, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x10, 0x00, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x11, 0x20, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x21, 0x2d, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x22, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x23, 0x03, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x14, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x15, 0x20, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x16, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x17, 0x60, 0x00, 0x00, 0x00}, 4},
+ {{0x1c, 0x20, 0x00, 0x2d, 0x00, 0x00}, 4},
+ {{0x13, 0x20, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x21, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x22, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x23, 0x01, 0x01, 0x00, 0x00}, 4},
+ {{0x13, 0x24, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x25, 0x01, 0x16, 0x00, 0x00}, 4},
+ {{0x13, 0x26, 0x01, 0x12, 0x00, 0x00}, 4},
+ {{0x13, 0x27, 0x01, 0x20, 0x00, 0x00}, 4},
+ {{0x13, 0x28, 0x01, 0x0e, 0x00, 0x00}, 4},
+ {{0x13, 0x29, 0x01, 0x22, 0x00, 0x00}, 4},
+ {{0x13, 0x2a, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2b, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x2c, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2d, 0x01, 0x02, 0x00, 0x00}, 4},
+ {{0x13, 0x2e, 0x01, 0x09, 0x00, 0x00}, 4},
+ {{0x13, 0x2f, 0x01, 0x07, 0x00, 0x00}, 4},
+ {{0x12, 0x34, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x13, 0x34, 0x01, 0xa1, 0x00, 0x00}, 4},
+ {{0x13, 0x35, 0x01, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x01, 0x04, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x02, 0x92, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x10, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x11, 0x64, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x12, 0x00, 0x00, 0x00, 0x00}, 4},
+ {{0x11, 0x13, 0x91, 0x00, 0x00, 0x00}, 4},
Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
Hi Tycho, Yes, so far the only device that I know should use gapped clock is the DVBSky T330 a.k.a. TechnoTrend CT2-4400. I've also seen that the Hauppauge HVR-2205 Windows driver enables this option, but it seems to me that that board works ok also without this. Cheers, -olli On 24 April 2015 at 09:01, Olli Salonen olli.salo...@iki.fi wrote: Hi Tycho, Yes, so far the only device that I know should use gapped clock is the DVBSky T330 a.k.a. TechnoTrend CT2-4400. I've also seen that the Hauppauge HVR-2205 Windows driver enables this option, but it seems to me that that board works ok also without this. Cheers, -olli On 24 April 2015 at 08:57, Tycho Lürsen tycholur...@gmail.com wrote: One more question: cx23885-dvb.c (and maybe others) contains a couple of instances of si2168_config.ts_mode = SI2168_TS_PARALLEL; and si2168_config.ts_mode = SI2168_TS_SERIAL; But you don't patch them with si2168_config.ts_clock_gapped = true; Is this intentional? Kind regards, Tycho Op 23-04-15 om 23:11 schreef Olli Salonen: Change the dvbsky driver to support gapped clock instead of the current hack. Signed-off-by: Olli Salonen olli.salo...@iki.fi --- drivers/media/usb/dvb-usb-v2/dvbsky.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c b/drivers/media/usb/dvb-usb-v2/dvbsky.c index cdf59bc..0f73b1d 100644 --- a/drivers/media/usb/dvb-usb-v2/dvbsky.c +++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c @@ -615,7 +615,8 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap) memset(si2168_config, 0, sizeof(si2168_config)); si2168_config.i2c_adapter = i2c_adapter; si2168_config.fe = adap-fe[0]; - si2168_config.ts_mode = SI2168_TS_PARALLEL | 0x40; + si2168_config.ts_mode = SI2168_TS_PARALLEL; + si2168_config.ts_clock_gapped = true; memset(info, 0, sizeof(struct i2c_board_info)); strlcpy(info.type, si2168, I2C_NAME_SIZE); info.addr = 0x64; -- 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
[GIT PULL FOR v4.2] Various fixes
The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.2d for you to fetch changes up to 01dcae42e1d19014a6c83258bc4944b56b111372: usbtv: fix v4l2-compliance issues (2015-04-24 10:09:46 +0200) Cheolhyun Park (1): drx-j: Misspelled comment corrected Dan Carpenter (1): i2c: ov2659: signedness bug inov2659_set_fmt() Geert Uytterhoeven (3): v4l: xilinx: VIDEO_XILINX should depend on HAS_DMA v4l: VIDEOBUF2_DMA_SG should depend on HAS_DMA Input: TOUCHSCREEN_SUR40 should depend on HAS_DMA Hans Verkuil (7): cx88: v4l2-compliance fixes bttv: fix missing irq after reloading driver DocBook/media: fix typo DocBook/media: Improve G_EDID specification saa7164: fix querycap warning cx18: add missing caps for the PCM video device usbtv: fix v4l2-compliance issues Jan Kara (1): vb2: Push mmap_sem down to memops Julia Lawall (3): si4713: fix error return code as102: fix error return code radio: fix error return code Lad, Prabhakar (1): media: i2c: ov2659: add VIDEO_V4L2_SUBDEV_API dependency Prashant Laddha (4): v4l2-dv-timings: fix rounding error in vsync_bp calculation v4l2-dv-timings: fix rounding in hblank and hsync calculation v4l2-dv-timings: add sanity checks in cvt,gtf calculations v4l2-dv-timings: replace hsync magic number with a macro Steven Toth (6): saa7164: I2C improvements for upcoming HVR2255/2205 boards saa7164: Adding additional I2C debug. saa7164: Improvements for I2C handling saa7164: Add Digital TV support for the HVR2255 and HVR2205 saa7164: Copyright update saa7164: fix HVR2255 ATSC inversion issue jean-michel.hautb...@vodalys.com (1): media: adv7604: Fix masks used for querying timings in ADV7611 Documentation/DocBook/media/v4l/controls.xml | 4 +- Documentation/DocBook/media/v4l/vidioc-g-edid.xml | 7 +++ drivers/input/touchscreen/Kconfig | 3 +- drivers/media/dvb-frontends/drx39xyj/drxj.c | 38 ++-- drivers/media/i2c/Kconfig | 2 +- drivers/media/i2c/adv7604.c | 69 +- drivers/media/i2c/ov2659.c| 2 +- drivers/media/pci/bt8xx/bttv-driver.c | 2 + drivers/media/pci/cx18/cx18-streams.c | 1 + drivers/media/pci/cx88/cx88-core.c| 2 + drivers/media/pci/cx88/cx88-mpeg.c| 6 +- drivers/media/pci/cx88/cx88-vbi.c | 6 +- drivers/media/pci/cx88/cx88-video.c | 7 +-- drivers/media/pci/cx88/cx88.h | 1 - drivers/media/pci/saa7164/saa7164-api.c | 21 +-- drivers/media/pci/saa7164/saa7164-buffer.c| 2 +- drivers/media/pci/saa7164/saa7164-bus.c | 2 +- drivers/media/pci/saa7164/saa7164-cards.c | 188 +++- drivers/media/pci/saa7164/saa7164-cmd.c | 2 +- drivers/media/pci/saa7164/saa7164-core.c | 2 +- drivers/media/pci/saa7164/saa7164-dvb.c | 232 +- drivers/media/pci/saa7164/saa7164-encoder.c | 13 +++-- drivers/media/pci/saa7164/saa7164-fw.c| 2 +- drivers/media/pci/saa7164/saa7164-i2c.c | 9 +-- drivers/media/pci/saa7164/saa7164-reg.h | 2 +- drivers/media/pci/saa7164/saa7164-types.h | 2 +- drivers/media/pci/saa7164/saa7164-vbi.c | 13 +++-- drivers/media/pci/saa7164/saa7164.h | 7 ++- drivers/media/platform/xilinx/Kconfig | 2 +- drivers/media/radio/radio-timb.c | 4 +- drivers/media/radio/si4713/si4713.c | 4 +- drivers/media/usb/as102/as102_drv.c | 1 + drivers/media/usb/usbtv/usbtv-video.c | 12 ++-- drivers/media/v4l2-core/Kconfig | 2 +- drivers/media/v4l2-core/v4l2-dv-timings.c | 29 +++--- drivers/media/v4l2-core/videobuf2-core.c | 2 - drivers/media/v4l2-core/videobuf2-dma-contig.c| 7 +++ drivers/media/v4l2-core/videobuf2-dma-sg.c| 6 ++ drivers/media/v4l2-core/videobuf2-vmalloc.c | 6 +- 39 files changed, 605 insertions(+), 117 deletions(-) -- 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 v4 00/17] media: blackfin: bfin_capture enhancements
On 04/10/2015 12:42 PM, Scott Jiang wrote: Hi Hans, Hans, I tried to use v4l2-compliance but it failed to compile. Sorry for telling you it have passed compilation because I forgot to use blackfin toolchain. ./configure --without-jpeg --host=bfin-linux-uclibc --disable-libv4l The main problem is there is no argp.h in uClibc, how to disable checking this? checking for argp.h... no configure: error: Cannot continue: argp.h not found Scott Hi Scott, Can you try this patch for v4l-utils? It makes argp optional, and it should allow v4l2-compliance to compile with uclibc (unless there are more problems). I'm no autoconf guru, so I'm not certain if everything is correct, but it seemed to do its job when I remove argp.h from my system. Yes, I can pass configure now. But there is another error when make make[3]: Entering directory `/home/scott/projects/git-kernel/v4l-utils/lib/libdvbv5' CC libdvbv5_la-parse_string.lo parse_string.c:26:19: error: iconv.h: No such file or directory parse_string.c: In function 'dvb_iconv_to_charset': parse_string.c:316: error: 'iconv_t' undeclared (first use in this function) I tried to pass this library, while --without-libdvbv5 is not supported. If you can pass the configure step, then you should be able to run this: cd utils/v4l2-compliance cat *.cpp x.cpp g++ -o v4l2-compliance x.cpp -I . -I ../../include/ -DNO_LIBV4L2 (you need to use the right toolchain here, of course) If this compiles OK, then you have a v4l2-compliance tool that you can use. Sorry for the delay in answering. Regards, Hans -- 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 0/9 v2] Helper to abstract vma handling in media layer
Dear All, On 2015-04-02 17:25, Hans Verkuil wrote: On 04/02/2015 05:02 PM, Jan Kara wrote: Hello, On Tue 17-03-15 12:56:30, Jan Kara wrote: After a long pause I'm sending second version of my patch series to abstract vma handling from the various media drivers. After this patch set drivers have to know much less details about vmas, their types, and locking. My motivation for the series is that I want to change get_user_pages() locking and I want to handle subtle locking details in as few places as possible. The core of the series is the new helper get_vaddr_pfns() which is given a virtual address and it fills in PFNs into provided array. If PFNs correspond to normal pages it also grabs references to these pages. The difference from get_user_pages() is that this function can also deal with pfnmap, mixed, and io mappings which is what the media drivers need. I have tested the patches with vivid driver so at least vb2 code got some exposure. Conversion of other drivers was just compile-tested so I'd like to ask respective maintainers if they could have a look. Also I'd like to ask mm folks to check patch 2/9 implementing the helper. Thanks! Ping? Any reactions? For patch 1/9: Acked-by: Hans Verkuil hans.verk...@cisco.com For the other patches I do not feel qualified to give Acks. I've Cc-ed Pawel and Marek who have a better understanding of the mm internals than I do. Hopefully they can review the code. It definitely looks like a good idea, and if nobody else will comment on the vb2 patches in the next 2 weeks, then I'll try to review it myself (for whatever that's worth). I'm really sorry that I didn't manage to find time to review this patchset. I really like the idea of moving pfn lookup from videobuf2/driver to some common code in mm and it is really great that someone managed to provide nice generic code for it. I've applied the whole patchset onto v4.0 and tested it on Odroid U3 (with some additional patches). VideoBuf2-dc works still fine with USERPTR gathered from other's device mmaped buffer. You can add my: Acked-by: Marek Szyprowski m.szyprow...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com for the patches 1-8. Patch 9/9 doesn't apply anymore, so I've skipped it. Patch 2 needs a small fixup - you need to add '#include linux/vmalloc.h', because otherwise it doesn't compile. There have been also a minor conflict to be resolved in patch 7. Best regards -- Marek Szyprowski, PhD Samsung RD Institute Poland -- 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
[GIT PULL FOR v4.2] marvell-ccic fixes
This supersedes https://patchwork.linuxtv.org/patch/29163/. Added two more patches (fix memory leak on failure path in cafe_smbus_setup() and fix V4L2_PIX_FMT_SBGGR8 support). All tested on my OLPC XO laptop. Regards, Hans The following changes since commit e183201b9e917daf2530b637b2f34f1d5afb934d: [media] uvcvideo: add support for VIDIOC_QUERY_EXT_CTRL (2015-04-10 10:29:27 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v4.2a for you to fetch changes up to 3ac439bd9a26d2852f631b5ba90b9fc2bf5deff6: marvell-ccic: fix memory leak on failure path in cafe_smbus_setup() (2015-04-24 11:55:34 +0200) Alexey Khoroshilov (1): marvell-ccic: fix memory leak on failure path in cafe_smbus_setup() Hans Verkuil (19): marvell-ccic: fix vb2 warning marvell-ccic: fill in bus_info marvell-ccic: webcam drivers shouldn't support g/s_std ov7670: check for valid width/height in ov7670_enum_frame_interval marvell-ccic: fill in colorspace marvell-ccic: control handler fixes marvell-ccic: switch to struct v4l2_fh marvell-ccic: implement control events marvell-ccic: use vb2 helpers and core locking marvell-ccic: add create_bufs support marvell-ccic: add DMABUF support for all three DMA modes marvell-ccic: fix streaming issues marvell-ccic: correctly requeue buffers marvell-ccic: add planar support to dma-vmalloc marvell-ccic: drop V4L2_PIX_FMT_JPEG dead code ov7670: use colorspace SRGB instead of JPEG marvell-ccic: fix the bytesperline and sizeimage calculations marvell-ccic: drop support for PIX_FMT_422P marvell-ccic: fix V4L2_PIX_FMT_SBGGR8 support drivers/media/i2c/ov7670.c| 25 - drivers/media/platform/marvell-ccic/cafe-driver.c | 13 ++- drivers/media/platform/marvell-ccic/mcam-core.c | 452 +++--- drivers/media/platform/marvell-ccic/mcam-core.h | 3 +- drivers/media/platform/marvell-ccic/mmp-driver.c | 1 + 5 files changed, 199 insertions(+), 295 deletions(-) -- 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 v5 06/10] media: Add registration helpers for V4L2 flash sub-devices
Hi Sakari,
On Fri, 24 Apr 2015 00:52:12 +0300
Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Jacek,
Jacek Anaszewski wrote:
...
+#define call_flash_op(v4l2_flash, op,
arg) \
+ (has_flash_op(v4l2_flash,
op) ? \
+ v4l2_flash-ops-op(v4l2_flash,
arg) :\
+ -EINVAL)
+
+static enum led_brightness __intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl,
+ s32 intensity)
Fits on previous line.
+{
+ s64 intensity64 = intensity - ctrl-minimum;
intensity, ctrl-step and ctrl-minimum are 32-bit signed integers.
Do you need a 64-bit integer here?
step is u64.
Nevertheless integer controls will not have values outside the s32
range, using a step value that's outside the range makes no sense
either. I think you should use s32 instead.
I infer that local u32 variable should be assigned ctrl-step,
and then used as a divisor.
+
+ do_div(intensity64, ctrl-step);
+
+ /*
+ * Indicator LEDs, unlike torch LEDs, are turned on/off
basing on
+ * the state of V4L2_CID_FLASH_INDICATOR_INTENSITY
control only.
+ * Therefore it must be possible to set it to 0 level
which in
+ * the LED subsystem reflects LED_OFF state.
+ */
+ if (ctrl-id != V4L2_CID_FLASH_INDICATOR_INTENSITY)
+ ++intensity64;
I think the condition could simply be ctrl-minimum instead, that
way I find it easier to understand what's happening here. I'd
expect the minimum for non-intensity controls always to be
non-zero, though, so the end result is the same. Up to you.
Minimum for indicator control must be 0 to make possible
turning the indicator LED off only with this control.
Would torch be still on if the minimum torch current was 0 mA? I'd
say no.
Although in that case I'd expect the driver to use a different range,
and selecting the off mode would then turn it off, I still think
that's a better condition than relying on the control id.
I didn't catch your point previously. Probably you was thinking
about somethig like this:
if (ctrl-minimum)
++intensity;
If so, I agree.
...
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash =
v4l2_ctrl_to_v4l2_flash(c);
+ struct led_classdev_flash *fled_cdev =
v4l2_flash-fled_cdev;
+ bool is_strobing;
+ int ret;
+
+ switch (c-id) {
+ case V4L2_CID_FLASH_TORCH_INTENSITY:
+ case V4L2_CID_FLASH_INDICATOR_INTENSITY:
+ return
v4l2_flash_update_led_brightness(v4l2_flash, c);
+ case V4L2_CID_FLASH_INTENSITY:
+ ret = led_update_flash_brightness(fled_cdev);
+ if (ret 0)
+ return ret;
+ /* no conversion is needed */
Maybe a stupid question, but why is it not needed?
Because LED Flash class also uses microamperes.
Right, I had missed that. It'd be nice if that was said in the
comment, it might not be obvious to others either.
OK, I will add the comment.
--
Best Regards,
Jacek Anaszewski
--
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 0/9 v2] Helper to abstract vma handling in media layer
Hi Marek, On 04/24/2015 12:59 PM, Marek Szyprowski wrote: Dear All, On 2015-04-02 17:25, Hans Verkuil wrote: On 04/02/2015 05:02 PM, Jan Kara wrote: Hello, On Tue 17-03-15 12:56:30, Jan Kara wrote: After a long pause I'm sending second version of my patch series to abstract vma handling from the various media drivers. After this patch set drivers have to know much less details about vmas, their types, and locking. My motivation for the series is that I want to change get_user_pages() locking and I want to handle subtle locking details in as few places as possible. The core of the series is the new helper get_vaddr_pfns() which is given a virtual address and it fills in PFNs into provided array. If PFNs correspond to normal pages it also grabs references to these pages. The difference from get_user_pages() is that this function can also deal with pfnmap, mixed, and io mappings which is what the media drivers need. I have tested the patches with vivid driver so at least vb2 code got some exposure. Conversion of other drivers was just compile-tested so I'd like to ask respective maintainers if they could have a look. Also I'd like to ask mm folks to check patch 2/9 implementing the helper. Thanks! Ping? Any reactions? For patch 1/9: Acked-by: Hans Verkuil hans.verk...@cisco.com For the other patches I do not feel qualified to give Acks. I've Cc-ed Pawel and Marek who have a better understanding of the mm internals than I do. Hopefully they can review the code. It definitely looks like a good idea, and if nobody else will comment on the vb2 patches in the next 2 weeks, then I'll try to review it myself (for whatever that's worth). I'm really sorry that I didn't manage to find time to review this patchset. I really like the idea of moving pfn lookup from videobuf2/driver to some common code in mm and it is really great that someone managed to provide nice generic code for it. I've applied the whole patchset onto v4.0 and tested it on Odroid U3 (with some additional patches). VideoBuf2-dc works still fine with USERPTR gathered from other's device mmaped buffer. You can add my: Acked-by: Marek Szyprowski m.szyprow...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Thanks! for the patches 1-8. Patch 9/9 doesn't apply anymore, so I've skipped it. Patch 2 needs a small fixup - you need to add '#include linux/vmalloc.h', because otherwise it doesn't compile. There have been also a minor conflict to be resolved in patch 7. I've just added patch 1/9 to my pull request for 4.2. But for patch 2/9 I need Acks from the mm maintainers. I think it makes sense if patches 2-8 all go in together via the linux-media tree. Jan, can you reach out to the right devs to get Acks? Regards, Hans -- 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 v5 06/10] media: Add registration helpers for V4L2 flash sub-devices
Hi Jacek,
On Fri, Apr 24, 2015 at 12:29:17PM +0200, Jacek Anaszewski wrote:
Hi Sakari,
On Fri, 24 Apr 2015 00:52:12 +0300
Sakari Ailus sakari.ai...@iki.fi wrote:
Hi Jacek,
Jacek Anaszewski wrote:
...
+#define call_flash_op(v4l2_flash, op,
arg)\
+ (has_flash_op(v4l2_flash,
op) ? \
+ v4l2_flash-ops-op(v4l2_flash,
arg) : \
+ -EINVAL)
+
+static enum led_brightness __intensity_to_led_brightness(
+ struct v4l2_ctrl *ctrl,
+ s32 intensity)
Fits on previous line.
+{
+ s64 intensity64 = intensity - ctrl-minimum;
intensity, ctrl-step and ctrl-minimum are 32-bit signed integers.
Do you need a 64-bit integer here?
step is u64.
Nevertheless integer controls will not have values outside the s32
range, using a step value that's outside the range makes no sense
either. I think you should use s32 instead.
I infer that local u32 variable should be assigned ctrl-step,
and then used as a divisor.
You could cast explicitly as well. Either is fine for me.
+
+ do_div(intensity64, ctrl-step);
+
+ /*
+* Indicator LEDs, unlike torch LEDs, are turned on/off
basing on
+* the state of V4L2_CID_FLASH_INDICATOR_INTENSITY
control only.
+* Therefore it must be possible to set it to 0 level
which in
+* the LED subsystem reflects LED_OFF state.
+*/
+ if (ctrl-id != V4L2_CID_FLASH_INDICATOR_INTENSITY)
+ ++intensity64;
I think the condition could simply be ctrl-minimum instead, that
way I find it easier to understand what's happening here. I'd
expect the minimum for non-intensity controls always to be
non-zero, though, so the end result is the same. Up to you.
Minimum for indicator control must be 0 to make possible
turning the indicator LED off only with this control.
Would torch be still on if the minimum torch current was 0 mA? I'd
say no.
Although in that case I'd expect the driver to use a different range,
and selecting the off mode would then turn it off, I still think
that's a better condition than relying on the control id.
I didn't catch your point previously. Probably you was thinking
about somethig like this:
if (ctrl-minimum)
++intensity;
If so, I agree.
Yes, that's what I meant.
...
+static int v4l2_flash_g_volatile_ctrl(struct v4l2_ctrl *c)
+{
+ struct v4l2_flash *v4l2_flash =
v4l2_ctrl_to_v4l2_flash(c);
+ struct led_classdev_flash *fled_cdev =
v4l2_flash-fled_cdev;
+ bool is_strobing;
+ int ret;
+
+ switch (c-id) {
+ case V4L2_CID_FLASH_TORCH_INTENSITY:
+ case V4L2_CID_FLASH_INDICATOR_INTENSITY:
+ return
v4l2_flash_update_led_brightness(v4l2_flash, c);
+ case V4L2_CID_FLASH_INTENSITY:
+ ret = led_update_flash_brightness(fled_cdev);
+ if (ret 0)
+ return ret;
+ /* no conversion is needed */
Maybe a stupid question, but why is it not needed?
Because LED Flash class also uses microamperes.
Right, I had missed that. It'd be nice if that was said in the
comment, it might not be obvious to others either.
OK, I will add the comment.
Thanks!
--
Kind regards,
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
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] marvell-ccic: fix RGB444 format
The RGB444 format swapped the red and blue components, fix this.
Rather than making a new BGR444 format (as I proposed initially), Jon prefers
to just fix this and return the colors in the right order. I think that makes
sense in this case.
Since the RGB444 pixel format is deprecated due to the ambiguous specification
of the alpha component we use the XRGB444 pixel format instead (specified as
having
no alpha channel).
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Tested-by: Hans Verkuil hans.verk...@cisco.com
---
diff --git a/drivers/media/platform/marvell-ccic/mcam-core.c
b/drivers/media/platform/marvell-ccic/mcam-core.c
index 3c12065..cc92ba5 100644
--- a/drivers/media/platform/marvell-ccic/mcam-core.c
+++ b/drivers/media/platform/marvell-ccic/mcam-core.c
@@ -138,8 +138,8 @@ static struct mcam_format_struct {
.planar = true,
},
{
- .desc = RGB 444,
- .pixelformat= V4L2_PIX_FMT_RGB444,
+ .desc = XRGB 444,
+ .pixelformat= V4L2_PIX_FMT_XRGB444,
.mbus_code = MEDIA_BUS_FMT_RGB444_2X8_PADHI_LE,
.bpp= 2,
.planar = false,
@@ -777,10 +777,9 @@ static void mcam_ctlr_image(struct mcam_camera *cam)
mcam_reg_write_mask(cam, REG_CTRL0,
C0_DF_YUV | C0_YUV_PACKED | C0_YUVE_SWAP24, C0_DF_MASK);
break;
- case V4L2_PIX_FMT_RGB444:
+ case V4L2_PIX_FMT_XRGB444:
mcam_reg_write_mask(cam, REG_CTRL0,
- C0_DF_RGB | C0_RGBF_444 | C0_RGB4_XRGB, C0_DF_MASK);
- /* Alpha value? */
+ C0_DF_RGB | C0_RGBF_444 | C0_RGB4_XBGR, C0_DF_MASK);
break;
case V4L2_PIX_FMT_RGB565:
mcam_reg_write_mask(cam, REG_CTRL0,
--
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] [media] vivid: add 1080p capture at 2 fps and 5 fps to webcam emulation
Hi Hans, Am Freitag, den 24.04.2015, 08:43 +0200 schrieb Hans Verkuil: Hi Philipp, Thank you for the patch, but I have one question: On 04/23/2015 03:52 PM, Philipp Zabel wrote: Use the VIVID_WEBCAM_SIZES constant where appropriate and add a 1920x1080 pixel frame size setting with frame rates of 2 fps and 5 fps. Why add both 2 and 5 fps? Is there a reason why you want both of those fps values? Just wondering. I just wanted to quickly test 1080p at 5 fps, so I didn't change that afterwards for the patch. 5 fps also seems like the next logical step. webcam_intervals needs to be twice the size of webcam_sizes, the comment above webcam_intervals told me to add two intervals for every new element in webcam_sizes. For the second interval, I didn't think much about the actual value. Choosing 2 fps next was probably influenced by our monetary system. To keep data rates similar to 720p at 10 fps and 15 fps, 1080p at 4 fps and 6 fps, respectively, would be the better choice. regards Philipp -- 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 v4 06/10] cec: add HDMI CEC framework
Hi Kamil, Hans, I'm the main developer of libCEC (https://github.com/Pulse-Eight/libcec). Sorry for the late time to jump in here, but I wasn't signed up to this mailing list and someone pointed me to this discussion. Unfortunately this approach will not work with half the TVs that are out there. I'll explain why: * because of how some (common) brands implemented CEC in their TVs, this implementation will not work, as the TV will just reject it. In libCEC, we've created work arounds for brands like this. Without these work arounds, your in-kernel implementation will be very vendor specific. e.g. this implementation will work for Samsung's TVs, but not for the TVs made by another big TV brand. All commands, including CEC_OP_ABORT, should be passed to userspace to make it work with all brands. * it should be made possible to not have the kernel send any CEC message, try to process any received CEC message, or ack to any logical address at all, to allow libraries like libCEC to fully handle all CEC traffic. Some brands only enable routing of some CEC keys when a specific device type is used. libCEC will allocate a logical address of the correct type for the brand that's used. If another address is first allocated by the kernel, and the TV communicates with it to find out it's name and things like that, and libCEC allocates another address a bit later when initialised, then you'll end up with multiple entries in the device list on the TV, and only one of them will work. * CEC is *very* vendor specific. The main reason is, in my opinion, the use of the word should instead of shall in the spec. It's addressed in the new version, but it'll take years before all the non 2.x devices are gone. What works for vendor A will simply not work for vendor B. libCEC aims to address this, in a library that can be used on all major platforms and by all major programming languages. You could duplicate the work done there in the kernel to make make the implementation work with all brands, but I think that this does simply not belong in the kernel when it can be handled in userspace perfectly. So I suggest that you limit the in-kernel implementation to handling raw traffic only, to have it do this (and nothing more): * allocate one or more logical addresses, and ack CEC traffic sent to those logical addresses * receive CEC traffic and forward it to userspace (traffic sent to all addresses is preferred, not just traffic sent to the logical address used by the device running this code) * transmit CEC traffic initiated by userspace thanks, Lars Op den Kamp On 23-04-15 15:03, Kamil Debski wrote: From: Hans Verkuil hansv...@cisco.com The added HDMI CEC framework provides a generic kernel interface for HDMI CEC devices. Signed-off-by: Hans Verkuil hansv...@cisco.com [k.deb...@samsung.com: Merged CEC Updates commit by Hans Verkuil] [k.deb...@samsung.com: Merged Update author commit by Hans Verkuil] [k.deb...@samsung.com: change kthread handling when setting logical address] [k.deb...@samsung.com: code cleanup and fixes] [k.deb...@samsung.com: add missing CEC commands to match spec] [k.deb...@samsung.com: add RC framework support] [k.deb...@samsung.com: move and edit documentation] [k.deb...@samsung.com: add vendor id reporting] [k.deb...@samsung.com: add possibility to clear assigned logical addresses] [k.deb...@samsung.com: documentation fixes, clenaup and expansion] [k.deb...@samsung.com: reorder of API structs and add reserved fields] [k.deb...@samsung.com: fix handling of events and fix 32/64bit timespec problem] [k.deb...@samsung.com: add cec.h to include/uapi/linux/Kbuild] Signed-off-by: Kamil Debski k.deb...@samsung.com --- Documentation/cec.txt | 396 drivers/media/Kconfig |6 + drivers/media/Makefile|2 + drivers/media/cec.c | 1161 + include/media/cec.h | 140 ++ include/uapi/linux/Kbuild |1 + include/uapi/linux/cec.h | 303 7 files changed, 2009 insertions(+) create mode 100644 Documentation/cec.txt create mode 100644 drivers/media/cec.c create mode 100644 include/media/cec.h create mode 100644 include/uapi/linux/cec.h diff --git a/Documentation/cec.txt b/Documentation/cec.txt new file mode 100644 index 000..2b6c08a --- /dev/null +++ b/Documentation/cec.txt @@ -0,0 +1,396 @@ +CEC Kernel Support +== + +The CEC framework provides a unified kernel interface for use with HDMI CEC +hardware. It is designed to handle a multiple variants of hardware. Adding to +the flexibility of the framework it enables to set which parts of the CEC +protocol processing is handled by the hardware, by the driver and by the +userspace application. + + +The CEC Protocol + + +The CEC protocol enables consumer electronic devices to communicate with each +other through the HDMI connection. The protocol uses logical addresses in the
Re: [PATCH] cx18: add missing caps for the PCM video device
On April 24, 2015 2:55:07 AM EDT, Hans Verkuil hverk...@xs4all.nl wrote:
The cx18 PCM video device didn't have any capabilities set, which
caused a warnings
in the v4l2 core:
[6.229393] [ cut here ]
[6.229414] WARNING: CPU: 1 PID: 593 at
drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70
[videodev]()
[6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi
x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel
snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+)
snd_hda_intel
snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart
iTCO_wdt
snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul
crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel
videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat
dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev
mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis
mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper
[6.229444] drm ptp pps_core video
[6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted
3.19.3-200.fc21.x86_64 #1
[6.229447] Hardware name: Gigabyte Technology Co., Ltd.
Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014
[6.229448] d12b1131 88042dacfc28
8176e215
[6.229449] 88042dacfc68
8109bc1a
[6.229451] a0594000 88042dacfd90
a04e2140
[6.229452] Call Trace:
[6.229466] [8176e215] dump_stack+0x45/0x57
[6.229469] [8109bc1a] warn_slowpath_common+0x8a/0xc0
[6.229472] [8109bd4a] warn_slowpath_null+0x1a/0x20
[6.229474] [a04ca401] v4l_querycap+0x41/0x70 [videodev]
[6.229477] [a04ca6cc] __video_do_ioctl+0x29c/0x320
[videodev]
[6.229479] [81227131] ? do_last+0x2f1/0x1210
[6.229491] [a04cc776] video_usercopy+0x366/0x5d0
[videodev]
[6.229494] [a04ca430] ? v4l_querycap+0x70/0x70
[videodev]
[6.229497] [a04cc9f5] video_ioctl2+0x15/0x20 [videodev]
[6.229499] [a04c6794] v4l2_ioctl+0x164/0x180 [videodev]
[6.229501] [8122e298] do_vfs_ioctl+0x2f8/0x500
[6.229502] [8122e521] SyS_ioctl+0x81/0xa0
[6.229505] [81774a09] system_call_fastpath+0x12/0x17
[6.229506] ---[ end trace dacd80d4b19277ea ]---
Added the necessary capabilities to stop this warning.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Laura Abbott labb...@redhat.com
Cc: sta...@vger.kernel.org # for v3.19 and up
---
diff --git a/drivers/media/pci/cx18/cx18-streams.c
b/drivers/media/pci/cx18/cx18-streams.c
index c82d25d..c986084 100644
--- a/drivers/media/pci/cx18/cx18-streams.c
+++ b/drivers/media/pci/cx18/cx18-streams.c
@@ -90,6 +90,7 @@ static struct {
encoder PCM audio,
VFL_TYPE_GRABBER, CX18_V4L2_ENC_PCM_OFFSET,
PCI_DMA_FROMDEVICE,
+ V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
},
{ /* CX18_ENC_STREAM_TYPE_IDX */
encoder IDX,
Thanks Hans!
Acked-by: Andy Walls awa...@md.metrocast.net
--
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
[RCF02] Driver for Toshiba TC358743 CSI-2 to HDMI bridge
From: Mats Randgaard matra...@cisco.com Hi, I have finally finished the second RFC for this driver. Changes since RFC01: - Improved code based on feedback from Hans and Philipp. For the CSI parameters have I only written a set of values that can serve as a starting point, since calculation of the parameters in the driver will require more work. - Fixed problem with some sources that are transmitting an unstable signal while they are in standby. - Fixed problem where audio was not received from some sources after coming out of standby, reconnecting cable or stopping/starting the stream. - When the stream is enabled a proper lane transition is triggered on the CSI interface to ensure that the CSI receiver is ready. - All CE and IT formats are detected as RGB full quantization range in DVI mode. Philipp, I have not had time to look at your patches, so maybe you can rebase them on this version of the driver? Mats Randgaard (1): Driver for Toshiba TC358743 CSI-2 to HDMI bridge MAINTAINERS|6 + drivers/media/i2c/Kconfig |9 + drivers/media/i2c/Makefile |1 + drivers/media/i2c/tc358743.c | 1838 drivers/media/i2c/tc358743_regs.h | 680 + include/media/tc358743.h | 92 ++ include/uapi/linux/v4l2-controls.h |4 + 7 files changed, 2630 insertions(+) create mode 100644 drivers/media/i2c/tc358743.c create mode 100644 drivers/media/i2c/tc358743_regs.h create mode 100644 include/media/tc358743.h -- 2.3.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: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
Steven, thanks for your comment You are very welcome. So maybe this should also go into cx23885? I'm in Europe and only have DVB-C My understanding is that it applies to all USB/PCIe bridges. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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/5] vivid-tpg: add tpg_log_status()
From: Hans Verkuil hans.verk...@cisco.com
Add a log_status function to the test pattern generator and use that
in vivid. This simplifies debugging complex colorspace problems.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-core.c | 13 -
drivers/media/platform/vivid/vivid-tpg.c | 16
drivers/media/platform/vivid/vivid-tpg.h | 1 +
3 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/media/platform/vivid/vivid-core.c
b/drivers/media/platform/vivid/vivid-core.c
index d33f164..d6caeeb 100644
--- a/drivers/media/platform/vivid/vivid-core.c
+++ b/drivers/media/platform/vivid/vivid-core.c
@@ -392,6 +392,17 @@ static int vidioc_s_parm(struct file *file, void *fh,
return vivid_vid_out_g_parm(file, fh, parm);
}
+static int vidioc_log_status(struct file *file, void *fh)
+{
+ struct vivid_dev *dev = video_drvdata(file);
+ struct video_device *vdev = video_devdata(file);
+
+ v4l2_ctrl_log_status(file, fh);
+ if (vdev-vfl_dir == VFL_DIR_RX vdev-vfl_type == VFL_TYPE_GRABBER)
+ tpg_log_status(dev-tpg);
+ return 0;
+}
+
static ssize_t vivid_radio_read(struct file *file, char __user *buf,
size_t size, loff_t *offset)
{
@@ -610,7 +621,7 @@ static const struct v4l2_ioctl_ops vivid_ioctl_ops = {
.vidioc_g_edid = vidioc_g_edid,
.vidioc_s_edid = vidioc_s_edid,
- .vidioc_log_status = v4l2_ctrl_log_status,
+ .vidioc_log_status = vidioc_log_status,
.vidioc_subscribe_event = vidioc_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index cb766eb..69cd8fb 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -1670,6 +1670,22 @@ static int tpg_pattern_avg(const struct tpg_data *tpg,
return -1;
}
+void tpg_log_status(struct tpg_data *tpg)
+{
+ pr_info(tpg source WxH: %ux%u (%s)\n,
+ tpg-src_width, tpg-src_height,
+ tpg-is_yuv ? YCbCr : RGB);
+ pr_info(tpg field: %u\n, tpg-field);
+ pr_info(tpg crop: %ux%u@%dx%d\n, tpg-crop.width, tpg-crop.height,
+ tpg-crop.left, tpg-crop.top);
+ pr_info(tpg compose: %ux%u@%dx%d\n, tpg-compose.width,
tpg-compose.height,
+ tpg-compose.left, tpg-compose.top);
+ pr_info(tpg colorspace: %d\n, tpg-colorspace);
+ pr_info(tpg Y'CbCr encoding: %d/%d\n, tpg-ycbcr_enc,
tpg-real_ycbcr_enc);
+ pr_info(tpg quantization: %d/%d\n, tpg-quantization,
tpg-real_quantization);
+ pr_info(tpg RGB range: %d/%d\n, tpg-rgb_range, tpg-real_rgb_range);
+}
+
/*
* This struct contains common parameters used by both the drawing of the
* test pattern and the drawing of the extras (borders, square, etc.)
diff --git a/drivers/media/platform/vivid/vivid-tpg.h
b/drivers/media/platform/vivid/vivid-tpg.h
index a50cd2e..ef8638f 100644
--- a/drivers/media/platform/vivid/vivid-tpg.h
+++ b/drivers/media/platform/vivid/vivid-tpg.h
@@ -192,6 +192,7 @@ int tpg_alloc(struct tpg_data *tpg, unsigned max_w);
void tpg_free(struct tpg_data *tpg);
void tpg_reset_source(struct tpg_data *tpg, unsigned width, unsigned height,
u32 field);
+void tpg_log_status(struct tpg_data *tpg);
void tpg_set_font(const u8 *f);
void tpg_gen_text(const struct tpg_data *tpg,
--
2.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 0/5] vivid-tpg: fixes/improvements
From: Hans Verkuil hans.verk...@cisco.com - Add logging - Add full range variants of several Y'CbCr encodings to be consistent with the existing encodings - Ignore quantization range for the XV601/709 encodings as that does not apply for those encodings Hans Hans Verkuil (5): vivid-tpg: add tpg_log_status() vivid-tpg: add full range SMPTE 240M support vivid-tpg: add full range BT.2020 support vivid-tpg: add full range BT.2020C support vivid-tpg: fix XV601/709 Y'CbCr encoding drivers/media/platform/vivid/vivid-core.c | 13 +++- drivers/media/platform/vivid/vivid-tpg.c | 109 -- drivers/media/platform/vivid/vivid-tpg.h | 1 + 3 files changed, 103 insertions(+), 20 deletions(-) -- 2.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 5/5] vivid-tpg: fix XV601/709 Y'CbCr encoding
From: Hans Verkuil hans.verk...@cisco.com
For these encodings the quantization range should be ignored, since
there is only one possible Y'CbCr encoding.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 097d299..4df755a 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -509,10 +509,19 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
switch (tpg-real_ycbcr_enc) {
case V4L2_YCBCR_ENC_601:
- case V4L2_YCBCR_ENC_XV601:
case V4L2_YCBCR_ENC_SYCC:
rgb2ycbcr(full ? bt601_full : bt601, r, g, b, y_offset, y, cb,
cr);
break;
+ case V4L2_YCBCR_ENC_XV601:
+ /* Ignore quantization range, there is only one possible
+* Y'CbCr encoding. */
+ rgb2ycbcr(bt601, r, g, b, 16, y, cb, cr);
+ break;
+ case V4L2_YCBCR_ENC_XV709:
+ /* Ignore quantization range, there is only one possible
+* Y'CbCr encoding. */
+ rgb2ycbcr(rec709, r, g, b, 16, y, cb, cr);
+ break;
case V4L2_YCBCR_ENC_BT2020:
rgb2ycbcr(full ? bt2020_full : bt2020, r, g, b, y_offset, y,
cb, cr);
break;
@@ -535,7 +544,6 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r, int
g, int b,
rgb2ycbcr(full ? smpte240m_full : smpte240m, r, g, b, y_offset,
y, cb, cr);
break;
case V4L2_YCBCR_ENC_709:
- case V4L2_YCBCR_ENC_XV709:
default:
rgb2ycbcr(full ? rec709_full : rec709, r, g, b, y_offset, y,
cb, cr);
break;
@@ -617,10 +625,19 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
switch (tpg-real_ycbcr_enc) {
case V4L2_YCBCR_ENC_601:
- case V4L2_YCBCR_ENC_XV601:
case V4L2_YCBCR_ENC_SYCC:
ycbcr2rgb(full ? bt601_full : bt601, y, cb, cr, y_offset, r, g,
b);
break;
+ case V4L2_YCBCR_ENC_XV601:
+ /* Ignore quantization range, there is only one possible
+* Y'CbCr encoding. */
+ ycbcr2rgb(bt601, y, cb, cr, 16, r, g, b);
+ break;
+ case V4L2_YCBCR_ENC_XV709:
+ /* Ignore quantization range, there is only one possible
+* Y'CbCr encoding. */
+ ycbcr2rgb(rec709, y, cb, cr, 16, r, g, b);
+ break;
case V4L2_YCBCR_ENC_BT2020:
ycbcr2rgb(full ? bt2020_full : bt2020, y, cb, cr, y_offset, r,
g, b);
break;
@@ -652,7 +669,6 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y, int
cb, int cr,
ycbcr2rgb(full ? smpte240m_full : smpte240m, y, cb, cr,
y_offset, r, g, b);
break;
case V4L2_YCBCR_ENC_709:
- case V4L2_YCBCR_ENC_XV709:
default:
ycbcr2rgb(full ? rec709_full : rec709, y, cb, cr, y_offset, r,
g, b);
break;
--
2.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/5] vivid-tpg: add full range BT.2020 support
From: Hans Verkuil hans.verk...@cisco.com
In order to be consistent with the other Y'CbCr encodings add
support for full range V4L2_YCBCR_ENC_BT2020.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 59bdbae..a7ead15 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -489,6 +489,12 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
{ COEFF(-0.1396, 224), COEFF(-0.3604, 224), COEFF(0.5, 224)
},
{ COEFF(0.5, 224), COEFF(-0.4598, 224), COEFF(-0.0402, 224)
},
};
+ static const int bt2020_full[3][3] = {
+ { COEFF(0.2627, 255), COEFF(0.6780, 255), COEFF(0.0593, 255)
},
+ { COEFF(-0.1396, 255), COEFF(-0.3604, 255), COEFF(0.5, 255)
},
+ { COEFF(0.5, 255), COEFF(-0.4698, 255), COEFF(-0.0402, 255)
},
+ };
+
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
unsigned y_offset = full ? 0 : 16;
int lin_y, yc;
@@ -500,7 +506,7 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r, int
g, int b,
rgb2ycbcr(full ? bt601_full : bt601, r, g, b, y_offset, y, cb,
cr);
break;
case V4L2_YCBCR_ENC_BT2020:
- rgb2ycbcr(bt2020, r, g, b, 16, y, cb, cr);
+ rgb2ycbcr(full ? bt2020_full : bt2020, r, g, b, y_offset, y,
cb, cr);
break;
case V4L2_YCBCR_ENC_BT2020_CONST_LUM:
lin_y = (COEFF(0.2627, 255) * rec709_to_linear(r) +
@@ -582,6 +588,11 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
{ COEFF(1, 219), COEFF(-0.1646, 224), COEFF(-0.5714, 224) },
{ COEFF(1, 219), COEFF(1.8814, 224), COEFF(0, 224) },
};
+ static const int bt2020_full[3][3] = {
+ { COEFF(1, 255), COEFF(0, 255), COEFF(1.4746, 255) },
+ { COEFF(1, 255), COEFF(-0.1646, 255), COEFF(-0.5714, 255) },
+ { COEFF(1, 255), COEFF(1.8814, 255), COEFF(0, 255) },
+ };
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
unsigned y_offset = full ? 0 : 16;
int lin_r, lin_g, lin_b, lin_y;
@@ -593,7 +604,7 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y, int
cb, int cr,
ycbcr2rgb(full ? bt601_full : bt601, y, cb, cr, y_offset, r, g,
b);
break;
case V4L2_YCBCR_ENC_BT2020:
- ycbcr2rgb(bt2020, y, cb, cr, 16, r, g, b);
+ ycbcr2rgb(full ? bt2020_full : bt2020, y, cb, cr, y_offset, r,
g, b);
break;
case V4L2_YCBCR_ENC_BT2020_CONST_LUM:
y -= 16 4;
--
2.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/5] vivid-tpg: add full range SMPTE 240M support
From: Hans Verkuil hans.verk...@cisco.com
In order to be consistent with the other Y'CbCr encodings add
support for full range V4L2_YCBCR_ENC_SMPTE240M.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 69cd8fb..59bdbae 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -479,6 +479,11 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
{ COEFF(-0.116, 224), COEFF(-0.384, 224), COEFF(0.5, 224)},
{ COEFF(0.5, 224),COEFF(-0.445, 224), COEFF(-0.055, 224) },
};
+ static const int smpte240m_full[3][3] = {
+ { COEFF(0.212, 255), COEFF(0.701, 255), COEFF(0.087, 255) },
+ { COEFF(-0.116, 255), COEFF(-0.384, 255), COEFF(0.5, 255)},
+ { COEFF(0.5, 255),COEFF(-0.445, 255), COEFF(-0.055, 255) },
+ };
static const int bt2020[3][3] = {
{ COEFF(0.2627, 219), COEFF(0.6780, 219), COEFF(0.0593, 219)
},
{ COEFF(-0.1396, 224), COEFF(-0.3604, 224), COEFF(0.5, 224)
},
@@ -513,7 +518,7 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r, int
g, int b,
*cr = (((r - yc) * COEFF(1.0 / 0.9936, 224)) 16) +
(128 4);
break;
case V4L2_YCBCR_ENC_SMPTE240M:
- rgb2ycbcr(smpte240m, r, g, b, 16, y, cb, cr);
+ rgb2ycbcr(full ? smpte240m_full : smpte240m, r, g, b, y_offset,
y, cb, cr);
break;
case V4L2_YCBCR_ENC_709:
case V4L2_YCBCR_ENC_XV709:
@@ -567,6 +572,11 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
{ COEFF(1, 219), COEFF(-0.2253, 224), COEFF(-0.4767, 224) },
{ COEFF(1, 219), COEFF(1.8270, 224), COEFF(0, 224) },
};
+ static const int smpte240m_full[3][3] = {
+ { COEFF(1, 255), COEFF(0, 255), COEFF(1.5756, 255) },
+ { COEFF(1, 255), COEFF(-0.2253, 255), COEFF(-0.4767, 255) },
+ { COEFF(1, 255), COEFF(1.8270, 255), COEFF(0, 255) },
+ };
static const int bt2020[3][3] = {
{ COEFF(1, 219), COEFF(0, 224), COEFF(1.4746, 224) },
{ COEFF(1, 219), COEFF(-0.1646, 224), COEFF(-0.5714, 224) },
@@ -610,7 +620,7 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y, int
cb, int cr,
*g = linear_to_rec709(lin_g 12);
break;
case V4L2_YCBCR_ENC_SMPTE240M:
- ycbcr2rgb(smpte240m, y, cb, cr, 16, r, g, b);
+ ycbcr2rgb(full ? smpte240m_full : smpte240m, y, cb, cr,
y_offset, r, g, b);
break;
case V4L2_YCBCR_ENC_709:
case V4L2_YCBCR_ENC_XV709:
--
2.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/5] vivid-tpg: add full range BT.2020C support
From: Hans Verkuil hans.verk...@cisco.com
In order to be consistent with the other Y'CbCr encodings add
support for full range V4L2_YCBCR_ENC_BT2020_CONST_LUM.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/platform/vivid/vivid-tpg.c | 40 +++-
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index a7ead15..097d299 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -494,6 +494,14 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
{ COEFF(-0.1396, 255), COEFF(-0.3604, 255), COEFF(0.5, 255)
},
{ COEFF(0.5, 255), COEFF(-0.4698, 255), COEFF(-0.0402, 255)
},
};
+ static const int bt2020c[4] = {
+ COEFF(1.0 / 1.9404, 224), COEFF(1.0 / 1.5816, 224),
+ COEFF(1.0 / 1.7184, 224), COEFF(1.0 / 0.9936, 224),
+ };
+ static const int bt2020c_full[4] = {
+ COEFF(1.0 / 1.9404, 255), COEFF(1.0 / 1.5816, 255),
+ COEFF(1.0 / 1.7184, 255), COEFF(1.0 / 0.9936, 255),
+ };
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
unsigned y_offset = full ? 0 : 16;
@@ -513,15 +521,15 @@ static void color_to_ycbcr(struct tpg_data *tpg, int r,
int g, int b,
COEFF(0.6780, 255) * rec709_to_linear(g) +
COEFF(0.0593, 255) * rec709_to_linear(b)) 16;
yc = linear_to_rec709(lin_y);
- *y = (yc * 219) / 255 + (16 4);
+ *y = full ? yc : (yc * 219) / 255 + (16 4);
if (b = yc)
- *cb = (((b - yc) * COEFF(1.0 / 1.9404, 224)) 16) +
(128 4);
+ *cb = (((b - yc) * (full ? bt2020c_full[0] :
bt2020c[0])) 16) + (128 4);
else
- *cb = (((b - yc) * COEFF(1.0 / 1.5816, 224)) 16) +
(128 4);
+ *cb = (((b - yc) * (full ? bt2020c_full[1] :
bt2020c[1])) 16) + (128 4);
if (r = yc)
- *cr = (((r - yc) * COEFF(1.0 / 1.7184, 224)) 16) +
(128 4);
+ *cr = (((r - yc) * (full ? bt2020c_full[2] :
bt2020c[2])) 16) + (128 4);
else
- *cr = (((r - yc) * COEFF(1.0 / 0.9936, 224)) 16) +
(128 4);
+ *cr = (((r - yc) * (full ? bt2020c_full[3] :
bt2020c[3])) 16) + (128 4);
break;
case V4L2_YCBCR_ENC_SMPTE240M:
rgb2ycbcr(full ? smpte240m_full : smpte240m, r, g, b, y_offset,
y, cb, cr);
@@ -593,8 +601,18 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
{ COEFF(1, 255), COEFF(-0.1646, 255), COEFF(-0.5714, 255) },
{ COEFF(1, 255), COEFF(1.8814, 255), COEFF(0, 255) },
};
+ static const int bt2020c[4] = {
+ COEFF(1.9404, 224), COEFF(1.5816, 224),
+ COEFF(1.7184, 224), COEFF(0.9936, 224),
+ };
+ static const int bt2020c_full[4] = {
+ COEFF(1.9404, 255), COEFF(1.5816, 255),
+ COEFF(1.7184, 255), COEFF(0.9936, 255),
+ };
+
bool full = tpg-real_quantization == V4L2_QUANTIZATION_FULL_RANGE;
unsigned y_offset = full ? 0 : 16;
+ int y_fac = full ? COEFF(1.0, 255) : COEFF(1.0, 219);
int lin_r, lin_g, lin_b, lin_y;
switch (tpg-real_ycbcr_enc) {
@@ -607,23 +625,23 @@ static void ycbcr_to_color(struct tpg_data *tpg, int y,
int cb, int cr,
ycbcr2rgb(full ? bt2020_full : bt2020, y, cb, cr, y_offset, r,
g, b);
break;
case V4L2_YCBCR_ENC_BT2020_CONST_LUM:
- y -= 16 4;
+ y -= full ? 0 : 16 4;
cb -= 128 4;
cr -= 128 4;
if (cb = 0)
- *b = COEFF(1.0, 219) * y + COEFF(1.9404, 224) * cb;
+ *b = y_fac * y + (full ? bt2020c_full[0] : bt2020c[0])
* cb;
else
- *b = COEFF(1.0, 219) * y + COEFF(1.5816, 224) * cb;
+ *b = y_fac * y + (full ? bt2020c_full[1] : bt2020c[1])
* cb;
*b = *b 12;
if (cr = 0)
- *r = COEFF(1.0, 219) * y + COEFF(1.7184, 224) * cr;
+ *r = y_fac * y + (full ? bt2020c_full[2] : bt2020c[2])
* cr;
else
- *r = COEFF(1.0, 219) * y + COEFF(0.9936, 224) * cr;
+ *r = y_fac * y + (full ? bt2020c_full[3] : bt2020c[3])
* cr;
*r = *r 12;
lin_r = rec709_to_linear(*r);
lin_b = rec709_to_linear(*b);
- lin_y = rec709_to_linear((y * 255) / 219);
+ lin_y = rec709_to_linear((y * 255) / (full ? 255 : 219));
Re: [PATCH 02/12] dvbsky: use si2168 config option ts_clock_gapped
I've also seen that the Hauppauge HVR-2205 Windows driver enables this option, but it seems to me that that board works ok also without this. Olli, I found out why this is, I thought you'd appreciate the comment Apparently the issue only occurs with DVB streams faster than approximately 50Mbps, which standard DVB-T/T2, ATSC and QAM-B never are. The issue apparently, is with some QAM-A (DVB-C) streams in Europe. This explains why I've never seen it. That's being said, I do plan to add the gapped clock patch to the SAA7164 shortly - for safety. -- Steven Toth - Kernel Labs http://www.kernellabs.com -- 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
[RCF02] Driver for Toshiba TC358743 CSI-2 to HDMI bridge
From: Mats Randgaard matra...@cisco.com
The driver is tested on our hardware and all the implemented features
works as expected.
Missing features:
- CEC support
- HDCP repeater support
- IR support
Signed-off-by: Mats Randgaard matra...@cisco.com
---
MAINTAINERS|6 +
drivers/media/i2c/Kconfig |9 +
drivers/media/i2c/Makefile |1 +
drivers/media/i2c/tc358743.c | 1838
drivers/media/i2c/tc358743_regs.h | 680 +
include/media/tc358743.h | 92 ++
include/uapi/linux/v4l2-controls.h |4 +
7 files changed, 2630 insertions(+)
create mode 100644 drivers/media/i2c/tc358743.c
create mode 100644 drivers/media/i2c/tc358743_regs.h
create mode 100644 include/media/tc358743.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 30e7e38..49e9f84 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9856,6 +9856,12 @@ L: platform-driver-...@vger.kernel.org
S: Orphan
F: drivers/platform/x86/toshiba_acpi.c
+TOSHIBA TC358743 DRIVER
+M: Mats Randgaard matra...@cisco.com
+L: linux-media@vger.kernel.org
+S: Maintained
+F: drivers/media/i2c/tc358743*
+
TOSHIBA SMM DRIVER
M: Jonathan Buzzard jonat...@buzzard.org.uk
L: tlinux-us...@tce.toshiba-dme.co.jp
diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
index 6f30ea7..e352daa 100644
--- a/drivers/media/i2c/Kconfig
+++ b/drivers/media/i2c/Kconfig
@@ -285,6 +285,15 @@ config VIDEO_SAA711X
To compile this driver as a module, choose M here: the
module will be called saa7115.
+config VIDEO_TC358743
+ tristate Toshiba TC358743 decoder
+ depends on VIDEO_V4L2 I2C
+ ---help---
+ Support for the Toshiba TC358743 HDMI to MIPI CSI-2 bridge
+
+ To compile this driver as a module, choose M here: the
+ module will be called tc358743.
+
config VIDEO_TVP514X
tristate Texas Instruments TVP514x video decoder
depends on VIDEO_V4L2 I2C
diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
index f165fae..07db257 100644
--- a/drivers/media/i2c/Makefile
+++ b/drivers/media/i2c/Makefile
@@ -78,3 +78,4 @@ obj-$(CONFIG_VIDEO_AK881X)+= ak881x.o
obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o
obj-$(CONFIG_VIDEO_ML86V7667) += ml86v7667.o
obj-$(CONFIG_VIDEO_OV2659) += ov2659.o
+obj-$(CONFIG_VIDEO_TC358743) += tc358743.o
diff --git a/drivers/media/i2c/tc358743.c b/drivers/media/i2c/tc358743.c
new file mode 100644
index 000..e9328c4
--- /dev/null
+++ b/drivers/media/i2c/tc358743.c
@@ -0,0 +1,1838 @@
+/*
+ * tc358743 - Toshiba HDMI to CSI-2 bridge
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights
+ * reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ *
+ */
+
+/*
+ * References (c = chapter, p = page):
+ * REF_01 - Toshiba, TC358743XBG (H2C), Functional Specification, Rev 0.60
+ * REF_02 - Toshiba, TC358743XBG_HDMI-CSI_Tv11p_nm.xls
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/slab.h
+#include linux/i2c.h
+#include linux/delay.h
+#include linux/videodev2.h
+#include linux/workqueue.h
+#include linux/v4l2-dv-timings.h
+#include media/v4l2-dv-timings.h
+#include media/v4l2-device.h
+#include media/v4l2-ctrls.h
+#include media/tc358743.h
+
+#include tc358743_regs.h
+
+static int debug;
+module_param(debug, int, 0644);
+MODULE_PARM_DESC(debug, debug level (0-3));
+
+MODULE_DESCRIPTION(Toshiba TC358743 HDMI to CSI-2 bridge driver);
+MODULE_AUTHOR(Ramakrishnan Muthukrishnan r...@rkrishnan.org);
+MODULE_AUTHOR(Mikhail Khelik mkhe...@cisco.com);
+MODULE_AUTHOR(Mats Randgaard matra...@cisco.com);
+MODULE_LICENSE(GPL);
+
+#define EDID_NUM_BLOCKS_MAX 8
+#define EDID_BLOCK_SIZE 128
+
+static const struct v4l2_dv_timings_cap tc358743_timings_cap = {
+ .type = V4L2_DV_BT_656_1120,
+ /* keep this initialization for compatibility with GCC 4.4.6 */
+ .reserved = { 0 },
+ /* Pixel clock from REF_01 p. 20. Min/max height/width are unknown */
+ V4L2_INIT_BT_TIMINGS(1, 1, 1, 1, 0, 16500,
+ V4L2_DV_BT_STD_CEA861 | V4L2_DV_BT_STD_DMT |
+ V4L2_DV_BT_STD_GTF | V4L2_DV_BT_STD_CVT,
+ V4L2_DV_BT_CAP_PROGRESSIVE |
+
[GIT PULL]: dma-buf updates for 4.1-rc1
Hi Linus, May I request you to pull a few dma-buf changes for 4.1-rc1? minor cleanup only; this could've gone in for the 4.0 merge window, but for a copy-paste stupidity from me. It has been in the for-next since then, and no issues reported. Thanks and best regards, Sumit. The following changes since commit 646da63172f660ba84f195c1165360a9b73583ee: Merge tag 'remoteproc-4.1-next' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc (2015-04-20 15:40:10 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/dma-buf-for-4.1 for you to fetch changes up to 72449cb47b0104c32ff8fb9380ade9113375d8d1: staging: android: ion: fix wrong init of dma_buf_export_info (2015-04-21 14:47:16 +0530) - cleanup of dma_buf_export() - correction of copy-paste stupidity while doing the cleanup Sumit Semwal (2): dma-buf: cleanup dma_buf_export() to make it easily extensible staging: android: ion: fix wrong init of dma_buf_export_info Documentation/dma-buf-sharing.txt | 23 +++-- drivers/dma-buf/dma-buf.c | 47 -- drivers/gpu/drm/armada/armada_gem.c| 10 -- drivers/gpu/drm/drm_prime.c| 12 --- drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 9 +++-- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 10 -- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 9 - drivers/gpu/drm/tegra/gem.c| 10 -- drivers/gpu/drm/ttm/ttm_object.c | 9 +++-- drivers/gpu/drm/udl/udl_dmabuf.c | 9 - drivers/media/v4l2-core/videobuf2-dma-contig.c | 8 - drivers/media/v4l2-core/videobuf2-dma-sg.c | 8 - drivers/media/v4l2-core/videobuf2-vmalloc.c| 8 - drivers/staging/android/ion/ion.c | 9 +++-- include/linux/dma-buf.h| 34 +++ 15 files changed, 152 insertions(+), 63 deletions(-) -- 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] marvell-ccic: fix RGB444 format
On Fri, 24 Apr 2015 11:52:47 +0200 Hans Verkuil hverk...@xs4all.nl wrote: The RGB444 format swapped the red and blue components, fix this. Rather than making a new BGR444 format (as I proposed initially), Jon prefers to just fix this and return the colors in the right order. I think that makes sense in this case. Since the RGB444 pixel format is deprecated due to the ambiguous specification of the alpha component we use the XRGB444 pixel format instead (specified as having no alpha channel). Seems good to me. Acked-by: Jonathan Corbet cor...@lwn.net jon -- 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 0/9 v2] Helper to abstract vma handling in media layer
On Fri 24-04-15 13:07:37, Hans Verkuil wrote: Hi Marek, On 04/24/2015 12:59 PM, Marek Szyprowski wrote: Dear All, On 2015-04-02 17:25, Hans Verkuil wrote: On 04/02/2015 05:02 PM, Jan Kara wrote: Hello, On Tue 17-03-15 12:56:30, Jan Kara wrote: After a long pause I'm sending second version of my patch series to abstract vma handling from the various media drivers. After this patch set drivers have to know much less details about vmas, their types, and locking. My motivation for the series is that I want to change get_user_pages() locking and I want to handle subtle locking details in as few places as possible. The core of the series is the new helper get_vaddr_pfns() which is given a virtual address and it fills in PFNs into provided array. If PFNs correspond to normal pages it also grabs references to these pages. The difference from get_user_pages() is that this function can also deal with pfnmap, mixed, and io mappings which is what the media drivers need. I have tested the patches with vivid driver so at least vb2 code got some exposure. Conversion of other drivers was just compile-tested so I'd like to ask respective maintainers if they could have a look. Also I'd like to ask mm folks to check patch 2/9 implementing the helper. Thanks! Ping? Any reactions? For patch 1/9: Acked-by: Hans Verkuil hans.verk...@cisco.com For the other patches I do not feel qualified to give Acks. I've Cc-ed Pawel and Marek who have a better understanding of the mm internals than I do. Hopefully they can review the code. It definitely looks like a good idea, and if nobody else will comment on the vb2 patches in the next 2 weeks, then I'll try to review it myself (for whatever that's worth). I'm really sorry that I didn't manage to find time to review this patchset. I really like the idea of moving pfn lookup from videobuf2/driver to some common code in mm and it is really great that someone managed to provide nice generic code for it. I've applied the whole patchset onto v4.0 and tested it on Odroid U3 (with some additional patches). VideoBuf2-dc works still fine with USERPTR gathered from other's device mmaped buffer. You can add my: Acked-by: Marek Szyprowski m.szyprow...@samsung.com Tested-by: Marek Szyprowski m.szyprow...@samsung.com Thanks! Thank you both for having a look at the patches! for the patches 1-8. Patch 9/9 doesn't apply anymore, so I've skipped it. Patch 2 needs a small fixup - you need to add '#include linux/vmalloc.h', because otherwise it doesn't compile. There have been also a minor conflict to be resolved in patch 7. I've just added patch 1/9 to my pull request for 4.2. But for patch 2/9 I need Acks from the mm maintainers. I think it makes sense if patches 2-8 all go in together via the linux-media tree. Jan, can you reach out to the right devs to get Acks? Sure, I'll ping some mm guys explicitely. Honza -- Jan Kara j...@suse.cz SUSE Labs, CR -- 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
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date: Sat Apr 25 04:00:20 CEST 2015 git branch: test git hash: e183201b9e917daf2530b637b2f34f1d5afb934d gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-44-g40791b9 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.19.0-1.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: WARNINGS linux-2.6.33.7-i686: WARNINGS linux-2.6.34.7-i686: WARNINGS linux-2.6.35.9-i686: WARNINGS linux-2.6.36.4-i686: WARNINGS linux-2.6.37.6-i686: WARNINGS linux-2.6.38.8-i686: WARNINGS linux-2.6.39.4-i686: WARNINGS linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: WARNINGS linux-3.17.8-i686: WARNINGS linux-3.18.7-i686: WARNINGS linux-3.19-i686: WARNINGS linux-4.0-rc1-i686: WARNINGS linux-2.6.32.27-x86_64: WARNINGS linux-2.6.33.7-x86_64: WARNINGS linux-2.6.34.7-x86_64: WARNINGS linux-2.6.35.9-x86_64: WARNINGS linux-2.6.36.4-x86_64: WARNINGS linux-2.6.37.6-x86_64: WARNINGS linux-2.6.38.8-x86_64: WARNINGS linux-2.6.39.4-x86_64: WARNINGS linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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: [PATCH 1/9] mm: Provide new get_vaddr_pfns() helper
On Mon 17-03-14 20:49:28, Jan Kara wrote:
Provide new function get_vaddr_pfns(). This function maps virtual
addresses from given start and fills given array with page frame numbers of
the corresponding pages. If given start belongs to a normal vma, the function
grabs reference to each of the pages to pin them in memory. If start
belongs to VM_IO | VM_PFNMAP vma, we don't touch page structures. Caller
should make sure pfns aren't reused for anything else while he is using
them.
This function is created for various drivers to simplify handling of
their buffers.
MM guys, could you have a look at this patch? Linux Media people like the
abstraction of buffer handling and would like to merge the patch set (see
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/89268).
But for that they need ack from mm people that the interface is ok with
them. So far the only comment I got regarding the interface was from Dave
Hansen that I could also handle VM_MIXEDMAP mappings - I could if people
really want that but so far there are no users for that. Thanks!
Honza
Signed-off-by: Jan Kara j...@suse.cz
---
include/linux/mm.h | 46 +++
mm/memory.c| 165
+
2 files changed, 211 insertions(+)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index da8ad480bea7..b3bd29cc40dd 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -18,6 +18,8 @@
#include linux/pfn.h
#include linux/bit_spinlock.h
#include linux/shrinker.h
+#include linux/slab.h
+#include linux/vmalloc.h
struct mempolicy;
struct anon_vma;
@@ -1180,6 +1182,50 @@ get_user_pages_unlocked(struct task_struct *tsk,
struct mm_struct *mm,
return ret;
}
+/* Container for pinned pfns / pages */
+struct pinned_pfns {
+ unsigned int nr_allocated_pfns; /* Number of pfns we have space for */
+ unsigned int nr_pfns; /* Number of pfns stored in pfns array
*/
+ unsigned int got_ref:1; /* Did we pin pfns by getting page ref?
*/
+ unsigned int is_pages:1;/* Does array contain pages or pfns? */
+ void *ptrs[0]; /* Array of pinned pfns / pages.
+ * Use pfns_vector_pages() or
+ * pfns_vector_pfns() for access */
+};
+
+struct pinned_pfns *pfns_vector_create(int nr_pfns);
+static inline void pfns_vector_destroy(struct pinned_pfns *pfns)
+{
+ if (!is_vmalloc_addr(pfns))
+ kfree(pfns);
+ else
+ vfree(pfns);
+}
+int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
+struct pinned_pfns *pfns);
+void put_vaddr_pfns(struct pinned_pfns *pfns);
+int pfns_vector_to_pages(struct pinned_pfns *pfns);
+
+static inline int pfns_vector_count(struct pinned_pfns *pfns)
+{
+ return pfns-nr_pfns;
+}
+
+static inline struct page **pfns_vector_pages(struct pinned_pfns *pfns)
+{
+ if (!pfns-is_pages)
+ return NULL;
+ return (struct page **)(pfns-ptrs);
+}
+
+static inline unsigned long *pfns_vector_pfns(struct pinned_pfns *pfns)
+{
+ if (pfns-is_pages)
+ return NULL;
+ return (unsigned long *)(pfns-ptrs);
+}
+
+
struct kvec;
int get_kernel_pages(const struct kvec *iov, int nr_pages, int write,
struct page **pages);
diff --git a/mm/memory.c b/mm/memory.c
index 22dfa617bddb..87bebcfb8911 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2024,6 +2024,171 @@ long get_user_pages(struct task_struct *tsk, struct
mm_struct *mm,
EXPORT_SYMBOL(get_user_pages);
/**
+ * get_vaddr_pfns() - map virtual addresses to pfns
+ * @start: starting user address
+ * @nr_pfns: number of pfns from start to map
+ * @write: whether pages will be written to by the caller
+ * @force: whether to force write access even if user mapping is
+ * readonly. This will result in the page being COWed even
+ * in MAP_SHARED mappings. You do not want this.
+ * @pfns:structure which receives pfns of the pages mapped.
+ * It should have space for at least nr_pfns pfns.
+ *
+ * This function maps virtual addresses from @start and fills @pfns structure
+ * with page frame numbers of corresponding pages. If @start belongs to a
+ * normal vma, the function grabs reference to each of the pages to pin them
in
+ * memory. If @start belongs to VM_IO | VM_PFNMAP vma, we don't touch page
+ * structures. Caller should make sure pfns aren't reused for anything else
+ * while he is using them.
+ *
+ * This function takes care of grabbing mmap_sem as necessary.
+ */
+int get_vaddr_pfns(unsigned long start, int nr_pfns, int write, int force,
+struct pinned_pfns *pfns)
+{
+ struct mm_struct *mm = current-mm;
+ struct
Re: [PATCH] cx18: add missing caps for the PCM video device
On 04/24/2015 08:55 AM, Hans Verkuil wrote:
The cx18 PCM video device didn't have any capabilities set, which caused a
warnings
in the v4l2 core:
[6.229393] [ cut here ]
[6.229414] WARNING: CPU: 1 PID: 593 at
drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70
[videodev]()
[6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409
tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi
x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel
snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+) snd_hda_intel
snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart iTCO_wdt
snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul
crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel
videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat
dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev
mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis
mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc
i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper
[6.229444] drm ptp pps_core video
[6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted
3.19.3-200.fc21.x86_64 #1
[6.229447] Hardware name: Gigabyte Technology Co., Ltd.
Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014
[6.229448] d12b1131 88042dacfc28
8176e215
[6.229449] 88042dacfc68
8109bc1a
[6.229451] a0594000 88042dacfd90
a04e2140
[6.229452] Call Trace:
[6.229466] [8176e215] dump_stack+0x45/0x57
[6.229469] [8109bc1a] warn_slowpath_common+0x8a/0xc0
[6.229472] [8109bd4a] warn_slowpath_null+0x1a/0x20
[6.229474] [a04ca401] v4l_querycap+0x41/0x70 [videodev]
[6.229477] [a04ca6cc] __video_do_ioctl+0x29c/0x320 [videodev]
[6.229479] [81227131] ? do_last+0x2f1/0x1210
[6.229491] [a04cc776] video_usercopy+0x366/0x5d0 [videodev]
[6.229494] [a04ca430] ? v4l_querycap+0x70/0x70 [videodev]
[6.229497] [a04cc9f5] video_ioctl2+0x15/0x20 [videodev]
[6.229499] [a04c6794] v4l2_ioctl+0x164/0x180 [videodev]
[6.229501] [8122e298] do_vfs_ioctl+0x2f8/0x500
[6.229502] [8122e521] SyS_ioctl+0x81/0xa0
[6.229505] [81774a09] system_call_fastpath+0x12/0x17
[6.229506] ---[ end trace dacd80d4b19277ea ]---
Added the necessary capabilities to stop this warning.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Tested-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Laura Abbott labb...@redhat.com
Cc: sta...@vger.kernel.org # for v3.19 and up
---
diff --git a/drivers/media/pci/cx18/cx18-streams.c
b/drivers/media/pci/cx18/cx18-streams.c
index c82d25d..c986084 100644
--- a/drivers/media/pci/cx18/cx18-streams.c
+++ b/drivers/media/pci/cx18/cx18-streams.c
@@ -90,6 +90,7 @@ static struct {
encoder PCM audio,
VFL_TYPE_GRABBER, CX18_V4L2_ENC_PCM_OFFSET,
PCI_DMA_FROMDEVICE,
+ V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
},
{ /* CX18_ENC_STREAM_TYPE_IDX */
encoder IDX,
--
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
[PATCH] usbtv: fix v4l2-compliance issues
Running v4l2-compliance on my usbtv stick revealed two failures:
1) Correct handling of CREATE_BUFS in usbtv_queue_setup was missing. Added this.
2) The sequence counter wasn't reset to 0 when starting streaming.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Tested-by: Hans Verkuil hans.verk...@cisco.com
---
diff --git a/drivers/media/usb/usbtv/usbtv-video.c
b/drivers/media/usb/usbtv/usbtv-video.c
index 9d3525f..08fb0f2 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -599,15 +599,18 @@ static struct v4l2_file_operations usbtv_fops = {
};
static int usbtv_queue_setup(struct vb2_queue *vq,
- const struct v4l2_format *v4l_fmt, unsigned int *nbuffers,
+ const struct v4l2_format *fmt, unsigned int *nbuffers,
unsigned int *nplanes, unsigned int sizes[], void *alloc_ctxs[])
{
struct usbtv *usbtv = vb2_get_drv_priv(vq);
+ unsigned size = USBTV_CHUNK * usbtv-n_chunks * 2 * sizeof(u32);
- if (*nbuffers 2)
- *nbuffers = 2;
+ if (vq-num_buffers + *nbuffers 2)
+ *nbuffers = 2 - vq-num_buffers;
*nplanes = 1;
- sizes[0] = USBTV_CHUNK * usbtv-n_chunks * 2 * sizeof(u32);
+ if (fmt fmt-fmt.pix.sizeimage size)
+ return -EINVAL;
+ sizes[0] = fmt ? fmt-fmt.pix.sizeimage : size;
return 0;
}
@@ -635,6 +638,7 @@ static int usbtv_start_streaming(struct vb2_queue *vq,
unsigned int count)
if (usbtv-udev == NULL)
return -ENODEV;
+ usbtv-sequence = 0;
return usbtv_start(usbtv);
}
--
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] fix: make menuconfig breaks due to whitespaces in Kconfig
Hi, Can you show the Kconfig script that contains the syntax error? I don't quite see how this goes wrong. Perhaps if I see the broken Kconfig I understand this better. Thanks, Hans On 04/10/2015 05:21 AM, tcm...@gmx.net wrote: From: TC tcm...@gmx.net Date: Fri, 10 Apr 2015 04:29:20 +0200 Subject: on some systems like Ubuntu 14.04, whitespaces are added from make_kconfig.pl to Kconfig script during make menuconfig causing it to fail with ./Kconfig:778: syntax error! this patch just removes the originating spaces in two lines --- v4l/scripts/make_kconfig.pl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/v4l/scripts/make_kconfig.pl b/v4l/scripts/make_kconfig.pl index 28b56d0..9228a7b 100755 --- a/v4l/scripts/make_kconfig.pl +++ b/v4l/scripts/make_kconfig.pl @@ -252,8 +252,8 @@ sub checkdeps() # Text to be added to disabled options my $disabled_msg = 'EOF'; ---help--- - WARNING! This driver needs at least kernel %s! It may not - compile or work correctly on your kernel, which is too old. + WARNING! This driver needs at least kernel %s! It may not + compile or work correctly on your kernel, which is too old. EOF -- 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 v2 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? Regards, Benoit Example -- 1.7.10.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 -- 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 v2 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Hi Benoit, On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote: Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? This is done in the caller function; endpoint-bus is zeroed in v4l2_of_parse_endpoint(). I believe reading rest of the properties relies on the same. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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 v2 12/15] dt: bindings: Add lane-polarity property to endpoint nodes
Sakari Ailus sakari.ai...@iki.fi wrote on Fri [2015-Apr-24 22:49:33 +0300]: Hi Benoit, On Fri, Apr 24, 2015 at 02:41:00PM -0500, Benoit Parrot wrote: Sakari Ailus sakari.ai...@iki.fi wrote on Thu [2015-Mar-26 00:57:36 +0200]: Add lane-polarity property to endpoint nodes. This essentially tells that the order of the differential signal wires is inverted. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Documentation/devicetree/bindings/media/video-interfaces.txt |6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/media/video-interfaces.txt b/Documentation/devicetree/bindings/media/video-interfaces.txt index 571b4c6..9cd2a36 100644 --- a/Documentation/devicetree/bindings/media/video-interfaces.txt +++ b/Documentation/devicetree/bindings/media/video-interfaces.txt @@ -106,6 +106,12 @@ Optional endpoint properties - link-frequencies: Allowed data bus frequencies. For MIPI CSI-2, for instance, this is the actual frequency of the bus, not bits per clock per lane value. An array of 64-bit unsigned integers. +- lane-polarities: an array of polarities of the lanes starting from the clock + lane and followed by the data lanes in the same order as in data-lanes. + Valid values are 0 (normal) and 1 (inverted). The length of the array + should be the combined length of data-lanes and clock-lanes properties. + If the lane-polarities property is omitted, the value must be interpreted + as 0 (normal). This property is valid for serial busses only. I am interested in this functionality. But I do have the following question. If the lane-polarities property is not specified, shouldn't the relevant struct member (bus-lane_polarities[i]) be set to 0? This is done in the caller function; endpoint-bus is zeroed in v4l2_of_parse_endpoint(). I believe reading rest of the properties relies on the same. Dang, missed that. Sorry for the noise. -- Kind regards, Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- 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
