Re: [PATCH 3/3] [media] rc: Remove ir-common module
Am Samstag, den 13.11.2010, 17:33 -0200 schrieb Mauro Carvalho Chehab:
> Now, just one old bttv board uses the old RC5 raw decoding routines.
> Its conversion to rc-core requires the generation of IRQ data for both
> positive and negative transitions at the IRQ line. I'm not sure if
> bttv driver supports it or if the transitions will be reliable enough.
> So, due to the lack of hardware for testing, the better for now is to
> just move the legacy routines to bttv driver, and wait for someone with
> a Nebula Digi could help to port it to use also rc-core raw decoders.
>
> Signed-off-by: Mauro Carvalho Chehab
Without any testing feedback from the bttv Nebula Digi since we made it
available for the saa7134 for Asus IR IRQ sampling too
Acked-by: hermann pitton
Cheers,
Hermann
> delete mode 100644 drivers/media/rc/ir-functions.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 2d15468..ef19375 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -10,11 +10,6 @@ menuconfig IR_CORE
> if you don't need IR, as otherwise, you may not be able to
> compile the driver for your adapter.
>
> -config IR_LEGACY
> - tristate
> - depends on IR_CORE
> - default IR_CORE
> -
> if IR_CORE
>
> config LIRC
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 859c12c..8c0e4cb 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -1,10 +1,8 @@
> -ir-common-objs := ir-functions.o
> rc-core-objs := rc-main.o rc-raw.o
>
> obj-y += keymaps/
>
> obj-$(CONFIG_IR_CORE) += rc-core.o
> -obj-$(CONFIG_IR_LEGACY) += ir-common.o
> obj-$(CONFIG_LIRC) += lirc_dev.o
> obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
> obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
> diff --git a/drivers/media/rc/ir-functions.c b/drivers/media/rc/ir-functions.c
> deleted file mode 100644
> index 14397d0..000
> --- a/drivers/media/rc/ir-functions.c
> +++ /dev/null
> @@ -1,120 +0,0 @@
> -/*
> - * some common functions to handle infrared remote protocol decoding for
> - * drivers which have not yet been (or can't be) converted to use the
> - * regular protocol decoders...
> - *
> - * (c) 2003 Gerd Knorr [SuSE Labs]
> - *
> - * 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.
> - *
> - * You should have received a copy of the GNU General Public License
> - * along with this program; if not, write to the Free Software
> - * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include "rc-core-priv.h"
> -
> -/*
> -- */
> -
> -MODULE_AUTHOR("Gerd Knorr [SuSE Labs]");
> -MODULE_LICENSE("GPL");
> -
> -/* RC5 decoding stuff, moved from bttv-input.c to share it with
> - * saa7134 */
> -
> -/* decode raw bit pattern to RC5 code */
> -static u32 ir_rc5_decode(unsigned int code)
> -{
> - unsigned int org_code = code;
> - unsigned int pair;
> - unsigned int rc5 = 0;
> - int i;
> -
> - for (i = 0; i < 14; ++i) {
> - pair = code & 0x3;
> - code >>= 2;
> -
> - rc5 <<= 1;
> - switch (pair) {
> - case 0:
> - case 2:
> - break;
> - case 1:
> - rc5 |= 1;
> - break;
> - case 3:
> - IR_dprintk(1, "ir-common: ir_rc5_decode(%x) bad
> code\n", org_code);
> - return 0;
> - }
> - }
> - IR_dprintk(1, "ir-common: code=%x, rc5=%x, start=%x, toggle=%x,
> address=%x, "
> - "instr=%x\n", rc5, org_code, RC5_START(rc5),
> - RC5_TOGGLE(rc5), RC5_ADDR(rc5), RC5_INSTR(rc5));
> - return rc5;
> -}
> -
> -void ir_rc5_timer_end(unsigned long data)
> -{
> - struct card_ir *ir = (struct card_ir *)data;
> - struct timeval tv;
> - unsigned long current_jiffies;
> - u32 gap;
> - u32 rc5 = 0;
> -
> - /* get time */
> - current_jiffies = jiffies;
> - do_gettimeofday(&tv);
> -
> - /* avoid overflow with gap >1s */
> - if (tv.tv_sec - ir->base_time.tv_sec > 1) {
> - gap = 20;
> - } else {
> - gap = 100 * (tv.tv_sec - ir->base_time.tv_sec) +
> - tv.tv_usec - ir->base_time.tv_usec;
> - }
> -
> - /* signal we're ready to start a new code */
> - ir->active = 0;
Re: new_build on ubuntu (dvbdev.c)
On Sun, 2010-11-14 at 09:08 +1100, Vincent McIntyre wrote: > Hi, > I'm trying to build on 2.6.32 (ubuntu lucid i386). > > I followed the instructions for building from git[1] Shouldn't you be building from: http://git.linuxtv.org/mchehab/new_build.git for backward compat builds? (I'm not sure myself.) > but I get an error I don't understand. > > make -C /lib/modules/2.6.32-25-3dbc39-generic/build > SUBDIRS=/home/me/git/clones/linuxtv.org/new_build/v4l modules > make[3]: Entering directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic' > CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-xc2028.o > CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-simple.o > CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-types.o > CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/mt20xx.o > ...all ok so far... > CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/flexcop-dma.o > /home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.c:108: error: > 'noop_llseek' undeclared here (not in a function) noop_llseek() is a newer kernl function that provided a trivial llseek() implmenetation for drivers that don't support llseek() but still want to provide a successful return code: http://lkml.org/lkml/2010/4/9/193 http://lkml.org/lkml/2010/4/9/184 > Is it that an additional backport patch may be needed here? Yup. It looks like you need something. You'll need a patch to implement the trivial noop_llseek() function available in the links above. > The kernel I am running here is Ubuntu 2.6.32-25.43-generic > (2.6.32.21+drm33.7) > with one tiny patch, reverting a bad change to drivers/usb/serial/ftdi_sio.c. > > Any advice appreciated. Regards, Andy > [1] http://git.linuxtv.org/media_tree.git > -- -- 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: Oops w/ 'Terratec Cinergy T USB XXS (HD)/ T3'
Toralf Förster wrote at 13:14:41 > I get with the current -git tree the attached OOps at an almost stable > Gentoo Linux running at a ThinkPad T400. FWIW solved by something between 9457b24..0143832 probably commit 2c2742d ? -- MfG/Kind regards Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3 -- 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
new_build on ubuntu (dvbdev.c)
Hi, I'm trying to build on 2.6.32 (ubuntu lucid i386). I followed the instructions for building from git[1] but I get an error I don't understand. make -C /lib/modules/2.6.32-25-3dbc39-generic/build SUBDIRS=/home/me/git/clones/linuxtv.org/new_build/v4l modules make[3]: Entering directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic' CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-xc2028.o CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-simple.o CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/tuner-types.o CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/mt20xx.o ...all ok so far... CC [M] /home/me/git/clones/linuxtv.org/new_build/v4l/flexcop-dma.o /home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.c:108: error: 'noop_llseek' undeclared here (not in a function) make[4]: *** [/home/me/git/clones/linuxtv.org/new_build/v4l/dvbdev.o] Error 1 make[3]: *** [_module_/home/me/git/clones/linuxtv.org/new_build/v4l] Error 2 make[3]: Leaving directory `/usr/src/linux-headers-2.6.32-25-3dbc39-generic' make[2]: *** [default] Error 2 make[2]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build/v4l' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/me/git/clones/linuxtv.org/new_build' make: *** [default] Error 2 Is it that an additional backport patch may be needed here? The kernel I am running here is Ubuntu 2.6.32-25.43-generic (2.6.32.21+drm33.7) with one tiny patch, reverting a bad change to drivers/usb/serial/ftdi_sio.c. Any advice appreciated. [1] http://git.linuxtv.org/media_tree.git -- 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] SoC Camera: ov6650: minor cleanups
On Sat, 13 Nov 2010, Janusz Krzysztofik wrote: > Thursday 30 September 2010 13:35:49 Janusz Krzysztofik wrote: > > There are still two SG mode specific corner cases to be corrected, > > previously not detected because of poor sensor driver functionality: 1) > > frame size not exceeding one page, resulting in "unexpected end of frame" > > message and capture restart every frame, and 2) last sgbuf lenght less than > > bytes_per_line, resulting in unstable picture. I'm going to address those > > two with fixes. > > Since both issues don't affect typical usage (one of standard resolutions) > and > both are videobuf-sg related, I'm wondering if I should better wait for > videobuf2 and try to port my driver instead of making things still more > complicated than they already are. What do you think? Well, I _would_ say: restrict the driver to avoid those corner cases. I.e., add a test to omap1_cam_set_fmt() and / or omap1_cam_set_crop() in SG case to verify, that the frame is at least one page large and that the lasg sgbuf is large enough. If this is not the case adjust the frame to satisfy these restrictions. But the problem is - at S_FMT / S_CROP time you don't know yet, whether you're going to use SG. I haven't studied videobuf2 in enough detail to understand, why and how it would help you? Isn't this a principal problem with your SG implementation? Maybe we should take this as yet one more argument against your "emulated sg" mode and remove it completely from the driver, relying on contiguous video buffers, selecting and implementing some boot-time memory reservation, and, possibly, adding the omap1 camera driver to the list of other drivers, waiting to break down again with 2.6.37, unless the "conflicting mapping mode" problem on ARM gets resolved before then? Also, please, move use_sg inside struct omap1_cam_dev. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] Remove ir-common module
On Sat, Nov 13, 2010 at 05:33:19PM -0200, Mauro Carvalho Chehab wrote: >I did some tests using the Encore FM 5.3. This were the last device using >the legacy IR support on saa7134. After it, only one device >(Nebula Electronics DigiTV) still uses it. It is an old device, so, it will >probably not be easy to find someone with such hardware. Excellent, this was exactly what I was hoping for :) -- David Härdeman -- 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: Raw mode for SAA7134_BOARD_ENCORE_ENLTV_FM53?
Em 12-11-2010 19:06, David Härdeman escreveu: > On Fri, Nov 12, 2010 at 12:23:56PM -0200, Mauro Carvalho Chehab wrote: >> Em 12-11-2010 12:14, David Härdeman escreveu: >>> Mauro, >>> >>> as far as I could tell, you wrote the initial support for >>> SAA7134_BOARD_ENCORE_ENLTV_FM53 in >>> drivers/media/video/saa7134/saa7134-input.c, right? >>> >>> It appears to be the only user of ir-functions.c left in that driver and >>> I'm wondering if it could be converted to use raw_decode with a patch >>> similar to what you committed for SAA7134_BOARD_ASUSTeK_P7131_ANALOG? >>> >> I need to check if I still have this board, or if it were a board that >> someone borrowed me. >> >> I'll put it on my todo list. > > Since that list is probably quite long, anyone else who reads this and > who has an Encore ENLTV-FM v5.3, feel free to get in touch with me in > the meantime. Fortunately, the board is here. I received 4 boards almost the same time, and I had to return 2 of them. Thankfully, this were not one of them ;) OK, I did some tests, and it works properly with the raw decoders. So, I'm posting 3 patches converting it to use the raw decoders, and removing the legacy code. There's still one old board (6+ years) at bttv that uses the raw decoding via the old way. For now, I just moved the legacy code into bttv driver. I think it won't be easy to find someone with this legacy hardware that could help on some tests, so, it may take some time until we can get rid of those legacy code there. Cheers, 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 2/3] [media] saa7134: Remove legacy IR decoding logic inside the module
The only IR left still using the old raw decoders on saa7134 is ENCORE
FM 5.3. As it is now using the standard rc-core raw decoders, lots
of old code can be removed from saa7134.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index 4878f46..72562b8 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -54,11 +54,8 @@ MODULE_PARM_DESC(disable_other_ir, "disable full codes of "
#define i2cdprintk(fmt, arg...)if (ir_debug) \
printk(KERN_DEBUG "%s/ir: " fmt, ir->name , ## arg)
-/* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */
-static int saa7134_rc5_irq(struct saa7134_dev *dev);
-static int saa7134_nec_irq(struct saa7134_dev *dev);
+/* Helper function for raw decoding at GPIO16 or GPIO18 */
static int saa7134_raw_decode_irq(struct saa7134_dev *dev);
-static void nec_task(unsigned long data);
/* GPIO generic keycode builder */
@@ -397,12 +394,8 @@ void saa7134_input_irq(struct saa7134_dev *dev)
if (!ir->running)
return;
- if (ir->nec_gpio) {
- saa7134_nec_irq(dev);
- } else if (!ir->polling && !ir->rc5_gpio && !ir->raw_decode) {
+ if (!ir->polling && !ir->raw_decode) {
build_key(dev);
- } else if (ir->rc5_gpio) {
- saa7134_rc5_irq(dev);
} else if (ir->raw_decode) {
saa7134_raw_decode_irq(dev);
}
@@ -448,17 +441,6 @@ static int __saa7134_ir_start(void *priv)
(unsigned long)dev);
ir->timer.expires = jiffies + HZ;
add_timer(&ir->timer);
- } else if (ir->rc5_gpio) {
- /* set timer_end for code completion */
- init_timer(&ir->timer_end);
- ir->timer_end.function = ir_rc5_timer_end;
- ir->timer_end.data = (unsigned long)ir;
- ir->shift_by = 2;
- ir->start = 0x2;
- ir->addr = 0x17;
- ir->rc5_remote_gap = ir_rc5_remote_gap;
- } else if (ir->nec_gpio) {
- tasklet_init(&ir->tlet, nec_task, (unsigned long)dev);
} else if (ir->raw_decode) {
/* set timer_end for code completion */
init_timer(&ir->timer_end);
@@ -486,10 +468,6 @@ static void __saa7134_ir_stop(void *priv)
return;
if (dev->remote->polling)
del_timer_sync(&dev->remote->timer);
- else if (ir->rc5_gpio)
- del_timer_sync(&ir->timer_end);
- else if (ir->nec_gpio)
- tasklet_kill(&ir->tlet);
else if (ir->raw_decode) {
del_timer_sync(&ir->timer_end);
ir->active = 0;
@@ -531,40 +509,6 @@ static void saa7134_ir_close(struct rc_dev *rc)
__saa7134_ir_stop(dev);
}
-
-static int saa7134_ir_change_protocol(struct rc_dev *rc, u64 ir_type)
-{
- struct saa7134_dev *dev = rc->priv;
- struct card_ir *ir = dev->remote;
- u32 nec_gpio, rc5_gpio;
-
- if (ir_type == IR_TYPE_RC5) {
- dprintk("Changing protocol to RC5\n");
- nec_gpio = 0;
- rc5_gpio = 1;
- } else if (ir_type == IR_TYPE_NEC) {
- dprintk("Changing protocol to NEC\n");
- nec_gpio = 1;
- rc5_gpio = 0;
- } else {
- dprintk("IR protocol type %ud is not supported\n",
- (unsigned)ir_type);
- return -EINVAL;
- }
-
- if (ir->running) {
- saa7134_ir_stop(dev);
- ir->nec_gpio = nec_gpio;
- ir->rc5_gpio = rc5_gpio;
- saa7134_ir_start(dev);
- } else {
- ir->nec_gpio = nec_gpio;
- ir->rc5_gpio = rc5_gpio;
- }
-
- return 0;
-}
-
int saa7134_input_init1(struct saa7134_dev *dev)
{
struct card_ir *ir;
@@ -574,10 +518,7 @@ int saa7134_input_init1(struct saa7134_dev *dev)
u32 mask_keydown = 0;
u32 mask_keyup = 0;
int polling = 0;
- int rc5_gpio = 0;
- int nec_gpio = 0;
int raw_decode = 0;
- int allow_protocol_change = 0;
int err;
if (dev->has_remote != SAA7134_REMOTE_GPIO)
@@ -830,8 +771,6 @@ int saa7134_input_init1(struct saa7134_dev *dev)
ir->mask_keydown = mask_keydown;
ir->mask_keyup = mask_keyup;
ir->polling = polling;
- ir->rc5_gpio = rc5_gpio;
- ir->nec_gpio = nec_gpio;
ir->raw_decode = raw_decode;
/* init input device */
@@ -846,11 +785,6 @@ int saa7134_input_init1(struct saa7134_dev *dev)
if (raw_decode)
rc->driver_type = RC_DRIVER_IR_RAW;
- if (!raw_decode && allow_protocol_change) {
- rc->allowed_protos = IR_TYPE_RC5
[PATCH 0/3] Remove ir-common module
I did some tests using the Encore FM 5.3. This were the last device using the legacy IR support on saa7134. After it, only one device (Nebula Electronics DigiTV) still uses it. It is an old device, so, it will probably not be easy to find someone with such hardware. As the conversion requires to test if raw decoding work with bttv (e. g. if the hardware works properly generating IRQ's on both GPIO transitions), we need someone with this hardware, or with another hardware that connects an IRQ directly into a bttv GPIO pin capable of generating IRQ's. While we don't have it, let's just move the legacy code to bttv driver. Mauro Carvalho Chehab (3): [media] saa7134: use rc-core raw decoders for Encore FM 5.3 [media] saa7134: Remove legacy IR decoding logic inside the module [media] rc: Remove ir-common module drivers/media/rc/Kconfig|5 - drivers/media/rc/Makefile |2 - drivers/media/rc/ir-functions.c | 120 -- drivers/media/video/bt8xx/Kconfig |2 +- drivers/media/video/bt8xx/bttv-input.c | 103 - drivers/media/video/saa7134/Kconfig |2 +- drivers/media/video/saa7134/saa7134-input.c | 226 +-- drivers/media/video/saa7134/saa7134.h |2 +- 8 files changed, 107 insertions(+), 355 deletions(-) delete mode 100644 drivers/media/rc/ir-functions.c -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] rc: Remove ir-common module
Now, just one old bttv board uses the old RC5 raw decoding routines.
Its conversion to rc-core requires the generation of IRQ data for both
positive and negative transitions at the IRQ line. I'm not sure if
bttv driver supports it or if the transitions will be reliable enough.
So, due to the lack of hardware for testing, the better for now is to
just move the legacy routines to bttv driver, and wait for someone with
a Nebula Digi could help to port it to use also rc-core raw decoders.
Signed-off-by: Mauro Carvalho Chehab
delete mode 100644 drivers/media/rc/ir-functions.c
diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
index 2d15468..ef19375 100644
--- a/drivers/media/rc/Kconfig
+++ b/drivers/media/rc/Kconfig
@@ -10,11 +10,6 @@ menuconfig IR_CORE
if you don't need IR, as otherwise, you may not be able to
compile the driver for your adapter.
-config IR_LEGACY
- tristate
- depends on IR_CORE
- default IR_CORE
-
if IR_CORE
config LIRC
diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
index 859c12c..8c0e4cb 100644
--- a/drivers/media/rc/Makefile
+++ b/drivers/media/rc/Makefile
@@ -1,10 +1,8 @@
-ir-common-objs := ir-functions.o
rc-core-objs := rc-main.o rc-raw.o
obj-y += keymaps/
obj-$(CONFIG_IR_CORE) += rc-core.o
-obj-$(CONFIG_IR_LEGACY) += ir-common.o
obj-$(CONFIG_LIRC) += lirc_dev.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
diff --git a/drivers/media/rc/ir-functions.c b/drivers/media/rc/ir-functions.c
deleted file mode 100644
index 14397d0..000
--- a/drivers/media/rc/ir-functions.c
+++ /dev/null
@@ -1,120 +0,0 @@
-/*
- * some common functions to handle infrared remote protocol decoding for
- * drivers which have not yet been (or can't be) converted to use the
- * regular protocol decoders...
- *
- * (c) 2003 Gerd Knorr [SuSE Labs]
- *
- * 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.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- */
-
-#include
-#include
-#include
-#include
-#include "rc-core-priv.h"
-
-/* --
*/
-
-MODULE_AUTHOR("Gerd Knorr [SuSE Labs]");
-MODULE_LICENSE("GPL");
-
-/* RC5 decoding stuff, moved from bttv-input.c to share it with
- * saa7134 */
-
-/* decode raw bit pattern to RC5 code */
-static u32 ir_rc5_decode(unsigned int code)
-{
- unsigned int org_code = code;
- unsigned int pair;
- unsigned int rc5 = 0;
- int i;
-
- for (i = 0; i < 14; ++i) {
- pair = code & 0x3;
- code >>= 2;
-
- rc5 <<= 1;
- switch (pair) {
- case 0:
- case 2:
- break;
- case 1:
- rc5 |= 1;
- break;
- case 3:
- IR_dprintk(1, "ir-common: ir_rc5_decode(%x) bad
code\n", org_code);
- return 0;
- }
- }
- IR_dprintk(1, "ir-common: code=%x, rc5=%x, start=%x, toggle=%x,
address=%x, "
- "instr=%x\n", rc5, org_code, RC5_START(rc5),
- RC5_TOGGLE(rc5), RC5_ADDR(rc5), RC5_INSTR(rc5));
- return rc5;
-}
-
-void ir_rc5_timer_end(unsigned long data)
-{
- struct card_ir *ir = (struct card_ir *)data;
- struct timeval tv;
- unsigned long current_jiffies;
- u32 gap;
- u32 rc5 = 0;
-
- /* get time */
- current_jiffies = jiffies;
- do_gettimeofday(&tv);
-
- /* avoid overflow with gap >1s */
- if (tv.tv_sec - ir->base_time.tv_sec > 1) {
- gap = 20;
- } else {
- gap = 100 * (tv.tv_sec - ir->base_time.tv_sec) +
- tv.tv_usec - ir->base_time.tv_usec;
- }
-
- /* signal we're ready to start a new code */
- ir->active = 0;
-
- /* Allow some timer jitter (RC5 is ~24ms anyway so this is ok) */
- if (gap < 28000) {
- IR_dprintk(1, "ir-common: spurious timer_end\n");
- return;
- }
-
- if (ir->last_bit < 20) {
- /* ignore spurious codes (caused by light/other remotes) */
- IR_dprintk(1, "ir-common: short code: %x\n", ir->code);
- } else {
- ir->code = (
[PATCH 1/3] [media] saa7134: use rc-core raw decoders for Encore FM 5.3
Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index fbb2ff1..4878f46 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -767,9 +767,10 @@ int saa7134_input_init1(struct saa7134_dev *dev) break; case SAA7134_BOARD_ENCORE_ENLTV_FM53: ir_codes = RC_MAP_ENCORE_ENLTV_FM53; - mask_keydown = 0x004; - mask_keycode = 0x7f; - nec_gpio = 1; + mask_keydown = 0x004; /* Enable GPIO18 line on both edges */ + mask_keyup = 0x004; + mask_keycode = 0x; + raw_decode = 1; break; case SAA7134_BOARD_10MOONSTVMASTER3: ir_codes = RC_MAP_ENCORE_ENLTV; -- 1.7.1 -- 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] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Nov 13 19:00:21 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/10] MCDE: Add frame buffer device driver
On Saturday, November 13, 2010 18:26:45 Marcus LORENTZON wrote: > Hi Hans, > MCDE is for both "video" and graphics. That is, it supports YUV and RGB > buffers to be blended onto a background during scanout. And as most SOCs it > supports normal CRTC type of continous scanout like LCD and MIPI DPI/DSI > video mode and command mode scanout like MIPI DBI/DSI. I guess you have seen > the slides of U8500 published at the last L4L2 smmit in Helsinki > (http://linuxtv.org/downloads/presentations/summit_jun_2010/ste_V4L2_developer_meeting.pdf). I'm an idiot. I should have checked that presentation in the first place. I was wondering whether this driver corresponded to what we discussed in Helsinki or whether it was new development. Now I know :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SoC Camera: ov6650: minor cleanups
Monday 08 November 2010 22:20:33 Guennadi Liakhovetski wrote: > On Tue, 2 Nov 2010, Janusz Krzysztofik wrote: > > This is a followup patch that addresses two minor issues left in the > > recently added ov6650 sensor driver, as I've promised to the subsystem > > maintainer: > > - remove a pair of extra brackets, > > - drop useless case for not possible v4l2_mbus_pixelcode enum value of 0. > > > > Created against linux-2.6.37-rc1. > > > > Signed-off-by: Janusz Krzysztofik > > Applied together with other your 3 patches and pushed for 2.6.37-rc2. Hi Guennadi, Thanks for taking my fixes. Thursday 30 September 2010 13:35:49 Janusz Krzysztofik wrote: > There are still two SG mode specific corner cases to be corrected, > previously not detected because of poor sensor driver functionality: 1) > frame size not exceeding one page, resulting in "unexpected end of frame" > message and capture restart every frame, and 2) last sgbuf lenght less than > bytes_per_line, resulting in unstable picture. I'm going to address those > two with fixes. Since both issues don't affect typical usage (one of standard resolutions) and both are videobuf-sg related, I'm wondering if I should better wait for videobuf2 and try to port my driver instead of making things still more complicated than they already are. What do you think? Thanks, Janusz -- 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/10] MCDE: Add frame buffer device driver
Hi Hans, MCDE is for both "video" and graphics. That is, it supports YUV and RGB buffers to be blended onto a background during scanout. And as most SOCs it supports normal CRTC type of continous scanout like LCD and MIPI DPI/DSI video mode and command mode scanout like MIPI DBI/DSI. I guess you have seen the slides of U8500 published at the last L4L2 smmit in Helsinki (http://linuxtv.org/downloads/presentations/summit_jun_2010/ste_V4L2_developer_meeting.pdf). And as you might remember I had the action to propose a way of posting "GEM" type of buffers to V4L2 devices. That's kind of what I'm working on. First we just had to get the basic support up for customers using framebuffer API. Even though it's an old API it can do most of what you need on a mobile device. And the work to add framebuffer support was not a big deal once we had MCDE DSS driver framework in place. This is what Jimmy is now pushing. The next step we are working on is investigating how to extend the support for all the other features of MCDE. The two obvious choices are V4L2 and DRM. Both have their pros and cons. DRM has wide support in the community for window systems like X and now lately Wayland (go Kristian ;). I have not had time to investigate video overlay support in KMS yet. But my feeling is that "desktop" drivers are moving away from overlays and I guess userspace OpenGL composition is replacing overlays, blitters and other 2D HW rapidly. But my personal feeling is that SOC platform vendors try to do both. So personally I still see big possibilities for blitter/overlay HW, especially for power efficiency since these HW blocks can do basic composition with less gates and lower clock rates -> less power. To enable this type of HW we need APIs that can be used by ordinary userspace frameworks. Here KMS and "GEM" allow us to handle resolution changes, memory management and inter process buffer sharing. But the structure of DRM still look a bit to daunting for MCDE. Of course we could squeeze MCDE into DRM framework, we just have to undestand what we Have to use of DRM and what is actually valuable to reuse. It's not a big deal to maintain a driver like MCDE. On the other hand we might want to use KMS API. And Alex presented a new option I had not considered before, simply implement the KMS ioctl API. Both options are something we are looking at right now. Then there's the video stuff. Like video/camera overlays. Here userspace frameworks push us in the direction of V4L2 (mainly gstreamer). For example exposing overlays as V4L2 output devices. V4L2 media controller, mem2mem, output devices also looks like the best option for building a complete open source OpenWFC solution on top of linux kernel APIs. Giving us a standard API for user space blitter/overlay use to be used in _paralell_ with OpenGL(ES). Note that OpenWFC is a rendering API for blitters and overlays, not a standard window system as many confuse it with. The only question left is where do we control the muxing of channels/overlays/encoders/outputs etc. V4L2 media control API looks like the most flexible solution to do this. But KMS still have some features for controlling this type of connections for display outputs. And if we choose to go for KMS for resolution changes, TV mode settings etc. There's still little reason to go down the V4L2 media control path. And V4L2 media control path is still early development. I guess these lists are a good place to start learning others' views on DRM/KMS vs. V4L2/MC for SOC display sub systems like MCDE DSS. Of course, these are not exclusive, but we still have to look at the value of supporting both APIs in paralell. /BR /Marcus From: Hans Verkuil [hverk...@xs4all.nl] Sent: Saturday, November 13, 2010 12:54 PM To: Marcus LORENTZON Cc: Alex Deucher; Jimmy RUBIN; linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver Hi Marcus, Is your display system 'just' for graphics output? Or can it also do video? I ask because many SoC display systems are designed for video output with a separate graphics layer that can be blended in. Usually the video output is handled through the video4linux API and the graphics through fbdev. Using drm is not yet common for SoC (I can't remember seeing anything of that kind, but I never actively looked for it either). With the increasing complexity of SoC graphics parts I am sure drm will become much more relevant. A separate issue is memory handling. V4L and graphics drivers share similar problems. It's my intention to start looking into this some time next year. It all seems quite messy at the moment. Regards, Hans On Friday, November 12, 2010 17:46:53 Marcus LORENTZON wrote: > Hi Alex, > Do you have any idea of how we should use KMS without being a "real" drm 3D > d
Re: [PATCH 2/3] i2c: Drivers shouldn't include
On Sat, 13 Nov 2010 12:34:23 -0200, Mauro Carvalho Chehab wrote:
> Em 05-11-2010 18:07, Jean Delvare escreveu:
> > Drivers don't need to include , especially not when
> > they don't use anything that header file provides.
> >
> > Signed-off-by: Jean Delvare
> > Cc: Michael Hunold
> > Cc: Mauro Carvalho Chehab
>
> I suspect that you want to include it via your tree, so:
> Acked-by: Mauro Carvalho Chehab
Indeed, thanks.
> > ---
> > drivers/media/common/saa7146_i2c.c|1 -
> > drivers/media/video/ir-kbd-i2c.c |1 -
> > drivers/staging/olpc_dcon/olpc_dcon.c |1 -
> > 3 files changed, 3 deletions(-)
> >
> > --- linux-2.6.37-rc1.orig/drivers/media/common/saa7146_i2c.c
> > 2010-11-02 09:19:35.0 +0100
> > +++ linux-2.6.37-rc1/drivers/media/common/saa7146_i2c.c 2010-11-05
> > 15:34:25.0 +0100
> > @@ -391,7 +391,6 @@ static int saa7146_i2c_xfer(struct i2c_a
> >
> >
> > /*/
> > /* i2c-adapter helper functions
> > */
> > -#include
> >
> > /* exported algorithm data */
> > static struct i2c_algorithm saa7146_algo = {
> > --- linux-2.6.37-rc1.orig/drivers/media/video/ir-kbd-i2c.c 2010-11-02
> > 09:19:35.0 +0100
> > +++ linux-2.6.37-rc1/drivers/media/video/ir-kbd-i2c.c 2010-11-05
> > 15:34:18.0 +0100
> > @@ -44,7 +44,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> >
> > #include
> > --- linux-2.6.37-rc1.orig/drivers/staging/olpc_dcon/olpc_dcon.c
> > 2010-11-02 09:19:37.0 +0100
> > +++ linux-2.6.37-rc1/drivers/staging/olpc_dcon/olpc_dcon.c 2010-11-05
> > 15:34:14.0 +0100
> > @@ -17,7 +17,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> >
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jean Delvare
--
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: gspca_ov534: Changing framerates, different behaviour in 2.6.36
On Sat, 13 Nov 2010 16:12:05 +0100 Antonio Ospite wrote: > guvcview: > > If I: > 1. Go to the "Video & Files Tab" > 2. Change the "Frame Rate" value from the drop down menu > [...] > > since 2.6.36 + the regression fix in [1] (please apply it): > 3a. dmesg shows the message: ov534: frame_rate: xx > 3b. guvcviews gives some errors and the preview image halts: >VIDIOC_QBUF - Unable to queue buffer: Invalid argument >Could not grab image (select timeout): > Resource temporarily unavailable > [...] > I am trying to spot what caused this, I guess it is something in > gspca_main, hopefully Jean-François has some idea that can help me > narrowing down the search. > Reverting f7059eaa285c0460569ffd26c43ae07e3f03cd6c brings the old behaviour back. So something there is not happy with changing frame rate on the fly. Regards, Antonio -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpQPMdcoS43V.pgp Description: PGP signature
gspca_ov534: Changing framerates, different behaviour in 2.6.36
Hi, in 2.6.36 and later there is a change of behavior when changing framerates with the gspca_ov534 driver, here's what happens using guvcview: If I: 1. Go to the "Video & Files Tab" 2. Change the "Frame Rate" value from the drop down menu in 2.6.35: 3a. dmesg shows the message: ov534: frame_rate: xx 3b. The frame rate is changed and the guvcview preview window shows the different capture speed since 2.6.36 + the regression fix in [1] (please apply it): 3a. dmesg shows the message: ov534: frame_rate: xx 3b. guvcviews gives some errors and the preview image halts: VIDIOC_QBUF - Unable to queue buffer: Invalid argument Could not grab image (select timeout): Resource temporarily unavailable Setting framerates works only once per device opening (tested with "luvcview -i xx"), it's just changing it "live" that is broken in newer kernels. I am trying to spot what caused this, I guess it is something in gspca_main, hopefully Jean-François has some idea that can help me narrowing down the search. Note that AFAIK gspca_ov534 is the only gspca driver enumerating framerates with VIDIOC_ENUM_FRAMEINTERVALS, but from a quick look nothing changed in this area. Thanks, Antonio [1] http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/24899 -- Antonio Ospite http://ao2.it PGP public key ID: 0x4553B001 A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? pgpywGosbKEcu.pgp Description: PGP signature
Re: [GIT PATCHES FOR 2.6.38] mantis for_2.6.38
Mauro Carvalho Chehab writes: > Em 12-11-2010 12:43, Bjørn Mork escreveu: >> >> git://git.mork.no/mantis.git for_2.6.38 > > Didn't work: > > git pull git://git.mork.no/mantis.git for_2.6.38 > fatal: Couldn't find remote ref for_2.6.38 Damn, sorry about that. Was supposed to be git://git.mork.no/mantis.git for_v2.6.38 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
Re: [PATCH 3/3] i2c: Mark i2c_adapter.id as deprecated
On Friday, November 05, 2010 21:10:01 Jean Delvare wrote:
> It's about time to make it clear that i2c_adapter.id is deprecated.
> Hopefully this will remind the last user to move over to a different
> strategy.
>
> Signed-off-by: Jean Delvare
> Cc: Hans Verkuil
> Cc: Jarod Wilson
Acked-by: Hans Verkuil
> ---
> drivers/i2c/i2c-mux.c |1 -
> include/linux/i2c.h |2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> --- linux-2.6.37-rc1.orig/include/linux/i2c.h 2010-11-05 13:55:17.0
> +0100
> +++ linux-2.6.37-rc1/include/linux/i2c.h 2010-11-05 15:41:20.0
> +0100
> @@ -353,7 +353,7 @@ struct i2c_algorithm {
> */
> struct i2c_adapter {
> struct module *owner;
> - unsigned int id;
> + unsigned int id __deprecated;
> unsigned int class; /* classes to allow probing for */
> const struct i2c_algorithm *algo; /* the algorithm to access the bus */
> void *algo_data;
> --- linux-2.6.37-rc1.orig/drivers/i2c/i2c-mux.c 2010-11-05
> 16:06:18.0 +0100
> +++ linux-2.6.37-rc1/drivers/i2c/i2c-mux.c2010-11-05 16:06:33.0
> +0100
> @@ -120,7 +120,6 @@ struct i2c_adapter *i2c_add_mux_adapter(
> snprintf(priv->adap.name, sizeof(priv->adap.name),
>"i2c-%d-mux (chan_id %d)", i2c_adapter_id(parent), chan_id);
> priv->adap.owner = THIS_MODULE;
> - priv->adap.id = parent->id;
> priv->adap.algo = &priv->algo;
> priv->adap.algo_data = priv;
> priv->adap.dev.parent = &parent->dev;
>
>
>
--
Hans Verkuil - video4linux developer - sponsored by Cisco
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] i2c: Mark i2c_adapter.id as deprecated
Em 05-11-2010 18:10, Jean Delvare escreveu:
> It's about time to make it clear that i2c_adapter.id is deprecated.
> Hopefully this will remind the last user to move over to a different
> strategy.
>
> Signed-off-by: Jean Delvare
> Cc: Hans Verkuil
> Cc: Jarod Wilson
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/i2c/i2c-mux.c |1 -
> include/linux/i2c.h |2 +-
> 2 files changed, 1 insertion(+), 2 deletions(-)
>
> --- linux-2.6.37-rc1.orig/include/linux/i2c.h 2010-11-05 13:55:17.0
> +0100
> +++ linux-2.6.37-rc1/include/linux/i2c.h 2010-11-05 15:41:20.0
> +0100
> @@ -353,7 +353,7 @@ struct i2c_algorithm {
> */
> struct i2c_adapter {
> struct module *owner;
> - unsigned int id;
> + unsigned int id __deprecated;
> unsigned int class; /* classes to allow probing for */
> const struct i2c_algorithm *algo; /* the algorithm to access the bus */
> void *algo_data;
> --- linux-2.6.37-rc1.orig/drivers/i2c/i2c-mux.c 2010-11-05
> 16:06:18.0 +0100
> +++ linux-2.6.37-rc1/drivers/i2c/i2c-mux.c2010-11-05 16:06:33.0
> +0100
> @@ -120,7 +120,6 @@ struct i2c_adapter *i2c_add_mux_adapter(
> snprintf(priv->adap.name, sizeof(priv->adap.name),
>"i2c-%d-mux (chan_id %d)", i2c_adapter_id(parent), chan_id);
> priv->adap.owner = THIS_MODULE;
> - priv->adap.id = parent->id;
> priv->adap.algo = &priv->algo;
> priv->adap.algo_data = priv;
> priv->adap.dev.parent = &parent->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
Re: [PATCH 1/3] i2c: Delete unused adapter IDs
On Saturday, November 13, 2010 15:33:18 Mauro Carvalho Chehab wrote: > Em 05-11-2010 18:06, Jean Delvare escreveu: > > Delete unused I2C adapter IDs. Special cases are: > > > > * I2C_HW_B_RIVA was still set in driver rivafb, however no other > > driver is ever looking for this value, so we can safely remove it. > > * I2C_HW_B_HDPVR is used in staging driver lirc_zilog, however no > > adapter ID is ever set to this value, so the code in question never > > runs. As the code additionally expects that I2C_HW_B_HDPVR may not > > be defined, we can delete it now and let the lirc_zilog driver > > maintainer rewrite this piece of code. > > > > Big thanks for Hans Verkuil for doing all the hard work :) > > > > Signed-off-by: Jean Delvare > > Cc: Hans Verkuil > > Cc: Jarod Wilson > > Acked-by: Mauro Carvalho Chehab Well, if everyone acks, then I'd better join :-) Acked-by: Hans Verkuil Regards, Hans > > --- > > drivers/video/riva/rivafb-i2c.c |1 - > > include/linux/i2c-id.h | 22 -- > > 2 files changed, 23 deletions(-) > > > > --- linux-2.6.37-rc1.orig/include/linux/i2c-id.h2010-11-05 > > 13:55:17.0 +0100 > > +++ linux-2.6.37-rc1/include/linux/i2c-id.h 2010-11-05 15:05:32.0 > > +0100 > > @@ -32,28 +32,6 @@ > > */ > > > > /* --- Bit algorithm adapters > > */ > > -#define I2C_HW_B_BT848 0x010005 /* BT848 video boards */ > > -#define I2C_HW_B_RIVA 0x010010 /* Riva based graphics cards */ > > -#define I2C_HW_B_ZR36067 0x010019 /* Zoran-36057/36067 based boards */ > > #define I2C_HW_B_CX2388x 0x01001b /* connexant 2388x based tv cards */ > > -#define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards > > */ > > -#define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards > > */ > > -#define I2C_HW_B_CX23885 0x010022 /* conexant 23885 based tv cards > > (bus1) */ > > -#define I2C_HW_B_AU08280x010023 /* auvitek au0828 usb bridge */ > > -#define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */ > > -#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */ > > - > > -/* --- SGI adapters > > */ > > -#define I2C_HW_SGI_VINO0x16 > > - > > -/* --- SMBus only adapters */ > > -#define I2C_HW_SMBUS_W9968CF 0x04000d > > -#define I2C_HW_SMBUS_OV511 0x04000e /* OV511(+) USB 1.1 webcam ICs */ > > -#define I2C_HW_SMBUS_OV518 0x04000f /* OV518(+) USB 1.1 webcam ICs */ > > -#define I2C_HW_SMBUS_CAFE 0x040012 /* Marvell 88ALP01 "CAFE" cam */ > > - > > -/* --- Miscellaneous adapters */ > > -#define I2C_HW_SAA7146 0x06 /* SAA7146 video decoder bus */ > > -#define I2C_HW_SAA7134 0x09 /* SAA7134 video decoder bus */ > > > > #endif /* LINUX_I2C_ID_H */ > > --- linux-2.6.37-rc1.orig/drivers/video/riva/rivafb-i2c.c 2010-11-05 > > 13:55:17.0 +0100 > > +++ linux-2.6.37-rc1/drivers/video/riva/rivafb-i2c.c2010-11-05 > > 13:55:19.0 +0100 > > @@ -94,7 +94,6 @@ static int __devinit riva_setup_i2c_bus( > > > > strcpy(chan->adapter.name, name); > > chan->adapter.owner = THIS_MODULE; > > - chan->adapter.id= I2C_HW_B_RIVA; > > chan->adapter.class = i2c_class; > > chan->adapter.algo_data = &chan->algo; > > chan->adapter.dev.parent= &chan->par->pdev->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 > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] i2c: Drivers shouldn't include
Em 05-11-2010 18:07, Jean Delvare escreveu:
> Drivers don't need to include , especially not when
> they don't use anything that header file provides.
>
> Signed-off-by: Jean Delvare
> Cc: Michael Hunold
> Cc: Mauro Carvalho Chehab
I suspect that you want to include it via your tree, so:
Acked-by: Mauro Carvalho Chehab
> ---
> drivers/media/common/saa7146_i2c.c|1 -
> drivers/media/video/ir-kbd-i2c.c |1 -
> drivers/staging/olpc_dcon/olpc_dcon.c |1 -
> 3 files changed, 3 deletions(-)
>
> --- linux-2.6.37-rc1.orig/drivers/media/common/saa7146_i2c.c 2010-11-02
> 09:19:35.0 +0100
> +++ linux-2.6.37-rc1/drivers/media/common/saa7146_i2c.c 2010-11-05
> 15:34:25.0 +0100
> @@ -391,7 +391,6 @@ static int saa7146_i2c_xfer(struct i2c_a
>
>
> /*/
> /* i2c-adapter helper functions
> */
> -#include
>
> /* exported algorithm data */
> static struct i2c_algorithm saa7146_algo = {
> --- linux-2.6.37-rc1.orig/drivers/media/video/ir-kbd-i2c.c2010-11-02
> 09:19:35.0 +0100
> +++ linux-2.6.37-rc1/drivers/media/video/ir-kbd-i2c.c 2010-11-05
> 15:34:18.0 +0100
> @@ -44,7 +44,6 @@
> #include
> #include
> #include
> -#include
> #include
>
> #include
> --- linux-2.6.37-rc1.orig/drivers/staging/olpc_dcon/olpc_dcon.c
> 2010-11-02 09:19:37.0 +0100
> +++ linux-2.6.37-rc1/drivers/staging/olpc_dcon/olpc_dcon.c2010-11-05
> 15:34:14.0 +0100
> @@ -17,7 +17,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
>
>
--
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/3] i2c: Delete unused adapter IDs
Em 05-11-2010 18:06, Jean Delvare escreveu: > Delete unused I2C adapter IDs. Special cases are: > > * I2C_HW_B_RIVA was still set in driver rivafb, however no other > driver is ever looking for this value, so we can safely remove it. > * I2C_HW_B_HDPVR is used in staging driver lirc_zilog, however no > adapter ID is ever set to this value, so the code in question never > runs. As the code additionally expects that I2C_HW_B_HDPVR may not > be defined, we can delete it now and let the lirc_zilog driver > maintainer rewrite this piece of code. > > Big thanks for Hans Verkuil for doing all the hard work :) > > Signed-off-by: Jean Delvare > Cc: Hans Verkuil > Cc: Jarod Wilson Acked-by: Mauro Carvalho Chehab > --- > drivers/video/riva/rivafb-i2c.c |1 - > include/linux/i2c-id.h | 22 -- > 2 files changed, 23 deletions(-) > > --- linux-2.6.37-rc1.orig/include/linux/i2c-id.h 2010-11-05 > 13:55:17.0 +0100 > +++ linux-2.6.37-rc1/include/linux/i2c-id.h 2010-11-05 15:05:32.0 > +0100 > @@ -32,28 +32,6 @@ > */ > > /* --- Bit algorithm adapters > */ > -#define I2C_HW_B_BT848 0x010005 /* BT848 video boards */ > -#define I2C_HW_B_RIVA0x010010 /* Riva based graphics cards */ > -#define I2C_HW_B_ZR36067 0x010019 /* Zoran-36057/36067 based boards */ > #define I2C_HW_B_CX2388x 0x01001b /* connexant 2388x based tv cards */ > -#define I2C_HW_B_EM28XX 0x01001f /* em28xx video capture cards > */ > -#define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards > */ > -#define I2C_HW_B_CX23885 0x010022 /* conexant 23885 based tv cards > (bus1) */ > -#define I2C_HW_B_AU0828 0x010023 /* auvitek au0828 usb bridge */ > -#define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */ > -#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */ > - > -/* --- SGI adapters */ > -#define I2C_HW_SGI_VINO 0x16 > - > -/* --- SMBus only adapters */ > -#define I2C_HW_SMBUS_W9968CF 0x04000d > -#define I2C_HW_SMBUS_OV511 0x04000e /* OV511(+) USB 1.1 webcam ICs */ > -#define I2C_HW_SMBUS_OV518 0x04000f /* OV518(+) USB 1.1 webcam ICs */ > -#define I2C_HW_SMBUS_CAFE0x040012 /* Marvell 88ALP01 "CAFE" cam */ > - > -/* --- Miscellaneous adapters */ > -#define I2C_HW_SAA7146 0x06 /* SAA7146 video decoder bus */ > -#define I2C_HW_SAA7134 0x09 /* SAA7134 video decoder bus */ > > #endif /* LINUX_I2C_ID_H */ > --- linux-2.6.37-rc1.orig/drivers/video/riva/rivafb-i2c.c 2010-11-05 > 13:55:17.0 +0100 > +++ linux-2.6.37-rc1/drivers/video/riva/rivafb-i2c.c 2010-11-05 > 13:55:19.0 +0100 > @@ -94,7 +94,6 @@ static int __devinit riva_setup_i2c_bus( > > strcpy(chan->adapter.name, name); > chan->adapter.owner = THIS_MODULE; > - chan->adapter.id= I2C_HW_B_RIVA; > chan->adapter.class = i2c_class; > chan->adapter.algo_data = &chan->algo; > chan->adapter.dev.parent= &chan->par->pdev->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
Re: [GIT PATCHES FOR 2.6.38] mantis for_2.6.38
Em 12-11-2010 12:43, Bjørn Mork escreveu: > Hello, > > I've been waiting for this list of patchwork patches to be included for > quite a while, and have now taken the liberty to clean them up as > necessary and add them to a git tree, based on the current media_tree > for_v2.6.38 branch, with exceptions as noted below: > >> == mantis patches - Waiting for Manu Abraham >> == >> >> Apr,15 2010: [5/8] ir-core: convert mantis from ir-functions.c >>http://patchwork.kernel.org/patch/92961 David Härdeman >> > > already applied as commit f0bdee26a2dc904c463bae1c2ae9ad06f97f100d > >> Jun,20 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, >> improve http://patchwork.kernel.org/patch/107036 Marko Ristola >> > > duplicate of http://patchwork.kernel.org/patch/118173 > >> Jun,20 2010: [2/2] DVB/V4L: mantis: remove unused files >>http://patchwork.kernel.org/patch/107062 Bjørn Mork >> Jun,20 2010: mantis: use dvb_attach to avoid double dereferencing on module >> removal http://patchwork.kernel.org/patch/107063 Bjørn Mork >> Jun,21 2010: Mantis, hopper: use MODULE_DEVICE_TABLE use the macro to make >> modules http://patchwork.kernel.org/patch/107147 Manu Abraham >> >> Jul, 3 2010: mantis: Rename gpio_set_bits to mantis_gpio_set_bits >>http://patchwork.kernel.org/patch/109972 Ben Hutchings >> >> Jul, 8 2010: Mantis DMA transfer cleanup, fixes data corruption and a race, >> improve http://patchwork.kernel.org/patch/110909 Marko Ristola >> > > another duplicate of http://patchwork.kernel.org/patch/118173 > >> Jul, 9 2010: Mantis: append tasklet maintenance for DVB stream delivery >>http://patchwork.kernel.org/patch/111090 Marko Ristola >> >> Jul,10 2010: Mantis driver patch: use interrupt for I2C traffic instead of >> busy reg http://patchwork.kernel.org/patch/111245 Marko Ristola >> >> Jul,19 2010: Twinhan DTV Ter-CI (3030 mantis) >>http://patchwork.kernel.org/patch/112708 Niklas Claesson >> > > Missing Signed-off-by, and I'm also a bit confused wrt what the patch > actually is. Needs further cleanup. > >> Aug, 7 2010: Refactor Mantis DMA transfer to deliver 16Kb TS data per >> interrupt http://patchwork.kernel.org/patch/118173 Marko Ristola >> >> Oct,10 2010: [v2] V4L/DVB: faster DVB-S lock for mantis cards using stb0899 >> demod http://patchwork.kernel.org/patch/244201 Tuxoholic >> > Patchwork updated. Thanks for checking those duplicated stuff. > > > The following changes since commit > > af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3[media] IR: add tv power scancode > to rc6 mce keymap > > are available in the git repository at: > > git://git.mork.no/mantis.git for_2.6.38 Didn't work: git pull git://git.mork.no/mantis.git for_2.6.38 fatal: Couldn't find remote ref for_2.6.38 Cheers, 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
msp3400 regression fix for 2.6.36?
Hi Mauro, Will you backport this fix to the stable 2.6.36? http://git.linuxtv.org/linux-2.6.git?a=commit;h=0310871d8f71da4ad8643687fbc40f219a0dac4d The patch applies fine against 2.6.36. If you want me to do something, then let me know. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] gspca for_2.6.38
Em 13-11-2010 10:16, Anca Emanuel escreveu: > On Sat, Nov 13, 2010 at 11:46 AM, Jean-Francois Moine wrote: >> The following changes since commit >> af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3: >> >> [media] IR: add tv power scancode to rc6 mce keymap (2010-11-10 00:58:49 >> -0200) >> >> are available in the git repository at: >> git://linuxtv.org/jfrancois/gspca.git for_2.6.38 >> >> Jean-François Moine (16): >> gspca - ov519: Handle the snapshot on capture stop when CONFIG_INPUT=m >> gspca - ov519: Don't do USB exchanges after disconnection >> gspca - ov519: Change types '__xx' to 'xx' >> gspca - ov519: Reduce the size of some variables >> gspca - ov519: Define the sensor types in an enum >> gspca - ov519: Cleanup source >> gspca - ov519: Set their numbers in the ov519 and ov7670 register names >> gspca - ov519: Define the disabled controls in a table >> gspca - ov519: Propagate errors to higher level >> gspca - ov519: Clearer debug and error messages >> gspca - ov519: Check the disabled controls at start time only >> gspca - ov519: Simplify the LED control functions >> gspca - ov519: Change the ov519 start and stop sequences >> gspca - ov519: Initialize the ov519 snapshot register >> gspca - ov519: Re-initialize the webcam at resume time >> gspca - ov519: New sensor ov7660 with bridge ov530 (ov519) >> >> Nicolas Kaiser (1): >> gspca - cpia1: Fix error check >> >> drivers/media/video/gspca/cpia1.c |2 +- >> drivers/media/video/gspca/ov519.c | 1671 >> +-- >> drivers/media/video/gspca/w996Xcf.c | 325 +++ >> 3 files changed, 1131 insertions(+), 867 deletions(-) > > Some conflicts against mainline: Didn't get any conflict against branch staging/for_v2.6.38. Patches applied, thanks. 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
[GIT PULL for 2.6.36-rc2] drivers/media fixes
Hi Linus, Please pull from: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus For a few bug fixes on some drivers, and for Arnd's patch to finish the BKL removal from V4L/DVB, as discussed during the KS/2010. Thanks! Mauro The following changes since commit c8ddb2713c624f432fa5fe3c7ecffcdda46ea0d4: Linux 2.6.37-rc1 (2010-11-01 07:54:12 -0400) are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git v4l_for_linus Arnd Bergmann (1): [media] v4l: kill the BKL Daniel Drake (1): [media] cafe_ccic: fix subdev configuration Dmitri Belimov (1): [media] saa7134: Fix autodetect for Behold A7 and H7 TV cards Janusz Krzysztofik (4): [media] SoC Camera: OMAP1: update for recent framework changes [media] SoC Camera: OMAP1: update for recent videobuf changes [media] SOC Camera: OMAP1: typo fix [media] SoC Camera: ov6650: minor cleanups Jean Delvare (1): [media] BZ#22292: dibx000_common: Restore i2c algo pointer Sascha Hauer (2): [media] ARM mx3_camera: check for DMA engine type [media] soc-camera: Compile fixes for mx2-camera Stefan Ringel (1): [media] tm6000: bugfix set tv standards drivers/media/Kconfig|1 - drivers/media/dvb/frontends/dibx000_common.c |1 + drivers/media/video/cafe_ccic.c |5 ++- drivers/media/video/cx231xx/cx231xx-417.c|6 +--- drivers/media/video/cx23885/cx23885-417.c|9 +--- drivers/media/video/cx23885/cx23885-video.c |5 drivers/media/video/mx2_camera.c | 13 --- drivers/media/video/mx3_camera.c |4 +++ drivers/media/video/omap1_camera.c | 16 +++--- drivers/media/video/ov6650.c |4 +-- drivers/media/video/saa7134/saa7134-cards.c | 24 ++-- drivers/media/video/se401.c |7 ++--- drivers/media/video/stk-webcam.c |4 --- drivers/media/video/tlg2300/pd-main.c| 13 +++ drivers/media/video/usbvideo/vicam.c | 29 - drivers/media/video/v4l2-dev.c |7 +++-- drivers/media/video/zoran/zoran.h|1 + drivers/media/video/zoran/zoran_card.c |1 + drivers/media/video/zoran/zoran_driver.c | 27 ++- drivers/staging/tm6000/tm6000-video.c|1 + 20 files changed, 86 insertions(+), 92 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
TBS 6921 support
Hi all, I have recently contacted TBS support to see if they have new products, and they do have something in the pipeline: the 6921 and 8921, about to be released, IIRC end of november. I am interested in whicether that has good linux support. On this link you can check the specs and chips: http://www.tbsdtv.com/english/product/images/8920_vs_8921.jpg They say they have linux drivers but I would like to make sure they are good and reliable. If anyone here could tell me if these are supported or about to be. I am prepared to do some testing reporting, time permitting. TIA Bye Manu -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] davinci vpbe: V4L2 Display driver for DM644X
Hi Manju, I've reviewed the other patches as well. The only one for which I had comments was patch 2/6. However, what I think would be useful here is to have an overview document, either as part of a source or header, or as a separate text document. It is not easy to get a good overview of how everything fits together, and a document that describes the various parts and how they fit together would be very benificial. I am thinking in particular of vendors building a new board based on this device: how and where do you define new i2c display devices, how are they initialized, etc. Regards, Hans On Monday, November 08, 2010 15:54:05 Manjunath Hadli wrote: > This driver is written for Texas Instruments's DM644X VPBE IP. > This SoC supports 2 video planes and 2 OSD planes as part of its > OSD (On Screen Display) block. The OSD lanes predminantly support > RGB space and the Video planes support YUV data. Out of these 4, > the 2 video planes are supported as part of the V4L2 driver. These > would be enumerated as video2 and video3 dev nodes. > The blending and video timing generator unit (VENC- for Video Encoder) > is the unit which combines/blends the output of these 4 planes > into a single stream and this output is given to Video input devices > like TV and other digital LCDs. The software for VENC is designed as > a subdevice with support for SD(NTSC and PAL) modes and 2 outputs. > This SoC forms the iniial implementation of its later additions > like DM355 and DM365. > > Muralidharan Karicheri (6): > davinci vpbe: V4L2 display driver for DM644X SoC > davinci vpbe: VPBE display driver > davinci vpbe: OSD(On Screen Display ) block > davinci vpbe: VENC( Video Encoder) implementation > davinci vpbe: platform specific additions > davinci vpbe: Build infrastructure for VPBE driver > > arch/arm/mach-davinci/board-dm644x-evm.c | 85 +- > arch/arm/mach-davinci/dm644x.c | 181 ++- > arch/arm/mach-davinci/include/mach/dm644x.h |4 + > drivers/media/video/davinci/Kconfig | 22 + > drivers/media/video/davinci/Makefile |2 + > drivers/media/video/davinci/vpbe.c | 861 ++ > drivers/media/video/davinci/vpbe_display.c | 2283 > ++ > drivers/media/video/davinci/vpbe_osd.c | 1208 ++ > drivers/media/video/davinci/vpbe_osd_regs.h | 389 + > drivers/media/video/davinci/vpbe_venc.c | 617 +++ > drivers/media/video/davinci/vpbe_venc_regs.h | 189 +++ > include/media/davinci/vpbe.h | 187 +++ > include/media/davinci/vpbe_display.h | 144 ++ > include/media/davinci/vpbe_osd.h | 397 + > include/media/davinci/vpbe_types.h | 170 ++ > include/media/davinci/vpbe_venc.h| 70 + > 16 files changed, 6790 insertions(+), 19 deletions(-) > create mode 100644 drivers/media/video/davinci/vpbe.c > create mode 100644 drivers/media/video/davinci/vpbe_display.c > create mode 100644 drivers/media/video/davinci/vpbe_osd.c > create mode 100644 drivers/media/video/davinci/vpbe_osd_regs.h > create mode 100644 drivers/media/video/davinci/vpbe_venc.c > create mode 100644 drivers/media/video/davinci/vpbe_venc_regs.h > create mode 100644 include/media/davinci/vpbe.h > create mode 100644 include/media/davinci/vpbe_display.h > create mode 100644 include/media/davinci/vpbe_osd.h > create mode 100644 include/media/davinci/vpbe_types.h > create mode 100644 include/media/davinci/vpbe_venc.h > > -- > 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 > > -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] davinci vpbe: VPBE display driver
Some minor review comments...
On Monday, November 08, 2010 15:54:25 Manjunath Hadli wrote:
> From: Muralidharan Karicheri
>
> This patch implements the coe functionality of the dislay driver,
> mainly controlling the VENC and other encoders, and acting as
> the one point interface for the man V4L2 driver.This implements
> the cre of each of the V4L2 IOCTLs.
>
> Signed-off-by: Muralidharan Karicheri
> Signed-off-by: Manjunath Hadli
> ---
> drivers/media/video/davinci/vpbe.c | 861
>
> include/media/davinci/vpbe.h | 187
> 2 files changed, 1048 insertions(+), 0 deletions(-)
> create mode 100644 drivers/media/video/davinci/vpbe.c
> create mode 100644 include/media/davinci/vpbe.h
>
> diff --git a/drivers/media/video/davinci/vpbe.c
> b/drivers/media/video/davinci/vpbe.c
> new file mode 100644
> index 000..17ff1e7
> --- /dev/null
> +++ b/drivers/media/video/davinci/vpbe.c
> @@ -0,0 +1,861 @@
> +/*
> + * Copyright (C) 2010 Texas Instruments Inc
> + *
> + * 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.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +
> +
> +#define VPBE_DEFAULT_OUTPUT "Composite"
> +#define VPBE_DEFAULT_MODE"ntsc"
> +
> +static char *def_output = VPBE_DEFAULT_OUTPUT;
> +static char *def_mode = VPBE_DEFAULT_MODE;
> +static struct osd_state *osd_device;
> +static int debug;
> +
> +module_param(def_output, charp, S_IRUGO);
> +module_param(def_mode, charp, S_IRUGO);
> +module_param(debug, int, 0644);
> +
> +MODULE_PARM_DESC(def_output, "vpbe output name (default:Composite)");
> +MODULE_PARM_DESC(ef_mode, "vpbe output mode name (default:ntsc");
> +MODULE_PARM_DESC(debug, "Debug level 0-1");
> +
> +MODULE_DESCRIPTION("TI DMXXX VPBE Display controller");
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Texas Instruments");
> +
> +/**
> + * vpbe_current_encoder_info - Get config info for current encoder
> + * @vpbe_dev - vpbe device ptr
> + *
> + * Return ptr to current encoder config info
> + */
> +static struct encoder_config_info*
> +vpbe_current_encoder_info(struct vpbe_device *vpbe_dev)
> +{
> + struct vpbe_display_config *vpbe_config = vpbe_dev->cfg;
> + int index = vpbe_dev->current_sd_index;
> + return ((index == 0) ? &vpbe_config->venc :
> + &vpbe_config->ext_encoders[index-1]);
> +}
> +
> +/**
> + * vpbe_find_encoder_sd_index - Given a name find encoder sd index
> + *
> + * @vpbe_config - ptr to vpbe cfg
> + * @output_index - index used by application
> + *
> + * Return sd index of the encoder
> + */
> +static int vpbe_find_encoder_sd_index(struct vpbe_display_config
> *vpbe_config,
> + int index)
> +{
> + char *encoder_name = vpbe_config->outputs[index].subdev_name;
> + int i;
> +
> + /* Venc is always first */
> + if (!strcmp(encoder_name, vpbe_config->venc.module_name))
> + return 0;
> +
> + for (i = 0; i < vpbe_config->num_ext_encoders; i++) {
> + if (!strcmp(encoder_name,
> + vpbe_config->ext_encoders[i].module_name))
> + return i+1;
> + }
> + return -EINVAL;
> +}
> +
> +/**
> + * vpbe_g_cropcap - Get crop capabilities of the display
> + * @vpbe_dev - vpbe device ptr
> + * @cropcap - cropcap is a ptr to struct v4l2_cropcap
> + *
> + * Update the crop capabilities in crop cap for current
> + * mode
> + */
> +static int vpbe_g_cropcap(struct vpbe_device *vpbe_dev,
> + struct v4l2_cropcap *cropcap)
> +{
> + if (NULL == cropcap)
> + return -EINVAL;
> + cropcap->bounds.left = 0;
> + cropcap->bounds.top = 0;
> + cropcap->bounds.width = vpbe_dev->current_timings.xres;
> + cropcap->bounds.height = vpbe_dev->current_timings.yres;
> + cropcap->defrect = cropcap->bounds;
> + return 0;
> +}
> +
> +/**
> + * vpbe_enum_outputs - enumerate outputs
> + * @vpbe_dev - vpbe device ptr
> + * @output - ptr to v4l2_output structure
> + *
> + * Enumerates the outputs available at the vpbe display
> + * returns the status, -EINVAL if end of output list
> + */
> +static int vpbe_enum_outputs(struct vpbe_device
Re: [GIT PATCHES FOR 2.6.38] gspca for_2.6.38
On Sat, Nov 13, 2010 at 11:46 AM, Jean-Francois Moine wrote: > The following changes since commit > af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3: > > [media] IR: add tv power scancode to rc6 mce keymap (2010-11-10 00:58:49 > -0200) > > are available in the git repository at: > git://linuxtv.org/jfrancois/gspca.git for_2.6.38 > > Jean-François Moine (16): > gspca - ov519: Handle the snapshot on capture stop when CONFIG_INPUT=m > gspca - ov519: Don't do USB exchanges after disconnection > gspca - ov519: Change types '__xx' to 'xx' > gspca - ov519: Reduce the size of some variables > gspca - ov519: Define the sensor types in an enum > gspca - ov519: Cleanup source > gspca - ov519: Set their numbers in the ov519 and ov7670 register names > gspca - ov519: Define the disabled controls in a table > gspca - ov519: Propagate errors to higher level > gspca - ov519: Clearer debug and error messages > gspca - ov519: Check the disabled controls at start time only > gspca - ov519: Simplify the LED control functions > gspca - ov519: Change the ov519 start and stop sequences > gspca - ov519: Initialize the ov519 snapshot register > gspca - ov519: Re-initialize the webcam at resume time > gspca - ov519: New sensor ov7660 with bridge ov530 (ov519) > > Nicolas Kaiser (1): > gspca - cpia1: Fix error check > > drivers/media/video/gspca/cpia1.c | 2 +- > drivers/media/video/gspca/ov519.c | 1671 > +-- > drivers/media/video/gspca/w996Xcf.c | 325 +++ > 3 files changed, 1131 insertions(+), 867 deletions(-) Some conflicts against mainline: diff --cc drivers/staging/cx25821/Kconfig index 1d73334,9c2e259..000 --- a/drivers/staging/cx25821/Kconfig +++ b/drivers/staging/cx25821/Kconfig @@@ -1,7 -1,6 +1,11 @@@ config VIDEO_CX25821 tristate "Conexant cx25821 support" ++<<< HEAD + depends on DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT + depends on BKL # please fix ++=== + depends on DVB_CORE && VIDEO_DEV && PCI && I2C ++>>> b49b143975141c461bfd11dd1c6632c1a1c7f8ff select I2C_ALGOBIT select VIDEO_BTCX select VIDEO_TVEEPROM diff --cc drivers/staging/go7007/Kconfig index 3aecd30,75ddaad..000 --- a/drivers/staging/go7007/Kconfig +++ b/drivers/staging/go7007/Kconfig @@@ -1,10 -1,9 +1,14 @@@ config VIDEO_GO7007 tristate "WIS GO7007 MPEG encoder support" ++<<< HEAD + depends on VIDEO_DEV && PCI && I2C && INPUT + depends on BKL # please fix ++=== + depends on VIDEO_DEV && PCI && I2C ++>>> b49b143975141c461bfd11dd1c6632c1a1c7f8ff depends on SND select VIDEOBUF_DMA_SG - depends on VIDEO_IR + depends on IR_CORE select VIDEO_TUNER select VIDEO_TVEEPROM select SND_PCM Running new kernel now, ov7660 works. Thank you. -- 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/10] MCDE: Add frame buffer device driver
Hi Marcus, Is your display system 'just' for graphics output? Or can it also do video? I ask because many SoC display systems are designed for video output with a separate graphics layer that can be blended in. Usually the video output is handled through the video4linux API and the graphics through fbdev. Using drm is not yet common for SoC (I can't remember seeing anything of that kind, but I never actively looked for it either). With the increasing complexity of SoC graphics parts I am sure drm will become much more relevant. A separate issue is memory handling. V4L and graphics drivers share similar problems. It's my intention to start looking into this some time next year. It all seems quite messy at the moment. Regards, Hans On Friday, November 12, 2010 17:46:53 Marcus LORENTZON wrote: > Hi Alex, > Do you have any idea of how we should use KMS without being a "real" drm 3D > device? Do you mean that we should use the KMS ioctls on for display driver? > Or do you mean that we should expose a /dev/drmX device only capable of KMS > and no GEM? > > What if we were to add a drm driver for 3D later on. Is it possible to have a > separate drm device for display and one for 3D, but still share "GEM" like > buffers between these devices? It look like GEM handles are device relative. > This is a vital use case for us. And we really don't like to entangle our > MCDE display driver, memory manager and 3D driver without a good reason. > Today they are maintained as independent drivers without code dependencies. > Would this still be possible using drm? Or does drm require memory manager, > 3D and display to be one driver? I can see the drm=graphics card on desktop > machines. But embedded UMA systems doesn't really have this dependency. You > can switch memory mamanger, 3D driver, display manager in menuconfig > independently of the other drivers. Not that it's used like that on one > particular HW, but for different HW you can use different parts. In drm it > looks like all these pieces belong together. > > Do you think the driver should live in the "gpu/drm" folder, even though it's > not a gpu driver? > > Do you know of any other driver that use DRM/KMS API but not being a PC-style > graphics card that we could look at for inspiration? > > And GEM, is that the only way of exposing graphics buffers to user space in > drm? Or is it possible (is it ok) to expose another similar API? You > mentioned that there are TTM and GEM, do both expose user space APIs for > things like sharing buffers between processes, security, cache management, > defragmentation? Or are these type of features defined by DRM and not TTM/GEM? > > /BR > /Marcus > > > -Original Message- > > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > > Sent: den 12 november 2010 16:53 > > To: Jimmy RUBIN > > Cc: linux-fb...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > linux-media@vger.kernel.org; Linus WALLEIJ; Dan JOHANSSON; Marcus > > LORENTZON > > Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver > > > > On Fri, Nov 12, 2010 at 8:18 AM, Jimmy RUBIN > > wrote: > > > Hi Alex, > > > > > > Good point, we are looking at this for possible future improvements > > but for the moment we feel like > > > the structure of drm does not add any simplifications for our driver. > > We have the display manager (MCDE DSS = KMS) and the memory manager > > (HWMEM = GEM) that could be migrated to drm framework. But we do not > > have drm drivers for 3D hw and this also makes drm a less obvious > > choice at the moment. > > > > > > > You don't have to use the drm strictly for 3D hardware. historically > > that's why it was written, but with kms, it also provides an interface > > for complex display systems. fbdev doesn't really deal properly with > > multiple display controllers or connectors that are dynamically > > re-routeable at runtime. I've seen a lot of gross hacks to fbdev to > > support this kind of stuff in the past, so it'd be nice to use the > > interface we now have for it if you need that functionality. > > Additionally, you can use the shared memory manager to both the > > display side and v4l side. While the current drm drivers use GEM > > externally, there's no requirement that a kms driver has to use GEM. > > radeon and nouveau use ttm internally for example. Something to > > consider. I just want to make sure people are aware of the interface > > and what it's capable of. > > > > Alex > > > > > Jimmy > > > > > > -Original Message- > > > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > > > Sent: den 10 november 2010 15:43 > > > To: Jimmy RUBIN > > > Cc: linux-fb...@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; linux-media@vger.kernel.org; Linus WALLEIJ; > > Dan JOHANSSON > > > Subject: Re: [PATCH 00/10] MCDE: Add frame buffer device driver > > > > > > On Wed, Nov 10, 2010 at 7:04 AM, Jimmy Rubin > > wrote: > > >> These set of patches contains
[GIT PATCHES FOR 2.6.38] gspca for_2.6.38
The following changes since commit af9f14f7fc31f0d7b7cdf8f7f7f15a3c3794aea3: [media] IR: add tv power scancode to rc6 mce keymap (2010-11-10 00:58:49 -0200) are available in the git repository at: git://linuxtv.org/jfrancois/gspca.git for_2.6.38 Jean-François Moine (16): gspca - ov519: Handle the snapshot on capture stop when CONFIG_INPUT=m gspca - ov519: Don't do USB exchanges after disconnection gspca - ov519: Change types '__xx' to 'xx' gspca - ov519: Reduce the size of some variables gspca - ov519: Define the sensor types in an enum gspca - ov519: Cleanup source gspca - ov519: Set their numbers in the ov519 and ov7670 register names gspca - ov519: Define the disabled controls in a table gspca - ov519: Propagate errors to higher level gspca - ov519: Clearer debug and error messages gspca - ov519: Check the disabled controls at start time only gspca - ov519: Simplify the LED control functions gspca - ov519: Change the ov519 start and stop sequences gspca - ov519: Initialize the ov519 snapshot register gspca - ov519: Re-initialize the webcam at resume time gspca - ov519: New sensor ov7660 with bridge ov530 (ov519) Nicolas Kaiser (1): gspca - cpia1: Fix error check drivers/media/video/gspca/cpia1.c |2 +- drivers/media/video/gspca/ov519.c | 1671 +-- drivers/media/video/gspca/w996Xcf.c | 325 +++ 3 files changed, 1131 insertions(+), 867 deletions(-) -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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
