Re: IR remote control autorepeat / evdev
On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: Em 12-05-2011 02:37, Anssi Hannula escreveu: I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. - Subject: Use a more consistent value for RC repeat period From: Mauro Carvalho Chehab mche...@redhat.com The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index f53f9c6..ee67169 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) */ dev-input_dev-rep[REP_DELAY] = 500; + /* + * As a repeat event on protocols like RC-5 and NEC take as long as + * 110/114ms, using 33ms as a repeat period is not the right thing + * to do. + */ + dev-input_dev-rep[REP_PERIOD] = 125; + path = kobject_get_path(dev-dev.kobj, GFP_KERNEL); printk(KERN_INFO %s: %s as %s\n, dev_name(dev-dev), so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a client to set the repeat rate would provide the same solution - for those clients/devices affected. The interesting question is how clients would identify the devices that are affected by this (other than trial and error). Cheers, Peter -- 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 is there no enum_input in v4l2_subdev_video_ops
Hi Scott, On Wednesday 11 May 2011 10:43:30 Jiang, Scott wrote: On Tue, May 10, 2011 at 5:51 PM, Laurent Pinchart wrote: On Tuesday 10 May 2011 08:14:10 Hans Verkuil wrote: On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart wrote: Why is there no enum_input operation in v4l2_subdev_video_ops? Why do you need one ? Because I want to query decoder how many inputs it can support. So the question is where we should store inputs info, board specific data or decoder driver? I appreciate your advice. ENUMINPUT as defined by V4L2 enumerates input connectors available on the board. Which inputs the board designer hooked up is something that only the top-level V4L driver will know. Subdevices do not have that information, so enuminputs is not applicable there. Of course, subdevices do have input pins and output pins, but these are assumed to be fixed. With the s_routing ops the top level driver selects which input and output pins are active. Enumeration of those inputs and outputs wouldn't gain you anything as far as I can tell since the subdevice simply does not know which inputs/outputs are actually hooked up. It's the top level driver that has that information (usually passed in through board/card info structures). I agree. Subdevs don't have enough knowledge of their surroundings to make input enumeration really useful. They could enumerate their input pins, but not the inputs that are actually hooked up on board. The media controller framework is one way of solving this issue. It can report links for every input pad. Scott, can you tell us a bit more about the decoder you're working with ? What kind of system is it used in ? I'm working on ADV7183 and VS6624 connecting with blackfin through ppi. Enumerating inputs only matters for the ADV7183. The issue is that the adv7183 driver doesn't know how its inputs are routed on the board. I see several solutions to fix this issue. - Create an adv7183 platform data structure, and fill it in board code with input routing information. The adv7183 driver can use that information to implement a (to be added) enum_input operation. I don't really like this solution, as the adv7183 really shouldn't care about how video signals are routed on the board. Definitely not. - Pass the same information to the master v4l2_device driver that instantiates the adv7183. The information can then be used to implement the G_INPUT ioctl, or for internal purpose. You won't need any enum_input subdev operation in that case. This is the way to do it. The TI davinci drivers do this, for example. - Use the media controller API to expose routing information to userspace. Like in the previous solution, board code would pass input routing information to the v4l2_device driver that would use use to create links. Links will then be enumerable and configurable by userspace. This does not work (yet), since this would require the MC to have connector entities which we do not have (yet). We will need them for ALSA, and I think we also need them for V4L, but for V4L we need to figure out the relationship between the _INPUT and _OUTPUT V4L2 ioctls and a MC with connector entities first. Regards, Hans By the way, ppi is a generic parallel interface, that means it can't know the fmt supported itself. Should I use enum_mbus_fmt to ask decoder for this info? I found it in v4l2_subdev_video_ops, but didn't know its usage exactly. The enum_mbus_fmt can be used for that purpose, yes. You can use it to query the ADV7183 and VS6624 for their supported formats. You can also query the current format with g_mbus_fmt. If you want to implement the media controller API, you should go for the pad- level operations instead of enum_mbus_fmt/g_mbus_fmt (available in 2.6.39). -- 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 -- 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: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. 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: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. Honza -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Signed-off-by: Josh Wu josh...@atmel.com --- base on branch staging/for_v2.6.40 arch/arm/mach-at91/include/mach/at91_isi.h | 454 drivers/media/video/Kconfig| 10 + drivers/media/video/Makefile |1 + drivers/media/video/atmel-isi.c| 1089 4 files changed, 1554 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h create mode 100644 drivers/media/video/atmel-isi.c diff --git a/arch/arm/mach-at91/include/mach/at91_isi.h b/arch/arm/mach-at91/include/mach/at91_isi.h new file mode 100644 index 000..3219358 --- /dev/null +++ b/arch/arm/mach-at91/include/mach/at91_isi.h @@ -0,0 +1,454 @@ +/* + * Register definitions for the Atmel Image Sensor Interface. + * + * Copyright (C) 2011 Atmel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __AT91_ISI_H__ +#define __AT91_ISI_H__ + +#include linux/videodev2.h +#include linux/i2c.h +#include media/v4l2-device.h +#include media/v4l2-common.h +#include media/v4l2-ioctl.h +#include media/v4l2-chip-ident.h + +/* ISI register offsets */ +#define ISI_CR10x +#define ISI_CR20x0004 +#define ISI_SR 0x0008 +#define ISI_IER0x000c +#define ISI_IDR0x0010 +#define ISI_IMR0x0014 +#define ISI_PSIZE 0x0020 +#define ISI_PDECF 0x0024 +#define ISI_PPFBD 0x0028 +#define ISI_CDBA 0x002c +#define ISI_Y2R_SET0 0x0030 +#define ISI_Y2R_SET1 0x0034 +#define ISI_R2Y_SET0 0x0038 +#define ISI_R2Y_SET1 0x003c +#define ISI_R2Y_SET2 0x0040 + +/* ISI_V2 register offsets */ +#define ISI_V2_CFG10x +#define ISI_V2_CFG20x0004 +#define ISI_V2_PSIZE 0x0008 +#define ISI_V2_PDECF 0x000c +#define ISI_V2_Y2R_SET00x0010 +#define ISI_V2_Y2R_SET10x0014 +#define ISI_V2_R2Y_SET00x0018 +#define ISI_V2_R2Y_SET10x001C +#define ISI_V2_R2Y_SET20x0020 +#define ISI_V2_CTRL0x0024 +#define ISI_V2_STATUS 0x0028 +#define ISI_V2_INTEN 0x002C +#define ISI_V2_INTDIS 0x0030 +#define ISI_V2_INTMASK 0x0034 +#define ISI_V2_DMA_CHER0x0038 +#define ISI_V2_DMA_CHDR0x003C +#define ISI_V2_DMA_CHSR0x0040 +#define ISI_V2_DMA_P_ADDR 0x0044 +#define ISI_V2_DMA_P_CTRL 0x0048 +#define ISI_V2_DMA_P_DSCR 0x004C +#define ISI_V2_DMA_C_ADDR 0x0050 +#define ISI_V2_DMA_C_CTRL 0x0054 +#define ISI_V2_DMA_C_DSCR 0x0058 + +/* Bitfields in CR1 */ +#define ISI_RST_OFFSET 0 +#define ISI_RST_SIZE 1 +#define ISI_DIS_OFFSET 1 +#define ISI_DIS_SIZE 1 +#define ISI_HSYNC_POL_OFFSET 2 +#define ISI_HSYNC_POL_SIZE 1 +#define ISI_VSYNC_POL_OFFSET 3 +#define ISI_VSYNC_POL_SIZE 1 +#define ISI_PIXCLK_POL_OFFSET 4 +#define ISI_PIXCLK_POL_SIZE1 +#define ISI_EMB_SYNC_OFFSET6 +#define ISI_EMB_SYNC_SIZE 1 +#define ISI_CRC_SYNC_OFFSET7 +#define ISI_CRC_SYNC_SIZE 1 +#define ISI_FRATE_OFFSET 8 +#define ISI_FRATE_SIZE 3 +#define ISI_FULL_OFFSET12 +#define ISI_FULL_SIZE 1 +#define ISI_THMASK_OFFSET 13 +#define ISI_THMASK_SIZE2 +#define ISI_CODEC_ON_OFFSET15 +#define ISI_CODEC_ON_SIZE 1 +#define ISI_SLD_OFFSET 16 +#define ISI_SLD_SIZE 8
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote: +err_alloc_isi: + clk_disable(pclk); clk_put() ? -- 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: Problems of Pinnacle PCTV Hybrid pro stick in linux
Hello all Is there anyone could find the source of problems described below? http://daftar.minidns.net/pctv/problem.html On Mon, May 9, 2011 at 3:08 PM, a baffian mjnh...@gmail.com wrote: Hello all, Can anyone help to solve the problems of linux driver of Pinnacle PCTV Hybrid pro stick ? It is an em28xx based hybride (digital and analog TV) USB adapter. i wrote the complete story of my experiences with it, and its problems in http://daftar.minidns.net/pctv/problem.html Good Luck -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI)support
Hi, Russell From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, May 12, 2011 3:47 PM On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote: +err_alloc_isi: +clk_disable(pclk); clk_put() ? Ok, will be fixed in V2 patch. Thanks. Best Regards, Josh Wu -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI)support
On Thu, 12 May 2011, Wu, Josh wrote: Hi, Russell From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, May 12, 2011 3:47 PM On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote: +err_alloc_isi: + clk_disable(pclk); clk_put() ? Ok, will be fixed in V2 patch. Thanks. You might wait with v2 until I find time to review your patch. Will take a couple of days, I think. A general question, though: how compatible is this driver with the AVR32? 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] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote:
This patch is to enable Atmel Image Sensor Interface (ISI) driver support.
- Using soc-camera framework with videobuf2 dma-contig allocator
- Supporting video streaming of YUV packed format
- Tested on AT91SAM9M10G45-EK with OV2640
A few more points...
+static int __init atmel_isi_probe(struct platform_device *pdev)
Should be __devinit otherwise you'll have section errors.
+{
+ unsigned int irq;
+ struct atmel_isi *isi;
+ struct clk *pclk;
+ struct resource *regs;
+ int ret;
+ struct device *dev = pdev-dev;
+ struct isi_platform_data *pdata;
+ struct soc_camera_host *soc_host;
+
+ regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!regs)
+ return -ENXIO;
+
+ pclk = clk_get(pdev-dev, isi_clk);
+ if (IS_ERR(pclk))
+ return PTR_ERR(pclk);
+
+ clk_enable(pclk);
Return value of clk_enable() should be checked.
+
+ isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
+ if (!isi) {
+ ret = -ENOMEM;
+ dev_err(pdev-dev, can't allocate interface!\n);
+ goto err_alloc_isi;
+ }
+
+ isi-pclk = pclk;
+
+ spin_lock_init(isi-lock);
+ init_waitqueue_head(isi-capture_wq);
+
+ isi-alloc_ctx = vb2_dma_contig_init_ctx(pdev-dev);
+ if (IS_ERR(isi-alloc_ctx)) {
+ ret = PTR_ERR(isi-alloc_ctx);
+ goto err_alloc_isi;
+ }
+
+ isi-regs = ioremap(regs-start, resource_size(regs));
+ if (!isi-regs) {
+ ret = -ENOMEM;
+ goto err_ioremap;
+ }
+
+ if (dev-platform_data)
+ pdata = (struct isi_platform_data *) dev-platform_data;
+ else {
+ static struct isi_platform_data isi_default_data = {
+ .frate = 0,
+ .has_emb_sync = 0,
+ .emb_crc_sync = 0,
+ .hsync_act_low = 0,
+ .vsync_act_low = 0,
+ .pclk_act_falling = 0,
+ .isi_full_mode = 1,
+ /* to use codec and preview path simultaneously */
+ .flags = ISI_DATAWIDTH_8 |
+ ISI_DATAWIDTH_10,
+ };
+ dev_info(pdev-dev,
+ No config available using default values\n);
+ pdata = isi_default_data;
+ }
+
+ isi-pdata = pdata;
+ isi-platform_flags = pdata-flags;
+ if (isi-platform_flags == 0)
+ isi-platform_flags = ISI_DATAWIDTH_8;
+
+ isi_writel(isi, V2_CTRL, ISI_BIT(V2_DIS));
+ /* Check if module disable */
+ while (isi_readl(isi, V2_STATUS) ISI_BIT(V2_DIS))
+ cpu_relax();
+
+ irq = platform_get_irq(pdev, 0);
This should also be checked.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI)support
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de] Sent: Thursday, May 12, 2011 5:32 PM On Thu, 12 May 2011, Wu, Josh wrote: Hi, Russell From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] Sent: Thursday, May 12, 2011 3:47 PM On Thu, May 12, 2011 at 03:42:18PM +0800, Josh Wu wrote: +err_alloc_isi: + clk_disable(pclk); clk_put() ? Ok, will be fixed in V2 patch. Thanks. You might wait with v2 until I find time to review your patch. Will take a couple of days, I think. A general question, though: how compatible is this driver with the AVR32? That is ok. For AVR32, I think I need time to check with AVR team. I will update the status when I got more information. Best Regards, Josh Wu -- 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: [linux-dvb] TeVii S470 (cx23885 / ds3000) makes the machine unstable
Monday, May 9, 2011, 7:39:09 PM, you wrote: I still have this very annoying issue. I see no obvious reason, but my DVB-S card just stops locking the signal, I get really a lot of these errors in my syslog: May 9 19:04:33 localhost kernel: ds3000_readreg: reg=0xd(error=-5) May 9 19:04:33 localhost kernel: ds3000_writereg: writereg error(err == -5, reg == 0x03, value == 0x12) May 9 19:04:33 localhost kernel: ds3000_tuner_readreg: reg=0x3d(error=-5) May 9 19:04:33 localhost kernel: ds3000_writereg: writereg error(err == -5, reg == 0x03, value == 0x12) May 9 19:04:33 localhost kernel: ds3000_tuner_readreg: reg=0x21(error=-5) May 9 19:04:33 localhost kernel: ds3000_readreg: reg=0x8c(error=-5) May 9 19:04:33 localhost kernel: ds3000_readreg: reg=0x8d(error=-5) and then the machine just freezes. Could it be some buffer overflow? How could I track it? The machine is perfectly stable when S470 card is out... Sorry for replying to my own's post, as I just want to make this information available in case someone would find this mail thread later. The issue appear to be related to S470 overheating. I discovered that my S470 became very-very hot right after I power the machine up, and recently it started to freeze right after the boot. So the board was shipped to the dealer for tests / exchange, and my machine is back to normal operation (without a DVB-S2 card, temporarily). My friend's board is slightly cooler - so putting a fan blowing directly on the board seem to solve the problem for him completely (no freezes for three days now). So it's very likely to be hardware-related, and not a driver / configuration issue. -- Best regards, Andrew -- 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: dvb-core/dvb_frontend.c: Synchronizing legacy and new tuning API
HoP jpetr...@gmail.com writes: 2011/5/12 Bjørn Mork bj...@mork.no: Andreas Oberritter o...@linuxtv.org writes: Please try the patches submitted for testing: http://www.mail-archive.com/linux-media@vger.kernel.org/msg31194.html Ah, great! Thanks. Nothing better than a problem already solved. Not solved. Andreas did an attempt to solve it (at least as far as I know patches not get accepted yet), so please report your result of testing. Sure. Now, the only machine I've got with DVB cards is running a stock Debian 2.6.32 kernel and I prefer not to mess with that. But I did a quick-n-dirty backport of the API changes to 2.6.32, built a new dvb_core module and loaded that. And the results are good, as expected. All parameters are now in sync. Both these adapters have been tuned by VDR (which uses the new API): bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter0/frontend0 == /dev/dvb/adapter0/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 264006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 264006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) bjorn@canardo:/usr/local/src/git/linux-2.6$ /tmp/dvb_fe_test /dev/dvb/adapter1/frontend0 == /dev/dvb/adapter1/frontend0 == name: Philips TDA10023 DVB-C type: FE_QAM == FE_GET_FRONTEND == frequency : 272006739 inversion : off (0) symbol_rate : 690 fec_inner : FEC_NONE (0) modulation: QAM_256 (5) == FE_GET_PROPERTY == [17] DTV_DELIVERY_SYSTEM : SYS_DVBC_ANNEX_AC (1) [03] DTV_FREQUENCY : 272006739 [06] DTV_INVERSION : off (0) [08] DTV_SYMBOL_RATE : 690 [09] DTV_INNER_FEC : FEC_NONE (0) [04] DTV_MODULATION : QAM_256 (5) [35] DTV_API_VERSION : 5.1 [05] DTV_BANDWIDTH_HZ: BANDWIDTH_AUTO (3) I've obviously messed up the API_VERSION, so this is probably more dirty than quick But all the important values, like frequency, inversion and inner_fec, are now in sync. Thanks a lot. Feel free to add Tested-by: Bjørn Mork bj...@mork.no to the whole patch series if that matters to anyone. I'd really like this to go into 2.6.40 if that is possible. It would have been nice to see it in 2.6.32-longerm was well, but I guess that's out of the question since it builds on top of other API changes (DVBT2). 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: ngene CI problems
On 11/05/2011 20:59, Oliver Endriss wrote: I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 CU Oliver Great! Will give it a try tonight and report. Thx, -- Issa -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
+struct atmel_isi;
do we really this here?
+
+enum atmel_isi_pixfmt {
+ ATMEL_ISI_PIXFMT_GREY, /* Greyscale */
+ ATMEL_ISI_PIXFMT_CbYCrY,
+ ATMEL_ISI_PIXFMT_CrYCbY,
+ ATMEL_ISI_PIXFMT_YCbYCr,
+ ATMEL_ISI_PIXFMT_YCrYCb,
+ ATMEL_ISI_PIXFMT_RGB24,
+ ATMEL_ISI_PIXFMT_BGR24,
+ ATMEL_ISI_PIXFMT_RGB16,
+ ATMEL_ISI_PIXFMT_BGR16,
+ ATMEL_ISI_PIXFMT_GRB16, /* G[2:0] R[4:0]/B[4:0] G[5:3] */
+ ATMEL_ISI_PIXFMT_GBR16, /* G[2:0] B[4:0]/R[4:0] G[5:3] */
+ ATMEL_ISI_PIXFMT_RGB24_REV,
+ ATMEL_ISI_PIXFMT_BGR24_REV,
+ ATMEL_ISI_PIXFMT_RGB16_REV,
+ ATMEL_ISI_PIXFMT_BGR16_REV,
+ ATMEL_ISI_PIXFMT_GRB16_REV, /* G[2:0] R[4:0]/B[4:0] G[5:3] */
+ ATMEL_ISI_PIXFMT_GBR16_REV, /* G[2:0] B[4:0]/R[4:0] G[5:3] */
+};
+
+struct isi_platform_data {
+ u8 has_emb_sync;
+ u8 emb_crc_sync;
+ u8 hsync_act_low;
+ u8 vsync_act_low;
+ u8 pclk_act_falling;
+ u8 isi_full_mode;
+#define ISI_HSYNC_ACT_LOW0x01
+#define ISI_VSYNC_ACT_LOW0x02
+#define ISI_PXCLK_ACT_FALLING0x04
+#define ISI_EMB_SYNC 0x08
+#define ISI_CRC_SYNC 0x10
+#define ISI_FULL 0x20
+#define ISI_DATAWIDTH_8 0x40
+#define ISI_DATAWIDTH_10 0x80
+ u32 flags;
+ u8 gs_mode;
+#define ISI_GS_2PIX_PER_WORD 0x00
+#define ISI_GS_1PIX_PER_WORD 0x01
+ u8 pixfmt;
+ u8 sfd;
+ u8 sld;
+ u8 thmask;
+#define ISI_BURST_4_8_16 0x00
+#define ISI_BURST_8_16 0x01
+#define ISI_BURST_16 0x02
+ u8 frate;
+#define ISI_FRATE_DIV_2 0x01
+#define ISI_FRATE_DIV_3 0x02
+#define ISI_FRATE_DIV_4 0x03
+#define ISI_FRATE_DIV_5 0x04
+#define ISI_FRATE_DIV_6 0x05
+#define ISI_FRATE_DIV_7 0x06
+#define ISI_FRATE_DIV_8 0x07
+};
+
+#endif /* __AT91_ISI_H__ */
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index d61414e..eae6005 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -80,6 +80,16 @@ menuconfig VIDEO_CAPTURE_DRIVERS
Some of those devices also supports FM radio.
if VIDEO_CAPTURE_DRIVERS VIDEO_V4L2
+config VIDEO_ATMEL_ISI
+ tristate ATMEL Image Sensor Interface (ISI) support
+ depends on VIDEO_DEV SOC_CAMERA
depends on AT91 if the drivers is at91 specific or avr32 otherwise
+ select VIDEOBUF2_DMA_CONTIG
+ default n
it's n by default please remove
+ ---help---
+ This module makes the ATMEL Image Sensor Interface available
+ as a v4l2 device.
+ Say Y here to enable selecting the Image Sensor Interface.
+ When in doubt, say N.
config VIDEO_ADV_DEBUG
bool Enable advanced debug functionality
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index a10e4c3..f734a65 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -166,6 +166,7 @@ obj-$(CONFIG_VIDEO_SH_MOBILE_CSI2)+=
sh_mobile_csi2.o
obj-$(CONFIG_VIDEO_SH_MOBILE_CEU)+= sh_mobile_ceu_camera.o
obj-$(CONFIG_VIDEO_OMAP1)+= omap1_camera.o
obj-$(CONFIG_VIDEO_SAMSUNG_S5P_FIMC) += s5p-fimc/
+obj-$(CONFIG_VIDEO_ATMEL_ISI)+= atmel-isi.o
obj-$(CONFIG_ARCH_DAVINCI) += davinci/
diff --git a/drivers/media/video/atmel-isi.c b/drivers/media/video/atmel-isi.c
new file mode 100644
index 000..33d0b83
--- /dev/null
+++ b/drivers/media/video/atmel-isi.c
@@ -0,0 +1,1089 @@
+/*
+ * Copyright (c) 2011 Atmel Corporation
+ *
+ * Based on previous work by Lars Haring and Sedji Gaouaou
+ *
+ * Based on the bttv driver for Bt848 with respective copyright holders
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/clk.h
+#include linux/completion.h
+#include linux/fs.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/moduleparam.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/version.h
+#include linux/kfifo.h
+
+#include mach/board.h
+#include mach/cpu.h
+#include mach/at91_isi.h
+
+#include media/videobuf2-dma-contig.h
+#include media/soc_camera.h
+#include media/soc_mediabus.h
+
+#define ATMEL_ISI_VERSIONKERNEL_VERSION(1, 0, 0)
+#define MAX_BUFFER_NUMS 32
+#define MAX_SUPPORT_WIDTH2048
+#define MAX_SUPPORT_HEIGHT 2048
+
+static unsigned int vid_limit = 16;
+
+enum isi_buffer_state {
+ ISI_BUF_NEEDS_INIT,
+ ISI_BUF_PREPARED,
+};
+
+/* Single frame capturing states */
+enum {
+ STATE_IDLE = 0,
+ STATE_CAPTURE_READY,
+ STATE_CAPTURE_WAIT_SOF,
+ STATE_CAPTURE_IN_PROGRESS,
+
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On Thu, 12 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote: [snip] + if (0 == *nbuffers) please invert the test Don't think this is required by CodingStyle or anything like that. If it were, you'd have to revamp half of the kernel. 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: IR remote control autorepeat / evdev
Peter Hutterer wrote: On Thu, May 12, 2011 at 03:36:47AM +0200, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: Em 12-05-2011 02:37, Anssi Hannula escreveu: I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. - Subject: Use a more consistent value for RC repeat period From: Mauro Carvalho Chehabmche...@redhat.com The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: Mauro Carvalho Chehabmche...@redhat.com diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index f53f9c6..ee67169 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) */ dev-input_dev-rep[REP_DELAY] = 500; + /* +* As a repeat event on protocols like RC-5 and NEC take as long as +* 110/114ms, using 33ms as a repeat period is not the right thing +* to do. +*/ + dev-input_dev-rep[REP_PERIOD] = 125; + path = kobject_get_path(dev-dev.kobj, GFP_KERNEL); printk(KERN_INFO %s: %s as %s\n, dev_name(dev-dev), so if I get this right, a XkbSetControls(.. XkbRepeatKeysMask ...) by a client to set the repeat rate would provide the same solution - for those clients/devices affected. The interesting question is how clients would identify the devices that are affected by this (other than trial and error). ir-keytable in v4l-utils is able to identify rc event devices by way of prodding in /sys/class/rc/, but I'm assuming that means every client would have to grow insight into how to do the same. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Help needed: Anysee E30C Plus (DVB-C Tuner)
Hi I am new to this mailing list, so bare with me if this have been asked before. I have just bought an Anysee E30C Plus, as I had read, that this device is supported in Linux, my plan is building a Mythtv media center, to replace my old harddisk recorder. However I cannot get it to work, and then I read thatt the newest version might not work, and that I should join this list. I have tried to compile a new kernel with the newest dvb stuff from the git repository, just to make sure, that I have the newest drivers. I have alsio blacklistet the zl10353 module to avoid the device being loaded as an DVB-T device (which it is not, it is a cable only version). What information do you need me to obtain, or do you have a hint to how I might get this working? The device is reconnized OK as seen here from dmesg: [ 11.354973] dvb-usb: found a 'Anysee DVB USB2.0' in warm state. [ 11.355004] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 11.355239] DVB: registering new adapter (Anysee DVB USB2.0) [ 11.356661] anysee: firmware version:0.1.2 hardware id:15 [ 11.391192] IR NEC protocol handler initialized [ 11.412221] IR RC5(x) protocol handler initialized [ 11.412611] DVB: Unable to find symbol zl10353_attach() [ 11.414527] DVB: Unable to find symbol zl10353_attach() [ 11.417536] DVB: registering adapter 1 frontend 0 (Philips TDA10023 DVB-C)... [ 11.430950] IR RC6 protocol handler initialized [ 11.553821] IR JVC protocol handler initialized [ 11.555642] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb2/2-5/input/input6 [ 11.555682] dvb-usb: schedule remote query interval to 200 msecs. [ 11.555689] dvb-usb: Anysee DVB USB2.0 successfully initialized and connected. [ 11.557207] usbcore: registered new interface driver dvb_usb_anysee [ 11.569445] IR Sony protocol handler initialized [ 11.584259] lirc_dev: IR Remote Control driver registered, major 251 [ 11.586747] IR LIRC bridge handler initialized but lsusb reports this as an DVB-T Device: tux3:~ # lsusb -s 002:002 -v Bus 002 Device 002: ID 1c73:861f AMT Anysee E30 USB 2.0 DVB-T Receiver Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x1c73 AMT idProduct 0x861f Anysee E30 USB 2.0 DVB-T Receiver bcdDevice1.00 iManufacturer 1 AMT.CO.KR iProduct2 anysee-FA(LP) iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 83 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 4 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 1 bNumEndpoints
[PATCH] ngene: blocking and nonblocking io for sec0
Patch allows for blocking or nonblocking io on the ngene sec0 device.
It also enforces one reader and one writer at a time.
Signed-off-by: Issa Gorissen flo...@usa.net
--
--- a/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-10 19:11:21.0
+0200
+++ b/linux/drivers/media/dvb/ngene/ngene-dvb.c 2011-05-12 15:28:53.573185365
+0200
@@ -53,15 +53,29 @@ static ssize_t ts_write(struct file *fil
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- if (wait_event_interruptible(dev-tsout_rbuf.queue,
-dvb_ringbuffer_free
-(dev-tsout_rbuf) = count) 0)
+ if (!count)
return 0;
- dvb_ringbuffer_write(dev-tsout_rbuf, buf, count);
+ if (nonblock) {
+ avail = dvb_ringbuffer_avail(dev-tsout_rbuf);
+ if (!avail)
+ return -EAGAIN;
+ } else {
+ while (1) {
+ if (wait_event_interruptible(dev-tsout_rbuf.queue,
+dvb_ringbuffer_free
+(dev-tsout_rbuf) =
count) = 0)
+ break;
+ }
+ avail = count;
+ }
+
+ dvb_ringbuffer_write(dev-tsout_rbuf, buf, avail);
+ return avail;
- return count;
}
static ssize_t ts_read(struct file *file, char *buf,
@@ -70,22 +84,35 @@ static ssize_t ts_read(struct file *file
struct dvb_device *dvbdev = file-private_data;
struct ngene_channel *chan = dvbdev-priv;
struct ngene *dev = chan-dev;
- int left, avail;
+ int avail = 0;
+ char nonblock = file-f_flags O_NONBLOCK;
- left = count;
- while (left) {
- if (wait_event_interruptible(
- dev-tsin_rbuf.queue,
- dvb_ringbuffer_avail(dev-tsin_rbuf) 0) 0)
- return -EAGAIN;
+ if (!count)
+ return 0;
+
+ if (nonblock) {
avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
- if (avail left)
- avail = left;
- dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
- left -= avail;
- buf += avail;
+ } else {
+ while (!avail) {
+ if (wait_event_interruptible(
+ dev-tsin_rbuf.queue,
+ dvb_ringbuffer_avail(dev-tsin_rbuf) 0)
0)
+ continue;
+
+ avail = dvb_ringbuffer_avail(dev-tsin_rbuf);
+ }
}
- return count;
+
+ if (avail count)
+ avail = count;
+ if (avail 0)
+ dvb_ringbuffer_read_user(dev-tsin_rbuf, buf, avail);
+
+ if (!avail)
+ return -EAGAIN;
+ else
+ return avail;
+
}
static const struct file_operations ci_fops = {
@@ -98,9 +125,9 @@ static const struct file_operations ci_f
struct dvb_device ngene_dvbdev_ci = {
.priv= 0,
- .readers = -1,
- .writers = -1,
- .users = -1,
+ .readers = 1,
+ .writers = 1,
+ .users = 2,
.fops= ci_fops,
};
--
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: Help needed: Anysee E30C Plus (DVB-C Tuner)
On 05/12/2011 04:27 PM, Per Kofod wrote: Hi I am new to this mailing list, so bare with me if this have been asked before. I have just bought an Anysee E30C Plus, as I had read, that this device is supported in Linux, my plan is building a Mythtv media center, to replace my old harddisk recorder. However I cannot get it to work, and then I read thatt the newest version might not work, and that I should join this list. I have tried to compile a new kernel with the newest dvb stuff from the git repository, just to make sure, that I have the newest drivers. I have alsio blacklistet the zl10353 module to avoid the device being loaded as an DVB-T device (which it is not, it is a cable only version). What information do you need me to obtain, or do you have a hint to how I might get this working? The device is reconnized OK as seen here from dmesg: [ 11.354973] dvb-usb: found a 'Anysee DVB USB2.0' in warm state. [ 11.355004] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 11.355239] DVB: registering new adapter (Anysee DVB USB2.0) [ 11.356661] anysee: firmware version:0.1.2 hardware id:15 For the some reason hardware ID 15 does not work on latest Ubuntu 11.04. That is basically E30 Combo Plus and newer E30 C Plus, which is same device as E30 Combo Plus but without DVB-T demod. Install latest drivers and it will work. And I hope someone have time to examine why it does not work anymore out-of-the-box in Ubuntu 11.04. http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Antti -- 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
Re: Bug in HVR1300. Found part of a patch, if reverted
Hi there in the latest kernel (and all those since when the patch was written) this patch is still required for the HVR-1300 to work, any chance of it getting incorporated? thanks Mike Hi list, there seems to be a bug in cx88 (HVR1300) that is responsible for not switching channels, and not being able to scan. Complete description can be found on launchpad: https://bugs.launchpad.net/mythtv/+bug/439163 (starting from comment #16) Anyway, i digged it down to this patch: http://www.mail-archive.com/linuxtv-commits@xxx/msg02195.html When reverting the following part of the patch it starts working again: snip-- diff -r 576096447a45 -r d2eedb425718 linux/drivers/media/video/cx88/cx88-dvb.c - --- a/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:18 2008 - -0200 +++ b/linux/drivers/media/video/cx88/cx88-dvb.c Thu Dec 18 07:28:35 2008 - -0200 @@ -1135,40 +1135,44 @@ static int cx8802_dvb_advise_acquire(str * on the bus. Take the bus from the cx23416 and enable the * cx22702 demod */ - - cx_set(MO_GP0_IO, 0x0080); /* cx22702 out of reset and enable */ + /* Toggle reset on cx22702 leaving i2c active */ + cx_set(MO_GP0_IO, 0x0080); + udelay(1000); + cx_clear(MO_GP0_IO, 0x0080); + udelay(50); + cx_set(MO_GP0_IO, 0x0080); + udelay(1000); + /* enable the cx22702 pins */ cx_clear(MO_GP0_IO, 0x0004); udelay(1000); break; - -snip Regards Frank Sagurna -- 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: Help needed: Anysee E30C Plus (DVB-C Tuner)
Thanks, that worked. Actually I am not running ubuntu on this PC; but OpenSuSE 11.4; but I was planninh using Mythbuntu far my media center. Thanks a lot. Cheers Per On 05/12/2011 04:08 PM, Antti Palosaari wrote: On 05/12/2011 04:27 PM, Per Kofod wrote: Hi I am new to this mailing list, so bare with me if this have been asked before. I have just bought an Anysee E30C Plus, as I had read, that this device is supported in Linux, my plan is building a Mythtv media center, to replace my old harddisk recorder. However I cannot get it to work, and then I read thatt the newest version might not work, and that I should join this list. I have tried to compile a new kernel with the newest dvb stuff from the git repository, just to make sure, that I have the newest drivers. I have alsio blacklistet the zl10353 module to avoid the device being loaded as an DVB-T device (which it is not, it is a cable only version). What information do you need me to obtain, or do you have a hint to how I might get this working? The device is reconnized OK as seen here from dmesg: [ 11.354973] dvb-usb: found a 'Anysee DVB USB2.0' in warm state. [ 11.355004] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 11.355239] DVB: registering new adapter (Anysee DVB USB2.0) [ 11.356661] anysee: firmware version:0.1.2 hardware id:15 For the some reason hardware ID 15 does not work on latest Ubuntu 11.04. That is basically E30 Combo Plus and newer E30 C Plus, which is same device as E30 Combo Plus but without DVB-T demod. Install latest drivers and it will work. And I hope someone have time to examine why it does not work anymore out-of-the-box in Ubuntu 11.04. http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers 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
[GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch Hans de Goede (2): v4l: Add M420 format definition uvcvideo: Add M420 format support Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities drivers/media/video/uvc/Makefile |3 + drivers/media/video/uvc/uvc_driver.c | 71 ++-- drivers/media/video/uvc/uvc_entity.c | 118 ++ drivers/media/video/uvc/uvc_queue.c | 34 ++- drivers/media/video/uvc/uvc_v4l2.c | 17 + drivers/media/video/uvc/uvcvideo.h | 27 drivers/media/video/v4l2-dev.c | 18 + drivers/media/video/v4l2-device.c|5 +- include/linux/videodev2.h|1 + include/media/v4l2-dev.h |2 + 10 files changed, 287 insertions(+), 9 deletions(-) create mode 100644 drivers/media/video/uvc/uvc_entity.c -- 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: [GIT PATCH FOR 2.6.40] uvcvideo patches
Hi Mauro, On Thursday 12 May 2011 17:30:36 Laurent Pinchart wrote: Hi Mauro, The following changes since commit f9b51477fe540fb4c65a05027fdd6f2ecce4db3b: [media] DVB: return meaningful error codes in dvb_frontend (2011-05-09 05:47:20 +0200) are available in the git repository at: git://linuxtv.org/pinchartl/uvcvideo.git uvcvideo-next Bob Liu (2): Revert V4L/DVB: v4l2-dev: remove get_unmapped_area uvcvideo: Add support for NOMMU arch Hans de Goede (2): v4l: Add M420 format definition I forgot to add documentation for the new format. Please ignore the pull request, I'll resubmit it tomorrow. uvcvideo: Add M420 format support Laurent Pinchart (4): v4l: Release module if subdev registration fails uvcvideo: Register a v4l2_device uvcvideo: Register subdevices for each entity uvcvideo: Connect video devices to media entities drivers/media/video/uvc/Makefile |3 + drivers/media/video/uvc/uvc_driver.c | 71 ++-- drivers/media/video/uvc/uvc_entity.c | 118 ++ drivers/media/video/uvc/uvc_queue.c | 34 ++- drivers/media/video/uvc/uvc_v4l2.c | 17 + drivers/media/video/uvc/uvcvideo.h | 27 drivers/media/video/v4l2-dev.c | 18 + drivers/media/video/v4l2-device.c|5 +- include/linux/videodev2.h|1 + include/media/v4l2-dev.h |2 + 10 files changed, 287 insertions(+), 9 deletions(-) create mode 100644 drivers/media/video/uvc/uvc_entity.c -- 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: Audio Video synchronization for data received from a HDMI receiver chip
Which HDMI receiver chip? -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Bhupesh SHARMA Sent: Wednesday, May 11, 2011 10:49 PM To: linux-media@vger.kernel.org Cc: Laurent Pinchart; Guennadi Liakhovetski; Hans Verkuil Subject: Audio Video synchronization for data received from a HDMI receiver chip Hi Linux media folks, We are considering putting an advanced HDMI receiver chip on our SoC, to allow reception of HDMI audio and video. The chip receives HDMI data from a host like a set-up box or DVD player. It provides a video data interface and SPDIF/I2S audio data interface. We plan to support the HDMI video using the V4L2 framework and the HDMI audio using ALSA framework. Now, what seems to be intriguing us is how the audio-video synchronization will be maintained? Will a separate bridging entity required to ensure the same or whether this can be left upon a user space application like mplayer or gstreamer. Also is there a existing interface between the V4L2 and ALSA frameworks and the same can be used in our design? Regards, Bhupesh ST Microelectronics -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Help needed: Anysee E30C Plus (DVB-C Tuner)
Thanks for the report. I have now following matrix: not working: OpenSuSE 11.4 Kernel 2.6.37 Ubuntu 11.4 Kernel 2.6.38 working: Fedora 14 Kernel 2.6.35 regards Antti On 05/12/2011 05:35 PM, Per Kofod wrote: Thanks, that worked. Actually I am not running ubuntu on this PC; but OpenSuSE 11.4; but I was planninh using Mythbuntu far my media center. Thanks a lot. Cheers Per On 05/12/2011 04:08 PM, Antti Palosaari wrote: On 05/12/2011 04:27 PM, Per Kofod wrote: Hi I am new to this mailing list, so bare with me if this have been asked before. I have just bought an Anysee E30C Plus, as I had read, that this device is supported in Linux, my plan is building a Mythtv media center, to replace my old harddisk recorder. However I cannot get it to work, and then I read thatt the newest version might not work, and that I should join this list. I have tried to compile a new kernel with the newest dvb stuff from the git repository, just to make sure, that I have the newest drivers. I have alsio blacklistet the zl10353 module to avoid the device being loaded as an DVB-T device (which it is not, it is a cable only version). What information do you need me to obtain, or do you have a hint to how I might get this working? The device is reconnized OK as seen here from dmesg: [ 11.354973] dvb-usb: found a 'Anysee DVB USB2.0' in warm state. [ 11.355004] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 11.355239] DVB: registering new adapter (Anysee DVB USB2.0) [ 11.356661] anysee: firmware version:0.1.2 hardware id:15 For the some reason hardware ID 15 does not work on latest Ubuntu 11.04. That is basically E30 Combo Plus and newer E30 C Plus, which is same device as E30 Combo Plus but without DVB-T demod. Install latest drivers and it will work. And I hope someone have time to examine why it does not work anymore out-of-the-box in Ubuntu 11.04. http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers Antti -- 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
[cron job] v4l-dvb daily build: ERRORS
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:Thu May 12 19:02:02 CEST 2011 git hash:f9b51477fe540fb4c65a05027fdd6f2ecce4db3b gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: OK linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS spec-git: OK 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 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
digital tuner
I have an analog: Hauppauge WinTV-Go PLUS which has a lineout. I'm considering a digital card. The Hauppauge WinTV-HVR-1250 does NOT have a lineout so how does it do sound? Does PCIe pass through the sound to the OS sound system? I read on the linuxtv wiki that only the digital works on this card. -- 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.39] Fix subdev control enumeration
Hi Mauro, I haven't seen this fix appearing upstream, did it slip through the cracks? Regards, Hans On Monday, May 02, 2011 13:19:03 Hans Verkuil wrote: Hi Mauro, This fix is for 2.6.39. Control enumeration for subdev device nodes is broken. The fix is simple and has been tested by Sakari. Regards, Hans The following changes since commit 28df73703e738d8ae7a958350f74b08b2e9fe9ed: Mauro Carvalho Chehab (1): [media] xc5000: Improve it to work better with 6MHz-spaced channels are available in the git repository at: ssh://linuxtv.org/git/hverkuil/media_tree.git ctrl-fix Hans Verkuil (1): v4l2-subdev: fix broken subdev control enumeration drivers/media/video/v4l2-subdev.c | 14 +++--- 1 files changed, 7 insertions(+), 7 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 -- 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] tea575x: remove freq_fixup from struct
freq_fixup is a constant, no need to hold it in struct snd_tea575x and set in
each driver.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-10
22:31:40.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-12
21:00:50.0 +0200
@@ -26,6 +26,8 @@
#include media/v4l2-dev.h
#include media/v4l2-ioctl.h
+#define TEA575X_FMIF 10700
+
#define TEA575X_DATA (1 0)
#define TEA575X_CLK(1 1)
#define TEA575X_WREN (1 2)
@@ -46,7 +48,6 @@ struct snd_tea575x {
bool mute; /* Device is muted? */
bool stereo;/* receiving stereo */
bool tuned; /* tuned to a station */
- unsigned int freq_fixup;/* crystal onboard */
unsigned int val; /* hw value */
unsigned long freq; /* frequency */
unsigned long in_use; /* set if the device is in use */
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-10
22:31:40.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-05-12
21:00:37.0 +0200
@@ -141,9 +141,9 @@ static void snd_tea575x_get_freq(struct
freq /= 10;
/* crystal fixup */
if (tea-tea5759)
- freq += tea-freq_fixup;
+ freq += TEA575X_FMIF;
else
- freq -= tea-freq_fixup;
+ freq -= TEA575X_FMIF;
tea-freq = freq * 16; /* from kHz */
}
@@ -156,9 +156,9 @@ static void snd_tea575x_set_freq(struct
freq /= 16; /* to kHz */
/* crystal fixup */
if (tea-tea5759)
- freq -= tea-freq_fixup;
+ freq -= TEA575X_FMIF;
else
- freq += tea-freq_fixup;
+ freq += TEA575X_FMIF;
/* freq /= 12.5 */
freq *= 10;
freq /= 125;
--- linux-2.6.39-rc2-/sound/pci/es1968.c2011-05-10 22:31:43.0
+0200
+++ linux-2.6.39-rc2/sound/pci/es1968.c 2011-05-10 23:47:32.0 +0200
@@ -2794,7 +2794,6 @@ static int __devinit snd_es1968_create(s
#ifdef CONFIG_SND_ES1968_RADIO
chip-tea.card = card;
- chip-tea.freq_fixup = 10700;
chip-tea.private_data = chip;
chip-tea.ops = snd_es1968_tea_ops;
if (!snd_tea575x_init(chip-tea))
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-10 23:24:39.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-10 23:47:43.0 +0200
@@ -1231,7 +1231,6 @@ static int __devinit snd_fm801_create(st
#ifdef TEA575X_RADIO
chip-tea.card = card;
- chip-tea.freq_fixup = 10700;
chip-tea.private_data = chip;
chip-tea.ops = snd_fm801_tea_ops;
if ((tea575x_tuner TUNER_TYPE_MASK) 0
--
Ondrej Zary
--
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] tea575x: remove unused card from struct
struct snd_card *card is present in struct snd_tea575x but never used.
Remove it.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-12
21:22:35.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-12
21:21:37.0 +0200
@@ -42,7 +42,6 @@ struct snd_tea575x_ops {
};
struct snd_tea575x {
- struct snd_card *card;
struct video_device *vd;/* video device */
bool tea5759; /* 5759 chip is present */
bool mute; /* Device is muted? */
--- linux-2.6.39-rc2-/sound/pci/es1968.c2011-05-12 21:22:35.0
+0200
+++ linux-2.6.39-rc2/sound/pci/es1968.c 2011-05-12 21:22:09.0 +0200
@@ -2793,7 +2793,6 @@ static int __devinit snd_es1968_create(s
snd_card_set_dev(card, pci-dev);
#ifdef CONFIG_SND_ES1968_RADIO
- chip-tea.card = card;
chip-tea.private_data = chip;
chip-tea.ops = snd_es1968_tea_ops;
if (!snd_tea575x_init(chip-tea))
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-12 21:22:35.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-12 21:22:05.0 +0200
@@ -1230,7 +1230,6 @@ static int __devinit snd_fm801_create(st
snd_card_set_dev(card, pci-dev);
#ifdef TEA575X_RADIO
- chip-tea.card = card;
chip-tea.private_data = chip;
chip-tea.ops = snd_fm801_tea_ops;
if ((tea575x_tuner TUNER_TYPE_MASK) 0
--
Ondrej Zary
--
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] tea575x: use better card and bus names
Provide real card and bus_info instead of hardcoded values.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-05-12
21:53:43.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h 2011-05-12
21:37:40.0 +0200
@@ -52,6 +52,8 @@ struct snd_tea575x {
unsigned long in_use; /* set if the device is in use */
struct snd_tea575x_ops *ops;
void *private_data;
+ u8 card[32];
+ u8 bus_info[32];
};
int snd_tea575x_init(struct snd_tea575x *tea);
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-12
21:22:35.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c2011-05-12
21:41:11.0 +0200
@@ -178,8 +178,9 @@ static int vidioc_querycap(struct file *
struct snd_tea575x *tea = video_drvdata(file);
strlcpy(v-driver, tea575x-tuner, sizeof(v-driver));
- strlcpy(v-card, tea-tea5759 ? TEA5759 : TEA5757, sizeof(v-card));
- sprintf(v-bus_info, PCI);
+ strlcpy(v-card, tea-card, sizeof(v-card));
+ strlcat(v-card, tea-tea5759 ? TEA5759 : TEA5757,
sizeof(v-card));
+ strlcpy(v-bus_info, tea-bus_info, sizeof(v-bus_info));
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
return 0;
--- linux-2.6.39-rc2-/sound/pci/es1968.c2011-05-12 21:53:43.0
+0200
+++ linux-2.6.39-rc2/sound/pci/es1968.c 2011-05-12 21:45:59.0 +0200
@@ -2795,6 +2795,8 @@ static int __devinit snd_es1968_create(s
#ifdef CONFIG_SND_ES1968_RADIO
chip-tea.private_data = chip;
chip-tea.ops = snd_es1968_tea_ops;
+ strlcpy(chip-tea.card, SF64-PCE2, sizeof(chip-tea.card));
+ sprintf(chip-tea.bus_info, PCI:%s, pci_name(pci));
if (!snd_tea575x_init(chip-tea))
printk(KERN_INFO es1968: detected TEA575x radio\n);
#endif
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-12 21:53:43.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-12 21:50:19.0 +0200
@@ -1232,6 +1232,7 @@ static int __devinit snd_fm801_create(st
#ifdef TEA575X_RADIO
chip-tea.private_data = chip;
chip-tea.ops = snd_fm801_tea_ops;
+ sprintf(chip-tea.bus_info, PCI:%s, pci_name(pci));
if ((tea575x_tuner TUNER_TYPE_MASK) 0
(tea575x_tuner TUNER_TYPE_MASK) 4) {
if (snd_tea575x_init(chip-tea))
@@ -1246,6 +1247,7 @@ static int __devinit snd_fm801_create(st
break;
}
}
+ strlcpy(chip-tea.card, snd_fm801_tea575x_gpios[(tea575x_tuner
TUNER_TYPE_MASK) - 1].name, sizeof(chip-tea.card));
#endif
*rchip = chip;
--
Ondrej Zary
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Add VIDEO IN driver for OKI SEMICONDUCTOR ML7213/ML7223 IOHs
Hi Tomoya, This is a pretty big patch and it will take some time to review properly. However, I can give some high-level comments already based on an initial scan of the code. 1) New drivers that use controls (G/S_CTRL et al) must use the new control framework. See Documentation/video4linux/v4l2-controls.txt. We are slowly converting existing drivers to this framework, and I don't want to add to that workload :-) 2) The sensor drivers should be named 'ov7620', 'ncm13j', etc. and be independent of (and not refer to) the IOH driver. After all, these sensor drivers can be used in other devices as well. 3) ioh_video_in.c is definitely too large with 4704 lines. I would strongly suggest splitting it in multiple files. 4) There are a bunch of IOH_VIDEO_ private ioctls. I haven't had time to analyse them, but it would help a lot if you could write some sort of overview of what they do and why you need them. I suspect that some can be replaced by private controls, some might already be available in V4L2 and some might need extensions to V4L2 (I hope not, though). 5) The OH_VIDEO_IN_DMA_CONTIG define makes a mess of the code. Why do you need it? I have never seen a driver that can support either DMA_CONTIG or VMALLOC and I would like to know some background information here. BTW, 2.6.39 merges the new videobuf2 framework (the successor to videobuf), which I would recommend that you use. It is much easier to work with and understand than videobuf. Regards, Hans On Thursday, May 12, 2011 10:16:04 Tomoya MORINAGA wrote: This patch is for Video IN driver of OKI SEMICONDUCTOR ML7213/ML7223 IOHs (Input/Output Hub). These ML7213/ML7223 IOHs are companion chip for Intel Atom E6xx series. ML7213 IOH is for IVI(In-Vehicle Infotainment) use and ML7223 IOH is for MP(Media Phone) use. Signed-off-by: Tomoya MORINAGA tomoya-li...@dsn.okisemi.com --- drivers/media/video/Kconfig | 79 + drivers/media/video/Makefile | 15 + drivers/media/video/ioh_video_in.c| 4704 + drivers/media/video/ioh_video_in_main.h | 1058 ++ drivers/media/video/ioh_video_in_ml86v76651.c | 620 drivers/media/video/ioh_video_in_ncm13j.c | 584 +++ drivers/media/video/ioh_video_in_ov7620.c | 637 drivers/media/video/ioh_video_in_ov9653.c | 818 + 8 files changed, 8515 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/ioh_video_in.c create mode 100644 drivers/media/video/ioh_video_in_main.h create mode 100644 drivers/media/video/ioh_video_in_ml86v76651.c create mode 100644 drivers/media/video/ioh_video_in_ncm13j.c create mode 100644 drivers/media/video/ioh_video_in_ov7620.c create mode 100644 drivers/media/video/ioh_video_in_ov9653.c diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 00f51dd..11a96a8 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -928,6 +928,85 @@ config VIDEO_MX2 Interface +config IOH_VIDEOIN +tristate OKI SEMICONDUCTOR ML7213/ML7223 IOH VIDEO IN +depends on PCI DMADEVICES + select PCH_DMA +help + This driver is for Video IN of OKI SEMICONDUCTOR ML7213/ML7223 IOHs + (Input/Output Hub). + These ML7213/ML7223 IOHs are companion chip for Intel Atom E6xx + series. + ML7213 IOH is for IVI(In-Vehicle Infotainment) use and ML7223 IOH is + for MP(Media Phone) use. + +config IOH_VIDEO_DEVICE_SELECT +boolean + +choice +prompt Select IOH VIDEO IN Device +depends on IOH_VIDEOIN +help + This is a selection of used device of the IOH VIDEO. + +config IOH_ML86V76651 +boolean IOH VIDEO IN(ML86V76651) +depends on PCI IOH_VIDEOIN I2C_EG20T +help + If you say yes to this option, support will be included for the + IOH VIDEO ON Driver(ML86V76651). + +config IOH_ML86V76653 +boolean IOH VIDEO IN(ML86V76653) +depends on PCI IOH_VIDEOIN I2C_EG20T +help + If you say yes to this option, support will be included for the + IOH VIDEO ON Driver(ML86V76653). + +config IOH_OV7620 +boolean IOH VIDEO IN(OV7620) +depends on PCI IOH_VIDEOIN I2C_EG20T +help + If you say yes to this option, support will be included for the + IOH VIDEO ON Driver(OV7620). + +config IOH_OV9653 +boolean IOH VIDEO IN(OV9653) +depends on PCI IOH_VIDEOIN I2C_EG20T +help + If you say yes to this option, support will be included for the + IOH VIDEO ON Driver(OV9653). + +config IOH_NCM13J +boolean IOH VIDEO IN(NCM13-J) +depends on PCI IOH_VIDEOIN I2C_EG20T +help + If you say yes to this option, support will be included for the + IOH VIDEO ON Driver(NCM13-J). +endchoice
Re: Audio Video synchronization for data received from a HDMI receiver chip
On Thursday, May 12, 2011 18:59:33 Charlie X. Liu wrote: Which HDMI receiver chip? Indeed, that's my question as well :-) Anyway, this question comes up regularly. V4L2 provides timestamps for each frame, so that's no problem. But my understanding is that ALSA does not give you timestamps, so if there are processing delays between audio and video, then you have no way of knowing. The obvious solution is to talk to the ALSA people to see if some sort of timestamping is possible, but nobody has done that. This is either because everyone that needs it hacks around it instead of trying to really solve it, or because it is never a problem in practice. Hope this helps! Regards, Hans -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media-ow...@vger.kernel.org] On Behalf Of Bhupesh SHARMA Sent: Wednesday, May 11, 2011 10:49 PM To: linux-media@vger.kernel.org Cc: Laurent Pinchart; Guennadi Liakhovetski; Hans Verkuil Subject: Audio Video synchronization for data received from a HDMI receiver chip Hi Linux media folks, We are considering putting an advanced HDMI receiver chip on our SoC, to allow reception of HDMI audio and video. The chip receives HDMI data from a host like a set-up box or DVD player. It provides a video data interface and SPDIF/I2S audio data interface. We plan to support the HDMI video using the V4L2 framework and the HDMI audio using ALSA framework. Now, what seems to be intriguing us is how the audio-video synchronization will be maintained? Will a separate bridging entity required to ensure the same or whether this can be left upon a user space application like mplayer or gstreamer. Also is there a existing interface between the V4L2 and ALSA frameworks and the same can be used in our design? Regards, Bhupesh ST Microelectronics -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB nGene CI : TS Discontinuities issues
On 11/05/11 15:12, Issa Gorissen wrote:
From: Ralph Metzler r...@metzlerbros.de
Issa Gorissen writes:
Could you please take a look at the cxd2099 issues ?
I have attached a version with my changes. I have tested a lot of
different settings with the help of the chip datasheet.
Scrambled programs are not handled correctly. I don't know if it is the
TICLK/MCLKI which is too high or something, or the sync detector ? Also,
as we have to set the TOCLK to max of 72MHz, there are way too much null
packets added. Is there a way to solve this ?
I do not have any cxd2099 issues.
I have a simple test program which includes a 32bit counter as payload
and can pump data through the CI with full speed and have no packet
loss. I only tested decoding with an ORF stream and an Alphacrypt CAM
but also had no problems with this.
Please take care not to write data faster than it is read. Starting two
dds will not guarantee this. To be certain you could write a small
program which never writes more packets than input buffer size minus
the number of read packets (and minus the stuffing null packets on ngene).
Before blaming packet loss on the CI data path also please make
certain that you have no buffer overflows in the input part of
the sec device.
In the ngene driver you can e.g. add a printk in tsin_exchange():
if (dvb_ringbuffer_free(dev-tsin_rbuf) len) {
...
} else
printk (buffer overflow \n);
Regards,
Ralph
Ralph,
Done some more tests, from by test tool, I found out that I have to skip
(rather often) bytes to find the sync one when reading from sec0. I
thought I only needed to do that at the start of the stream, not in the
middle; because I always read/write 188 bytes from it.
Could you share your test code ? I'm finding it difficult to interact
with this sec0 implementation.
Thx
--
Issa
--
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 v3] DVB: Add basic API support for DVB-T2 and bump minor version
From: Andreas Oberritter o...@linuxtv.org
st...@stevekerrison.com: Remove private definitions from cxd2820r that existed
before API was defined
Signed-off-by: Andreas Oberritter o...@linuxtv.org
Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
drivers/media/dvb/dvb-core/dvb_frontend.c | 13 +
drivers/media/dvb/dvb-core/dvb_frontend.h |3 +++
drivers/media/dvb/frontends/cxd2820r_priv.h | 12
include/linux/dvb/frontend.h| 20
include/linux/dvb/version.h |2 +-
5 files changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.c
b/drivers/media/dvb/dvb-core/dvb_frontend.c
index 31e2c0d..8c9ff8a 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -1148,10 +1148,9 @@ static void dtv_property_adv_params_sync(struct
dvb_frontend *fe)
break;
}
- if(c-delivery_system == SYS_ISDBT) {
- /* Fake out a generic DVB-T request so we pass validation in
the ioctl */
- p-frequency = c-frequency;
- p-inversion = c-inversion;
+ /* Fake out a generic DVB-T request so we pass validation in the ioctl
*/
+ if ((c-delivery_system == SYS_ISDBT) ||
+ (c-delivery_system == SYS_DVBT2)) {
p-u.ofdm.constellation = QAM_AUTO;
p-u.ofdm.code_rate_HP = FEC_AUTO;
p-u.ofdm.code_rate_LP = FEC_AUTO;
@@ -1324,6 +1323,9 @@ static int dtv_property_process_get(struct dvb_frontend
*fe,
case DTV_ISDBS_TS_ID:
tvp-u.data = fe-dtv_property_cache.isdbs_ts_id;
break;
+ case DTV_DVBT2_PLP_ID:
+ tvp-u.data = fe-dtv_property_cache.dvbt2_plp_id;
+ break;
default:
r = -1;
}
@@ -1479,6 +1481,9 @@ static int dtv_property_process_set(struct dvb_frontend
*fe,
case DTV_ISDBS_TS_ID:
fe-dtv_property_cache.isdbs_ts_id = tvp-u.data;
break;
+ case DTV_DVBT2_PLP_ID:
+ fe-dtv_property_cache.dvbt2_plp_id = tvp-u.data;
+ break;
default:
r = -1;
}
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 3b86050..5590eb6 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -358,6 +358,9 @@ struct dtv_frontend_properties {
/* ISDB-T specifics */
u32 isdbs_ts_id;
+
+ /* DVB-T2 specifics */
+ u32 dvbt2_plp_id;
};
struct dvb_frontend {
diff --git a/drivers/media/dvb/frontends/cxd2820r_priv.h
b/drivers/media/dvb/frontends/cxd2820r_priv.h
index d4e2e0b..25adbee 100644
--- a/drivers/media/dvb/frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb/frontends/cxd2820r_priv.h
@@ -40,18 +40,6 @@
#undef warn
#define warn(f, arg...) printk(KERN_WARNING LOG_PREFIX: f \n , ## arg)
-/*
- * FIXME: These are totally wrong and must be added properly to the API.
- * Only temporary solution in order to get driver compile.
- */
-#define SYS_DVBT2 SYS_DAB
-#define TRANSMISSION_MODE_1K 0
-#define TRANSMISSION_MODE_16K 0
-#define TRANSMISSION_MODE_32K 0
-#define GUARD_INTERVAL_1_128 0
-#define GUARD_INTERVAL_19_128 0
-#define GUARD_INTERVAL_19_256 0
-
struct reg_val_mask {
u32 reg;
u8 val;
diff --git a/include/linux/dvb/frontend.h b/include/linux/dvb/frontend.h
index 493a2bf..36a3ed6 100644
--- a/include/linux/dvb/frontend.h
+++ b/include/linux/dvb/frontend.h
@@ -175,14 +175,20 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
- TRANSMISSION_MODE_4K
+ TRANSMISSION_MODE_4K,
+ TRANSMISSION_MODE_1K,
+ TRANSMISSION_MODE_16K,
+ TRANSMISSION_MODE_32K,
} fe_transmit_mode_t;
typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
- BANDWIDTH_AUTO
+ BANDWIDTH_AUTO,
+ BANDWIDTH_5_MHZ,
+ BANDWIDTH_10_MHZ,
+ BANDWIDTH_1_712_MHZ,
} fe_bandwidth_t;
@@ -191,7 +197,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
- GUARD_INTERVAL_AUTO
+ GUARD_INTERVAL_AUTO,
+ GUARD_INTERVAL_1_128,
+ GUARD_INTERVAL_19_128,
+ GUARD_INTERVAL_19_256,
} fe_guard_interval_t;
@@ -305,7 +314,9 @@ struct dvb_frontend_event {
#define DTV_ISDBS_TS_ID42
-#define DTV_MAX_COMMANDDTV_ISDBS_TS_ID
+#define DTV_DVBT2_PLP_ID 43
+
+#define DTV_MAX_COMMANDDTV_DVBT2_PLP_ID
typedef enum fe_pilot {
PILOT_ON,
@@ -337,6 +348,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
Re: [PATCH v2 5/5] Documentation: Update to include DVB-T2 additions
I've just realised there is some illegal whitespace in this patch here:
@@ -553,5 +568,20 @@ typedef enum fe_guard_interval {
/section
/section
/section
+ section id=dvbt2-params
+ titleDVB-T2 parameters/title
+
+ paraThis section covers parameters that apply only
to the DVB-T2 delivery method. DVB-T2
Auto-tab between the title and first paragraph. My apologies! If I need
to do anything about this let me know.
--
Steve Kerrison MEng Hons.
http://www.stevekerrison.com/
On Sun, 2011-05-08 at 20:17 +0100, Steve Kerrison wrote:
A few new capabilities added to frontend.h for DVB-T2. Added these
to the documentation plus some notes explaining that they are
used by the T2 delivery system.
Signed-off-by: Steve Kerrison st...@stevekerrison.com
---
Documentation/DocBook/dvb/dvbproperty.xml | 36 ++--
Documentation/DocBook/dvb/frontend.h.xml | 20 +---
2 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml
b/Documentation/DocBook/dvb/dvbproperty.xml
index 05ce603..52d5e3c 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -217,9 +217,12 @@ get/set up to 64 properties. The actual meaning of each
property is described on
paraBandwidth for the channel, in HZ./para
paraPossible values:
+ constant1712000/constant,
+ constant500/constant,
constant600/constant,
constant700/constant,
- constant800/constant.
+ constant800/constant,
+ constant1000/constant.
/para
paraNotes:/para
@@ -231,6 +234,8 @@ get/set up to 64 properties. The actual meaning of each
property is described on
para4) Bandwidth in ISDB-T is fixed (6MHz) or can be easily
derived from
other parameters (DTV_ISDBT_SB_SEGMENT_IDX,
DTV_ISDBT_SB_SEGMENT_COUNT)./para
+ para5) DVB-T supports 6, 7 and 8MHz./para
+ para6) In addition, DVB-T2 supports 1.172, 5 and 10MHz./para
/section
section id=DTV_DELIVERY_SYSTEM
@@ -257,6 +262,7 @@ typedef enum fe_delivery_system {
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
+ SYS_DVBT2,
} fe_delivery_system_t;
/programlisting
@@ -273,7 +279,10 @@ typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
- TRANSMISSION_MODE_4K
+ TRANSMISSION_MODE_4K,
+ TRANSMISSION_MODE_1K,
+ TRANSMISSION_MODE_16K,
+ TRANSMISSION_MODE_32K,
} fe_transmit_mode_t;
/programlisting
@@ -284,6 +293,8 @@ typedef enum fe_transmit_mode {
para2) If constantDTV_TRANSMISSION_MODE/constant is set
the constantTRANSMISSION_MODE_AUTO/constant the
hardware will try to find the correct FFT-size (if
capable) and will
use TMCC to fill in the missing parameters./para
+ para3) DVB-T specifies 2K and 8K as valid sizes./para
+ para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para
/section
section id=DTV_GUARD_INTERVAL
@@ -296,7 +307,10 @@ typedef enum fe_guard_interval {
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
- GUARD_INTERVAL_AUTO
+ GUARD_INTERVAL_AUTO,
+ GUARD_INTERVAL_1_128,
+ GUARD_INTERVAL_19_128,
+ GUARD_INTERVAL_19_256,
} fe_guard_interval_t;
/programlisting
@@ -304,6 +318,7 @@ typedef enum fe_guard_interval {
para1) If constantDTV_GUARD_INTERVAL/constant is set the
constantGUARD_INTERVAL_AUTO/constant the hardware will
try to find the correct guard interval (if capable) and
will use TMCC to fill
in the missing parameters./para
+ para2) Intervals 1/128, 19/128 and 19/256 are used only for
DVB-T2 at present/para
/section
/section
@@ -553,5 +568,20 @@ typedef enum fe_guard_interval {
/section
/section
/section
+ section id=dvbt2-params
+ titleDVB-T2 parameters/title
+
+ paraThis section covers parameters that apply only to the
DVB-T2 delivery method. DVB-T2
+ support is currently in the early stages development so
expect this section to grow
+ and become more detailed with time./para
+
+ section id=dvbt2-plp-id
+ titleconstantDTV_DVBT2_PLP_ID/constant/title
+
+ paraDVB-T2 supports Physical Layer Pipes (PLP) to
allow transmission of
+ many data
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On 05/12/2011 07:42 PM, Josh Wu wrote: This patch is to enable Atmel Image Sensor Interface (ISI) driver support. - Using soc-camera framework with videobuf2 dma-contig allocator - Supporting video streaming of YUV packed format - Tested on AT91SAM9M10G45-EK with OV2640 Hi Josh, Thansk for doing this. Overall the patch looks really good. A few comments below. ~Ryan Signed-off-by: Josh Wu josh...@atmel.com --- base on branch staging/for_v2.6.40 arch/arm/mach-at91/include/mach/at91_isi.h | 454 drivers/media/video/Kconfig| 10 + drivers/media/video/Makefile |1 + drivers/media/video/atmel-isi.c| 1089 4 files changed, 1554 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-at91/include/mach/at91_isi.h create mode 100644 drivers/media/video/atmel-isi.c diff --git a/arch/arm/mach-at91/include/mach/at91_isi.h b/arch/arm/mach-at91/include/mach/at91_isi.h new file mode 100644 index 000..3219358 --- /dev/null +++ b/arch/arm/mach-at91/include/mach/at91_isi.h @@ -0,0 +1,454 @@ +/* + * Register definitions for the Atmel Image Sensor Interface. + * + * Copyright (C) 2011 Atmel Corporation + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __AT91_ISI_H__ +#define __AT91_ISI_H__ + +#include linux/videodev2.h +#include linux/i2c.h +#include media/v4l2-device.h +#include media/v4l2-common.h +#include media/v4l2-ioctl.h +#include media/v4l2-chip-ident.h + +/* ISI register offsets */ +#define ISI_CR1 0x +#define ISI_CR2 0x0004 +#define ISI_SR 0x0008 +#define ISI_IER 0x000c +#define ISI_IDR 0x0010 +#define ISI_IMR 0x0014 +#define ISI_PSIZE0x0020 +#define ISI_PDECF0x0024 +#define ISI_PPFBD0x0028 +#define ISI_CDBA 0x002c +#define ISI_Y2R_SET0 0x0030 +#define ISI_Y2R_SET1 0x0034 +#define ISI_R2Y_SET0 0x0038 +#define ISI_R2Y_SET1 0x003c +#define ISI_R2Y_SET2 0x0040 + +/* ISI_V2 register offsets */ +#define ISI_V2_CFG1 0x +#define ISI_V2_CFG2 0x0004 +#define ISI_V2_PSIZE 0x0008 +#define ISI_V2_PDECF 0x000c +#define ISI_V2_Y2R_SET0 0x0010 +#define ISI_V2_Y2R_SET1 0x0014 +#define ISI_V2_R2Y_SET0 0x0018 +#define ISI_V2_R2Y_SET1 0x001C +#define ISI_V2_R2Y_SET2 0x0020 +#define ISI_V2_CTRL 0x0024 +#define ISI_V2_STATUS0x0028 +#define ISI_V2_INTEN 0x002C +#define ISI_V2_INTDIS0x0030 +#define ISI_V2_INTMASK 0x0034 +#define ISI_V2_DMA_CHER 0x0038 +#define ISI_V2_DMA_CHDR 0x003C +#define ISI_V2_DMA_CHSR 0x0040 +#define ISI_V2_DMA_P_ADDR0x0044 +#define ISI_V2_DMA_P_CTRL0x0048 +#define ISI_V2_DMA_P_DSCR0x004C +#define ISI_V2_DMA_C_ADDR0x0050 +#define ISI_V2_DMA_C_CTRL0x0054 +#define ISI_V2_DMA_C_DSCR0x0058 + +/* Bitfields in CR1 */ +#define ISI_RST_OFFSET 0 +#define ISI_RST_SIZE 1 +#define ISI_DIS_OFFSET 1 +#define ISI_DIS_SIZE 1 +#define ISI_HSYNC_POL_OFFSET 2 +#define ISI_HSYNC_POL_SIZE 1 +#define ISI_VSYNC_POL_OFFSET 3 +#define ISI_VSYNC_POL_SIZE 1 +#define ISI_PIXCLK_POL_OFFSET4 +#define ISI_PIXCLK_POL_SIZE 1 +#define ISI_EMB_SYNC_OFFSET 6 +#define ISI_EMB_SYNC_SIZE1 +#define ISI_CRC_SYNC_OFFSET 7 +#define ISI_CRC_SYNC_SIZE1 +#define ISI_FRATE_OFFSET 8 +#define ISI_FRATE_SIZE 3 +#define ISI_FULL_OFFSET 12 +#define ISI_FULL_SIZE1 +#define ISI_THMASK_OFFSET13 +#define ISI_THMASK_SIZE
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
On 05/13/2011 12:14 AM, Guennadi Liakhovetski wrote: On Thu, 12 May 2011, Jean-Christophe PLAGNIOL-VILLARD wrote: [snip] + if (0 == *nbuffers) please invert the test Don't think this is required by CodingStyle or anything like that. If it were, you'd have to revamp half of the kernel. It should at least be consistent within a file, which it is not true in this case. I think the preferred style is to have the variable on the left. ~Ryan -- Bluewater Systems Ltd - ARM Technology Solution Centre Ryan Mallon 5 Amuri Park, 404 Barbadoes St r...@bluewatersys.com PO Box 13 889, Christchurch 8013 http://www.bluewatersys.com New Zealand Phone: +64 3 3779127Freecall: Australia 1800 148 751 Fax: +64 3 3779135 USA 1800 261 2934 -- 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: ngene CI problems
On Thursday 12 May 2011 22:28:52 Issa Gorissen wrote: On 11/05/11 20:59, Oliver Endriss wrote: I reworked the driver to strip those null packets. Please try http://linuxtv.org/hg/~endriss/ngene-octopus-test/raw-rev/f0dc4237ad08 Tried your patch, but FFs have been replaced by 6Fs in null packets. Other than that, no improvement for me. Please double check that the patch applied cleanly. The 0x6F NULL packets should never be passed to userspace. CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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] DVB-T2 API updates, documentation and accompanying small fixes
Hello all, Rémi informed he have added this new API and DVB-T2 support for VLC media player Git tree [1]. I didn't test it yet, mostly due to lack of time :i I will test that sooner or later, feel free to test! [1] http://git.videolan.org/?p=vlc.git regards Antti On 05/08/2011 06:51 PM, Steve Kerrison wrote: Hi Mauro, Antti, Andreas, I hope this patch set is formed appropriately - it is my first patch submission direct to the linux-media group. Following the pull of Antti's work on support for the cxd2820r and PCTV nanoStick T2 290e, this patch set implements Andreas' modifications to the API to give provisional DVB-T2 support and the removal of a workaround for this in the cxd2820r module. In addition, there are some minor fixes to compiler warnings as a result of the expanded enums. I cannot test these myself but they treat unrecognized values as *_AUTO and I can't see where a problem would be created. I have updated the documentation a little. If I've done the right thing then I guess there is incentive there for me continue to expand DVB related elements of the API docs. This patch set has been tested by me on two systems, with one running a MythTV backend utilising a long-supported DVB tuner. MythTV works fine with the old tuner and the nanoStick T2 290e works in VLC. I've yet to test the 290e in MythTV - I was more intent on making sure the patches hadn't broken userland or older devices. Feedback, testing and discussion of where to go next is welcomed! Regards, Steve Kerrison. -- 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
[ANNOUNCE] New OMAP4 V4L2 Camera Project started
Hi all, Just to let you know that I've just officially registered for a new project in the Pandaboard.org portal for OMAP4 v4l2 camera support. You can find it here: http://omiio.org/content/omap4-v4l2-camera And also, you can find the actual Gitorious project with the code here: https://www.gitorious.org/omap4-v4l2-camera If anyone is interested in contributing for this project, please let me know, so I can add you as a contributor to the project. Regards, Sergio -- 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: IR remote control autorepeat / evdev
On 12.05.2011 04:36, Mauro Carvalho Chehab wrote: Em 12-05-2011 03:10, Mauro Carvalho Chehab escreveu: Em 12-05-2011 02:37, Anssi Hannula escreveu: I don't see any other places: $ git grep 'REP_PERIOD' . dvb/dvb-usb/dvb-usb-remote.c: input_dev-rep[REP_PERIOD] = d-props.rc.legacy.rc_interval; Indeed, the REP_PERIOD is not adjusted on other drivers. I agree that we should change it to something like 125ms, for example, as 33ms is too short, as it takes up to 114ms for a repeat event to arrive. IMO, the enclosed patch should do a better job with repeat events, without needing to change rc-core/input/event logic. It will indeed reduce the amount of ghost events so it brings us in the right direction. I'd still like to get rid of the ghost repeats entirely, or at least some way for users to do it if we don't do it by default. Maybe we could replace the kernel softrepeat with native repeats (for those protocols/drivers that have them), while making sure that repeat events before REP_DELAY are ignored and repeat events less than REP_PERIOD since the previous event are ignored, so the users can still configure them as they like? Or maybe just a module option that causes rc-core to use native repeat events, for those of us that want accurate repeat events without ghosting? - Subject: Use a more consistent value for RC repeat period From: Mauro Carvalho Chehab mche...@redhat.com The default REP_PERIOD is 33 ms. This doesn't make sense for IR's, as, in general, an IR repeat scancode is provided at every 110/115ms, depending on the RC protocol. So, increase its default, to do a better job avoiding ghost repeat events. Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c index f53f9c6..ee67169 100644 --- a/drivers/media/rc/rc-main.c +++ b/drivers/media/rc/rc-main.c @@ -1044,6 +1044,13 @@ int rc_register_device(struct rc_dev *dev) */ dev-input_dev-rep[REP_DELAY] = 500; + /* + * As a repeat event on protocols like RC-5 and NEC take as long as + * 110/114ms, using 33ms as a repeat period is not the right thing + * to do. + */ + dev-input_dev-rep[REP_PERIOD] = 125; + path = kobject_get_path(dev-dev.kobj, GFP_KERNEL); printk(KERN_INFO %s: %s as %s\n, dev_name(dev-dev), -- Anssi Hannula -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI) support
+
+/* Constants for RGB_CFG(ISI_V2) */
+#define ISI_V2_RGB_CFG_DEFAULT 0
+#define ISI_V2_RGB_CFG_MODE_1 1
+#define ISI_V2_RGB_CFG_MODE_2 2
+#define ISI_V2_RGB_CFG_MODE_3 3
+
+/* Bit manipulation macros */
+#define ISI_BIT(name) \
+ (1 ISI_##name##_OFFSET)
+#define ISI_BF(name, value)\
+ (((value) ((1 ISI_##name##_SIZE) - 1)) \
+ ISI_##name##_OFFSET)
+#define ISI_BFEXT(name, value) \
+ (((value) ISI_##name##_OFFSET) \
+ ((1 ISI_##name##_SIZE) - 1))
+#define ISI_BFINS(name, value, old)\
+ (((old) ~(((1 ISI_##name##_SIZE) - 1) \
+ISI_##name##_OFFSET))\
+| ISI_BF(name, value))
I really dislike this kind of register access magic. Not sure how others
feel about it. These macros are really ugly.
+/* Register access macros */
+#define isi_readl(port, reg) \
+ __raw_readl((port)-regs + ISI_##reg)
+#define isi_writel(port, reg, value) \
+ __raw_writel((value), (port)-regs + ISI_##reg)
If the token pasting stuff gets dropped then these can be static inline
functions which is preferred.
Sorry this make the C code much readable
and this can not be done as a inline
so please keep it as is
+
+#define ATMEL_V4L2_VID_FLAGS (V4L2_CAP_VIDEO_OUTPUT)
+
+struct atmel_isi;
+
+enum atmel_isi_pixfmt {
+ ATMEL_ISI_PIXFMT_GREY, /* Greyscale */
+ dev_info(pdev-dev,
+ No config available using default values\n);
+ pdata = isi_default_data;
+ }
+
+ isi-pdata = pdata;
+ isi-platform_flags = pdata-flags;
+ if (isi-platform_flags == 0)
+ isi-platform_flags = ISI_DATAWIDTH_8;
We could be mean here an require that people get the flags correct, e.g.
if (!((isi-platform_flags ISI_DATA_WIDTH_8) ||
(isi-platform_flags ISI_DATA_WIDTH_8))) {
dev_err(pdev-dev, No data width specified\n);
err = -ENOMEM;
goto fail;
}
Which discourages sloppy coding in the board files.
if this means default configuration so not need to have all board to set it
+
+ isi_writel(isi, V2_CTRL, ISI_BIT(V2_DIS));
+ /* Check if module disable */
+ while (isi_readl(isi, V2_STATUS) ISI_BIT(V2_DIS))
+ cpu_relax();
+
+ irq = platform_get_irq(pdev, 0);
Best Regards,
J.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] Modifications to the driver mb86a20s
Hi to all,
I added some modifications to the driver mb86a20s and would appreciate your
comments.
File: drivers/media/dvb/frontends/mb86a20s.c
-static int debug = 1;
+static int debug = 0;
module_param(debug, int, 0644);
MODULE_PARM_DESC(debug, Activates frontend debugging (default:0));
How is in the description by default debug is off.
-#define rc(args...) do {
+#define printk_rc(args...) do {
For clarity, only rc is somewhat vague.
+static int mb86a20s_i2c_gate_ctrl(struct dvb_frontend *fe, int enable)
Adds the i2c_gate_ctrl to mb86a20s driver.
The mb86a20s has an i2c bus which controls the flow of data to the tuner. When
enabled, the data stream flowing normally through the i2c bus, when disabled
the data stream to the tuner is cut and the i2c bus between mb86a20s and the
tuner goes to tri-state. The data flow between the mb86a20s and its controller
(CPU, USB), is not affected.
In hybrid systems with analog and digital TV, the i2c bus control can be done
in the analog demodulator.
- if (fe-ops.i2c_gate_ctrl)
- fe-ops.i2c_gate_ctrl(fe, 0);
val = mb86a20s_readreg(state, 0x0a) 0xf;
- if (fe-ops.i2c_gate_ctrl)
- fe-ops.i2c_gate_ctrl(fe, 1);
The i2c_gate_ctrl controls the i2c bus of the tuner so does not need to enable
it or disable it here.
+ for (i = 0; i 20; i++) {
+ if (mb86a20s_readreg(state, 0x0a) = 8) break;
+ msleep(100);
+ }
Waits for the stabilization of the demodulator.
+static int mb86a20s_get_algo(struct dvb_frontend *fe)
+{
+ return DVBFE_ALGO_HW;
+}
Because the mb86a20s_tune function was implemented.
Thanks, best regards,
Manoel.
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
i2c_gate_ctrl.patch
Description: Binary data
[PATCH 2/4] Modifications to the driver mb86a20s
This patch implements mb86a20s_read_snr and adds mb86a20s_read_ber and mb86a20s_read_ucblocks both without practical utility but that programs as dvbsnoop need. Signed-off-by: Manoel Pinheiro pinus...@hotmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] Modifications to the driver mb86a20s
This patch implements mb86a20s_read_snr and adds mb86a20s_read_ber and mb86a20s_read_ucblocks both without practical utility but that programs as dvbsnoop need. Signed-off-by: Manoel Pinheiro pinus...@hotmail.com read_snr.patch Description: Binary data
[PATCH 3/4] Modifications to the driver mb86a20s
This patch implements some modifications in the function
This patch implements some modifications in the initialization function of the
mb86a20s.
Explanation:
Several registers of mb86a20s can be programmed and to simplify this task and
due to lack of technical literature to elaborate the necessary calculations was
opted by the sending of values already ready for the registers, eliminating the
process of calculations.
The technique is quite simple: to each register that can be modified an
identification (REG_IDCFG) was attributed and those that do not need
modification was attributed REG_IDCFG_NONE.
The device that uses the demodulator mb86a20s simply informs the registers to
be modified through the configuration parameter of the function frontend_attach.
Like in the example:
static struct mb86a20s_config_regs_val mb86a20s_config_regs[] = {
{ REG2820_IDCFG, 0x33ddcd },
{ REG50D5_IDCFG, 0x00 }, /* use output TS parallel */
{ REG50D6_IDCFG, 0x17 }
};
static struct mb86a20s_config mb86a20s_cfg = {
.demod_address = DEMOD_I2C_ADDR,
.config_regs_size = ARRAY_SIZE(mb86a20s_config_regs),
.config_regs = mb86a20s_config_regs,
};
If there are no registers to be modified to do just this:
static struct mb86a20s_config mb86a20s_cfg = {
.demod_address = DEMOD_I2C_ADDR,
};
static int tbs_dtb08_frontend_attach(struct dvb_usb_adapter *adap)
{
adap-fe = dvb_attach(mb86a20s_attach, mb86a20s_cfg, adap-dev-i2c_adap);
if (adap-fe) {
frontend_tuner_attach(adap);
}
}
Signed-off-by: Manoel Pinheiro pinus...@hotmail.com
regs_init.patch
Description: Binary data
[PATCH 4/4] Modifications to the driver mb86a20s
This patch implement changes to the function mb86a20s_read_signal_strength. The original function, binary search, does not work with device dtb08. I would like to know if this function works. Signed-off-by: Manoel Pinheiro pinus...@hotmail.com signal_strength.patch Description: Binary data
adding dvb-t scan files for New Zealand
Hello all, I want to add dvb-t scan files for New Zealand, as there only seems to be one (For Waiatarua, Auckland, NZ). However I have no idea how to actually get the files I created added to the linux tv project. So if someone could either: 1) point me to a faq / wiki / web site explaining how I can update dvb-t scan files. or 2) Kindly add the files for me. I would be most grateful. I have pasted the contents of the files below (each comment block is a new file). -Richard Maxwell # Waiatarua, Auckland NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 53800 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 57000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 66600 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Pinehill, Remuera, Sky Tower, Auckland Infill, Auckland NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 53000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 56200 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 62600 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Te Aroha, Waikato NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 67400 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Hamilton Infill, Waikato NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69800 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 68200 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Kopukairua, Tauranga NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69800 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 64200 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Mt. Erin, Hawkes Bay NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 52200 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 55400 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 65000 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Napier Infill, Hawkes Bay NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Wharite, Manawatu NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Kaukau, Wellington NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 69000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 77800 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Fitzherbert, Baxters Knob, Wellington infill, Wellington NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 71400 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 73000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 76200 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Ngarara, Wellington NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 66600 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 73000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 76200 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Sugarloaf, Christchurch NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 68200 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 69800 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 70600 8MHz 3/4 NONE QAM64 8k 1/16 NONE # Mt Cargill, Dunedin NZ # # Channel allocation details for NZ can be found at # http://en.wikipedia.org/wiki/Freeview_(New_Zealand) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy T 65000 8MHz 3/4 NONE QAM64 8k 1/16 NONE T 66600 8MHz 3/4 NONE
RE: [PATCH] [media] at91: add Atmel Image Sensor Interface (ISI)support
On Thursday, May 12, 2011 5:35 PM, Russell King wrote:
A few more points...
+static int __init atmel_isi_probe(struct platform_device *pdev)
Should be __devinit otherwise you'll have section errors.
Ok, will be fixed in V2 patch.
+{
+unsigned int irq;
+struct atmel_isi *isi;
+struct clk *pclk;
+struct resource *regs;
+int ret;
+struct device *dev = pdev-dev;
+struct isi_platform_data *pdata;
+struct soc_camera_host *soc_host;
+
+regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+if (!regs)
+return -ENXIO;
+
+pclk = clk_get(pdev-dev, isi_clk);
+if (IS_ERR(pclk))
+return PTR_ERR(pclk);
+
+clk_enable(pclk);
Return value of clk_enable() should be checked.
Yes. I will add code to check the return value in V2 patch.
+
+isi = kzalloc(sizeof(struct atmel_isi), GFP_KERNEL);
+if (!isi) {
+ret = -ENOMEM;
[...]
+isi_writel(isi, V2_CTRL, ISI_BIT(V2_DIS));
+/* Check if module disable */
+while (isi_readl(isi, V2_STATUS) ISI_BIT(V2_DIS))
+cpu_relax();
+
+irq = platform_get_irq(pdev, 0);
This should also be checked.
Ditto, 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
