Re: [PATCH] V4L: uvcvideo: Add support for relative pan/tilt controls
Hi,
On 06/17/2014 02:38 AM, Vincent Palatin wrote:
> Map V4L2_CID_TILT_RELATIVE and V4L2_CID_PAN_RELATIVE to the standard UVC
> CT_PANTILT_ABSOLUTE_CONTROL terminal control request.
s/ABSOLUTE/RELATIVE in the commit message here.
Otherwise looks good to me.
Regards,
Hans
>
> Tested by plugging a Logitech ConferenceCam C3000e USB camera
> and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
> Verified that it can pan and tilt at the same time in both directions.
>
> Signed-off-by: Vincent Palatin
>
> Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
> ---
> drivers/media/usb/uvc/uvc_ctrl.c | 58
> +---
> 1 file changed, 55 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_ctrl.c
> b/drivers/media/usb/uvc/uvc_ctrl.c
> index 0eb82106..af18120 100644
> --- a/drivers/media/usb/uvc/uvc_ctrl.c
> +++ b/drivers/media/usb/uvc/uvc_ctrl.c
> @@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
> .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> .index = 12,
> .size = 4,
> - .flags = UVC_CTRL_FLAG_SET_CUR | UVC_CTRL_FLAG_GET_MIN
> - | UVC_CTRL_FLAG_GET_MAX | UVC_CTRL_FLAG_GET_RES
> - | UVC_CTRL_FLAG_GET_DEF
> + .flags = UVC_CTRL_FLAG_SET_CUR
> + | UVC_CTRL_FLAG_GET_RANGE
> | UVC_CTRL_FLAG_AUTO_UPDATE,
> },
> {
> @@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping
> *mapping,
> data[2] = min((int)abs(value), 0xff);
> }
>
> +static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
> + __u8 query, const __u8 *data)
> +{
> + int first = mapping->offset / 8;
> + __s8 rel = (__s8)data[first];
> +
> + switch (query) {
> + case UVC_GET_CUR:
> + return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
> + : -data[first+1]);
> + case UVC_GET_MIN:
> + return -data[first+1];
> + case UVC_GET_MAX:
> + case UVC_GET_RES:
> + case UVC_GET_DEF:
> + default:
> + return data[first+1];
> + }
> +}
> +
> +static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
> + __s32 value, __u8 *data)
> +{
> + int first = mapping->offset / 8;
> +
> + data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
> + data[first+1] = min_t(int, abs(value), 0xff);
> +}
> +
> static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> {
> .id = V4L2_CID_BRIGHTNESS,
> @@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
> .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> },
> {
> + .id = V4L2_CID_PAN_RELATIVE,
> + .name = "Pan (Relative)",
> + .entity = UVC_GUID_UVC_CAMERA,
> + .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> + .size = 16,
> + .offset = 0,
> + .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> + .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> + .get= uvc_ctrl_get_rel_speed,
> + .set= uvc_ctrl_set_rel_speed,
> + },
> + {
> + .id = V4L2_CID_TILT_RELATIVE,
> + .name = "Tilt (Relative)",
> + .entity = UVC_GUID_UVC_CAMERA,
> + .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
> + .size = 16,
> + .offset = 16,
> + .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
> + .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
> + .get= uvc_ctrl_get_rel_speed,
> + .set= uvc_ctrl_set_rel_speed,
> + },
> + {
> .id = V4L2_CID_PRIVACY,
> .name = "Privacy",
> .entity = UVC_GUID_UVC_CAMERA,
>
--
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: ERRORS
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: Tue Jun 17 04:00:18 CEST 2014 git branch: test git hash: f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0-14-gf11dd94 host hardware: x86_64 host os:3.14-5.slh.5-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: OK linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.31.14-i686: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK 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-i686: OK linux-3.13-i686: OK linux-3.14-i686: OK linux-3.15-i686: OK linux-3.16-rc1-i686: ERRORS linux-2.6.31.14-x86_64: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK 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-x86_64: OK linux-3.13-x86_64: OK linux-3.14-x86_64: OK linux-3.15-x86_64: OK linux-3.16-rc1-x86_64: ERRORS apps: OK spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.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
[PATCH] V4L: uvcvideo: Add support for relative pan/tilt controls
Map V4L2_CID_TILT_RELATIVE and V4L2_CID_PAN_RELATIVE to the standard UVC
CT_PANTILT_ABSOLUTE_CONTROL terminal control request.
Tested by plugging a Logitech ConferenceCam C3000e USB camera
and controlling pan/tilt from the userspace using the VIDIOC_S_CTRL ioctl.
Verified that it can pan and tilt at the same time in both directions.
Signed-off-by: Vincent Palatin
Change-Id: I7b70b228e5c0126683f5f0be34ffd2807f5783dc
---
drivers/media/usb/uvc/uvc_ctrl.c | 58 +---
1 file changed, 55 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/uvc/uvc_ctrl.c b/drivers/media/usb/uvc/uvc_ctrl.c
index 0eb82106..af18120 100644
--- a/drivers/media/usb/uvc/uvc_ctrl.c
+++ b/drivers/media/usb/uvc/uvc_ctrl.c
@@ -309,9 +309,8 @@ static struct uvc_control_info uvc_ctrls[] = {
.selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
.index = 12,
.size = 4,
- .flags = UVC_CTRL_FLAG_SET_CUR | UVC_CTRL_FLAG_GET_MIN
- | UVC_CTRL_FLAG_GET_MAX | UVC_CTRL_FLAG_GET_RES
- | UVC_CTRL_FLAG_GET_DEF
+ .flags = UVC_CTRL_FLAG_SET_CUR
+ | UVC_CTRL_FLAG_GET_RANGE
| UVC_CTRL_FLAG_AUTO_UPDATE,
},
{
@@ -391,6 +390,35 @@ static void uvc_ctrl_set_zoom(struct uvc_control_mapping
*mapping,
data[2] = min((int)abs(value), 0xff);
}
+static __s32 uvc_ctrl_get_rel_speed(struct uvc_control_mapping *mapping,
+ __u8 query, const __u8 *data)
+{
+ int first = mapping->offset / 8;
+ __s8 rel = (__s8)data[first];
+
+ switch (query) {
+ case UVC_GET_CUR:
+ return (rel == 0) ? 0 : (rel > 0 ? data[first+1]
+: -data[first+1]);
+ case UVC_GET_MIN:
+ return -data[first+1];
+ case UVC_GET_MAX:
+ case UVC_GET_RES:
+ case UVC_GET_DEF:
+ default:
+ return data[first+1];
+ }
+}
+
+static void uvc_ctrl_set_rel_speed(struct uvc_control_mapping *mapping,
+ __s32 value, __u8 *data)
+{
+ int first = mapping->offset / 8;
+
+ data[first] = value == 0 ? 0 : (value > 0) ? 1 : 0xff;
+ data[first+1] = min_t(int, abs(value), 0xff);
+}
+
static struct uvc_control_mapping uvc_ctrl_mappings[] = {
{
.id = V4L2_CID_BRIGHTNESS,
@@ -677,6 +705,30 @@ static struct uvc_control_mapping uvc_ctrl_mappings[] = {
.data_type = UVC_CTRL_DATA_TYPE_SIGNED,
},
{
+ .id = V4L2_CID_PAN_RELATIVE,
+ .name = "Pan (Relative)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 0,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
+ .id = V4L2_CID_TILT_RELATIVE,
+ .name = "Tilt (Relative)",
+ .entity = UVC_GUID_UVC_CAMERA,
+ .selector = UVC_CT_PANTILT_RELATIVE_CONTROL,
+ .size = 16,
+ .offset = 16,
+ .v4l2_type = V4L2_CTRL_TYPE_INTEGER,
+ .data_type = UVC_CTRL_DATA_TYPE_SIGNED,
+ .get= uvc_ctrl_get_rel_speed,
+ .set= uvc_ctrl_set_rel_speed,
+ },
+ {
.id = V4L2_CID_PRIVACY,
.name = "Privacy",
.entity = UVC_GUID_UVC_CAMERA,
--
2.0.0.526.g5318336
--
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] [v4l-utils] keytable: add support for XMP IR protocol
---
utils/keytable/keytable.c | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 065ac3b..ba98cd3 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -86,6 +86,7 @@ enum ir_protocols {
LIRC= 1 << 5,
SANYO = 1 << 6,
RC_5_SZ = 1 << 7,
+ XMP = 1 << 8,
OTHER = 1 << 31,
};
@@ -110,7 +111,7 @@ static const char doc[] = "\nAllows get/set IR
keycode/scancode tables\n"
" SYSDEV - the ir class as found at /sys/class/rc\n"
" TABLE- a file with a set of scancode=keycode value pairs\n"
" SCANKEY - a set of scancode1=keycode1,scancode2=keycode2.. value
pairs\n"
- " PROTOCOL - protocol name (nec, rc-5, rc-6, jvc, sony, sanyo,
rc-5-sz, lirc, other) to be enabled\n"
+ " PROTOCOL - protocol name (nec, rc-5, rc-6, jvc, sony, sanyo,
rc-5-sz, lirc, xmp, other) to be enabled\n"
" DELAY- Delay before repeating a keystroke\n"
" PERIOD - Period to repeat a keystroke\n"
" CFGFILE - configuration file that associates a driver/table name
with a keymap file\n"
@@ -234,6 +235,8 @@ static error_t parse_keyfile(char *fname, char **table)
ch_proto |= SANYO;
else if
(!strcasecmp(p,"rc-5-sz"))
ch_proto |= RC_5_SZ;
+ else if (!strcasecmp(p,"xmp"))
+ ch_proto |= XMP;
else if (!strcasecmp(p,"other")
|| !strcasecmp(p,"unknown"))
ch_proto |= OTHER;
else {
@@ -471,6 +474,8 @@ static error_t parse_opt(int k, char *arg, struct
argp_state *state)
ch_proto |= LIRC;
else if (!strcasecmp(p,"rc-5-sz"))
ch_proto |= RC_5_SZ;
+ else if (!strcasecmp(p,"xmp"))
+ ch_proto |= XMP;
else
goto err_inval;
p = strtok(NULL, ",;");
@@ -744,6 +749,8 @@ static enum ir_protocols v1_get_hw_protocols(char *name)
proto |= SANYO;
else if (!strcmp(p, "rc-5-sz"))
proto |= RC_5_SZ;
+ else if (!strcmp(p, "xmp"))
+ proto |= XMP;
else
proto |= OTHER;
@@ -790,6 +797,9 @@ static int v1_set_hw_protocols(struct rc_device *rc_dev)
if (rc_dev->current & RC_5_SZ)
fprintf(fp, "rc-5-sz ");
+ if (rc_dev->current & XMP)
+ fprintf(fp, "xmp ");
+
if (rc_dev->current & OTHER)
fprintf(fp, "unknown ");
@@ -921,6 +931,8 @@ static enum ir_protocols v2_get_protocols(struct rc_device
*rc_dev, char *name)
proto = LIRC;
else if (!strcmp(p, "rc-5-sz"))
proto = RC_5_SZ;
+ else if (!strcmp(p, "xmp"))
+ proto = XMP;
else
proto = OTHER;
@@ -977,6 +989,9 @@ static int v2_set_protocols(struct rc_device *rc_dev)
if (rc_dev->current & RC_5_SZ)
fprintf(fp, "+rc-5-sz\n");
+ if (rc_dev->current & XMP)
+ fprintf(fp, "+xmp\n");
+
if (rc_dev->current & OTHER)
fprintf(fp, "+unknown\n");
@@ -1006,6 +1021,8 @@ static void show_proto( enum ir_protocols proto)
fprintf (stderr, "LIRC ");
if (proto & RC_5_SZ)
fprintf (stderr, "RC-5-SZ ");
+ if (proto & XMP)
+ fprintf (stderr, "XMP ");
if (proto & OTHER)
fprintf (stderr, "other ");
}
@@ -1128,6 +1145,10 @@ static int get_attribs(struct rc_device *rc_dev, char
*sysfs_name)
rc_dev->supported |= SONY;
if (v1_get_sw_enabled_protocol(cur->name))
rc_dev->current |= SONY;
+ } else if (strstr(cur->name, "/xmp_decoder")) {
+ rc_dev->supported |= XMP;
+ if (v1_get_sw_enabled_protocol(cur->name))
+ rc_dev->current |= XMP;
}
}
@@ -1159,6 +1180,9 @@ static int set_proto(struct rc_device *rc_dev)
if (rc_dev->supported & SONY)
rc += v1_set_sw_enabled_protocol(rc_dev,
"/sony_decoder",
rc_dev->current & SONY);
+ if (rc_dev->supported & XMP)
+
Re: [PATCHv2 for v3.16] hdpvr: fix two audio bugs
On 06/16/2014 05:08 AM, Hans Verkuil wrote:
> Scott,
>
> Here is the correct version :-) Can you verify that it works for you?
>
> Regards,
>
> Hans
>
> When the audio encoding is changed the driver calls hdpvr_set_audio
> with the current opt->audio_input value. However, that should have
> been opt->audio_input + 1. So changing the audio encoding inadvertently
> changes the input as well. This bug has always been there.
>
> The second bug was introduced in kernel 3.10 and that broke the
> default_audio_input module option handling: the audio encoding was
> never switched to AC3 if default_audio_input was set to 2 (SPDIF input).
>
> In addition, since starting with 3.10 the audio encoding is always set
> at the start the first bug now always happens when the driver is loaded.
> In the past this bug would only surface if the user would change the
> audio encoding after the driver was loaded.
>
> Also fixes a small trivial typo (bufffer -> buffer).
>
> Signed-off-by: Hans Verkuil
> Reported-by: Scott Doty
> Cc: sta...@vger.kernel.org # for v3.10 and up
> ---
> drivers/media/usb/hdpvr/hdpvr-video.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
> b/drivers/media/usb/hdpvr/hdpvr-video.c
> index 0500c417..6bce01a 100644
> --- a/drivers/media/usb/hdpvr/hdpvr-video.c
> +++ b/drivers/media/usb/hdpvr/hdpvr-video.c
> @@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(struct urb *urb)
> }
>
> /*=*/
> -/* bufffer bits */
> +/* buffer bits */
>
> /* function expects dev->io_mutex to be hold by caller */
> int hdpvr_cancel_queue(struct hdpvr_device *dev)
> @@ -926,7 +926,7 @@ static int hdpvr_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_AUDIO_ENCODING:
> if (dev->flags & HDPVR_FLAG_AC3_CAP) {
> opt->audio_codec = ctrl->val;
> - return hdpvr_set_audio(dev, opt->audio_input,
> + return hdpvr_set_audio(dev, opt->audio_input + 1,
> opt->audio_codec);
> }
> return 0;
> @@ -1198,7 +1198,7 @@ int hdpvr_register_videodev(struct hdpvr_device *dev,
> struct device *parent,
> v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
> V4L2_CID_MPEG_AUDIO_ENCODING,
> ac3 ? V4L2_MPEG_AUDIO_ENCODING_AC3 :
> V4L2_MPEG_AUDIO_ENCODING_AAC,
> - 0x7, V4L2_MPEG_AUDIO_ENCODING_AAC);
> + 0x7, ac3 ? dev->options.audio_codec :
> V4L2_MPEG_AUDIO_ENCODING_AAC);
> v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
> V4L2_CID_MPEG_VIDEO_ENCODING,
> V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC, 0x3,
This did the trick! Now my 5.1 audio is back -- and as a bonus, the
device now resets properly after a channel change.
Thank you very much! Woo hoo! :)
-Scott
--
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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
Em Mon, 16 Jun 2014 15:04:44 -0400 Devin Heitmueller escreveu: > >> The official TV playback application, found on the CD with drivers, > >> captures samples from the card into its buffer, and plays from the other > >> end of the buffer concurrently. If there are, on average for a few > >> seconds, too few samples in the buffer, it means that they are consumed > >> faster than they arrive, and so the SAA chip is told to produce them a > >> bit faster. If they accumulate too much, the SAA chip is told to produce > >> them slower. That's it. > > > > Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > > > >> > > >> > The xc5000 tuner used on this TV device doesn't provide any mechanism > >> > to control audio PLL. It just sends the audio samples to au0828 via a > >> > I2S bus. All the audio control is done by the USB bridge at au0828, > >> > and that is pretty much limited. The only control that au0828 accepts > >> > is the control of the URB buffers (e. g., number of URB packets and > >> > URB size). > > It's probably worth noting that Mauro's explanation here is incorrect > - the xc5000 does *not* put out I2S. It outputs an SIF which is fed > to the au8522. The au8522 has the audio decoder, and it's responsible > for putting out I2S to the au0828. > > Hence the xc5000's PLL would have no role here. > Ah, OK. I didn't notice that hvr950q was using SIF. In this case, then maybe au8522 may have some PLL fine tune register to adjust the sampling rate. > In fact, you should see the exact same behavior on the A/V input, > since the au8522 is responsible for the I2S clock which drives the > cs5503 (the 5503 is in slave mode). I suspect that the best is to use a resampling code to avoid the frequency drift clock issue, as it is generic enough to cover both cases, and won't require hardware-assisted support. Yet, as I posted on my previous email, this is not yet the kind of bug that we're facing right now. If I'm doing the calculus correct, a -10Hz difference at a 48 kHz sampling rate would take ~150 seconds to cause an underrun (a 16 ms period_bytes lost). Regards, Mauro -- 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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
>> The official TV playback application, found on the CD with drivers, >> captures samples from the card into its buffer, and plays from the other >> end of the buffer concurrently. If there are, on average for a few >> seconds, too few samples in the buffer, it means that they are consumed >> faster than they arrive, and so the SAA chip is told to produce them a >> bit faster. If they accumulate too much, the SAA chip is told to produce >> them slower. That's it. > > Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > >> > >> > The xc5000 tuner used on this TV device doesn't provide any mechanism >> > to control audio PLL. It just sends the audio samples to au0828 via a >> > I2S bus. All the audio control is done by the USB bridge at au0828, >> > and that is pretty much limited. The only control that au0828 accepts >> > is the control of the URB buffers (e. g., number of URB packets and >> > URB size). It's probably worth noting that Mauro's explanation here is incorrect - the xc5000 does *not* put out I2S. It outputs an SIF which is fed to the au8522. The au8522 has the audio decoder, and it's responsible for putting out I2S to the au0828. Hence the xc5000's PLL would have no role here. In fact, you should see the exact same behavior on the A/V input, since the au8522 is responsible for the I2S clock which drives the cs5503 (the 5503 is in slave mode). Devin -- Devin J. Heitmueller - 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
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
Em Mon, 16 Jun 2014 23:16:02 +0600 "Alexander E. Patrakov" escreveu: > 16.06.2014 22:24, Mauro Carvalho Chehab wrote: > > Em Mon, 16 Jun 2014 20:38:52 +0600 > > "Alexander E. Patrakov" escreveu: > > > >> 16.06.2014 20:21, Mauro Carvalho Chehab wrote: > >>> Both xawtv and tvtime use the same code for audio: > >>> http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > >>> > >>> There's an algorithm there that gets the period size form both the > >>> capture and the playback cards, trying to find a minimum period that > >>> would work properly for both. > >> > >> I don't see any adaptive resampler (similar to what module-loopback does > >> in pulseaudio) there. > > > > Are you referring to changing the sample rate? This doesn't > > affect my test scenario, as the playback interface supports the > > only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): > > > > Codec: Realtek ALC269VC > > Default PCM: > > rates [0x5f0]: 32000 44100 48000 88200 96000 192000 > > bits [0xe]: 16 20 24 > > formats [0x1]: PCM > > No, it doesn't. The card only pretends to give out samples at 48000 Hz, > but, due to the imperfect quartz, actually gives them out at something > like 48010 or 47990 Hz (if we take the Realtek's idea of 48 kHz as the > source of truth), and that even changes slightly due to thermal issues. > The goal here is to measure the actual sample rate and to resample from > it to 48 kHz. I see. Well, you're talking about a xrun that would happen after several seconds, and caused by a clock drift between capture and playback xtals. The issue we're facing happens dozen of times a second, and it is caused by something else: despiste what period_size says, with this board, the sampling period is not continuous. The reason for that is simple: 1ms is the minimal interval for this board can feed interrupts, and the minimal period size = 192 bytes (as anything lower than 192 bytes would cause data to be dropped). As the maximum limit per URB transfer is 3072 bytes (12 URB packs, with 256 bytes each), we have: Period time = (num_bytes + 191) / 192 ms For num_bytes between 192 and 3072. After 3072, the URB endpoint will always use 3072 bytes per URB transfer, with takes 16 ms to be filled. So, the period time is given by: Period time = (num_bytes / 3072) * 16 ms In other words, the period ranges from 1 to 16 ms, in 1ms step, up to 3072 bytes. After that, the period is always multiple of 16 ms. Trying to set it to any value between 17 ms and 31 ms causes xruns, because the buffer will only be filled the next time the URB callback is called (and this happens on every 16 ms). That's what happens with xawtv currently: while the hardware has a 16ms-multiple constraint for the period size, but as there's no constraints at the ALSA Kernel code enforcing a period size multiple of 16 ms, xawtv will set it to its default latency (30 ms). That works fine for the first transfer, but it gets an underrun before the second one. So, we have about 30 underruns per second. There's nothing that can be done on userspace, as the 16 ms multiple request is specific to this card. Other cards use different URB constraints, as different maxsize and/or different number of URBs would result on a different period size. So, changing it in userspace from one card breaks for the others. > The "alsaloop" program (part of alsa-utils), when compiled > with libsamplerate, does exactly that. If GPLv2+ is OK for you, you can > copy the code. After having this big xrun issue fixed, I'll look into it. I need to check if xawtv/tvtime license is GPLv2. > >> Without that, or dynamically controlling the audio > >> capture clock PLL in the tuner, xruns are unavoidable when transferring > >> data between two unrelated cards. > > > > What do you mean by dynamically controlling the audio capture clock PLL > > in the tuner? That doesn't make any sense to me. > > Some chips (e.g. SAA7133) have a register that allows fine-tuning the > actual rate at which they sample the sound (while applications still > think that it is nominally at 32 kHz). This register is not exposed at > the ALSA level, but exposed as the "audio_clock_tweak" parameter of the > saa7134 module. Linux applications normally don't use this register, but > Windows uses this register as follows. > > The official TV playback application, found on the CD with drivers, > captures samples from the card into its buffer, and plays from the other > end of the buffer concurrently. If there are, on average for a few > seconds, too few samples in the buffer, it means that they are consumed > faster than they arrive, and so the SAA chip is told to produce them a > bit faster. If they accumulate too much, the SAA chip is told to produce > them slower. That's it. Ok. Well, xc5000 (with does the audio sampling) doesn't have it, AFAIKT. > > > > The xc5000 tuner used on this TV device doesn't provide any mechanism
We offer all purpose loan at 3% interest rate
We offer all purpose loan at 3% interest rate. Contact Us for more details by Email:santanderfinancegr...@gmail.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
MANY errors while building media docbooks
on Linux v3.16-rc1, building docbooks to a separate build directory (mkdir DOC; make O=DOC htmldocs) gives me more than 12,000 lines like this: grep: ./Documentation/DocBook//vidioc-subdev-g-fmt.xml: No such file or directory grep: ./Documentation/DocBook//vidioc-subdev-g-frame-interval.xml: No such file or directory grep: ./Documentation/DocBook//vidioc-subdev-g-selection.xml: No such file or directory grep: ./Documentation/DocBook//vidioc-subscribe-event.xml: No such file or directory grep: ./Documentation/DocBook//media-ioc-device-info.xml: No such file or directory grep: ./Documentation/DocBook//media-ioc-enum-entities.xml: No such file or directory grep: ./Documentation/DocBook//media-ioc-enum-links.xml: No such file or directory grep: ./Documentation/DocBook//media-ioc-setup-link.xml: No such file or directory -- ~Randy -- 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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
16.06.2014 22:24, Mauro Carvalho Chehab wrote: Em Mon, 16 Jun 2014 20:38:52 +0600 "Alexander E. Patrakov" escreveu: 16.06.2014 20:21, Mauro Carvalho Chehab wrote: Both xawtv and tvtime use the same code for audio: http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c There's an algorithm there that gets the period size form both the capture and the playback cards, trying to find a minimum period that would work properly for both. I don't see any adaptive resampler (similar to what module-loopback does in pulseaudio) there. Are you referring to changing the sample rate? This doesn't affect my test scenario, as the playback interface supports the only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): Codec: Realtek ALC269VC Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM No, it doesn't. The card only pretends to give out samples at 48000 Hz, but, due to the imperfect quartz, actually gives them out at something like 48010 or 47990 Hz (if we take the Realtek's idea of 48 kHz as the source of truth), and that even changes slightly due to thermal issues. The goal here is to measure the actual sample rate and to resample from it to 48 kHz. The "alsaloop" program (part of alsa-utils), when compiled with libsamplerate, does exactly that. If GPLv2+ is OK for you, you can copy the code. Without that, or dynamically controlling the audio capture clock PLL in the tuner, xruns are unavoidable when transferring data between two unrelated cards. What do you mean by dynamically controlling the audio capture clock PLL in the tuner? That doesn't make any sense to me. Some chips (e.g. SAA7133) have a register that allows fine-tuning the actual rate at which they sample the sound (while applications still think that it is nominally at 32 kHz). This register is not exposed at the ALSA level, but exposed as the "audio_clock_tweak" parameter of the saa7134 module. Linux applications normally don't use this register, but Windows uses this register as follows. The official TV playback application, found on the CD with drivers, captures samples from the card into its buffer, and plays from the other end of the buffer concurrently. If there are, on average for a few seconds, too few samples in the buffer, it means that they are consumed faster than they arrive, and so the SAA chip is told to produce them a bit faster. If they accumulate too much, the SAA chip is told to produce them slower. That's it. The xc5000 tuner used on this TV device doesn't provide any mechanism to control audio PLL. It just sends the audio samples to au0828 via a I2S bus. All the audio control is done by the USB bridge at au0828, and that is pretty much limited. The only control that au0828 accepts is the control of the URB buffers (e. g., number of URB packets and URB size). OK, as you can't tweak the PLL, you have to resample. The idea is, again, simple. Record samples to a buffer if you can, and play them through a variable-rate resampler concurrently if you can. You can use poll() to figure out the "if you can" part. If samples accumulate too much or if the buffer becomes too empty, change the resampling ratio slightly in order to compensate. As I said, the code is here: http://git.alsa-project.org/?p=alsa-utils.git;a=tree;f=alsaloop -- Alexander E. Patrakov -- 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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
Em Mon, 16 Jun 2014 20:38:52 +0600 "Alexander E. Patrakov" escreveu: > 16.06.2014 20:21, Mauro Carvalho Chehab wrote: > > Both xawtv and tvtime use the same code for audio: > > http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c > > > > There's an algorithm there that gets the period size form both the > > capture and the playback cards, trying to find a minimum period that > > would work properly for both. > > I don't see any adaptive resampler (similar to what module-loopback does > in pulseaudio) there. Are you referring to changing the sample rate? This doesn't affect my test scenario, as the playback interface supports the only PCM format/rate used by the TV card (48kHz, 16 bits/sample, stereo): Codec: Realtek ALC269VC Default PCM: rates [0x5f0]: 32000 44100 48000 88200 96000 192000 bits [0xe]: 16 20 24 formats [0x1]: PCM > Without that, or dynamically controlling the audio > capture clock PLL in the tuner, xruns are unavoidable when transferring > data between two unrelated cards. What do you mean by dynamically controlling the audio capture clock PLL in the tuner? That doesn't make any sense to me. The xc5000 tuner used on this TV device doesn't provide any mechanism to control audio PLL. It just sends the audio samples to au0828 via a I2S bus. All the audio control is done by the USB bridge at au0828, and that is pretty much limited. The only control that au0828 accepts is the control of the URB buffers (e. g., number of URB packets and URB size). > > So, until any further evidence appears, I think it is a common bug in > these audio codes. > alsa-info.txt.7qy7T0g90U Description: Binary data
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
Em Mon, 16 Jun 2014 09:22:08 -0400 Devin Heitmueller escreveu: > > This looks like a workaround for a userspace bug that would affect all > > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > > use? > > I have similar concerns, although I don't know what the right solution > is. For example, the last time Mauro tweaked the latency in tvtime, > it broke support for all cx231xx devices (note that tvtime and xawtv > share essentially the same ALSA code): > > http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b59a94cec746ccad6ebe > > It seems like there is definitely something wrong with the > latency/period selection in both applications, but we need some > insight from people who are better familiar with the ALSA subsystem > for advice on the "right" way to do low latency audio capture (i.e. > properly negotiating minimal latency in a way that works with all > devices). Well, I suspect that the issue is at Kernel level. Let's see the au0828 case: 48 kHz, 2 bytes/sample, 2 channels, 256 maxpacksize, 1 ms URB interval (bInterval = 1). In this case, there is 192 bytes per 1ms period. Let's assume that the period was set to 3456, with corresponds to a latency of 18 ms. In this case, as NUM_URBS = 12, it means that the transfer buffer will be set to its maximum value of 3072 bytes per URB pack (12 * 256), and the URB transfer_callback will be called on every 16 ms. So, what happens is: - after 16 ms, the first 3072 bytes arrive. The next packet will take another 16ms to arrive; - after 2 ms, underrun, as the period_size was not filled yet. The thing is that any latency that between 16 ms and 32 ms are invalid, as the URB settings won't support it. Regards, Mauro -- 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 RESEND] libv4lconvert: Fix a regression when converting from Y10B
Fix a regression introduced in commit
efc29f1764a30808ebf7b3e1d9bfa27b909bf641 (libv4lconvert: Reject too
short source buffer before accessing it).
The old code:
case V4L2_PIX_FMT_Y10BPACK:
...
if (result == 0 && src_size < (width * height * 10 / 8)) {
V4LCONVERT_ERR("short y10b data frame\n");
errno = EPIPE;
result = -1;
}
...
meant to say "If the conversion was *successful* _but_ the frame size
was invalid, then take the error path", but in
efc29f1764a30808ebf7b3e1d9bfa27b909bf641 this (maybe weird) logic was
misunderstood and v4lconvert_convert_pixfmt() was made to return an
error even in the case of a successful conversion from Y10B.
Fix the check, and now print only the message letting the errno and the
result from the conversion routines to be propagated to the caller.
Signed-off-by: Antonio Ospite
Cc: Gregor Jasny
---
lib/libv4lconvert/libv4lconvert.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/lib/libv4lconvert/libv4lconvert.c
b/lib/libv4lconvert/libv4lconvert.c
index c49d30d..50d6906 100644
--- a/lib/libv4lconvert/libv4lconvert.c
+++ b/lib/libv4lconvert/libv4lconvert.c
@@ -1052,11 +1052,8 @@ static int v4lconvert_convert_pixfmt(struct
v4lconvert_data *data,
width, height);
break;
}
- if (result == 0) {
+ if (result != 0)
V4LCONVERT_ERR("y10b conversion failed\n");
- errno = EPIPE;
- result = -1;
- }
break;
case V4L2_PIX_FMT_RGB565:
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
16.06.2014 20:21, Mauro Carvalho Chehab wrote: Both xawtv and tvtime use the same code for audio: http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c There's an algorithm there that gets the period size form both the capture and the playback cards, trying to find a minimum period that would work properly for both. I don't see any adaptive resampler (similar to what module-loopback does in pulseaudio) there. Without that, or dynamically controlling the audio capture clock PLL in the tuner, xruns are unavoidable when transferring data between two unrelated cards. So, until any further evidence appears, I think it is a common bug in these audio codes. -- Alexander E. Patrakov -- 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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
Em Mon, 16 Jun 2014 09:39:17 +0200 Clemens Ladisch escreveu: > (CC stable dropped; this is not how to submit stable patches.) > > Mauro Carvalho Chehab wrote: > > The Auvitek 0828 chip, used on HVR950Q actually need two > > quirks and not just one. > > > > The first one, already implemented, enforces that it won't have > > channel swaps at the transfers. > > > > However, for TV applications, like xawtv and tvtime, another quirk > > is needed, in order to enforce that, at least 2 URB transfer > > intervals will be needed to fill a buffer. > > > + period = 2 * MAX_URBS * fp->maxpacksize; > > + min_period = period * 90 / 100; > > + max_period = period * 110 / 100; > > I don't quite understand what you mean with "URB transfer interval". > > All USB audio devices transfer packets in intervals between 125 µs and > 1000 µs. In this case, it uses a 1000 µs, as defined at the USB descriptor for the au0828 devices (bInterval). FYI, those TV devices are too limited, in terms of audio: they only provide: - 48 kHz rate; - 16 bits/sample; - 2 channels; - maxumum URB size: 256 bytes. Its internal firmware is also too buggy. We needed to add several workarounds at both analog and digital stream support for some conditions that caused the chip to stop producing URBs, or made it to cause ESHUTDOWN errors while streaming. > MAX_URBS is a somewhat random value that is not directly derived from > either a hardware or software constraint. Yes, I noticed that. > Are you trying to enforce two packets per URB? No, I'm trying to enforce that it won't complain about underruns, while keeping the latency constrained. This is the same kind of fix we needed to do with em28xx-audio.c some time ago. In this case, I'm enforcing that the URB callback will receive 3072 samples, and that the PCM timer won't be triggered too early, e. g. it will wait for the needed time for the URB callback to be called twice. > Why are you setting both a minimum and a maximum? When I wrote em28xx patches, I did several tests with different max latency constraints. On some cases, when it selected an odd number of periods, we would still have some troubles. So, it sounds safer to keep the same type of logic here. Anyway, just setting the minimum is enough for xawtv/tvtime to work with the default -alsa-latency parameter. > Isn't this affected by the constraints of the playback device? Hard to tell without having a test hardware with different constraints. All playback hardware I currently have supports 48 kHz rate, and supports a period size in the range of this The application takes those constraints into account > > > Without it, buffer underruns happen when trying to syncronize the > > audio input from au0828 and the audio playback at the default audio > > output device. > > This looks like a workaround for a userspace bug that would affect all > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > use? Both xawtv and tvtime use the same code for audio: http://git.linuxtv.org/cgit.cgi/xawtv3.git/tree/common/alsa_stream.c There's an algorithm there that gets the period size form both the capture and the playback cards, trying to find a minimum period that would work properly for both. It tries to enforce a choice where the max latency would be constrained. The max latency is 30ms, by default, but the user can change it via -alsa-latency parameter. Regards, Mauro -- 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 v9 5/5] ARM: sunxi: Enable IR controller on cubieboard 2 and cubietruck in dts
On Mon, Jun 09, 2014 at 12:08:13AM +0600, Alexander Bersenev wrote: > This patch enables two IR devices in dts: > - One IR device physically found on Cubieboard 2 > - One IR device physically found on Cubietruck > > Signed-off-by: Alexander Bersenev > Signed-off-by: Alexsey Shestacov Applied, thanks. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v9 3/5] ARM: sunxi: Add pins for IR controller on A20 to dtsi
Hi, On Mon, Jun 09, 2014 at 12:08:11AM +0600, Alexander Bersenev wrote: > This patch adds pins for two IR controllers on A20 > > Signed-off-by: Alexander Bersenev > Signed-off-by: Alexsey Shestacov Applied, thanks. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v9 4/5] ARM: sunxi: Add IR controllers on A20 to dtsi
Hi,
On Mon, Jun 09, 2014 at 12:08:12AM +0600, Alexander Bersenev wrote:
> This patch adds records for two IR controllers on A20
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index c057c3e..fe1f8ff 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -763,6 +763,24 @@
> interrupts = <0 24 4>;
> };
>
> + ir0: ir@01c21800 {
> + compatible = "allwinner,sun7i-a20-ir";
> + clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clock-names = "apb", "ir";
> + interrupts = <0 5 4>;
> + reg = <0x01c21800 0x40>;
> + status = "disabled";
> + };
> +
> + ir1: ir@01c21c00 {
> + compatible = "allwinner,sun7i-a20-ir";
> + clocks = <&apb0_gates 7>, <&ir1_clk>;
> + clock-names = "apb", "ir";
> + interrupts = <0 6 4>;
> + reg = <0x01c21c00 0x40>;
> + status = "disabled";
> + };
> +
> lradc: lradc@01c22800 {
> compatible = "allwinner,sun4i-lradc-keys";
> reg = <0x01c22800 0x100>;
I'm fine with this patch, but it doesn't apply, since the above node
doesn't exist. Please rebase on top of v3.16-rc1 and resend the patch.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
> This looks like a workaround for a userspace bug that would affect all > USB audio devices. What period/buffer sizes are xawtv/tvtime trying to > use? I have similar concerns, although I don't know what the right solution is. For example, the last time Mauro tweaked the latency in tvtime, it broke support for all cx231xx devices (note that tvtime and xawtv share essentially the same ALSA code): http://git.linuxtv.org/cgit.cgi/tvtime.git/commit/?id=3d58ba563bfcc350c180b59a94cec746ccad6ebe It seems like there is definitely something wrong with the latency/period selection in both applications, but we need some insight from people who are better familiar with the ALSA subsystem for advice on the "right" way to do low latency audio capture (i.e. properly negotiating minimal latency in a way that works with all devices). Devin -- Devin J. Heitmueller - 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
Re: [PATCH] [media] sms: Remove CONFIG_ prefix from Kconfig symbols
On Wed, 2014-04-16 at 17:47 +0200, Paul Bolle wrote:
> Remove the CONFIG_ prefix from two Kconfig symbols in a dependency for
> SMS_SIANO_DEBUGFS. This prefix is invalid inside Kconfig files.
>
> Note that the current (common sense) dependency on SMS_USB_DRV and
> SMS_SDIO_DRV being equal ensures that SMS_SIANO_DEBUGFS will not
> violate its constraints. These constraint are that:
> - it should only be built if SMS_USB_DRV is set;
> - it can't be builtin if USB support is modular.
>
> So drop the dependency on SMS_USB_DRV, as it is unneeded.
>
> Fixes: 6c84b214284e ("[media] sms: fix randconfig building error")
> Reported-by: Martin Walch
> Signed-off-by: Paul Bolle
> ---
> This is not runtime tested, as I don't have the hardware.
>
> A matrix of the three cases in which this symbol can be set, to aid
> review and to see whether I actually understood the constraints:
>
> USB SMS_USB_DRV SMS_SDIO_DRV SMS_SIANO_MDTV SMS_SIANO_DEBUGFS
> mmm m y
> ymm m y
> yyy y y
>
> By the way, I found myself staring at the entries in this file for quite
> some time. Perhaps things would have been easier to understand if
> SMS_USB_DRV and SMS_SDIO_DRV both selected SMS_SIANO_MDTV. But I didn't
> dare to test that idea.
This can still be seen in v3.16-rc1 and in next-20140616.
Debugfs for smsdvb has been unbuildable since v3.12. That problem has
been reported even before v3.12 was released. Does no one care and can
it be removed?
> drivers/media/common/siano/Kconfig | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/media/common/siano/Kconfig
> b/drivers/media/common/siano/Kconfig
> index f953d33ee151..4bfbd5f463d1 100644
> --- a/drivers/media/common/siano/Kconfig
> +++ b/drivers/media/common/siano/Kconfig
> @@ -22,8 +22,7 @@ config SMS_SIANO_DEBUGFS
> bool "Enable debugfs for smsdvb"
> depends on SMS_SIANO_MDTV
> depends on DEBUG_FS
> - depends on SMS_USB_DRV
> - depends on CONFIG_SMS_USB_DRV = CONFIG_SMS_SDIO_DRV
> + depends on SMS_USB_DRV = SMS_SDIO_DRV
>
> ---help---
> Choose Y to enable visualizing a dump of the frontend
Paul Bolle
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/9] ARM: lager: add i2c1, i2c2 pins
Hello. On 06/15/2014 11:56 PM, Ben Dooks wrote: Add pinctrl definitions for i2c1 and i2c2 busses on the Lager board to ensure these are setup correctly at initialisation time. The i2c0 and i2c3 busses are connected to single function pins. Signed-off-by: Ben Dooks Likewise, this as been already merged by Simon. WBR, Sergei -- 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 v14 09/10] ARM: dts: mbimx51sd: Add display support.
On 06/16/2014 12:11 PM, Denis Carikli wrote:> + reg_lcd_3v3: lcd-en {
> + compatible = "regulator-fixed";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
> + regulator-name = "lcd-3v3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + gpio = <&gpio3 13 GPIO_ACTIVE_HIGH>;
> + regulator-boot-on;
> + };
> +};
This is wrong, I'll fix it in the next serie.
What it really does is to make regulator-fixed think that the gpio is
active low, the bindings documentation(fixed-regulator.txt) says:
> - enable-active-high: Polarity of GPIO is Active high
> If this property is missing, the default assumed is Active low.
Then regulator-boot-on will make it think that the regulator is already
on and so the regulator will be disabled.
From the bindings documentation (regulator.txt):
> regulator-boot-on: bootloader/firmware enabled regulator
Which result at the lcd regulator being physically powered on at boot.
I didn't see that because powering it on at boot is what I want.
How can I do that beside doing it in userspace by issuing the following
commands:
echo 4 > /sys/devices/display-subsystem/graphics/fb0/blank
echo 0 > /sys/devices/display-subsystem/graphics/fb0/blank
Denis.
--
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] ARM: lager: enable i2c devices
Hello.
On 06/15/2014 11:56 PM, Ben Dooks wrote:
Add i2c0, i2c1, i2c2 and i2c3 nodes to the Lager reference device tree as
these busses all have devices on them that can be probed even if they
are no drivers yet.
Signed-off-by: Ben Dooks
---
arch/arm/boot/dts/r8a7790-lager.dts | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index dd2fe46..8617755 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -317,3 +317,19 @@
cd-gpios = <&gpio3 22 GPIO_ACTIVE_LOW>;
status = "okay";
};
+
+&i2c0 {
+ status = "ok";
+};
+
+&i2c1 {
+ status = "ok";
+};
+
+&i2c2 {
+ status = "ok";
+};
+
+&i2c3 {
+ status = "ok";
+};
Against which tree is this patch? It has been merged to Simon's 'devel'
branch on my request already.
WBR, Sergei
--
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
[PATCHv2 for v3.16] hdpvr: fix two audio bugs
Scott,
Here is the correct version :-) Can you verify that it works for you?
Regards,
Hans
When the audio encoding is changed the driver calls hdpvr_set_audio
with the current opt->audio_input value. However, that should have
been opt->audio_input + 1. So changing the audio encoding inadvertently
changes the input as well. This bug has always been there.
The second bug was introduced in kernel 3.10 and that broke the
default_audio_input module option handling: the audio encoding was
never switched to AC3 if default_audio_input was set to 2 (SPDIF input).
In addition, since starting with 3.10 the audio encoding is always set
at the start the first bug now always happens when the driver is loaded.
In the past this bug would only surface if the user would change the
audio encoding after the driver was loaded.
Also fixes a small trivial typo (bufffer -> buffer).
Signed-off-by: Hans Verkuil
Reported-by: Scott Doty
Cc: sta...@vger.kernel.org # for v3.10 and up
---
drivers/media/usb/hdpvr/hdpvr-video.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c
b/drivers/media/usb/hdpvr/hdpvr-video.c
index 0500c417..6bce01a 100644
--- a/drivers/media/usb/hdpvr/hdpvr-video.c
+++ b/drivers/media/usb/hdpvr/hdpvr-video.c
@@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(struct urb *urb)
}
/*=*/
-/* bufffer bits */
+/* buffer bits */
/* function expects dev->io_mutex to be hold by caller */
int hdpvr_cancel_queue(struct hdpvr_device *dev)
@@ -926,7 +926,7 @@ static int hdpvr_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_AUDIO_ENCODING:
if (dev->flags & HDPVR_FLAG_AC3_CAP) {
opt->audio_codec = ctrl->val;
- return hdpvr_set_audio(dev, opt->audio_input,
+ return hdpvr_set_audio(dev, opt->audio_input + 1,
opt->audio_codec);
}
return 0;
@@ -1198,7 +1198,7 @@ int hdpvr_register_videodev(struct hdpvr_device *dev,
struct device *parent,
v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
V4L2_CID_MPEG_AUDIO_ENCODING,
ac3 ? V4L2_MPEG_AUDIO_ENCODING_AC3 :
V4L2_MPEG_AUDIO_ENCODING_AAC,
- 0x7, V4L2_MPEG_AUDIO_ENCODING_AAC);
+ 0x7, ac3 ? dev->options.audio_codec :
V4L2_MPEG_AUDIO_ENCODING_AAC);
v4l2_ctrl_new_std_menu(hdl, &hdpvr_ctrl_ops,
V4L2_CID_MPEG_VIDEO_ENCODING,
V4L2_MPEG_VIDEO_ENCODING_MPEG_4_AVC, 0x3,
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH for v3.16] hdpvr: fix two audio bugs
On 06/16/2014 02:04 PM, Hans Verkuil wrote: > Scott, > > Please verify that this solves your problem. It worked for me. Never mind, I'll repost the right patch in a minute. Hans > > Hans > > > When the audio encoding is changed the driver calls hdpvr_set_audio > with the current opt->audio_input value. However, that should have > been opt->audio_input + 1. So changing the audio encoding inadvertently > changes the input as well. This bug has always been there. > > The second bug was introduced in kernel 3.10 and that broke the > default_audio_input module option handling: the audio encoding was > never switched to AC3 if default_audio_input was set to 2 (SPDIF input). > > In addition, since starting with 3.10 the audio encoding is always set > at the start the first bug now always happens when the driver is loaded. > In the past this bug would only surface if the user would change the > audio encoding after the driver was loaded. > > Also fixes a small trivial typo (bufffer -> buffer). > > Signed-off-by: Hans Verkuil > Tested-by: Hans Verkuil > Reported-by: Scott Doty > Cc: sta...@vger.kernel.org # for v3.10 and up > --- > drivers/media/usb/hdpvr/hdpvr-video.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c > b/drivers/media/usb/hdpvr/hdpvr-video.c > index 0500c417..59f1dd4 100644 > --- a/drivers/media/usb/hdpvr/hdpvr-video.c > +++ b/drivers/media/usb/hdpvr/hdpvr-video.c > @@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(struct urb *urb) > } > > /*=*/ > -/* bufffer bits */ > +/* buffer bits */ > > /* function expects dev->io_mutex to be hold by caller */ > int hdpvr_cancel_queue(struct hdpvr_device *dev) > -- 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 for v3.16] hdpvr: fix two audio bugs
Scott, Please verify that this solves your problem. It worked for me. Hans When the audio encoding is changed the driver calls hdpvr_set_audio with the current opt->audio_input value. However, that should have been opt->audio_input + 1. So changing the audio encoding inadvertently changes the input as well. This bug has always been there. The second bug was introduced in kernel 3.10 and that broke the default_audio_input module option handling: the audio encoding was never switched to AC3 if default_audio_input was set to 2 (SPDIF input). In addition, since starting with 3.10 the audio encoding is always set at the start the first bug now always happens when the driver is loaded. In the past this bug would only surface if the user would change the audio encoding after the driver was loaded. Also fixes a small trivial typo (bufffer -> buffer). Signed-off-by: Hans Verkuil Tested-by: Hans Verkuil Reported-by: Scott Doty Cc: sta...@vger.kernel.org # for v3.10 and up --- drivers/media/usb/hdpvr/hdpvr-video.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/usb/hdpvr/hdpvr-video.c b/drivers/media/usb/hdpvr/hdpvr-video.c index 0500c417..59f1dd4 100644 --- a/drivers/media/usb/hdpvr/hdpvr-video.c +++ b/drivers/media/usb/hdpvr/hdpvr-video.c @@ -82,7 +82,7 @@ static void hdpvr_read_bulk_callback(struct urb *urb) } /*=*/ -/* bufffer bits */ +/* buffer bits */ /* function expects dev->io_mutex to be hold by caller */ int hdpvr_cancel_queue(struct hdpvr_device *dev) -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: "LED / flash API integration" related improvements
Hi Sakari, On 06/16/2014 10:53 AM, Sakari Ailus wrote: Hi Jacek and others, Comments from the LED API folks would be highly appreciated. (Cc linux-media as well.) My comments below. On Fri, May 09, 2014 at 04:28:44PM +0200, Jacek Anaszewski wrote: During review of "LED / flash API integration" patch sets two issues requiring modifications in the LED subsystem core emerged. I would like to consult possible ways of solving them: 1. == Some LED devices allow to control multiple LEDs independently. Currently there is no direct support for this in the LED subsystem and existing drivers register separate devices for each LED. LED / flash API integration effort is a good opportunity to provide support for exposing multiple LEDs by a single LED class device. I would like to add following API: /** * led_get_sub_leds_number - get the number of exposed LEDs * @led_cdev: the LED to query * @num_leds: number of exposed leds * * Get the number of leds exposed by the device. * * Returns: 0 on success or negative error value on failure */ int led_get_sub_leds_number(struct led_classdev *led_cdev, int *num_leds); /** * led_select_sub_led - select sub led to control * @led_cdev: the LED to set * @led_id: id of the sub led to control * * Set the sub led to be the target of the LED class API calls. * Maximum led_id equals num_leds - 1. * * Returns: 0 on success or negative error value on failure */ int led_select_sub_led(struct led_classdev *led_cdev, int led_id); Instead of this, how about using an array indexed by LED for the other functions? The problem with this is that often the registers to control LED specific properties contain the same configuration for another LED. The driver should thus cache the information until it needs to be applied, and I don't think configuring everything for every LED separately makes sense for either the user nor the driver. The max77693-flash is an example of such a design. It has one register for setting flash timeout and it affects timeout for both leds. The register would have to be written right before strobing the flash, in case the cached timeout value is different from the one in the register (cached on last write operation). The device has also common flash status register. I don't have good idea how to proceed in this case. After strobing the flash for any of the sub-leds the remaining ones will also report that they are strobing at the moment. Caching the configuration before applying it should still be done since this way extra register accesses can be avoided: registers often share different kind of configurations such as timeout and current as well. The configuration should be applied once an apply fonction is called. /** * led_get_sub_led - get currently selected sub led * @led_cdev: the LED to set * @led_id: id of currently selected sub led * * Get id of the sub led chosen as the target of LED class * API calls. Maximum led_id equals num_leds - 1. * * Returns: 0 on success or negative error value on failure */ int led_get_target_led(struct led_classdev *led_cdev, int* led_id); The functions functions would be mapped on the sysfs attributes: - available_leds - RO - sub_led_id - RW This kind of interface isn't going to be compatible with existing applications. If you want to keep the compatibility, the LEDs would probably need to be exposed as separate devices. If that's not a requirement, I'd use an array here as well. I started to implement the interface I proposed but encountered several issues related to led-triggers and led_blink feature. They would require significant modifications, I'd rather avoid. Instead I decided to register separate led class device in the driver for the max77693-flash device, similarly as it is accomplished in the led drivers of the other compound led devices. The V4L2 driver would still expose the device as a single sub-device. Controls that apply to individual LEDs would be array controls. Have those array controls been already added? If so, could you spot the place where they are implemented, or maybe there are some examples of usage or documentation? The attributes would be created only if the related callbacks are registered by the driver. 2. == The second issue, refers to the work queues being used in the brightness_set callbacks of the LED subsystem drivers. It interferes with the way how V4L2 Flash controls work, which expect that setting flash brightness has immediate effect. Proposed solutions: - move work queues out from the drivers to the LED core. - add brightness_set_now callback to be registered by the LED drivers and intended for call by v4l2-flash driver; it wouldn't schedule a work but do the job immediately I favour the former, but the la
Re: [patch v2] [media] davinci: vpif: missing unlocks on error
Hi Hans, On Mon, Jun 16, 2014 at 10:48 AM, Hans Verkuil wrote: > Prabhakar, > > Are you going to make a pull request for this, or shall I take it? Should it > be applied > to 3.16? > As this is not a critical bug, I was planning to wait for v3.17 as v3.16 is almost closed. Regards, --Prabhakar Lad > Regards, > > Hans > > On 06/13/2014 08:13 PM, Prabhakar Lad wrote: >> On Thu, Jun 12, 2014 at 8:01 AM, Dan Carpenter >> wrote: >>> We recently changed some locking around so we need some new unlocks on >>> the error paths. >>> >>> Signed-off-by: Dan Carpenter >> >> Applied! >> >> Thanks, >> --Prabhakar Lad >> >>> --- >>> v2: move the unlock so the list_for_each_entry_safe() loop is protected >>> >>> diff --git a/drivers/media/platform/davinci/vpif_capture.c >>> b/drivers/media/platform/davinci/vpif_capture.c >>> index a7ed164..1e4ec69 100644 >>> --- a/drivers/media/platform/davinci/vpif_capture.c >>> +++ b/drivers/media/platform/davinci/vpif_capture.c >>> @@ -269,6 +269,7 @@ err: >>> list_del(&buf->list); >>> vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED); >>> } >>> + spin_unlock_irqrestore(&common->irqlock, flags); >>> >>> return ret; >>> } >>> diff --git a/drivers/media/platform/davinci/vpif_display.c >>> b/drivers/media/platform/davinci/vpif_display.c >>> index 5bb085b..b431b58 100644 >>> --- a/drivers/media/platform/davinci/vpif_display.c >>> +++ b/drivers/media/platform/davinci/vpif_display.c >>> @@ -233,6 +233,7 @@ err: >>> list_del(&buf->list); >>> vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED); >>> } >>> + spin_unlock_irqrestore(&common->irqlock, flags); >>> >>> return ret; >>> } >> -- >> 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
[GIT PULL FOR v3.16] Two fixes
Two bug fixes that should go to 3.16 (the dv-timings.c fix even for 3.12 and up). Regards, Hans The following changes since commit f7a27ff1fb77e114d1059a5eb2ed1cffdc508ce8: [media] xc5000: delay tuner sleep to 5 seconds (2014-05-25 17:50:16 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.16a for you to fetch changes up to b3d14fb591e647056f111e1dabf13f542fdcc211: saa7134: use unlocked_ioctl instead of ioctl. (2014-06-16 12:37:41 +0200) Hans Verkuil (1): saa7134: use unlocked_ioctl instead of ioctl. Rickard Strandqvist (1): media: v4l2-core: v4l2-dv-timings.c: Cleaning up code wrong value used in aspect ratio. drivers/media/pci/saa7134/saa7134-empress.c | 2 +- drivers/media/v4l2-core/v4l2-dv-timings.c | 4 ++-- 2 files changed, 3 insertions(+), 3 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 v14 03/10] imx-drm: Correct BGR666 and the board's dts that use them.
On Mon, Jun 16, 2014 at 12:11:17PM +0200, Denis Carikli wrote: > The current BGR666 is not consistent with the other color mapings like BGR24. > BGR666 should be in the same byte order than BGR24. > > Signed-off-by: Denis Carikli > Acked-by: Philipp Zabel As I said probably around v10 time, I already have this patch queued, and I was going to send it to Greg before the previous merge window, but due to the number of patches I was already carrying, it was lost amongst the trees. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 v14 02/10] imx-drm: Add RGB666 support for parallel display.
On Mon, Jun 16, 2014 at 12:11:16PM +0200, Denis Carikli wrote: > Signed-off-by: Denis Carikli > Acked-by: Philipp Zabel As I said probably around v10 time, I already have this patch queued, and I was going to send it to Greg before the previous merge window, but due to the number of patches I was already carrying, it was lost amongst the trees. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 v14 01/10] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
On Mon, Jun 16, 2014 at 12:11:15PM +0200, Denis Carikli wrote: > That new macro is needed by the imx_drm staging driver > for supporting the QVGA display of the eukrea-cpuimx51 board. As I said probably around v10 time, I already have this patch queued, and I was going to send it to Greg before the previous merge window, but due to the number of patches I was already carrying, it was lost amongst the trees. -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- 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 v14 08/10] drm/panel: Add Eukrea mbimxsd51 displays.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v12->v13:
- Added a note explaining why the size is zero in
the eukrea_mbimxsd51_dvi(s)vga structs.
ChangeLog v11->v12:
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- New patch.
---
.../bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt |7 ++
.../bindings/panel/eukrea,mbimxsd51-dvi-svga.txt |7 ++
.../bindings/panel/eukrea,mbimxsd51-dvi-vga.txt|7 ++
drivers/gpu/drm/panel/panel-simple.c | 83
4 files changed, 104 insertions(+)
create mode 100644
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
create mode 100644
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
create mode 100644
Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
diff --git
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
new file mode 100644
index 000..03679d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-cmo-qvga.txt
@@ -0,0 +1,7 @@
+Eukrea CMO-QVGA (320x240 pixels) TFT LCD panel
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-cmo-qvga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
new file mode 100644
index 000..f408c9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-svga.txt
@@ -0,0 +1,7 @@
+Eukrea DVI-SVGA (800x600 pixels) DVI output.
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-dvi-svga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git
a/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
new file mode 100644
index 000..8ea90da
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/eukrea,mbimxsd51-dvi-vga.txt
@@ -0,0 +1,7 @@
+Eukrea DVI-VGA (640x480 pixels) DVI output.
+
+Required properties:
+- compatible: should be "eukrea,mbimxsd51-dvi-vga"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index a251361..adc40a7 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -403,6 +403,80 @@ static const struct panel_desc edt_etm0700g0dh6 = {
},
};
+static const struct drm_display_mode eukrea_mbimxsd51_cmoqvga_mode = {
+ .clock = 6500,
+ .hdisplay = 320,
+ .hsync_start = 320 + 38,
+ .hsync_end = 320 + 38 + 20,
+ .htotal = 320 + 38 + 20 + 30,
+ .vdisplay = 240,
+ .vsync_start = 240 + 15,
+ .vsync_end = 240 + 15 + 4,
+ .vtotal = 240 + 15 + 4 + 3,
+ .vrefresh = 60,
+ .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE |
+DRM_MODE_FLAG_POL_DE_LOW,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_cmoqvga = {
+ .modes = &eukrea_mbimxsd51_cmoqvga_mode,
+ .num_modes = 1,
+ .size = {
+ .width = 73,
+ .height = 56,
+ },
+};
+
+static const struct drm_display_mode eukrea_mbimxsd51_dvisvga_mode = {
+ .clock = 44333,
+ .hdisplay = 800,
+ .hsync_start = 800 + 112,
+ .hsync_end = 800 + 112 + 32,
+ .htotal = 800 + 112 + 32 + 80,
+ .vdisplay = 600,
+ .vsync_start = 600 + 3,
+ .vsync_end = 600 + 3 + 17,
+ .vtotal = 600 + 3 + 17 + 4,
+ .vrefresh = 60,
+ .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
+DRM_MODE_FLAG_POL_DE_HIGH,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_dvisvga = {
+ .modes = &eukrea_mbimxsd51_dvisvga_mode,
+ .num_modes = 1,
+ /* This is a DVI adapter for external displays */
+ .size = {
+ .width = 0,
+ .height = 0,
+ },
+};
+
+static const struct drm_display_mode eukrea_mbimxsd51_dvivga_mode = {
+ .clock = 23750,
+ .hdisplay = 640,
+ .hsync_start = 640 + 80,
+ .hsync_end = 640 + 80 + 16,
+ .htotal = 640 + 80 + 16 + 64,
+ .vdisplay = 480,
+ .vsync_start = 480 + 3,
+ .vsync_end = 480 + 3 + 13,
+ .vtotal = 480 + 3 + 13 + 4,
+ .vrefresh = 60,
+ .pol_flags = DRM_MODE_FLAG_POL_PIXDATA_POSEDGE |
+DRM_MODE_FLAG_POL_DE_HIGH,
+};
+
+static const struct panel_desc eukrea_mbimxsd51_dvivga = {
+ .modes = &eukrea_mbimxsd51_dvivga_mode,
+ .num_modes = 1,
+ /* This is a DVI adapter for external displays */
[PATCH v14 09/10] ARM: dts: mbimx51sd: Add display support.
The CMO-QVGA, DVI-SVGA and DVI-VGA are added.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- Rebased
- Removed enable-active-high in reg_lcd_3v3: its GPIO
already has the GPIO_ACTIVE_HIGH flag.
Without this removal, the display was off at boot
and powering it off and on was necessary to get an
image on it after the boot.
ChangeLog v10->v11:
- Now uses the drm-panel instead of the display-timings.
This is to get regulator support, which is lacking in
the imx-drm driver when using the display-timings.
ChangeLog v9->v10:
- Rebased
- Now enables the cmo-qvga regulator at boot.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- updated pixelclk-active after the following patch:
"imx-drm: Match ipu_di_signal_cfg's clk_pol with its description."
ChangeLog v7->v8:
- Rebased the patch: added the now required imx-drm node.
- Adapted the svga clock-frequency value in order to still
be able to display an image after the following commit:
"imx-drm: ipu-v3: more inteligent DI clock selection"
ChangeLog v6->v7:
- Shrinked even more the Cc list.
- Since the pingrp headers were removed, the references
to it where replaced by the actual pins.
- Added the targets to arch/arm/boot/dts/Makefile
ChangeLog v5->v6:
- Reordered the Cc list.
ChangeLog v3->v5:
- Updated to new GPIO defines.
- Updated to new licenses checkpatch requirements.
- one whitespace cleanup.
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51
boards.
- This patch now only adds display support.
- Added some interested people in the Cc list, and removed some people that
might be annoyed by the receiving of that patch which is unrelated to their
subsystem.
- rebased and reworked the dts displays addition.
- Also rebased and reworked the fsl,pins usage.
---
arch/arm/boot/dts/Makefile |3 ++
.../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts | 40
.../imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts | 28 +++
.../imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts | 28 +++
.../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 49
5 files changed, 148 insertions(+)
create mode 100644
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
create mode 100644
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
create mode 100644
arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0f1e8be..f0ec7b7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,9 @@ dtb-$(CONFIG_ARCH_MXC) += \
imx51-babbage.dtb \
imx51-digi-connectcore-jsk.dtb \
imx51-eukrea-mbimxsd51-baseboard.dtb \
+ imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dtb \
+ imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dtb \
+ imx51-eukrea-mbimxsd51-baseboard-dvi-vga.dtb \
imx53-ard.dtb \
imx53-m53evk.dtb \
imx53-mba53.dtb \
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
new file mode 100644
index 000..d273d09
--- /dev/null
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -0,0 +1,40 @@
+/*
+ * Copyright 2013 Eukréa Electromatique
+ *
+ * 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 the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include "imx51-eukrea-mbimxsd51-baseboard.dts"
+
+/ {
+ model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
+ compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga",
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+
+ panel: panel {
+ compatible = "eukrea,mbimxsd51-cmo-qvga", "simple-panel";
+ power-supply = <®_lcd_3v3>;
+ };
+
+ reg_lcd_3v3: lcd-en {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_lcd_3v3>;
+ regulator-name = "lcd-3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&gpio3 13 GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ };
+};
+
+&display {
+ status = "okay";
+ fsl,panel = <&panel>;
+};
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-dvi-svga.dts
new f
[PATCH v14 05/10] ARM: dts: imx5*, imx6*: correct display-timings nodes.
The imx-drm driver can't use the de-active and pixelclk-active display-timings properties yet. Instead the data-enable and the pixel data clock polarity are hardcoded in the imx-drm driver. So theses properties are now set to keep the same behaviour when imx-drm will start using them. Signed-off-by: Denis Carikli --- ChangeLog v13->v14: - None ChangeLog v10->v11: - imx53-tx53-x03x.dts change was removed because it already had the correct setting. ChangeLog v9->v10: - New patch that was splitted out of: "staging imx-drm: Use de-active and pixelclk-active display-timings." --- arch/arm/boot/dts/imx51-babbage.dts |2 ++ arch/arm/boot/dts/imx53-m53evk.dts|2 ++ arch/arm/boot/dts/imx6qdl-gw53xx.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-gw54xx.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabreauto.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabrelite.dtsi |2 ++ arch/arm/boot/dts/imx6qdl-sabresd.dtsi|2 ++ 8 files changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts index ee51a10..b64a9e3 100644 --- a/arch/arm/boot/dts/imx51-babbage.dts +++ b/arch/arm/boot/dts/imx51-babbage.dts @@ -56,6 +56,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; diff --git a/arch/arm/boot/dts/imx53-m53evk.dts b/arch/arm/boot/dts/imx53-m53evk.dts index 4b036b4..d03ced7 100644 --- a/arch/arm/boot/dts/imx53-m53evk.dts +++ b/arch/arm/boot/dts/imx53-m53evk.dts @@ -41,6 +41,8 @@ vfront-porch = <9>; vsync-len = <3>; vsync-active = <1>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi index d3125f0..7f993d6 100644 --- a/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi +++ b/arch/arm/boot/dts/imx6qdl-gw53xx.dtsi @@ -512,6 +512,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi index 532347f..e06cf9e 100644 --- a/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi +++ b/arch/arm/boot/dts/imx6qdl-gw54xx.dtsi @@ -534,6 +534,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi index 4c4b175..bcf5178 100644 --- a/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi +++ b/arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi @@ -353,6 +353,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi index 009abd6..230bbc6 100644 --- a/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabreauto.dtsi @@ -405,6 +405,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi index 6df6127..9f6b406 100644 --- a/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi +++ b/arch/arm/boot/dts/imx6qdl-sabrelite.dtsi @@ -353,6 +353,8 @@ vfront-porch = <7>; hsync-len = <60>; vsync-len = <10>; + de-active = <1>; + pixelclk-active = <0>; }; }; }; diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/
[PATCH v14 10/10] ARM: dts: mbimx51sd: Add CMO-QVGA backlight support.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- None
ChangeLog v11->v13:
- No changes
ChangeLog v9->v11:
- Now uses the drm-panel instead of the display-timings.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- The backlight is now on at boot.
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
- Reordered the Cc list.
ChangeLog v3->v5:
- Updated to the new GPIO defines.
ChangeLog v2->v3:
- Splitted out from the patch that added support for the cpuimx51/mbimxsd51
boards.
- This patch now only adds backlight support.
- Added some interested people in the Cc list, and removed some people that
might be annoyed by the receiving of that patch which is unrelated to their
subsystem.
---
.../imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
index d273d09..6e36dae 100644
--- a/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
+++ b/arch/arm/boot/dts/imx51-eukrea-mbimxsd51-baseboard-cmo-qvga.dts
@@ -17,9 +17,19 @@
model = "Eukrea MBIMXSD51 with the CMO-QVGA Display";
compatible = "eukrea,mbimxsd51-baseboard-cmo-qvga",
"eukrea,mbimxsd51-baseboard", "eukrea,cpuimx51", "fsl,imx51";
+ backlight: backlight {
+ compatible = "gpio-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_backlight_1>;
+ gpios = <&gpio3 4 GPIO_ACTIVE_HIGH>;
+ default-brightness-level = <1>;
+ default-on;
+ };
+
panel: panel {
compatible = "eukrea,mbimxsd51-cmo-qvga", "simple-panel";
power-supply = <®_lcd_3v3>;
+ backlight = <&backlight>;
};
reg_lcd_3v3: lcd-en {
--
1.7.9.5
--
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 v14 07/10] imx-drm: Use drm_display_mode timings flags.
The previous hardware behaviour was kept if the
flags are not set.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog v12->v13:
- This patch doesn't need the DRM_MODE_FLAG_POL_*_PRESERVE flags anymore.
- code cleanup to improve readability:
- ENABLE_POL_PRESERVE is now gone
- Less modifications in ipu_di_init_sync_panel
- more readable modifications in int ipu_crtc_mode_set
ChangeLog v11->v12:
- Rebased: It now uses the following new flags defines names:
CLK_POL, ENABLE_POL
- The inversions in ipuv3-crtc.c are now fixed.
- ipuv3-crtc.c was still using mode->private_flags
from the previous versions of this patchset, that's now fixed.
ChangeLog v10->v11:
- This patch was splitted-out and adapted from:
"Prepare imx-drm for extra display-timings retrival."
- The display-timings dt specific part was removed.
- The flags names were changed to use the DRM ones from:
"drm: drm_display_mode: add signal polarity flags"
---
drivers/gpu/ipu-v3/ipu-di.c |2 ++
drivers/staging/imx-drm/ipuv3-crtc.c | 18 --
include/video/imx-ipu-v3.h |4 ++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index d00f357..1a1e116 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -597,6 +597,8 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
if (sig->clk_pol == CLK_POL_POSEDGE)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
+ else if (sig->clk_pol == CLK_POL_NEGEDGE)
+ di_gen &= ~DI_GEN_POLARITY_DISP_CLK;
ipu_di_write(di, di_gen, DI_GENERAL);
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 7fec438..7fdf575 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -165,8 +165,22 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = ENABLE_POL_HIGH;
- sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+ if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_POSEDGE)
+ sig_cfg.clk_pol = CLK_POL_POSEDGE;
+ else if (mode->pol_flags & DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE)
+ sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+ else
+ /* If no PIXDATA flags were set, keep the old behaviour */
+ sig_cfg.clk_pol = CLK_POL_NEGEDGE;
+
+ if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_HIGH)
+ sig_cfg.enable_pol = ENABLE_POL_HIGH;
+ else if (mode->pol_flags & DRM_MODE_FLAG_POL_DE_LOW)
+ sig_cfg.enable_pol = ENABLE_POL_LOW;
+ else
+ /* If no DE flags were set, keep the old behaviour */
+ sig_cfg.enable_pol = ENABLE_POL_HIGH;
+
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 305..e660522 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -43,10 +43,10 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
- unsigned clk_pol:1;
- unsigned enable_pol:1;
unsigned Hsync_pol:1; /* true = active high */
unsigned Vsync_pol:1;
+ u8 clk_pol;
+ u8 enable_pol;
u16 width;
u16 height;
--
1.7.9.5
--
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 v14 06/10] drm: drm_display_mode: add signal polarity flags
We need a way to pass signal polarity informations
between DRM panels, and the display drivers.
To do that, a pol_flags field was added to drm_display_mode.
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Fixed DRM_MODE_FLAG_POL_DE_HIGH's description.
ChangeLog v12->v13:
- Added Docbook documentation for pol_flags the struct field.
- Removed the _PRESERVE defines: it was used by patches
against the imx_drm driver. Now theses patches have been
adapted not to require that defines.
ChangeLog v11->v12:
- Rebased: This patch now applies against drm_modes.h
- Rebased: It now uses the new DRM_MODE_FLAG_POL_DE flags defines names
ChangeLog v10->v11:
- Since the imx-drm won't be able to retrive its regulators
from the device tree when using display-timings nodes,
and that I was told that the drm simple-panel driver
already supported that, I then, instead, added what was
lacking to make the eukrea displays work with the
drm-simple-panel driver.
That required a way to get back the display polarity
informations from the imx-drm driver without affecting
userspace.
---
Documentation/DocBook/drm.tmpl | 30 ++
include/drm/drm_modes.h|6 ++
2 files changed, 36 insertions(+)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 7df3134..22d435f 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -2292,6 +2292,36 @@ void intel_crt_init(struct drm_device *dev)
and height_mm fields are only used
internally
during EDID parsing and should not be set when creating modes
manually.
+
+The pol_flags value represents the
display
+signal polarity flags, it can be a combination of
+
+
+DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE
+
+ drive pixel data on falling edge, sample data on rising
edge.
+
+
+
+DRM_MODE_FLAG_POL_PIXDATA_POSEDGE
+
+ Drive pixel data on rising edge, sample data on falling edge.
+
+
+
+DRM_MODE_FLAG_POL_DE_LOW
+
+ data-enable pulse is active low
+
+
+
+DRM_MODE_FLAG_POL_DE_HIGH
+
+ data-enable pulse is active high
+
+
+
+
int (*mode_valid)(struct drm_connector *connector,
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index 91d0582..c5cbe31 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -93,6 +93,11 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+#define DRM_MODE_FLAG_POL_PIXDATA_NEGEDGE BIT(1)
+#define DRM_MODE_FLAG_POL_PIXDATA_POSEDGE BIT(2)
+#define DRM_MODE_FLAG_POL_DE_LOW BIT(3)
+#define DRM_MODE_FLAG_POL_DE_HIGH BIT(4)
+
struct drm_display_mode {
/* Header */
struct list_head head;
@@ -144,6 +149,7 @@ struct drm_display_mode {
int vrefresh; /* in Hz */
int hsync; /* in kHz */
enum hdmi_picture_aspect picture_aspect_ratio;
+ unsigned int pol_flags;
};
/* mode specified on the command line */
--
1.7.9.5
--
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 v14 04/10] imx-drm: use defines for clock polarity settings
Signed-off-by: Denis Carikli
---
ChangeLog v13->v14:
- Rebased
ChangeLog 12->v13:
- No changes
ChangeLog 11->v12:
- Improved the define names to match the hardware:
ENABLE_POL is not a clock signal but instead an enable signal.
ChangeLog v9->v10:
- New patch which was splitted out from:
"staging: imx-drm: Use de-active and pixelclk-active display-timings.".
- Fixes many issues in "staging: imx-drm: Use de-active and pixelclk-active
display-timings.":
- More clear meaning of the polarity settings.
- The SET_CLK_POL and SET_DE_POL masks are not
needed anymore.
---
drivers/gpu/ipu-v3/ipu-di.c |4 ++--
drivers/staging/imx-drm/ipuv3-crtc.c |4 ++--
include/video/imx-ipu-v3.h |8 +++-
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c
index c490ba4..d00f357 100644
--- a/drivers/gpu/ipu-v3/ipu-di.c
+++ b/drivers/gpu/ipu-v3/ipu-di.c
@@ -595,7 +595,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
}
}
- if (sig->clk_pol)
+ if (sig->clk_pol == CLK_POL_POSEDGE)
di_gen |= DI_GEN_POLARITY_DISP_CLK;
ipu_di_write(di, di_gen, DI_GENERAL);
@@ -606,7 +606,7 @@ int ipu_di_init_sync_panel(struct ipu_di *di, struct
ipu_di_signal_cfg *sig)
reg = ipu_di_read(di, DI_POL);
reg &= ~(DI_POL_DRDY_DATA_POLARITY | DI_POL_DRDY_POLARITY_15);
- if (sig->enable_pol)
+ if (sig->enable_pol == ENABLE_POL_HIGH)
reg |= DI_POL_DRDY_POLARITY_15;
if (sig->data_pol)
reg |= DI_POL_DRDY_DATA_POLARITY;
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 720868b..7fec438 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -165,8 +165,8 @@ static int ipu_crtc_mode_set(struct drm_crtc *crtc,
if (mode->flags & DRM_MODE_FLAG_PVSYNC)
sig_cfg.Vsync_pol = 1;
- sig_cfg.enable_pol = 1;
- sig_cfg.clk_pol = 0;
+ sig_cfg.enable_pol = ENABLE_POL_HIGH;
+ sig_cfg.clk_pol = CLK_POL_NEGEDGE;
sig_cfg.width = mode->hdisplay;
sig_cfg.height = mode->vdisplay;
sig_cfg.pixel_fmt = out_pixel_fmt;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index 3e43e22..305 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -27,6 +27,12 @@ enum ipuv3_type {
#define IPU_PIX_FMT_GBR24 v4l2_fourcc('G', 'B', 'R', '3')
+#define CLK_POL_NEGEDGE0
+#define CLK_POL_POSEDGE1
+
+#define ENABLE_POL_LOW 0
+#define ENABLE_POL_HIGH1
+
/*
* Bitfield of Display Interface signal polarities.
*/
@@ -37,7 +43,7 @@ struct ipu_di_signal_cfg {
unsigned clksel_en:1;
unsigned clkidle_en:1;
unsigned data_pol:1;/* true = inverted */
- unsigned clk_pol:1; /* true = rising edge */
+ unsigned clk_pol:1;
unsigned enable_pol:1;
unsigned Hsync_pol:1; /* true = active high */
unsigned Vsync_pol:1;
--
1.7.9.5
--
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 v14 03/10] imx-drm: Correct BGR666 and the board's dts that use them.
The current BGR666 is not consistent with the other color mapings like BGR24.
BGR666 should be in the same byte order than BGR24.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v10->v13:
- Rebased
ChangeLog v9->v10:
- Rebased.
- Added Philipp Zabel's Ack.
- Included Lothar Waßmann's suggestion about imx-ldb.c.
- Shortened the patch title
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
ChangeLog v7->v8:
- Shrinked even more the Cc list.
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
- Added a better explanation of the change.
ChangeLog v5:
- New patch.
---
arch/arm/boot/dts/imx51-apf51dev.dts |2 +-
arch/arm/boot/dts/imx53-m53evk.dts |2 +-
drivers/gpu/ipu-v3/ipu-dc.c |4 ++--
drivers/staging/imx-drm/imx-ldb.c|4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/imx51-apf51dev.dts
b/arch/arm/boot/dts/imx51-apf51dev.dts
index c5a9a24..7b3851d 100644
--- a/arch/arm/boot/dts/imx51-apf51dev.dts
+++ b/arch/arm/boot/dts/imx51-apf51dev.dts
@@ -18,7 +18,7 @@
display@di1 {
compatible = "fsl,imx-parallel-display";
- interface-pix-fmt = "bgr666";
+ interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu_disp1>;
diff --git a/arch/arm/boot/dts/imx53-m53evk.dts
b/arch/arm/boot/dts/imx53-m53evk.dts
index d5d146a..4b036b4 100644
--- a/arch/arm/boot/dts/imx53-m53evk.dts
+++ b/arch/arm/boot/dts/imx53-m53evk.dts
@@ -24,7 +24,7 @@
soc {
display1: display@di1 {
compatible = "fsl,imx-parallel-display";
- interface-pix-fmt = "bgr666";
+ interface-pix-fmt = "rgb666";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_ipu_disp1>;
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 100d410..9974d41 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -439,9 +439,9 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
/* bgr666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_BGR666);
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 5, 0xfc); /* blue */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 0, 17, 0xfc); /* blue */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 1, 11, 0xfc); /* green */
- ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_BGR666, 2, 5, 0xfc); /* red */
/* lvds666 */
ipu_dc_map_clear(priv, IPU_DC_MAP_LVDS666);
diff --git a/drivers/staging/imx-drm/imx-ldb.c
b/drivers/staging/imx-drm/imx-ldb.c
index 7e3f019..5d22e40 100644
--- a/drivers/staging/imx-drm/imx-ldb.c
+++ b/drivers/staging/imx-drm/imx-ldb.c
@@ -188,11 +188,11 @@ static void imx_ldb_encoder_prepare(struct drm_encoder
*encoder)
switch (imx_ldb_ch->chno) {
case 0:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH0_24) ?
- V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
case 1:
pixel_fmt = (ldb->ldb_ctrl & LDB_DATA_WIDTH_CH1_24) ?
- V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_BGR666;
+ V4L2_PIX_FMT_RGB24 : V4L2_PIX_FMT_RGB666;
break;
default:
dev_err(ldb->dev, "unable to config di%d panel format\n",
--
1.7.9.5
--
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 v14 01/10] [media] v4l2: add new V4L2_PIX_FMT_RGB666 pixel format.
That new macro is needed by the imx_drm staging driver
for supporting the QVGA display of the eukrea-cpuimx51 board.
Signed-off-by: Denis Carikli
Acked-by: Mauro Carvalho Chehab
Acked-by: Laurent Pinchart
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- None
ChangeLog v10->v13:
- No changes
ChangeLog v9->v10:
- Rebased on top of:
"211e7f2 [media] DocBook media: drop the old incorrect packed RGB table"
- Added Philipp Zabel's Ack.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
ChangeLog v7->v8:
- Added Mauro Carvalho Chehab back to the list of Cc
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
ChangeLog v3->v4:
- Added Laurent Pinchart's Ack.
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Added Mauro Carvalho Chehab's Ack.
- Added documentation.
---
.../DocBook/media/v4l/pixfmt-packed-rgb.xml| 39
include/uapi/linux/videodev2.h |1 +
2 files changed, 40 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index e1c4f8b..88a7fe1 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -279,6 +279,45 @@ colorspace
V4L2_COLORSPACE_SRGB.
+
+ V4L2_PIX_FMT_RGB666
+ 'RGBH'
+
+ r5
+ r4
+ r3
+ r2
+ r1
+ r0
+ g5
+ g4
+
+ g3
+ g2
+ g1
+ g0
+ b5
+ b4
+ b3
+ b2
+
+ b1
+ b0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
V4L2_PIX_FMT_BGR24
'BGR3'
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 168ff50..08cac01 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -299,6 +299,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_RGB555X v4l2_fourcc('R', 'G', 'B', 'Q') /* 16 RGB-5-5-5
BE */
#define V4L2_PIX_FMT_RGB565X v4l2_fourcc('R', 'G', 'B', 'R') /* 16 RGB-5-6-5
BE */
#define V4L2_PIX_FMT_BGR666 v4l2_fourcc('B', 'G', 'R', 'H') /* 18 BGR-6-6-6
*/
+#define V4L2_PIX_FMT_RGB666 v4l2_fourcc('R', 'G', 'B', 'H') /* 18 RGB-6-6-6
*/
#define V4L2_PIX_FMT_BGR24 v4l2_fourcc('B', 'G', 'R', '3') /* 24 BGR-8-8-8
*/
#define V4L2_PIX_FMT_RGB24 v4l2_fourcc('R', 'G', 'B', '3') /* 24 RGB-8-8-8
*/
#define V4L2_PIX_FMT_BGR32 v4l2_fourcc('B', 'G', 'R', '4') /* 32
BGR-8-8-8-8 */
--
1.7.9.5
--
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 v14 02/10] imx-drm: Add RGB666 support for parallel display.
Signed-off-by: Denis Carikli
Acked-by: Philipp Zabel
---
ChangeLog v13->v14:
- Rebased
ChangeLog v9->v13:
- Rebased
ChangeLog v8->v9:
- Rebased.
- Added Philipp Zabel's ack.
- Shortened the patch title.
ChangeLog v8->v9:
- Removed the Cc. They are now set in git-send-email directly.
- Rebased.
ChangeLog v7->v8:
- Shrinked even more the Cc list.
ChangeLog v6->v7:
- Shrinked even more the Cc list.
ChangeLog v5->v6:
- Remove people not concerned by this patch from the Cc list.
ChangeLog v3->v5:
- Use the correct RGB order.
ChangeLog v2->v3:
- Added some interested people in the Cc list.
- Removed the commit message long desciption that was just a copy of the short
description.
- Rebased the patch.
- Fixed a copy-paste error in the ipu_dc_map_clear parameter.
---
.../bindings/staging/imx-drm/fsl-imx-drm.txt |4 ++--
drivers/gpu/ipu-v3/ipu-dc.c|9 +
drivers/staging/imx-drm/parallel-display.c |2 ++
3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index e75f0e5..c0eb95a 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -60,8 +60,8 @@ Required properties:
- compatible: Should be "fsl,imx-parallel-display"
Optional properties:
- interface_pix_fmt: How this display is connected to the
- display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
- and "lvds666".
+ display interface. Currently supported types: "rgb24", "rgb565", "bgr666",
+ "rgb666" and "lvds666".
- edid: verbatim EDID data block describing attached display.
- ddc: phandle describing the i2c bus handling the display data
channel
diff --git a/drivers/gpu/ipu-v3/ipu-dc.c b/drivers/gpu/ipu-v3/ipu-dc.c
index 2326c75..100d410 100644
--- a/drivers/gpu/ipu-v3/ipu-dc.c
+++ b/drivers/gpu/ipu-v3/ipu-dc.c
@@ -93,6 +93,7 @@ enum ipu_dc_map {
IPU_DC_MAP_BGR666,
IPU_DC_MAP_LVDS666,
IPU_DC_MAP_BGR24,
+ IPU_DC_MAP_RGB666,
};
struct ipu_dc {
@@ -161,6 +162,8 @@ static int ipu_pixfmt_to_map(u32 fmt)
return IPU_DC_MAP_LVDS666;
case V4L2_PIX_FMT_BGR24:
return IPU_DC_MAP_BGR24;
+ case V4L2_PIX_FMT_RGB666:
+ return IPU_DC_MAP_RGB666;
default:
return -EINVAL;
}
@@ -452,6 +455,12 @@ int ipu_dc_init(struct ipu_soc *ipu, struct device *dev,
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 1, 15, 0xff); /* green */
ipu_dc_map_config(priv, IPU_DC_MAP_BGR24, 0, 23, 0xff); /* blue */
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 0, 5, 0xfc); /* blue */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+
return 0;
}
diff --git a/drivers/staging/imx-drm/parallel-display.c
b/drivers/staging/imx-drm/parallel-display.c
index b567832..64b34336 100644
--- a/drivers/staging/imx-drm/parallel-display.c
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -218,6 +218,8 @@ static int imx_pd_bind(struct device *dev, struct device
*master, void *data)
imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB565;
else if (!strcmp(fmt, "bgr666"))
imxpd->interface_pix_fmt = V4L2_PIX_FMT_BGR666;
+ else if (!strcmp(fmt, "rgb666"))
+ imxpd->interface_pix_fmt = V4L2_PIX_FMT_RGB666;
else if (!strcmp(fmt, "lvds666"))
imxpd->interface_pix_fmt = v4l2_fourcc('L', 'V', 'D',
'6');
}
--
1.7.9.5
--
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] Add patch to allow compilation on versions < 3.5 with CONFIG_OF
On 06/12/2014 05:45 PM, Devin Heitmueller wrote: > Support for Open Firmware was introduced in the V4L2 tree, but > it depends on features only found in 3.5+. Add a patch to disable > the support for earlier kernels. > > Tested on Ubuntu 10.04 with kernel 3.2.0-030200-generic (which has > CONFIG_OF enabled by default). Doesn't this produce compiler warnings since the static v4l2_of_parse_* functions are now never called? I would patch v4l2-core/Makefile instead to just never compile v4l2-of.o. Regards, Hans > > Signed-off-by: Devin Heitmueller > --- > backports/backports.txt | 1 + > backports/v3.4_openfirmware.patch | 13 + > 2 files changed, 14 insertions(+) > create mode 100644 backports/v3.4_openfirmware.patch > > diff --git a/backports/backports.txt b/backports/backports.txt > index 281c263..08908e6 100644 > --- a/backports/backports.txt > +++ b/backports/backports.txt > @@ -43,6 +43,7 @@ add v3.6_i2c_add_mux_adapter.patch > > [3.4.255] > add v3.4_i2c_add_mux_adapter.patch > +add v3.4_openfirmware.patch > > [3.2.255] > add v3.2_devnode_uses_mode_t.patch > diff --git a/backports/v3.4_openfirmware.patch > b/backports/v3.4_openfirmware.patch > new file mode 100644 > index 000..f0a8d36 > --- /dev/null > +++ b/backports/v3.4_openfirmware.patch > @@ -0,0 +1,13 @@ > +--- a/drivers/media/v4l2-core/v4l2-of.c 2014-06-11 17:05:02.0 > -0700 > b/drivers/media/v4l2-core/v4l2-of.c 2014-06-11 17:05:34.0 > -0700 > +@@ -1,3 +1,5 @@ > ++/* Depends on symbols not present until kernel 3.5 */ > ++#if 0 > + /* > + * V4L2 OF binding parsing library > + * > +@@ -142,3 +144,4 @@ > + return 0; > + } > + EXPORT_SYMBOL(v4l2_of_parse_endpoint); > ++#endif > -- 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] [media] davinci: vpif: missing unlocks on error
Prabhakar, Are you going to make a pull request for this, or shall I take it? Should it be applied to 3.16? Regards, Hans On 06/13/2014 08:13 PM, Prabhakar Lad wrote: > On Thu, Jun 12, 2014 at 8:01 AM, Dan Carpenter > wrote: >> We recently changed some locking around so we need some new unlocks on >> the error paths. >> >> Signed-off-by: Dan Carpenter > > Applied! > > Thanks, > --Prabhakar Lad > >> --- >> v2: move the unlock so the list_for_each_entry_safe() loop is protected >> >> diff --git a/drivers/media/platform/davinci/vpif_capture.c >> b/drivers/media/platform/davinci/vpif_capture.c >> index a7ed164..1e4ec69 100644 >> --- a/drivers/media/platform/davinci/vpif_capture.c >> +++ b/drivers/media/platform/davinci/vpif_capture.c >> @@ -269,6 +269,7 @@ err: >> list_del(&buf->list); >> vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED); >> } >> + spin_unlock_irqrestore(&common->irqlock, flags); >> >> return ret; >> } >> diff --git a/drivers/media/platform/davinci/vpif_display.c >> b/drivers/media/platform/davinci/vpif_display.c >> index 5bb085b..b431b58 100644 >> --- a/drivers/media/platform/davinci/vpif_display.c >> +++ b/drivers/media/platform/davinci/vpif_display.c >> @@ -233,6 +233,7 @@ err: >> list_del(&buf->list); >> vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED); >> } >> + spin_unlock_irqrestore(&common->irqlock, flags); >> >> return ret; >> } > -- > 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/RFC v2 1/2] v4l2grab: Add threaded producer/consumer option
On 06/09/2014 03:51 PM, Thiago Santos wrote:
> Adds options to allow the buffer dqbuf to happen on one thread while
> the qbuf happens on another. This is useful to test concurrency access to
> the v4l2 features. To enable this, 3 new options were added:
>
> t: enable threaded mode (off by default and will use the loop)
> b: enable blocking io mode (off by default
> s: how much the consumer thread will sleep after reading a buffer, this is to
>simulate the time that it takes to process a buffer in a real application
>(in ms)
>
> For example, you can simulate an application that takes 1s to process a buffer
> with:
>
> v4l2grab -t -b -s 1000
Is there a reason why you want to use v4l2grab instead of v4l2-ctl? My guess is
that is was just easier to add it there. I'm not so keen about this, I'd much
rather see this being added to v4l2-ctl, ideally for both capture, output and
m2m devices.
I'll commit the second patch since HdG Acked it.
Regards,
Hans
>
> Signed-off-by: Thiago Santos
> ---
> contrib/test/Makefile.am | 2 +-
> contrib/test/v4l2grab.c | 261
> +++
> 2 files changed, 219 insertions(+), 44 deletions(-)
>
> diff --git a/contrib/test/Makefile.am b/contrib/test/Makefile.am
> index 80c7665..c2e3860 100644
> --- a/contrib/test/Makefile.am
> +++ b/contrib/test/Makefile.am
> @@ -25,7 +25,7 @@ pixfmt_test_CFLAGS = $(X11_CFLAGS)
> pixfmt_test_LDFLAGS = $(X11_LIBS)
>
> v4l2grab_SOURCES = v4l2grab.c
> -v4l2grab_LDADD = ../../lib/libv4l2/libv4l2.la
> ../../lib/libv4lconvert/libv4lconvert.la
> +v4l2grab_LDADD = ../../lib/libv4l2/libv4l2.la
> ../../lib/libv4lconvert/libv4lconvert.la -lpthread
>
> v4l2gl_SOURCES = v4l2gl.c
> v4l2gl_LDFLAGS = $(X11_LIBS) $(GL_LIBS) $(GLU_LIBS)
> diff --git a/contrib/test/v4l2grab.c b/contrib/test/v4l2grab.c
> index 674cbe7..3e1be3d 100644
> --- a/contrib/test/v4l2grab.c
> +++ b/contrib/test/v4l2grab.c
> @@ -24,8 +24,10 @@
> #include
> #include "../../lib/include/libv4l2.h"
> #include
> +#include
>
> -#define CLEAR(x) memset(&(x), 0, sizeof(x))
> +#define CLEAR_P(x,s) memset((x), 0, s)
> +#define CLEAR(x) CLEAR_P(&(x), sizeof(x))
>
> struct buffer {
> void *start;
> @@ -46,22 +48,206 @@ static void xioctl(int fh, unsigned long int request,
> void *arg)
> }
> }
>
> +/* Used by the multi thread capture version */
> +struct buffer_queue {
> + struct v4l2_buffer *buffers;
> + int buffers_size;
> +
> + int read_pos;
> + int write_pos;
> + int n_frames;
> +
> + int fd;
> +
> + pthread_mutex_t mutex;
> + pthread_cond_t buffer_cond;
> +};
> +
> +/* Gets a buffer and puts it in the buffers list at write position, then
> + * notifies the consumer that a new buffer is ready to be used */
> +static void *produce_buffer (void * p)
> +{
> + struct buffer_queue *bq;
> + fd_set fds;
> + struct timeval tv;
> + int i;
> + struct v4l2_buffer *buf;
> + int r;
> +
> + bq = p;
> +
> + for (i = 0; i < bq->n_frames; i++) {
> + printf ("Prod: %d\n", i);
> + buf = &bq->buffers[bq->write_pos % bq->buffers_size];
> + do {
> + FD_ZERO(&fds);
> + FD_SET(bq->fd, &fds);
> +
> + /* Timeout. */
> + tv.tv_sec = 2;
> + tv.tv_usec = 0;
> +
> + r = select(bq->fd + 1, &fds, NULL, NULL, &tv);
> + } while ((r == -1 && (errno == EINTR)));
> + if (r == -1) {
> + perror("select");
> + pthread_exit (NULL);
> + return NULL;
> + }
> +
> + CLEAR_P(buf, sizeof(struct v4l2_buffer));
> + buf->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
> + buf->memory = V4L2_MEMORY_MMAP;
> + xioctl(bq->fd, VIDIOC_DQBUF, buf);
> +
> + pthread_mutex_lock (&bq->mutex);
> + bq->write_pos++;
> + printf ("Prod: %d (done)\n", i);
> + pthread_cond_signal (&bq->buffer_cond);
> + pthread_mutex_unlock (&bq->mutex);
> +
> + }
> +
> + pthread_exit (NULL);
> +}
> +
> +/* will create a separate thread that will produce the buffers and put
> + * into a circular array while this same thread will get the buffers from
> + * this array and 'render' them */
> +static int capture_threads (int fd, struct buffer *buffers, int bufpool_size,
> + struct v4l2_format fmt, int n_frames,
> + char *out_dir, int sleep_ms)
> +{
> + struct v4l2_buffer buf;
> + unsigned inti;
> + struct buffer_queue buf_queue;
> + pthread_t producer;
> + charout_name[25 + strlen(out_dir)];
> + F
[RFC ATTN] Remove vbi-test.c, v4lgrab.c and qv4l2-qt3 from v4l-utils
Is there any objection if the vbi-test.c and v4lgrab.c utilities are removed from the v4l-utils.git? The v4lgrab.c is a v4l1 capture utility that no longer works since CONFIG_VIDEO_V4L1_COMPAT no longer exists. vbi-test.c just prints the vbi parameters, which 'v4l2-ctl --get-fmt-vbi' also does. If we want to keep this, then I'll just remove the CONFIG_VIDEO_V4L1_COMPAT parts of the code, keeping just the v4l2 API code. I would also like to remove the Qt3 version of qv4l2 (contrib qv4l2-qt3). It doesn't build anyway, and nobody is using qt3 anymore. 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: "LED / flash API integration" related improvements
Hi Jacek and others, Comments from the LED API folks would be highly appreciated. (Cc linux-media as well.) My comments below. On Fri, May 09, 2014 at 04:28:44PM +0200, Jacek Anaszewski wrote: > During review of "LED / flash API integration" patch sets two issues > requiring modifications in the LED subsystem core emerged. > I would like to consult possible ways of solving them: > > 1. > == > > Some LED devices allow to control multiple LEDs independently. > Currently there is no direct support for this in the LED subsystem > and existing drivers register separate devices for each LED. > > LED / flash API integration effort is a good opportunity to provide > support for exposing multiple LEDs by a single LED class device. > > I would like to add following API: > > /** > * led_get_sub_leds_number - get the number of exposed LEDs > * @led_cdev: the LED to query > * @num_leds: number of exposed leds > * > * Get the number of leds exposed by the device. > * > * Returns: 0 on success or negative error value on failure > */ > int led_get_sub_leds_number(struct led_classdev *led_cdev, > int *num_leds); > > /** > * led_select_sub_led - select sub led to control > * @led_cdev: the LED to set > * @led_id: id of the sub led to control > * > * Set the sub led to be the target of the LED class API calls. > * Maximum led_id equals num_leds - 1. > * > * Returns: 0 on success or negative error value on failure > */ > int led_select_sub_led(struct led_classdev *led_cdev, > int led_id); Instead of this, how about using an array indexed by LED for the other functions? The problem with this is that often the registers to control LED specific properties contain the same configuration for another LED. The driver should thus cache the information until it needs to be applied, and I don't think configuring everything for every LED separately makes sense for either the user nor the driver. Caching the configuration before applying it should still be done since this way extra register accesses can be avoided: registers often share different kind of configurations such as timeout and current as well. The configuration should be applied once an apply fonction is called. > /** > * led_get_sub_led - get currently selected sub led > * @led_cdev: the LED to set > * @led_id: id of currently selected sub led > * > * Get id of the sub led chosen as the target of LED class > * API calls. Maximum led_id equals num_leds - 1. > * > * Returns: 0 on success or negative error value on failure > */ > int led_get_target_led(struct led_classdev *led_cdev, > int* led_id); > > The functions functions would be mapped on the sysfs attributes: > - available_leds - RO > - sub_led_id - RW This kind of interface isn't going to be compatible with existing applications. If you want to keep the compatibility, the LEDs would probably need to be exposed as separate devices. If that's not a requirement, I'd use an array here as well. The V4L2 driver would still expose the device as a single sub-device. Controls that apply to individual LEDs would be array controls. > The attributes would be created only if the related callbacks > are registered by the driver. > > 2. > == > > The second issue, refers to the work queues being used in the > brightness_set callbacks of the LED subsystem drivers. It interferes > with the way how V4L2 Flash controls work, which expect that setting > flash brightness has immediate effect. > > Proposed solutions: > - move work queues out from the drivers to the LED core. > - add brightness_set_now callback to be registered by > the LED drivers and intended for call by v4l2-flash driver; > it wouldn't schedule a work but do the job immediately I favour the former, but the latter could be used to leave the existing callback as a compatibility means until all drivers are converted. This would probably be more work in total though than doing everything in a single patchset. -- 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: [CODA] Info about internal buffers in CodaDX6
Hello, No one can give me more information about these registers ? Thank you. Bets regards, Gaëtan Carlier. On 06/03/2014 10:32 AM, Gaëtan Carlier wrote: Dear, I am back to add support of h.264 decoding using Coda DX6 on i.MX27 (after long months of inactivity). I base my work on driver from linux 2.6.22 (libvpu) and last coda.c from linux-next/master. When I send DEC_SEQ_INIT command, it fails but I don't know why. 1) Which internal buffers do Coda DX6 really have/used for decoding PARABUF, WORKBUF, PSBUF, ...) ? 2) What is their role ? 3) I see in some code that there is a command CODA_RET_DEC_SEQ_ERR_REASON (0x1E0), which has the same opcode has RET_DEC_SEQ_NEXT_FRAME_NUM, but when I run this command after DEC_SEQ_INIT, it returns 1 that does not seems to be correct error (regarding RetCode enum in vpu_lib.h in libvpu) Code is based on 3.6.0 kernel revision with some backport from more recent version of coda.c Thanks a lot for your help. Best regards, Gaëtan Carlier. -- 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 00/30] Initial CODA960 (i.MX6 VPU) support
Hi Philipp, I went through this patch series and replied with some comments. I have two more general questions: 1) can you post the output of 'v4l2-compliance'? 2) what would be needed for 'v4l2-compliance -s' to work? For the encoder 'v4l2-compliance -s' will probably work OK, but for the decoder you need to feed v4l2-compliance -s some compressed stream. I assume each buffer should contain a single P/B/I frame? The v4l2-ctl utility has already support for writing captured data to a file, but it has no support to store the image sizes as well. So if the captured buffers do not all have the same size you cannot 'index' the captured file. If I would add support for that, then I can add support for it to v4l2-compliance as well, allowing you to playback an earlier captured compressed video stream and use that as the compliance test input. Does this makes sense? Regards, Hans On 06/13/2014 06:08 PM, Philipp Zabel wrote: > Hi, > > the following series adds initial support for the CODA960 Video > Processing Unit on i.MX6Q/D/DL/S SoCs to the coda driver. > > This series contains a few fixes and preparations, the CODA960 > support patch, a rework of the hardware access serialization > into a single threaded workqueue, some cleanups to use more > infrastructure that is available in the meantime, runtime PM > support, a few h.264 related v4l2 controls and fixes, support > for hard resets via the i.MX system reset controller, and a > patch that exports internal buffers to debugfs. > > regards > Philipp > > Michael Olbrich (2): > [media] v4l2-mem2mem: export v4l2_m2m_try_schedule > [media] coda: try to schedule a decode run after a stop command > > Philipp Zabel (28): > [media] coda: fix decoder I/P/B frame detection > [media] coda: fix readback of CODA_RET_DEC_SEQ_FRAME_NEED > [media] coda: fix h.264 quantization parameter range > [media] coda: fix internal framebuffer allocation size > [media] coda: simplify IRAM setup > [media] coda: Add encoder/decoder support for CODA960 > [media] coda: add selection API support for h.264 decoder > [media] coda: add support for frame size enumeration > [media] coda: add workqueue to serialize hardware commands > [media] coda: Use mem-to-mem ioctl helpers > [media] coda: use ctx->fh.m2m_ctx instead of ctx->m2m_ctx > [media] coda: Add runtime pm support > [media] coda: split firmware version check out of coda_hw_init > [media] coda: select GENERIC_ALLOCATOR > [media] coda: add h.264 min/max qp controls > [media] coda: add h.264 deblocking filter controls > [media] coda: add cyclic intra refresh control > [media] coda: let userspace force IDR frames by enabling the keyframe > flag in the source buffer > [media] coda: add decoder timestamp queue > [media] coda: alert userspace about macroblock errors > [media] coda: add sequence counter offset > [media] coda: use prescan_failed variable to stop stream after a > timeout > [media] coda: add reset control support > [media] coda: add bytesperline to queue data > [media] coda: allow odd width, but still round up bytesperline > [media] coda: round up internal frames to multiples of macroblock size > for h.264 > [media] coda: increase frame stride to 16 for h.264 > [media] coda: export auxiliary buffers via debugfs > > drivers/media/platform/Kconfig |1 + > drivers/media/platform/coda.c | 1505 > +++- > drivers/media/platform/coda.h | 115 ++- > drivers/media/v4l2-core/v4l2-mem2mem.c |3 +- > include/media/v4l2-mem2mem.h |2 + > 5 files changed, 1197 insertions(+), 429 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 18/30] [media] coda: let userspace force IDR frames by enabling the keyframe flag in the source buffer
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> This disables forcing IDR frames at GOP size intervals on CODA7541 and
> CODA960,
> which is only needed to work around a firmware bug on CodaDx6.
> Instead, the V4L2_BUF_FLAG_KEYFRAME v4l2 buffer flag is cleared before marking
> the source buffer done for dequeueing. Userspace can set it before queueing a
> frame to force an IDR frame, to implement VFU (Video Fast Update).
I'd like to see an RFC for this feature. Rather than 'misuse' it, I think this
should be standardized. I have nothing against using KEYFRAME in order to
implement VFU (in fact, I like it!), but it should be documented and
well-defined.
Regards,
Hans
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda.c | 18 ++
> 1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index 11e059d..cf75112 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -1264,22 +1264,22 @@ static void coda_prepare_encode(struct coda_ctx *ctx)
>* frame as IDR. This is a problem for some decoders that can't
>* recover when a frame is lost.
>*/
> - if (src_buf->v4l2_buf.sequence % ctx->params.gop_size) {
> - src_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_PFRAME;
> - src_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_KEYFRAME;
> - } else {
> + if ((src_buf->v4l2_buf.sequence % ctx->params.gop_size) == 0)
> src_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_KEYFRAME;
> + if (src_buf->v4l2_buf.flags & V4L2_BUF_FLAG_KEYFRAME)
> src_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_PFRAME;
> - }
> + else
> + src_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_PFRAME;
>
> if (dev->devtype->product == CODA_960)
> coda_set_gdi_regs(ctx);
>
> /*
> - * Copy headers at the beginning of the first frame for H.264 only.
> - * In MPEG4 they are already copied by the coda.
> + * Copy headers in front of the first frame and forced I frames for
> + * H.264 only. In MPEG4 they are already copied by the CODA.
>*/
> - if (src_buf->v4l2_buf.sequence == 0) {
> + if (src_buf->v4l2_buf.sequence == 0 ||
> + src_buf->v4l2_buf.flags & V4L2_BUF_FLAG_KEYFRAME) {
> pic_stream_buffer_addr =
> vb2_dma_contig_plane_dma_addr(dst_buf, 0) +
> ctx->vpu_header_size[0] +
> @@ -3245,6 +3245,8 @@ static void coda_finish_encode(struct coda_ctx *ctx)
> src_buf->v4l2_buf.flags & V4L2_BUF_FLAG_TSTAMP_SRC_MASK;
> dst_buf->v4l2_buf.timecode = src_buf->v4l2_buf.timecode;
>
> + /* Clear keyframe flag so userspace can misuse it to force an IDR frame
> */
> + src_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_KEYFRAME;
> v4l2_m2m_buf_done(src_buf, VB2_BUF_STATE_DONE);
>
> dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
>
--
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] DocBook media: fix small typo
know -> known Signed-off-by: Hans Verkuil --- Documentation/DocBook/media/v4l/io.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml index a086a5d..8c4ee74 100644 --- a/Documentation/DocBook/media/v4l/io.xml +++ b/Documentation/DocBook/media/v4l/io.xml @@ -1066,7 +1066,7 @@ state, in the application domain so to say. Drivers set or clear this flag when calling the VIDIOC_DQBUF ioctl. It may be set by video capture devices when the buffer contains a compressed image which is a -key frame (or field), &ie; can be decompressed on its own. Also know as +key frame (or field), &ie; can be decompressed on its own. Also known as an I-frame. Applications can set this bit when type refers to an output stream. -- 2.0.0 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/30] [media] coda: add support for frame size enumeration
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> This patch adds support for the VIDIOC_ENUM_FRAMESIZES ioctl.
> When decoding H.264, the output frame size is rounded up to the
> next multiple of the macroblock size (16 pixels).
Why do you need this? Implementing VIDIOC_ENUM_FRAMESIZES for a m2m device
seems odd.
Regards,
Hans
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda.c | 59
> +++
> 1 file changed, 59 insertions(+)
>
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index 7e4df82..b5e5983 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -958,6 +958,63 @@ static int coda_decoder_cmd(struct file *file, void *fh,
> return 0;
> }
>
> +static int coda_enum_framesizes(struct file *file, void *fh,
> + struct v4l2_frmsizeenum *fs)
> +{
> + struct coda_ctx *ctx = fh_to_ctx(fh);
> + struct coda_q_data *q_data_src;
> + struct coda_codec *codec;
> + struct vb2_queue *src_vq;
> + int max_w;
> + int max_h;
> + int i;
> +
> + if (fs->index > 0)
> + return -EINVAL;
> +
> + /*
> + * If the source format is already fixed, try to find a codec that
> + * converts to the given destination format
> + */
> + src_vq = v4l2_m2m_get_vq(ctx->m2m_ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
> + if (vb2_is_streaming(src_vq)) {
> + q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
> +
> + codec = coda_find_codec(ctx->dev, q_data_src->fourcc,
> + fs->pixel_format);
> + if (!codec)
> + return -EINVAL;
> +
> + fs->type = V4L2_FRMSIZE_TYPE_DISCRETE;
> + if (codec->src_fourcc == V4L2_PIX_FMT_H264) {
> + fs->discrete.width = round_up(q_data_src->width, 16);
> + fs->discrete.height = round_up(q_data_src->height, 16);
> + } else {
> + fs->discrete.width = q_data_src->width;
> + fs->discrete.height = q_data_src->height;
> + }
> + } else {
> + /* We don't know if input or output frame sizes are requested */
> + coda_get_max_dimensions(ctx->dev, NULL, &max_w, &max_h);
> + fs->type = V4L2_FRMSIZE_TYPE_CONTINUOUS;
> + fs->stepwise.min_width = MIN_W;
> + fs->stepwise.max_width = max_w;
> + fs->stepwise.step_width = 1;
> + fs->stepwise.min_height = MIN_H;
> + fs->stepwise.max_height = max_h;
> + fs->stepwise.step_height = 1;
> +
> + for (i = 0; i < ARRAY_SIZE(coda_formats); i++) {
> + if (coda_formats[i].fourcc == fs->pixel_format)
> + break;
> + }
> + if (i == ARRAY_SIZE(coda_formats))
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> static int coda_subscribe_event(struct v4l2_fh *fh,
> const struct v4l2_event_subscription *sub)
> {
> @@ -998,6 +1055,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
> .vidioc_try_decoder_cmd = coda_try_decoder_cmd,
> .vidioc_decoder_cmd = coda_decoder_cmd,
>
> + .vidioc_enum_framesizes = coda_enum_framesizes,
> +
> .vidioc_subscribe_event = coda_subscribe_event,
> .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
> };
>
--
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 07/30] [media] coda: add selection API support for h.264 decoder
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> The h.264 decoder produces capture frames that are a multiple of the
> macroblock
> size (16 pixels). To inform userspace about invalid pixel data at the edges,
> use the active and padded composing rectangles on the capture queue.
> The cropping information is obtained from the h.264 sequence parameter set.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda.c | 87
> +++
> 1 file changed, 87 insertions(+)
>
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index 10cc031..7e4df82 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -119,6 +119,7 @@ struct coda_q_data {
> unsigned intheight;
> unsigned intsizeimage;
> unsigned intfourcc;
> + struct v4l2_rectrect;
> };
>
> struct coda_aux_buf {
> @@ -737,6 +738,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct
> v4l2_format *f)
> q_data->width = f->fmt.pix.width;
> q_data->height = f->fmt.pix.height;
> q_data->sizeimage = f->fmt.pix.sizeimage;
> + q_data->rect.left = 0;
> + q_data->rect.top = 0;
> + q_data->rect.width = f->fmt.pix.width;
> + q_data->rect.height = f->fmt.pix.height;
>
> v4l2_dbg(1, coda_debug, &ctx->dev->v4l2_dev,
> "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
> @@ -873,6 +878,43 @@ static int coda_streamoff(struct file *file, void *priv,
> return ret;
> }
>
> +static int coda_g_selection(struct file *file, void *fh,
> + struct v4l2_selection *s)
> +{
> + struct coda_ctx *ctx = fh_to_ctx(fh);
> + struct coda_q_data *q_data;
> +
> + switch (s->target) {
> + case V4L2_SEL_TGT_CROP:
> + q_data = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
There is no check against s->type: CROP is only supported for output
buffers and should return -EINVAL for capture buffers and the reverse
for COMPOSE.
> + s->r = q_data->rect;
> + break;
> + case V4L2_SEL_TGT_CROP_DEFAULT:
> + case V4L2_SEL_TGT_CROP_BOUNDS:
> + q_data = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
> + s->r.left = 0;
> + s->r.top = 0;
> + s->r.width = q_data->width;
> + s->r.height = q_data->height;
> + break;
> + case V4L2_SEL_TGT_COMPOSE:
> + case V4L2_SEL_TGT_COMPOSE_DEFAULT:
> + q_data = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + s->r = q_data->rect;
> + break;
> + case V4L2_SEL_TGT_COMPOSE_BOUNDS:
> + case V4L2_SEL_TGT_COMPOSE_PADDED:
> + q_data = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
> + s->r.left = 0;
> + s->r.top = 0;
> + s->r.width = q_data->width;
> + s->r.height = q_data->height;
> + break;
Add:
default:
return -EINVAL;
Regards,
Hans
> + }
> +
> + return 0;
> +}
> +
> static int coda_try_decoder_cmd(struct file *file, void *fh,
> struct v4l2_decoder_cmd *dc)
> {
> @@ -951,6 +993,8 @@ static const struct v4l2_ioctl_ops coda_ioctl_ops = {
> .vidioc_streamon= coda_streamon,
> .vidioc_streamoff = coda_streamoff,
>
> + .vidioc_g_selection = coda_g_selection,
> +
> .vidioc_try_decoder_cmd = coda_try_decoder_cmd,
> .vidioc_decoder_cmd = coda_decoder_cmd,
>
> @@ -1506,6 +1550,10 @@ static void set_default_params(struct coda_ctx *ctx)
> ctx->q_data[V4L2_M2M_DST].width = max_w;
> ctx->q_data[V4L2_M2M_DST].height = max_h;
> ctx->q_data[V4L2_M2M_DST].sizeimage = CODA_MAX_FRAME_SIZE;
> + ctx->q_data[V4L2_M2M_SRC].rect.width = max_w;
> + ctx->q_data[V4L2_M2M_SRC].rect.height = max_h;
> + ctx->q_data[V4L2_M2M_DST].rect.width = max_w;
> + ctx->q_data[V4L2_M2M_DST].rect.height = max_h;
>
> if (ctx->dev->devtype->product == CODA_960)
> coda_set_tiled_map_type(ctx, GDI_LINEAR_FRAME_MAP);
> @@ -2033,6 +2081,21 @@ static int coda_start_decoding(struct coda_ctx *ctx)
> return -EINVAL;
> }
>
> + if (src_fourcc == V4L2_PIX_FMT_H264) {
> + u32 left_right;
> + u32 top_bottom;
> +
> + left_right = coda_read(dev, CODA_RET_DEC_SEQ_CROP_LEFT_RIGHT);
> + top_bottom = coda_read(dev, CODA_RET_DEC_SEQ_CROP_TOP_BOTTOM);
> +
> + q_data_dst->rect.left = (left_right >> 10) & 0x3ff;
> + q_data_dst->rect.top = (top_bottom >> 10) & 0x3ff;
> + q_data_dst->rect.width = width - q_data_dst->rect.left -
> + (left_right & 0x3ff);
> + q_data_dst->rect.height = height - q_data_dst->rect.top -
> + (top_bottom & 0x3ff);
> + }
> +
> ret
Re: [PATCH 01/30] [media] coda: fix decoder I/P/B frame detection
On 06/13/2014 06:08 PM, Philipp Zabel wrote:
> Currently the rotator unit is used to copy decoded frames out into buffers
> provided by videobuf2. Since the CODA reports the I/P/B frame type of the
> last decoded frame, and this frame will be copied out in a later device_run,
> depending on display order, we have to store the frame type until such time.
> This patch also adds the B-frame type.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/media/platform/coda.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/platform/coda.c b/drivers/media/platform/coda.c
> index b178379..a69fa3b 100644
> --- a/drivers/media/platform/coda.c
> +++ b/drivers/media/platform/coda.c
> @@ -209,6 +209,7 @@ struct coda_ctx {
> struct coda_aux_buf psbuf;
> struct coda_aux_buf slicebuf;
> struct coda_aux_buf internal_frames[CODA_MAX_FRAMEBUFFERS];
> + u32 frame_types[CODA_MAX_FRAMEBUFFERS];
> struct coda_aux_buf workbuf;
> int num_internal_frames;
> int idx;
> @@ -2693,15 +2694,6 @@ static void coda_finish_decode(struct coda_ctx *ctx)
>
> q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
>
> - val = coda_read(dev, CODA_RET_DEC_PIC_TYPE);
> - if ((val & 0x7) == 0) {
> - dst_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_KEYFRAME;
> - dst_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_PFRAME;
> - } else {
> - dst_buf->v4l2_buf.flags |= V4L2_BUF_FLAG_PFRAME;
> - dst_buf->v4l2_buf.flags &= ~V4L2_BUF_FLAG_KEYFRAME;
> - }
> -
> val = coda_read(dev, CODA_RET_DEC_PIC_ERR_MB);
> if (val > 0)
> v4l2_err(&dev->v4l2_dev,
> @@ -2748,6 +2740,14 @@ static void coda_finish_decode(struct coda_ctx *ctx)
> } else if (decoded_idx < 0 || decoded_idx >= ctx->num_internal_frames) {
> v4l2_err(&dev->v4l2_dev,
>"decoded frame index out of range: %d\n", decoded_idx);
> + } else {
> + val = coda_read(dev, CODA_RET_DEC_PIC_TYPE) & 0x7;
> + if (val == 0)
> + ctx->frame_types[decoded_idx] = V4L2_BUF_FLAG_KEYFRAME;
> + else if (val == 1)
> + ctx->frame_types[decoded_idx] = V4L2_BUF_FLAG_PFRAME;
> + else
> + ctx->frame_types[decoded_idx] = V4L2_BUF_FLAG_BFRAME;
> }
>
> if (display_idx == -1) {
> @@ -2770,6 +2770,10 @@ static void coda_finish_decode(struct coda_ctx *ctx)
> dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
> dst_buf->v4l2_buf.sequence = ctx->osequence++;
>
> + dst_buf->v4l2_buf.flags &= ~(V4L2_BUF_FLAG_KEYFRAME |
> + V4L2_BUF_FLAG_PFRAME);
Shouldn't this include '| V4L2_BUF_FLAG_BFRAME' as well?
Hans
> + dst_buf->v4l2_buf.flags |= ctx->frame_types[ctx->display_idx];
> +
> vb2_set_plane_payload(dst_buf, 0, width * height * 3 / 2);
>
> v4l2_m2m_buf_done(dst_buf, success ? VB2_BUF_STATE_DONE :
>
--
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: [alsa-devel] [PATCH 1/3] sound: Add a quirk to enforce period_bytes
(CC stable dropped; this is not how to submit stable patches.) Mauro Carvalho Chehab wrote: > The Auvitek 0828 chip, used on HVR950Q actually need two > quirks and not just one. > > The first one, already implemented, enforces that it won't have > channel swaps at the transfers. > > However, for TV applications, like xawtv and tvtime, another quirk > is needed, in order to enforce that, at least 2 URB transfer > intervals will be needed to fill a buffer. > + period = 2 * MAX_URBS * fp->maxpacksize; > + min_period = period * 90 / 100; > + max_period = period * 110 / 100; I don't quite understand what you mean with "URB transfer interval". All USB audio devices transfer packets in intervals between 125 µs and 1000 µs. MAX_URBS is a somewhat random value that is not directly derived from either a hardware or software constraint. Are you trying to enforce two packets per URB? Why are you setting both a minimum and a maximum? Isn't this affected by the constraints of the playback device? > Without it, buffer underruns happen when trying to syncronize the > audio input from au0828 and the audio playback at the default audio > output device. This looks like a workaround for a userspace bug that would affect all USB audio devices. What period/buffer sizes are xawtv/tvtime trying to use? Regards, Clemens -- 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 for v3.16] saa7134: use unlocked_ioctl instead of ioctl.
The saa7134 driver uses core-locking, so there is no longer any need
to use the ioctl op instead of the unlocked_ioctl op. This change
was forgotten for the saa7134-empress.c, so fix this.
Signed-off-by: Hans Verkuil
---
drivers/media/pci/saa7134/saa7134-empress.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/pci/saa7134/saa7134-empress.c
b/drivers/media/pci/saa7134/saa7134-empress.c
index e65c760..0006d6b 100644
--- a/drivers/media/pci/saa7134/saa7134-empress.c
+++ b/drivers/media/pci/saa7134/saa7134-empress.c
@@ -179,7 +179,7 @@ static const struct v4l2_file_operations ts_fops =
.read = vb2_fop_read,
.poll = vb2_fop_poll,
.mmap = vb2_fop_mmap,
- .ioctl= video_ioctl2,
+ .unlocked_ioctl = video_ioctl2,
};
static const struct v4l2_ioctl_ops ts_ioctl_ops = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
