cron job: media_tree daily build: OK
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: Thu Mar 27 04:00:17 CET 2014 git branch: test git hash: 8432164ddf7bfe40748ac49995356ab4dfda43b7 gcc version:i686-linux-gcc (GCC) 4.8.2 sparse version: v0.5.0 host hardware: x86_64 host os:3.13-5.slh.4-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-rc1-i686: OK 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-rc1-x86_64: OK apps: OK spec-git: OK sparse version: v0.5.0 sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.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 3/5] s5p-fimc: Roundup imagesize to row size for tiled formats
For tiled format, we need to allocated a multiple of the row size. A
good example is for 1280x720, wich get adjusted to 1280x736. In tiles,
this mean Y plane is 20x23 and UV plane 20x12. Because of the rounding,
the previous code would only have enough space to fit half of the last
row.
Signed-off-by: Nicolas Dufresne
---
drivers/media/platform/exynos4-is/fimc-core.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
b/drivers/media/platform/exynos4-is/fimc-core.c
index 2e70fab..7ea15ef 100644
--- a/drivers/media/platform/exynos4-is/fimc-core.c
+++ b/drivers/media/platform/exynos4-is/fimc-core.c
@@ -736,6 +736,7 @@ void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32
width, u32 height,
for (i = 0; i < pix->num_planes; ++i) {
struct v4l2_plane_pix_format *plane_fmt = &pix->plane_fmt[i];
u32 bpl = plane_fmt->bytesperline;
+ u32 sizeimage;
if (fmt->colplanes > 1 && (bpl == 0 || bpl < pix->width))
bpl = pix->width; /* Planar */
@@ -755,8 +756,16 @@ void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32
width, u32 height,
bytesperline /= 2;
plane_fmt->bytesperline = bytesperline;
- plane_fmt->sizeimage = max((pix->width * pix->height *
- fmt->depth[i]) / 8, plane_fmt->sizeimage);
+ sizeimage = pix->width * pix->height * fmt->depth[i] / 8;
+
+ /* Ensure full last row for tiled formats */
+ if (tiled_fmt(fmt)) {
+ /* 64 * 32 * plane_fmt->bytesperline / 64 */
+ u32 row_size = plane_fmt->bytesperline * 32;
+ sizeimage = roundup(sizeimage, row_size);
+ }
+
+ plane_fmt->sizeimage = max(sizeimage, plane_fmt->sizeimage);
}
}
--
1.8.5.3
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/5] s5p-fimc: Align imagesize to row size for tiled formats
Le mardi 25 mars 2014 à 16:51 -0400, Nicolas Dufresne a écrit :
> For tiled format, we need to allocated a multiple of the row size. A
> good example is for 1280x720, wich get adjusted to 1280x736. In tiles,
> this mean Y plane is 20x23 and UV plane 20x12. Because of the rounding,
> the previous code would only have enough space to fit half of the last
> row.
>
> Signed-off-by: Nicolas Dufresne
> ---
> drivers/media/platform/exynos4-is/fimc-core.c | 13 +++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/exynos4-is/fimc-core.c
> b/drivers/media/platform/exynos4-is/fimc-core.c
> index 2e70fab..0e94412 100644
> --- a/drivers/media/platform/exynos4-is/fimc-core.c
> +++ b/drivers/media/platform/exynos4-is/fimc-core.c
> @@ -736,6 +736,7 @@ void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32
> width, u32 height,
> for (i = 0; i < pix->num_planes; ++i) {
> struct v4l2_plane_pix_format *plane_fmt = &pix->plane_fmt[i];
> u32 bpl = plane_fmt->bytesperline;
> + u32 sizeimage;
>
> if (fmt->colplanes > 1 && (bpl == 0 || bpl < pix->width))
> bpl = pix->width; /* Planar */
> @@ -755,8 +756,16 @@ void fimc_adjust_mplane_format(struct fimc_fmt *fmt, u32
> width, u32 height,
> bytesperline /= 2;
>
> plane_fmt->bytesperline = bytesperline;
> - plane_fmt->sizeimage = max((pix->width * pix->height *
> -fmt->depth[i]) / 8, plane_fmt->sizeimage);
> + sizeimage = pix->width * pix->height * fmt->depth[i] / 8;
> +
> + /* Ensure full last row for tiled formats */
> + if (tiled_fmt(fmt)) {
> + /* 64 * 32 * plane_fmt->bytesperline / 64 */
> + u32 row_size = plane_fmt->bytesperline * 32;
> + sizeimage = ALIGN(sizeimage, row_size);
I made a mistake here, and it seems I've badly tested it too (was
setting the size from the test application). ALIGN won't work as
row_size is not a power of two. Sorry for that, will send an update.
roundup(sizeimage, row_size) would be the way to go. Will resubmit.
> + }
> +
> + plane_fmt->sizeimage = max(sizeimage, plane_fmt->sizeimage);
> }
> }
>
signature.asc
Description: This is a digitally signed message part
[GIT PULL v3.15] rtl28xxu remove duplicate USB ID
The following changes since commit 8432164ddf7bfe40748ac49995356ab4dfda43b7: [media] Sensoray 2255 uses videobuf2 (2014-03-24 17:23:43 -0300) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git rtl28xxu_id for you to fetch changes up to d412fb2a4c2effe3b3426330dfd1ee099b6b596f: rtl28xxu: remove duplicate ID 0458:707f Genius TVGo DVB-T03 (2014-03-27 00:20:30 +0200) Antti Palosaari (1): rtl28xxu: remove duplicate ID 0458:707f Genius TVGo DVB-T03 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 -- 1 file changed, 2 deletions(-) -- http://palosaari.fi/ -- 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] rtl28xxu: remove duplicate ID 0458:707f Genius TVGo DVB-T03
That ID was added twice mistakenly.
1st commit ac298ccdde4fe9b0a966e548a232ff4e8a6b8a31
2nd commit 1c1b8734094551eb4075cf68cf76892498c0da61
Revert commit 1c1b8734094551eb4075cf68cf76892498c0da61
Reported-by: Jan Vcelak
Signed-off-by: Antti Palosaari
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index c83c16c..61d196e 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1503,8 +1503,6 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
/* RTL2832P devices: */
{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
&rtl2832u_props, "Astrometa DVB-T2", NULL) },
- { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
- &rtl2832u_props, "Genius TVGo DVB-T03", NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] rc: img-ir: Expand copyright headers with GPL notices
Add the basic GPLv2+ license notice to the copyright headers at the top of all the source files in the img-ir driver. Reported-by: David Härdeman Signed-off-by: James Hogan Cc: Mauro Carvalho Chehab Cc: David Härdeman --- drivers/media/rc/img-ir/img-ir-core.c | 5 + drivers/media/rc/img-ir/img-ir-hw.c| 5 + drivers/media/rc/img-ir/img-ir-hw.h| 5 + drivers/media/rc/img-ir/img-ir-jvc.c | 5 + drivers/media/rc/img-ir/img-ir-nec.c | 5 + drivers/media/rc/img-ir/img-ir-raw.c | 5 + drivers/media/rc/img-ir/img-ir-raw.h | 5 + drivers/media/rc/img-ir/img-ir-sanyo.c | 5 + drivers/media/rc/img-ir/img-ir-sharp.c | 5 + drivers/media/rc/img-ir/img-ir-sony.c | 5 + drivers/media/rc/img-ir/img-ir.h | 5 + 11 files changed, 55 insertions(+) diff --git a/drivers/media/rc/img-ir/img-ir-core.c b/drivers/media/rc/img-ir/img-ir-core.c index 6b78348..a0cac2f 100644 --- a/drivers/media/rc/img-ir/img-ir-core.c +++ b/drivers/media/rc/img-ir/img-ir-core.c @@ -3,6 +3,11 @@ * * Copyright 2010-2014 Imagination Technologies Ltd. * + * 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 contains core img-ir code for setting up the driver. The two interfaces * (raw and hardware decode) are handled separately. */ diff --git a/drivers/media/rc/img-ir/img-ir-hw.c b/drivers/media/rc/img-ir/img-ir-hw.c index 579a52b..23b47c7 100644 --- a/drivers/media/rc/img-ir/img-ir-hw.c +++ b/drivers/media/rc/img-ir/img-ir-hw.c @@ -3,6 +3,11 @@ * * Copyright 2010-2014 Imagination Technologies Ltd. * + * 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 ties into the input subsystem using the RC-core. Protocol support is * provided in separate modules which provide the parameters and scancode * translation functions to set up the hardware decoder and interpret the diff --git a/drivers/media/rc/img-ir/img-ir-hw.h b/drivers/media/rc/img-ir/img-ir-hw.h index 6c9a94a..450f17d 100644 --- a/drivers/media/rc/img-ir/img-ir-hw.h +++ b/drivers/media/rc/img-ir/img-ir-hw.h @@ -2,6 +2,11 @@ * ImgTec IR Hardware Decoder found in PowerDown Controller. * * Copyright 2010-2014 Imagination Technologies Ltd. + * + * 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. */ #ifndef _IMG_IR_HW_H_ diff --git a/drivers/media/rc/img-ir/img-ir-jvc.c b/drivers/media/rc/img-ir/img-ir-jvc.c index 10209d2..85ee90f 100644 --- a/drivers/media/rc/img-ir/img-ir-jvc.c +++ b/drivers/media/rc/img-ir/img-ir-jvc.c @@ -2,6 +2,11 @@ * ImgTec IR Decoder setup for JVC protocol. * * Copyright 2012-2014 Imagination Technologies Ltd. + * + * 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. */ #include "img-ir-hw.h" diff --git a/drivers/media/rc/img-ir/img-ir-nec.c b/drivers/media/rc/img-ir/img-ir-nec.c index e7a731b..cff3212 100644 --- a/drivers/media/rc/img-ir/img-ir-nec.c +++ b/drivers/media/rc/img-ir/img-ir-nec.c @@ -2,6 +2,11 @@ * ImgTec IR Decoder setup for NEC protocol. * * Copyright 2010-2014 Imagination Technologies Ltd. + * + * 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. */ #include "img-ir-hw.h" diff --git a/drivers/media/rc/img-ir/img-ir-raw.c b/drivers/media/rc/img-ir/img-ir-raw.c index cfb01d9..33f37ed 100644 --- a/drivers/media/rc/img-ir/img-ir-raw.c +++ b/drivers/media/rc/img-ir/img-ir-raw.c @@ -3,6 +3,11 @@ * * Copyright 2010-2014 Imagination Technologies Ltd. * + * 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 ties into the input subsystem using the RC-core in raw mode. Raw IR * signal edges are reported and decoded by generic software decoders. */ diff --git a/drivers/media/rc/img-ir/img-ir-raw.h b/drivers/media/rc/img-ir/img-ir-raw.h index 9802ffd..4c9b767 100644 --- a/drivers/media/rc/img-ir/img-ir-raw.h
[PATCH 2/3] rc-main: Limit to a single wakeup protocol group
Limit the enabled wakeup protocols to be within a protocol group, as
defined by the proto_names array. For example this prevents the
selection of both rc-5 and nec, while allowing rc-5 alone (which
encompasses both normal rc-5 and rc-5x).
It doesn't usually make sense to enable more than one wakeup protocol
since only a single protocol can usually be used for wakeup at a time,
and doing so with encode based wakeup will result in an arbitrary
protocol being used if multiple are possible.
Reported-by: Antti Seppälä
Signed-off-by: James Hogan
Cc: Mauro Carvalho Chehab
Cc: Antti Seppälä
---
Sorry it took a little while to get around to submitting this.
---
drivers/media/rc/rc-main.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index e067fee..79d1060 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -979,6 +979,19 @@ static ssize_t store_protocols(struct device *device,
goto out;
}
+ if (fattr->type == RC_FILTER_WAKEUP) {
+ /* A proto_names entry must cover enabled wakeup protocols */
+ for (i = 0; i < ARRAY_SIZE(proto_names); i++)
+ if (type & proto_names[i].type &&
+ !(type & ~proto_names[i].type))
+ break;
+ if (i == ARRAY_SIZE(proto_names)) {
+ IR_dprintk(1, "Multiple distinct wakeup protocols\n");
+ ret = -EINVAL;
+ goto out;
+ }
+ }
+
change_protocol = (fattr->type == RC_FILTER_NORMAL)
? dev->change_protocol : dev->change_wakeup_protocol;
if (change_protocol) {
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] rc-main: Revert generic scancode filtering support
This reverts commit b8c7d915087c ([media] rc-main: add generic scancode
filtering), and removes certain parts of commit 6bea25af147f ([media]
rc-main: automatically refresh filter on protocol change) where generic
filtering is taken into account when refreshing filters on a protocol
change, but that code cannot be reached any longer since the filter mask
will always be zero if the s_filter callback is NULL.
Generic scancode filtering had questionable value and as David said:
> given how difficult it is to remove functionality that is in a
> released kernel...I think that particular part (i.e. the software
> filtering) should be removed until it has had further discussion.
Reported-by: David Härdeman
Signed-off-by: James Hogan
Cc: Mauro Carvalho Chehab
Cc: David Härdeman
Cc: Antti Seppälä
---
drivers/media/rc/rc-main.c | 26 --
1 file changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
index 99697aa..e067fee 100644
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -633,7 +633,6 @@ EXPORT_SYMBOL_GPL(rc_repeat);
static void ir_do_keydown(struct rc_dev *dev, int scancode,
u32 keycode, u8 toggle)
{
- struct rc_scancode_filter *filter;
bool new_event = !dev->keypressed ||
dev->last_scancode != scancode ||
dev->last_toggle != toggle;
@@ -641,11 +640,6 @@ static void ir_do_keydown(struct rc_dev *dev, int scancode,
if (new_event && dev->keypressed)
ir_do_keyup(dev, false);
- /* Generic scancode filtering */
- filter = &dev->scancode_filters[RC_FILTER_NORMAL];
- if (filter->mask && ((scancode ^ filter->data) & filter->mask))
- return;
-
input_event(dev->input_dev, EV_MSC, MSC_SCAN, scancode);
if (new_event && keycode != KEY_RESERVED) {
@@ -1012,9 +1006,6 @@ static ssize_t store_protocols(struct device *device,
if (!type) {
/* no protocol => clear filter */
ret = -1;
- } else if (!dev->s_filter) {
- /* generic filtering => accept any filter */
- ret = 0;
} else {
/* hardware filtering => try setting, otherwise clear */
ret = dev->s_filter(dev, fattr->type, &local_filter);
@@ -1023,8 +1014,7 @@ static ssize_t store_protocols(struct device *device,
/* clear the filter */
local_filter.data = 0;
local_filter.mask = 0;
- if (dev->s_filter)
- dev->s_filter(dev, fattr->type, &local_filter);
+ dev->s_filter(dev, fattr->type, &local_filter);
}
/* commit the new filter */
@@ -1068,7 +1058,9 @@ static ssize_t show_filter(struct device *device,
return -EINVAL;
mutex_lock(&dev->lock);
- if (fattr->mask)
+ if (!dev->s_filter)
+ val = 0;
+ else if (fattr->mask)
val = dev->scancode_filters[fattr->type].mask;
else
val = dev->scancode_filters[fattr->type].data;
@@ -1116,7 +1108,7 @@ static ssize_t store_filter(struct device *device,
return ret;
/* Scancode filter not supported (but still accept 0) */
- if (!dev->s_filter && fattr->type != RC_FILTER_NORMAL)
+ if (!dev->s_filter)
return val ? -EINVAL : count;
mutex_lock(&dev->lock);
@@ -1133,11 +1125,9 @@ static ssize_t store_filter(struct device *device,
ret = -EINVAL;
goto unlock;
}
- if (dev->s_filter) {
- ret = dev->s_filter(dev, fattr->type, &local_filter);
- if (ret < 0)
- goto unlock;
- }
+ ret = dev->s_filter(dev, fattr->type, &local_filter);
+ if (ret < 0)
+ goto unlock;
/* Success, commit the new filter */
*filter = local_filter;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] rc: Misc fixes for v3.15
A few misc fixes for v3.15, all relating to my previous patches. James Hogan (3): rc-main: Revert generic scancode filtering support rc-main: Limit to a single wakeup protocol group rc: img-ir: Expand copyright headers with GPL notices drivers/media/rc/img-ir/img-ir-core.c | 5 + drivers/media/rc/img-ir/img-ir-hw.c| 5 + drivers/media/rc/img-ir/img-ir-hw.h| 5 + drivers/media/rc/img-ir/img-ir-jvc.c | 5 + drivers/media/rc/img-ir/img-ir-nec.c | 5 + drivers/media/rc/img-ir/img-ir-raw.c | 5 + drivers/media/rc/img-ir/img-ir-raw.h | 5 + drivers/media/rc/img-ir/img-ir-sanyo.c | 5 + drivers/media/rc/img-ir/img-ir-sharp.c | 5 + drivers/media/rc/img-ir/img-ir-sony.c | 5 + drivers/media/rc/img-ir/img-ir.h | 5 + drivers/media/rc/rc-main.c | 39 ++ 12 files changed, 76 insertions(+), 18 deletions(-) Cc: Mauro Carvalho Chehab Cc: David Härdeman Cc: Antti Seppälä -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] TBS USB drivers (DVB-S/S2) - enable driver lock led code
[Please CC me on replies, I'm not subscribed]
The lock led code being enabled is based on GPLv2 code taken from:
https://bitbucket.org/CrazyCat/linux-tbs-drivers/
Just having to look at a device to get a visual lock notification by a
led is a nice feature.
--
Andreas Steinmetz SPAMmers use robot...@domdv.de
Signed-off-by: Andreas Steinmetz
diff -rNup v4l-dvb.orig/drivers/media/usb/dvb-usb/tbs-usb.c v4l-dvb/drivers/media/usb/dvb-usb/tbs-usb.c
--- v4l-dvb.orig/drivers/media/usb/dvb-usb/tbs-usb.c 2014-03-26 19:29:25.981009433 +0100
+++ v4l-dvb/drivers/media/usb/dvb-usb/tbs-usb.c 2014-03-26 19:34:39.864065854 +0100
@@ -348,8 +348,6 @@ static int tbsusb_set_voltage(struct dvb
voltage == SEC_VOLTAGE_18 ? command_18v : command_13v);
}
-#ifdef TBS_LOCKLED
-
static void tbsusb_led_ctrl(struct dvb_frontend *fe, int onoff)
{
static u8 led_off[2] = {0x05, 0x00};
@@ -358,8 +356,6 @@ static void tbsusb_led_ctrl(struct dvb_f
tbsusb_set_pin(fe, onoff ? led_on : led_off);
}
-#endif
-
static int tbsusb_i2c_transfer(struct i2c_adapter *adap,
struct i2c_msg msg[], int num)
{
@@ -766,9 +762,7 @@ static const struct stv090x_config stv09
.tuner_set_bandwidth= stb6100_set_bandwidth,
.tuner_get_bandwidth= stb6100_get_bandwidth,
-#ifdef TBS_LOCKLED
.set_lock_led = tbsusb_led_ctrl,
-#endif
};
static const struct stv090x_config stv0900_config = {
@@ -790,9 +784,7 @@ static const struct stv090x_config stv09
.tuner_set_bandwidth= stb6100_set_bandwidth,
.tuner_get_bandwidth= stb6100_get_bandwidth,
-#ifdef TBS_LOCKLED
.set_lock_led = tbsusb_led_ctrl,
-#endif
};
static const struct tda10071_config tda10071_config = {
@@ -803,24 +795,18 @@ static const struct tda10071_config tda1
.spec_inv = 0,
.xtal = 40444000, /* 40.444 MHz */
.pll_multiplier = 20,
-#ifdef TBS_LOCKLED
.set_lock_led = tbsusb_led_ctrl,
-#endif
};
static const struct cx24116_config cx24116_config = {
.demod_address = 0x55,
.mpg_clk_pos_pol = 0x01,
-#ifdef TBS_LOCKLED
.set_lock_led= tbsusb_led_ctrl,
-#endif
};
static const struct stv0288_config stv0288_config = {
.demod_address = 0x68,
-#ifdef TBS_LOCKLED
.set_lock_led = tbsusb_led_ctrl,
-#endif
};
static int tbsusb_frontend_attach(struct dvb_usb_adapter *d)
[PATCH 1/3] TBS USB drivers (DVB-S/S2) - basic driver
[Please CC me on replies, I'm not subscribed] The patch adds a driver for TBS USB DVB-S/S2 devices for which complete GPLv2 code exists. Code was taken from: http://www.tbsdtv.com/download/ https://bitbucket.org/CrazyCat/linux-tbs-drivers/ https://bitbucket.org/updatelee/v4l-updatelee Supported devices: -- TBS5980 - complete open source by manufacturer, current device TBS5928 - complete open source by manufacturer, old device TBS5920 - complete open source by manufacturer, old device TBS5910 - complete open source by manufacturer, old device TBS5925 - open source by manufacturer except 13V/18V control, voltage switching of TBS5980 however works, current device TBS5921 - open source from CrazyCat's bitbucket repository, old device Unsupported devices: TBS5922 - mostly closed source, current device TBS5990 - mostly closed source, current device TBS with USB PID 0x2601 - very old device for which the actual hardware used couldn't be determined. General: I do not have any manufacturer relationship. I'm just a user of TBS5980 and TBS5925 which work quite well as far as the hardware is concerned. I'm sufficiently annoyed, however, by the manufacturer's driver build system which actually is an old v4l tree replacing the kernel's current v4l tree. Thus I have reworked all available open source code for the TBS USB DVB-S/S2 hardware into a combined driver that is working with the current kernel. Testing: TBS5925 gets used daily and is working fine. TBS5980 gets used daily minus an actual CAM and is working fine without a CAM. The old devices can't be tested by me, I don't own them and they are not sold anymore. Maintenance: As a TBS5925/TBS5980 user I'm willing to maintain the driver as far as this is possible (see below). Regarding the older devices I'm willing to fix bugs for owners of these devices as long as I did introduce them in my combined driver. What I cannot do for any device is to fix any problems that would require manufacturer support or manufacturer documentation. As the TBS5980 manufacturer sources on which this driver is based didn't change for more than one and a half years (since when I started to collect manufacturer source archives) I'm quite confident that not much maintenance will be necessary. Firmware: - All required firmware except for the TBS5921 is available at http://www.tbsdtv.com/download/ (manufacturer website). The tda10071 firmware required additionally for the TBS5921 is already supported by the get_dvb_firmware script of the kernel. Due to the way the manufacturer handles software distribution I can't include the TBS firmware in the get_dvb_firmware script (no archive url, archive files updated every few months under a different file name). Notes: -- The ifdefs in the driver will go away by a followup patch after a necessary patch to some frontends. Please go on easy with me. I'm usually not writing kernel drivers. And I'm neither young nor healthy enough for flame wars. -- Andreas Steinmetz SPAMmers use robot...@domdv.de Signed-off-by: Andreas Steinmetz diff -rNup v4l-dvb.orig/drivers/media/dvb-core/dvb-usb-ids.h v4l-dvb/drivers/media/dvb-core/dvb-usb-ids.h --- v4l-dvb.orig/drivers/media/dvb-core/dvb-usb-ids.h 2014-03-26 15:03:13.399501288 +0100 +++ v4l-dvb/drivers/media/dvb-core/dvb-usb-ids.h 2014-03-26 15:19:08.658682532 +0100 @@ -70,6 +70,7 @@ #define USB_VID_EVOLUTEPC 0x1e59 #define USB_VID_AZUREWAVE 0x13d3 #define USB_VID_TECHNISAT 0x14f7 +#define USB_VID_TENOW0x734c /* Product IDs */ #define USB_PID_ADSTECH_USB2_COLD 0xa333 @@ -375,4 +376,10 @@ #define USB_PID_CTVDIGDUAL_V20xe410 #define USB_PID_PCTV_2002E 0x025c #define USB_PID_PCTV_2002E_SE 0x025d +#define USB_PID_TENOW_TBS59100x5910 +#define USB_PID_TENOW_TBS59200x5920 +#define USB_PID_TENOW_TBS59210x5921 +#define USB_PID_TENOW_TBS59250x5925 +#define USB_PID_TENOW_TBS59280x5928 +#define USB_PID_TENOW_TBS59800x5980 #endif diff -rNup v4l-dvb.orig/drivers/media/usb/dvb-usb/Kconfig v4l-dvb/drivers/media/usb/dvb-usb/Kconfig --- v4l-dvb.orig/drivers/media/usb/dvb-usb/Kconfig 2014-03-26 14:00:26.134339135 +0100 +++ v4l-dvb/drivers/media/usb/dvb-usb/Kconfig 2014-03-26 15:23:38.585581745 +0100 @@ -317,3 +317,23 @@ config DVB_USB_TECHNISAT_USB2 select DVB_STV6110x if MEDIA_SUBDRV_AUTOSELECT help Say Y here to support the Technisat USB2 DVB-S/S2 device + +config DVB_USB_TBS + tristate "TurboSight DVB-S/S2 USB2.0 support" + depends on DVB_USB + select DVB_PLL if MEDIA_SUBDRV_AUTOSELECT + select DVB_STV090x if MEDIA_SUBDRV_AUTOSELECT + select DVB_STB6100 if MEDIA_SUBDRV_AUTOSELECT + select DVB_CX24116 if MEDIA_SUBDRV_AUTOSELECT + select DVB_TDA10071 if MEDIA_SUBDRV_AUTOSELECT + select DVB_STV0299 if MEDIA_SUBDRV_AUTOSELECT + select DVB_STV0288 if MEDIA_SUBDRV_AU
[PATCH 2/3] TBS USB drivers (DVB-S/S2) - add lock led hooks to frontends
[Please CC me on replies, I'm not subscribed]
Based on GPLv2 code taken from:
https://bitbucket.org/CrazyCat/linux-tbs-drivers/
The patch adds lock led hooks to the stv090x, stv0288, cx24116 and
tda10071 frontends. Similar code already exists in the stv0900 frontend.
--
Andreas Steinmetz SPAMmers use robot...@domdv.de
Signed-off-by: Andreas Steinmetz
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.c v4l-dvb/drivers/media/dvb-frontends/cx24116.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.c 2014-03-26 14:00:26.009338722 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/cx24116.c 2014-03-26 19:30:42.561267100 +0100
@@ -703,6 +703,9 @@ static int cx24116_read_status(struct dv
if (lock & CX24116_HAS_SYNCLOCK)
*status |= FE_HAS_SYNC | FE_HAS_LOCK;
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, *status & FE_HAS_LOCK);
+
return 0;
}
@@ -,6 +1114,8 @@ static void cx24116_release(struct dvb_f
{
struct cx24116_state *state = fe->demodulator_priv;
dprintk("%s\n", __func__);
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
kfree(state);
}
@@ -1196,6 +1201,9 @@ static int cx24116_sleep(struct dvb_fron
dprintk("%s()\n", __func__);
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
+
/* Firmware CMD 36: Power config */
cmd.args[0x00] = CMD_TUNERSLEEP;
cmd.args[0x01] = 1;
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.h v4l-dvb/drivers/media/dvb-frontends/cx24116.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/cx24116.h 2014-03-26 14:00:26.009338722 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/cx24116.h 2014-03-26 19:30:42.562267103 +0100
@@ -34,6 +34,9 @@ struct cx24116_config {
/* Need to reset device during firmware loading */
int (*reset_device)(struct dvb_frontend *fe);
+ /* Hook for Lock LED */
+ void (*set_lock_led)(struct dvb_frontend *fe, int offon);
+
/* Need to set MPEG parameters */
u8 mpg_clk_pos_pol:0x02;
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.c v4l-dvb/drivers/media/dvb-frontends/stv0288.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.c 2014-03-26 14:00:26.026338778 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv0288.c 2014-03-26 19:30:52.361300077 +0100
@@ -381,6 +381,9 @@ static int stv0288_read_status(struct dv
dprintk("stv0288 has locked\n");
}
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, *status & FE_HAS_LOCK);
+
return 0;
}
@@ -415,6 +418,9 @@ static int stv0288_sleep(struct dvb_fron
{
struct stv0288_state *state = fe->demodulator_priv;
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
+
stv0288_writeregI(state, 0x41, 0x84);
state->initialised = 0;
@@ -532,6 +538,8 @@ static int stv0288_i2c_gate_ctrl(struct
static void stv0288_release(struct dvb_frontend *fe)
{
struct stv0288_state *state = fe->demodulator_priv;
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
kfree(state);
}
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.h v4l-dvb/drivers/media/dvb-frontends/stv0288.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv0288.h 2014-03-26 14:00:26.026338778 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv0288.h 2014-03-26 19:30:52.361300077 +0100
@@ -41,6 +41,9 @@ struct stv0288_config {
int min_delay_ms;
int (*set_ts_params)(struct dvb_frontend *fe, int is_punctured);
+
+ /* Hook for Lock LED */
+ void (*set_lock_led)(struct dvb_frontend *fe, int offon);
};
#if IS_ENABLED(CONFIG_DVB_STV0288)
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.c v4l-dvb/drivers/media/dvb-frontends/stv090x.c
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.c 2014-03-26 14:00:26.029338788 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv090x.c 2014-03-26 19:31:00.210326489 +0100
@@ -3546,6 +3546,9 @@ static int stv090x_read_status(struct dv
break;
}
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, *status & FE_HAS_LOCK);
+
return 0;
}
@@ -3893,6 +3896,9 @@ static int stv090x_sleep(struct dvb_fron
u32 reg;
u8 full_standby = 0;
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
+
if (stv090x_i2c_gate_ctrl(state, 1) < 0)
goto err;
@@ -4124,6 +4130,9 @@ static void stv090x_release(struct dvb_f
{
struct stv090x_state *state = fe->demodulator_priv;
+ if (state->config->set_lock_led)
+ state->config->set_lock_led(fe, 0);
+
state->internal->num_used--;
if (state->internal->num_used <= 0) {
diff -rNup v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.h v4l-dvb/drivers/media/dvb-frontends/stv090x.h
--- v4l-dvb.orig/drivers/media/dvb-frontends/stv090x.h 2014-03-26 14:00:26.029338788 +0100
+++ v4l-dvb/drivers/media/dvb-frontends/stv090x.h 2014-03-26 19:31:00.212326496 +0100
@@ -101,6 +101,9 @@ struct stv090x_config {
int (*tuner_set_refclk) (struct dvb_frontend *fe, u32 refclk);
int (*tuner_get_status) (struc
Re: [PATCH] [media] uvcvideo: Fix marking buffer erroneous in case of FID toggling
Hi Anton,
Thank you for the patch.
On Tuesday 25 March 2014 08:40:57 Anton Leontiev wrote:
> Set error bit for incomplete buffers when end of buffer is detected by
> FID toggling (for example when last transaction with EOF is lost).
> This prevents passing incomplete buffers to the userspace.
But this would also breaks buggy webcams that toggle the FID bit but don't set
the EOF bit. Support for this was added before the driver got merged in the
mainline kernel, and the SVN log is a bit terse I'm afraid:
V 104
- Check both EOF and FID bits to detect end of frames.
- Updated disclaimer and general status comment.
I don't remember which webcam(s) exhibit this behaviour.
Your patch would also mark valid buffers as erroneous when the list EOF bit is
in a packet of its own with no data.
As the uvcvideo driver already marks buffers smaller than the expected image
size as erroneous, missing EOF packets that contain data should already result
in buffers with the error bit set. Are you concerned about compressed formats
only ? While this patch would correctly detect the missing EOF packet in that
case, any other missing packet would still result in a corrupt image, so I'm
not sure if this would be worth it.
> Signed-off-by: Anton Leontiev
> ---
> drivers/media/usb/uvc/uvc_video.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/usb/uvc/uvc_video.c
> b/drivers/media/usb/uvc/uvc_video.c index 8d52baf..57c9a4b 100644
> --- a/drivers/media/usb/uvc/uvc_video.c
> +++ b/drivers/media/usb/uvc/uvc_video.c
> @@ -1133,6 +1133,17 @@ static int uvc_video_encode_data(struct uvc_streaming
> *stream, */
>
> /*
> + * Set error flag for incomplete buffer.
> + */
> +static void uvc_buffer_check_bytesused(const struct uvc_streaming *const
> stream,
> + struct uvc_buffer *const buf)
> +{
> + if (buf->length != buf->bytesused &&
> + !(stream->cur_format->flags & UVC_FMT_FLAG_COMPRESSED))
> + buf->error = 1;
> +}
> +
> +/*
> * Completion handler for video URBs.
> */
> static void uvc_video_decode_isoc(struct urb *urb, struct uvc_streaming
> *stream, @@ -1156,9 +1167,11 @@ static void uvc_video_decode_isoc(struct
> urb *urb, struct uvc_streaming *stream, do {
> ret = uvc_video_decode_start(stream, buf, mem,
> urb->iso_frame_desc[i].actual_length);
> - if (ret == -EAGAIN)
> + if (ret == -EAGAIN) {
> + uvc_buffer_check_bytesused(stream, buf);
> buf = uvc_queue_next_buffer(&stream->queue,
> buf);
> + }
> } while (ret == -EAGAIN);
>
> if (ret < 0)
> @@ -1173,11 +1186,7 @@ static void uvc_video_decode_isoc(struct urb *urb,
> struct uvc_streaming *stream, urb->iso_frame_desc[i].actual_length);
>
> if (buf->state == UVC_BUF_STATE_READY) {
> - if (buf->length != buf->bytesused &&
> - !(stream->cur_format->flags &
> - UVC_FMT_FLAG_COMPRESSED))
> - buf->error = 1;
> -
> + uvc_buffer_check_bytesused(stream, buf);
> buf = uvc_queue_next_buffer(&stream->queue, buf);
> }
> }
--
Regards,
Laurent Pinchart
--
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 2/6] drm/i2c: tda998x: Move tda998x to a couple encoder/connector
Hi Jean-François,
On Tuesday 25 March 2014 16:55:48 Jean-Francois Moine wrote:
> On Mon, 24 Mar 2014 23:39:01 +0100 Laurent Pinchart wrote:
> > On Friday 21 March 2014 09:17:32 Jean-Francois Moine wrote:
> > > The 'slave encoder' structure of the tda998x driver asks for glue
> > > between the DRM driver and the encoder/connector structures.
> > >
> > > This patch changes the driver to a normal DRM encoder/connector
> > > thanks to the infrastructure for componentised subsystems.
> >
> > I like the idea, but I'm not really happy with the implementation. Let me
> > try to explain why below.
> >
> > > Signed-off-by: Jean-Francois Moine
> > > ---
> > >
> > > drivers/gpu/drm/i2c/tda998x_drv.c | 323 ---
> > > 1 file changed, 188 insertions(+), 135 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > b/drivers/gpu/drm/i2c/tda998x_drv.c index fd6751c..1c25e40 100644
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> >
> > [snip]
> >
> > > @@ -44,10 +45,14 @@ struct tda998x_priv {
> > > wait_queue_head_t wq_edid;
> > > volatile int wq_edid_wait;
> > >
> > > - struct drm_encoder *encoder;
> > > + struct drm_encoder encoder;
> > > + struct drm_connector connector;
> > >
> > > };
> >
> > [snip]
> >
> > > -static int
> > > -tda998x_probe(struct i2c_client *client, const struct i2c_device_id
> > > *id)
> > > +static int tda_bind(struct device *dev, struct device *master, void
> > > *data)
> > > {
> > > + struct drm_device *drm = data;
> >
> > This is the part that bothers me. You're making two assumptions here, that
> > the DRM driver will pass a struct drm_device pointer to the bind
> > operation, and that the I2C encoder driver can take control of DRM
> > encoder and connector creation. Although it could become problematic
> > later, the first assumption isn't too much of an issue for now. I'll thus
> > focus on the second one.
> >
> > The component framework isolate the encoder and DRM master drivers as far
> > as component creation and binding is concerned, but doesn't provide a way
> > for the two drivers to communicate together (nor should it). You're
> > solving this by passing a pointer to the DRM device to the encoder bind
> > operation, making the encoder driver create a DRM encoder and connector,
> > and relying on the DRM core to orchestrate CRTCs, encoders and
> > connectors. You thus assume that the encoder hardware should be
> > represented by a DRM encoder object, and that its output is connected to
> > a connector that should be represented by a DRM connector object. While
> > this can work in your use case, that won't always hold true. Hardware
> > encoders can be chained together, while DRM encoders can't. The DRM core
> > has recently received support for bridge objects to overcome that
> > limitation. Depending on the hardware topology, a given hardware encoder
> > should be modeled as a DRM encoder or as a DRM bridge. That decision
> > shouldn't be taken by the encoder driver but by the DRM master driver.
> > The I2C encoder driver thus shouldn't create the DRM encoder and DRM
> > connector itself.
> >
> > I believe the encoder/master communication problem should be solved
> > differently. Instead of passing a pointer to the DRM device to the encoder
> > driver and making the encoder driver control DRM encoder and connector
> > creation, the encoder driver should instead create an object not visible
> > to userspace that can be retrieved by the DRM master driver (possibly
> > through registration with the DRM core, or by going through drvdata in the
> > encoder's struct device). The DRM master could use that object to
> > communicate with the encoder, and would register the DRM encoder and DRM
> > connector itself based on hardware topology.
> >
> > > + struct i2c_client *i2c_client = to_i2c_client(dev);
> > > + struct tda998x_priv *priv = i2c_get_clientdata(i2c_client);
> > > + struct drm_connector *connector = &priv->connector;
> > > + struct drm_encoder *encoder = &priv->encoder;
> > > + int ret;
> > > +
> > > + if (!try_module_get(THIS_MODULE)) {
> > > + dev_err(dev, "cannot get module %s\n", THIS_MODULE->name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = drm_connector_init(drm, connector,
> > > + &connector_funcs,
> > > + DRM_MODE_CONNECTOR_HDMIA);
> >
> > This is one example of the shortcomings I've explained above. An encoder
> > driver can't always know what connector type it is connected to. If I'm
> > not mistaken possible options here are DVII, DVID, HDMIA and HDMIB. It
> > should be up to the master driver to select the connector type based on
> > its overall view of the hardware, or even to a connector driver that would
> > be bound to a connector DT node (as proposed in
> > https://www.mail-archive.com/devicetree@vger.kernel.org/msg16585.html).
> [snip]
>
> The tda998x, as a HDMI tra
Re: [PATCH v2 3/3] [media] atmel-isi: add primary DT support
Hi Josh,
Thank you for the patch.
On Tuesday 25 March 2014 18:45:20 Josh Wu wrote:
> This patch add the DT support for Atmel ISI driver.
> It use the same v4l2 DT interface that defined in video-interfaces.txt.
>
> Signed-off-by: Josh Wu
> Cc: devicet...@vger.kernel.org
Reviewed-by: Laurent Pinchart
> ---
> v1 --> v2:
> refine the binding document.
> add port node description.
> removed the optional property.
>
> .../devicetree/bindings/media/atmel-isi.txt| 50 +
> drivers/media/platform/soc_camera/atmel-isi.c | 31 +++-
> 2 files changed, 79 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/atmel-isi.txt
>
> diff --git a/Documentation/devicetree/bindings/media/atmel-isi.txt
> b/Documentation/devicetree/bindings/media/atmel-isi.txt new file mode
> 100644
> index 000..11c98ee
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/atmel-isi.txt
> @@ -0,0 +1,50 @@
> +Atmel Image Sensor Interface (ISI) SoC Camera Subsystem
> +--
> +
> +Required properties:
> +- compatible: must be "atmel,at91sam9g45-isi"
> +- reg: physical base address and length of the registers set for the
> device;
> +- interrupts: should contain IRQ line for the ISI;
> +- clocks: list of clock specifiers, corresponding to entries in
> + the clock-names property;
> +- clock-names: must contain "isi_clk", which is the isi peripherial clock.
> +
> +ISI supports a single port node with parallel bus. It should contain one
> +'port' child node with child 'endpoint' node. Please refer to the bindings
> +defined in Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> + isi: isi@f0034000 {
> + compatible = "atmel,at91sam9g45-isi";
> + reg = <0xf0034000 0x4000>;
> + interrupts = <37 IRQ_TYPE_LEVEL_HIGH 5>;
> +
> + clocks = <&isi_clk>;
> + clock-names = "isi_clk";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_isi>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + isi_0: endpoint {
> + remote-endpoint = <&ov2640_0>;
> + };
> + };
> + };
> +
> + i2c1: i2c@f0018000 {
> + ov2640: camera@0x30 {
> + compatible = "omnivision,ov2640";
> + reg = <0x30>;
> +
> + port {
> + ov2640_0: endpoint {
> + remote-endpoint = <&isi_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c
> b/drivers/media/platform/soc_camera/atmel-isi.c index f4add0a..d6a1f7b
> 100644
> --- a/drivers/media/platform/soc_camera/atmel-isi.c
> +++ b/drivers/media/platform/soc_camera/atmel-isi.c
> @@ -19,6 +19,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
>
> @@ -33,6 +34,7 @@
> #define VID_LIMIT_BYTES (16 * 1024 * 1024)
> #define MIN_FRAME_RATE 15
> #define FRAME_INTERVAL_MILLI_SEC (1000 / MIN_FRAME_RATE)
> +#define ISI_DEFAULT_MCLK_FREQ2500
>
> /* Frame buffer descriptor */
> struct fbd {
> @@ -885,6 +887,20 @@ static int atmel_isi_remove(struct platform_device
> *pdev) return 0;
> }
>
> +static int atmel_isi_probe_dt(struct atmel_isi *isi,
> + struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> +
> + /* Default settings for ISI */
> + isi->pdata.full_mode = 1;
> + isi->pdata.mck_hz = ISI_DEFAULT_MCLK_FREQ;
> + isi->pdata.frate = ISI_CFG1_FRATE_CAPTURE_ALL;
> + isi->pdata.data_width_flags = ISI_DATAWIDTH_8 | ISI_DATAWIDTH_10;
> +
> + return 0;
> +}
> +
> static int atmel_isi_probe(struct platform_device *pdev)
> {
> unsigned int irq;
> @@ -896,7 +912,7 @@ static int atmel_isi_probe(struct platform_device *pdev)
> struct isi_platform_data *pdata;
>
> pdata = dev->platform_data;
> - if (!pdata || !pdata->data_width_flags) {
> + if ((!pdata || !pdata->data_width_flags) && !pdev->dev.of_node) {
> dev_err(&pdev->dev,
> "No config available for Atmel ISI\n");
> return -EINVAL;
> @@ -912,7 +928,11 @@ static int atmel_isi_probe(struct platform_device
> *pdev) if (IS_ERR(isi->pclk))
> return PTR_ERR(isi->pclk);
>
> - memcpy(&isi->pdata, pdata, sizeof(struct isi_platform_data));
> + if (pdata)
> + memcpy(&isi->pdata, pdata, sizeof(struct isi_platform_data));
> + else/* dt probe */
> + atmel_isi_probe_dt(isi, pdev);
> +
> isi->active = NULL;
>
Re: [PATCH 1/5] rc-main: add generic scancode filtering
On 26/03/14 13:44, David Härdeman wrote: > On 2014-03-26 08:08, Antti Seppälä wrote: >> On 26 March 2014 01:21, David Härdeman wrote: >>> On Tue, Mar 25, 2014 at 09:12:11AM +, James Hogan wrote: On Tuesday 25 March 2014 00:51:46 David Härdeman wrote: > What's the purpose of providing the sw scancode filtering in the > case where > there's no hardware filtering support at all? Consistency is probably the main reason, but I'll admit it's not perfectly consistent between generic/hardware filtering (mostly thanks to NEC scancode complexities), and I have no particular objection to dropping it if that isn't considered a good enough reason. >>> >>> I'm kind of sceptical...and given how difficult it is to remove >>> functionality that is in a released kernel...I think that particular >>> part (i.e. the software filtering) should be removed until it has had >>> further discussion... > ... >>> I don't understand. What's the purpose of a "software fallback" for >>> scancode filtering? Antti? >>> >> >> Well since the ImgTec patches will create a new sysfs interface for >> the HW scancode filtering I figured that it would be nice for it to >> also function on devices which lack the hardware filtering >> capabilities. Especially since it's only three lines of code. :) >> >> Therefore I suggested the software fallback. At the time I had no clue >> that there might be added complexities with nec scancodes. > > It's not only NEC scancodes, the sw scancode filter is state that is > changeable from user-space and which will require reader/writer > synchronization during the RX path (which is the "hottest" path in > rc-core). I've posted patches before which make the RX path lockless, > this change makes complicates such changes. > > Additionally, the provision of the sw fallback means that userspace has > no idea if there is an actual hardware filter present or not, meaning > that a userspace program that is aware of the scancode filter will > always enable it. > > So, I still think the SW part should be reverted, at least for now (i.e. > the sysfs file should only be present if there is hardware support). I've prepared a revert patch (which also reverts a part of a later patch which takes SW filtering into account when updating the filter on a protocol change). I'll double check it works right later and submit. Note that this still leaves the sysfs nodes there though, but if !s_filter then they read as 0 and only accept the value 0 to be written (mask == 0 represents no filtering). Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH 1/5] rc-main: add generic scancode filtering
On 2014-03-26 08:08, Antti Seppälä wrote: On 26 March 2014 01:21, David Härdeman wrote: On Tue, Mar 25, 2014 at 09:12:11AM +, James Hogan wrote: On Tuesday 25 March 2014 00:51:46 David Härdeman wrote: What's the purpose of providing the sw scancode filtering in the case where there's no hardware filtering support at all? Consistency is probably the main reason, but I'll admit it's not perfectly consistent between generic/hardware filtering (mostly thanks to NEC scancode complexities), and I have no particular objection to dropping it if that isn't considered a good enough reason. I'm kind of sceptical...and given how difficult it is to remove functionality that is in a released kernel...I think that particular part (i.e. the software filtering) should be removed until it has had further discussion... ... I don't understand. What's the purpose of a "software fallback" for scancode filtering? Antti? Well since the ImgTec patches will create a new sysfs interface for the HW scancode filtering I figured that it would be nice for it to also function on devices which lack the hardware filtering capabilities. Especially since it's only three lines of code. :) Therefore I suggested the software fallback. At the time I had no clue that there might be added complexities with nec scancodes. It's not only NEC scancodes, the sw scancode filter is state that is changeable from user-space and which will require reader/writer synchronization during the RX path (which is the "hottest" path in rc-core). I've posted patches before which make the RX path lockless, this change makes complicates such changes. Additionally, the provision of the sw fallback means that userspace has no idea if there is an actual hardware filter present or not, meaning that a userspace program that is aware of the scancode filter will always enable it. So, I still think the SW part should be reverted, at least for now (i.e. the sysfs file should only be present if there is hardware support). Mauro? //David -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/10] media: rc: ImgTec IR decoder driver
On 2014-03-26 10:28, James Hogan wrote: On 25/03/14 23:53, David Härdeman wrote: One thing I just noticed...your copyright headers throughout the driver seems a bit...sparse? :) True, I can add the basic: ... to each of the files if you think it's necessary. I think doing so for each *.c file would be a very good idea (and the *.h files if they are complicated enough), but I'm not the maintainer, so I can't tell you what to do :) //David -- 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 11/11] libdvbv5: fix PMT parser
Em Wed, 26 Mar 2014 07:38:15 +0100 Bjørn Mork escreveu: > André Roth writes: > > > On Tue, 25 Mar 2014 21:51:49 +0100 > > Bjørn Mork wrote: > > > >> > - * Copyright (c) 2011-2012 - Mauro Carvalho Chehab > >> > - * Copyright (c) 2012 - Andre Roth > >> > + * Copyright (c) 2013 - Andre Roth > >> > * > >> > * This program is free software; you can redistribute it and/or > >> > * modify it under the terms of the GNU General Public License > >> > >> This copyright change looked strange to me. Accidental deletion? > > > > Hi Bjørn, > > > > thanks for pointing this out. > > originally I was adding mauro to my dvb files as the "owner" of dvb in > > v4l. mauro then stated on some files that this was not his code and as > > the PMT is originally my code, I corrected this here. > > > > @mauro: please correct me if I'm wrong... > > Correcting the copyright is of course fine, but I think it would be good > to document that in the patch description so people like me don't end up > asking unnecessary questions :-) Yeah, a proper documentation always help. Btw, what we generally do here is to extend the copyright timestamp, instead of just replacing, like: Copyright (c) 2012-2014 > > > I'm a bit confused about the copyright year and author. Is this still > > needed in the age of git ? What is the policy for them ? > > IANAL. But looking at this from a practical point of view, I believe > that this info is useful whether it is required or not. Reading the > copyright owner(s) out of a git log can be a lot of work, and it isn't > necessariliy correct either - your copyright can be assigned to > e.g. your employer or to the FSF. It's also difficult to judge who of > many contributors have made changes big enough to make them copyright > owners. Some changes can be small in code size but still major, while > other changes can touch almost every line but still only be a minor > editorial fixup. The copyright laws were written to cover all sorts of intelectual work, and were written originally to cover music, painting, literature work. There are actually two kinds of copyrights: moral rights and economic rights. The GPL license (and all other sorts of licensing) deals with the economic rights. A copyright line, however, can, IMO, serve for both purposes: to tell the authorship and to identify who owns the economic rights and who is licensing them under GPL. If you develop something under your work contract, your employer likely has property rights. Yet, you still owns the moral rights[1]. On most Countries, it is not even possible to transfer them to someone else. [1] http://en.wikipedia.org/wiki/Moral_rights That warrants that a book written by, let's say, Julio Verne, will always be copyrighted by him, no matter if he (or his family) sold the economic rights, or if his books are already in public domain or not. > And why is it useful who owns a copyright and when the copyrighted work > was produced? If relicensing your code ever becomes a question, then we > need to know who to contact. You might think that relicensing isn't > going to happen. But there are real world examples where code has ended > up beeing linked to libraries with a GPL conflicting license, and > therefore needed an exception. The classical example is linking with > openssl. > > And the year is useful because copyright expires some years (depending > on country of origin, but typical 50) after the authors death. You > write code that will live forever, right? :-) Yeah, the property rights expires. The moral rights, however, never expire: if someone uses part of the Illiad (written around the 8th Century BC by Homero) on his work, he can't claim any rights on it, because that part of the text will forever belong to Homero. > > > Bjørn > -- > 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 -- 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 v4 00/10] media: rc: ImgTec IR decoder driver
On 25/03/14 23:53, David Härdeman wrote: > On Fri, Feb 28, 2014 at 11:28:50PM +, James Hogan wrote: >> Add a driver for the ImgTec Infrared decoder block. Two separate rc >> input devices are exposed depending on kernel configuration. One uses >> the hardware decoder which is set up with timings for a specific >> protocol and supports mask/value filtering and wake events. The other >> uses raw edge interrupts and the generic software protocol decoders to >> allow multiple protocols to be supported, including those not supported >> by the hardware decoder. > > One thing I just noticed...your copyright headers throughout the driver > seems a bit...sparse? :) True, I can add the basic: * 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. to each of the files if you think it's necessary. Cheers James signature.asc Description: OpenPGP digital signature
Re: [PATCH] adv7611: Set HPD GPIO direction to output
In that case: Acked-by: Hans Verkuil Regards, Hans On 03/26/14 11:03, Laurent Pinchart wrote: > Hi Hans, > > On Wednesday 26 March 2014 10:52:30 Hans Verkuil wrote: >> Hi Laurent, >> >> Stupid question perhaps, but why is gpiod_set_value_cansleep() removed? >> Does setting the output direction force the value to 0 as well? > > The last argument to gpiod_direction_output() sets the initial output level, > yes. > >> On 03/26/14 03:28, Laurent Pinchart wrote: >>> The HPD GPIO is used as an output but its direction is never set. Fix >>> it. >>> >>> Signed-off-by: Laurent Pinchart >>> --- >>> >>> drivers/media/i2c/adv7604.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> This patch applies on top of the ADV7611 support series queued for v3.16. >>> >>> diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c >>> index 51f14ab..b38ebb9 100644 >>> --- a/drivers/media/i2c/adv7604.c >>> +++ b/drivers/media/i2c/adv7604.c >>> @@ -2845,7 +2845,7 @@ static int adv7604_probe(struct i2c_client *client, >>> if (IS_ERR(state->hpd_gpio[i])) >>> continue; >>> >>> - gpiod_set_value_cansleep(state->hpd_gpio[i], 0); >>> + gpiod_direction_output(state->hpd_gpio[i], 0); >>> >>> v4l_info(client, "Handling HPD %u GPIO\n", i); >>> } > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adv7611: Set HPD GPIO direction to output
Hi Hans, On Wednesday 26 March 2014 10:52:30 Hans Verkuil wrote: > Hi Laurent, > > Stupid question perhaps, but why is gpiod_set_value_cansleep() removed? > Does setting the output direction force the value to 0 as well? The last argument to gpiod_direction_output() sets the initial output level, yes. > On 03/26/14 03:28, Laurent Pinchart wrote: > > The HPD GPIO is used as an output but its direction is never set. Fix > > it. > > > > Signed-off-by: Laurent Pinchart > > --- > > > > drivers/media/i2c/adv7604.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > This patch applies on top of the ADV7611 support series queued for v3.16. > > > > diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c > > index 51f14ab..b38ebb9 100644 > > --- a/drivers/media/i2c/adv7604.c > > +++ b/drivers/media/i2c/adv7604.c > > @@ -2845,7 +2845,7 @@ static int adv7604_probe(struct i2c_client *client, > > if (IS_ERR(state->hpd_gpio[i])) > > continue; > > > > - gpiod_set_value_cansleep(state->hpd_gpio[i], 0); > > + gpiod_direction_output(state->hpd_gpio[i], 0); > > > > v4l_info(client, "Handling HPD %u GPIO\n", i); > > } -- Regards, Laurent Pinchart -- 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] adv7611: Set HPD GPIO direction to output
Hi Laurent, Stupid question perhaps, but why is gpiod_set_value_cansleep() removed? Does setting the output direction force the value to 0 as well? Regards, Hans On 03/26/14 03:28, Laurent Pinchart wrote: > The HPD GPIO is used as an output but its direction is never set. Fix > it. > > Signed-off-by: Laurent Pinchart > --- > drivers/media/i2c/adv7604.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > This patch applies on top of the ADV7611 support series queued for v3.16. > > diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c > index 51f14ab..b38ebb9 100644 > --- a/drivers/media/i2c/adv7604.c > +++ b/drivers/media/i2c/adv7604.c > @@ -2845,7 +2845,7 @@ static int adv7604_probe(struct i2c_client *client, > if (IS_ERR(state->hpd_gpio[i])) > continue; > > - gpiod_set_value_cansleep(state->hpd_gpio[i], 0); > + gpiod_direction_output(state->hpd_gpio[i], 0); > > v4l_info(client, "Handling HPD %u GPIO\n", i); > } > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: why frameformat instead pixelformat?
On 03/24/14 17:52, Tom wrote: > Hello, > > while reading into the media-api issue I found out that for configuring the > entity pads a frameformat is used. > > For that I found the negotiation rfc of that topic, but I don't really get > the relevance of a frameformat. > > http://www.spinics.net/lists/linux-media/msg10006.html > > Can anyone explain why the media-api uses the frameformat instead of the > pixelformat and what the main differences are? The pixelformat describes the image format in memory, the mbus_framefmt describes the image data as it is transferred over a hardware bus. It's as simple as that. While the two are related (i.e. to get a certain pixelformat you probably need to set up a specific mbus_framefmt), the details of this relationship are board or even use-case dependent. 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: why frameformat instead pixelformat?
Tom gmx.net> writes: > > Hello, > > ... > For that I found the negotiation rfc of that topic, but I don't really get > the relevance of a frameformat. > > http://www.spinics.net/lists/linux-media/msg10006.html > > Can anyone explain why the media-api uses the frameformat instead of the > pixelformat and what the main differences are? > ... Can really nobody explain me why the media-api uses the v4l2_mbus_framefmt instead of the v4l2_format?? -- 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/5] rc-main: add generic scancode filtering
On 26 March 2014 01:21, David Härdeman wrote: > On Tue, Mar 25, 2014 at 09:12:11AM +, James Hogan wrote: >>On Tuesday 25 March 2014 00:51:46 David Härdeman wrote: >>> On Fri, Feb 28, 2014 at 11:17:02PM +, James Hogan wrote: >>> >Add generic scancode filtering of RC input events, and fall back to >>> >permitting any RC_FILTER_NORMAL scancode filter to be set if no s_filter >>> >callback exists. This allows raw IR decoder events to be filtered, and >>> >potentially allows hardware decoders to set looser filters and rely on >>> >generic code to filter out the corner cases. >>> >>> Hi James, >>> >>> What's the purpose of providing the sw scancode filtering in the case where >>> there's no hardware filtering support at all? >> >>Consistency is probably the main reason, but I'll admit it's not perfectly >>consistent between generic/hardware filtering (mostly thanks to NEC scancode >>complexities), and I have no particular objection to dropping it if that isn't >>considered a good enough reason. > > I'm kind of sceptical...and given how difficult it is to remove > functionality that is in a released kernel...I think that particular > part (i.e. the software filtering) should be removed until it has had > further discussion... > >>Here's the original discussion: >>On Monday 10 February 2014 21:45:30 Antti Seppälä wrote: >>> On 10 February 2014 11:58, James Hogan wrote: >>> > On Saturday 08 February 2014 13:30:01 Antti Seppälä wrote: >>> > > Also adding the scancode filter to it would >>> > > demonstrate its usage. >>> > >>> > To actually add filtering support to loopback would require either: >>> > * raw-decoder/rc-core level scancode filtering for raw ir drivers >>> > * OR loopback driver to encode like nuvoton and fuzzy match the IR >>> > signals. >>> >>> Rc-core level scancode filtering shouldn't be too hard to do right? If >>> such would exist then it would provide a software fallback to other rc >>> devices where hardware filtering isn't available. I'd love to see the >>> sysfs filter and filter_mask files to have an effect on my nuvoton too > > I don't understand. What's the purpose of a "software fallback" for > scancode filtering? Antti? > Well since the ImgTec patches will create a new sysfs interface for the HW scancode filtering I figured that it would be nice for it to also function on devices which lack the hardware filtering capabilities. Especially since it's only three lines of code. :) Therefore I suggested the software fallback. At the time I had no clue that there might be added complexities with nec scancodes. So like James said it exists mainly for api consistency reasons. -Antti -- 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
