Re: [PATCH] Illuminators and status LED controls
Andy == Andy Walls awa...@md.metrocast.net writes: Hi, Andy Given choices I made when I patched up gspca/cpia1.c for my Andy prototype LED API usage, I got these associations Andy By exposed LED name: Andy /sys/class/leds/video0:white:illuminator0 Indeed. But didn't we just decide that illuminators were an integral part of the video handling (similar to gain control), and only use the LED API for status LEDs that don't directly interfere with the video data? Andy The LED API has some shortcomings/annoyances: Andy - The method a driver provides to set the LED brightness cannot sleep, Andy so a workqueue is needed to simply turn a hardware light on and off for Andy USB devices. Andy - The Documentation is not very good for end-users or kernel developers Andy on using the LED API. No? I agree that the documentation is pretty minimalistic, but ok - It's not that complicated. Andy - For an LED trigger not to override a user's desire to inhibit an LED, Andy the user needs to know to cancel all the triggers on an LED before Andy setting the LEDs brightness to 0. Only a single trigger can be active at a time for a given LED. Andy Again, that happens to be the only real compelling use case I see for Andy using the LED API. However, I doubt many users will try to take Andy advantage of it, and I suspect even less will succeed in getting it Andy configured right. Good documentation could go a long way in correcting Andy that. That and using the LED for something else (perhaps with another trigger like I eplained earlier with wlan/hdd activity). Andy If a user configures multiple LED triggers on an LED, those triggers Andy will compete with each other. The net result is the most recent event Andy from the driver, any LED triggers wins, or user manipulation of sysfs Andy brightness. Only a single trigger can be active at a time for a given LED. Andy With indicators that's annoying, but not a failure. With illuminators, Andy that is a failure. Again, I don't think we should use the LED API for something as integral to the video signal as illuminators. -- Bye, Peter Korsgaard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. Best regards -- Marek Szyprowski Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. 1) It is in use so you can't just drop it. 2) The read() API is actually very useful for video devices that deal with compressed video streams. E.g. you can do things like 'cat /dev/video0 foo.mpg' It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT FIXES FOR 2.6.36] mem2mem_testdev fixes
Hi Mauro, please pull the below fixes for 2.6.36: The following changes since commit 7e0e8c4f78e93136a2fb44cf46366e868fb75a10: v4l: radio: si470x: fix unneeded free_irq() call (2010-09-06 15:24:33 +0900) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-2.6-samsung v4l/fixes_for_v2.6.36 Pawel Osciak (2): v4l: mem2mem_testdev: fix errorenous comparison v4l: mem2mem_testdev: add missing release for video_device drivers/media/video/mem2mem_testdev.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) -- Best regards, Pawel Osciak Linux Platform Group Samsung Poland RD Center -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Fri, Sep 10, 2010 at 4:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. FYI: KernelLabs has done a port of cx18 to videobuf. We just haven't submitted it upstream yet. I'm just mentioning this so nobody else feels the urge to take a crack at it. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/8] IR: extend MCE keymap.
On Fri, September 10, 2010 03:37, Jarod Wilson wrote: I think for mythtv, we're going to end up having a daemon process with elevated privs that reads directly from input devices to get around this annoyance, until such time as the annoyance is gone. A similar approach could work for XBMC since it already has input plugins (e.g. for using a Nintendo Wii controller, etc). -- David Härdeman -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Thu, 2010-09-09 at 22:01 -0400, Jarod Wilson wrote:
On Thu, Sep 09, 2010 at 12:34:27AM -0400, Jarod Wilson wrote:
...
For now, I've applied patches 3, 4 and 5, as it is nice to have Jarod's
review also.
I've finally got them all applied atop current media_tree staging/v2.6.37,
though none of the streamzap bits in patch 7 are applicable any longer.
Will try to get through looking and commenting (and testing) of the rest
of them tonight.
Also had to make a minor addition to the rc5-sz decoder (same change
as in the other decoders). Almost have all the requisite test kernels
for David's, Maxim's and Dmitry's patchsets built and installed, wish
my laptop was faster... Probably would have been faster to use a lab
box and copy data over. Oh well. So functional testing to hopefully
commence tomorrow morning.
Wuff. None of the three builds is at all stable on my laptop, but I can't
actually point the finger at any of the three patchsets, since I'm getting
spontaneous lockups doing nothing at all before even plugging in a
receiver. I did however get occasional periods of a non-panicking (not
starting X seems to help a lot). Initial results:
Btw, my printk blackbox patch could help you a lot.
I can't count how many times it helped me.
I just enable softlockup, hardlockup, and nmi watchdog, and let system
panic on oopses, and reboot. Or if you have hardware reboot button, you
can just use it. The point is that most BIOSES don't clear the ram, and
I take advantage of that.
Recently in an attempt to make it reserve only small portion of memory
(before I would use mem=) I also made this work out of box.
After a reboot, to get crash dmesg, just do
sudo cat /sys/kernel/debug/printk/crash_dmesg | strings
Note that kernel contains now a ramoops module that does similar things.
It doesn't reserve the memory automatically, and (this is the reason I
still don't use it) is only called by kernel to save oopses/panicks.
It should be enough though too, but my patch actually places the printk
buffer itself in the fixed area in the ram.
Best regards,
Maxim Levitsky
commit 8f1c423046c22dad6aaeca04bfcb0ab301843c36
Author: Maxim Levitsky maximlevit...@gmail.com
Date: Sat Jul 31 13:43:03 2010 +0300
printk: Allow to fix the physical address of printk buffer
Allows to put printk buffer at fixed location of ram (default 128M).
If debugfs is enabled, log of last boot is copied into
system ram, and can be accessed via debugfs, for example
cat /sys/kernel/debug/printk/crash_dmesg
Signed-off-by: Maxim Levitsky maximlevit...@gmail.com
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index ef292c7..a6eaf40 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -46,6 +46,7 @@ extern unsigned long saved_video_mode;
extern void reserve_standard_io_resources(void);
extern void i386_reserve_resources(void);
extern void setup_default_timer_irq(void);
+extern void early_reserve_printk_buffer(void);
#ifdef CONFIG_X86_MRST
extern void x86_mrst_early_setup(void);
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index c3a4fbb..6fbf2a0 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -843,6 +843,7 @@ void __init setup_arch(char **cmdline_p)
/* after early param, so could get panic from serial */
reserve_early_setup_data();
+ early_reserve_printk_buffer();
if (acpi_mps_check()) {
#ifdef CONFIG_X86_LOCAL_APIC
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 3ba6e06..8854a91 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -106,7 +106,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
if (is_ram pfn_valid(pfn) !PageReserved(pfn_to_page(pfn)))
return NULL;
- WARN_ON_ONCE(is_ram);
}
/*
diff --git a/kernel/printk.c b/kernel/printk.c
index 8fe465a..a6fff63 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -41,6 +41,7 @@
#include linux/notifier.h
#include asm/uaccess.h
+#include linux/debugfs.h
/*
* for_each_console() allows you to iterate on each console
@@ -167,6 +168,7 @@ void log_buf_kexec_setup(void)
}
#endif
+#ifndef CONFIG_HWMEM_PRINTK
static int __init log_buf_len_setup(char *str)
{
unsigned size = memparse(str, str);
@@ -207,6 +209,93 @@ out:
}
__setup(log_buf_len=, log_buf_len_setup);
+#endif
+
+#ifdef CONFIG_HWMEM_PRINTK
+
+char *old_log_buf;
+struct debugfs_blob_wrapper crash_dmesg_wrapper;
+static unsigned int printk_phys_address = CONFIG_HWMEM_PRINTK_DEFAULT_ADDRESS;
+
+
+static int __init printk_address_setup(char *p)
+{
+ char *tmp;
+
+ if (!strncmp(p, off, 3))
+ printk_phys_address = 0;
+ else
+ printk_phys_address = memparse(p, tmp);
+ return 0;
+}
+early_param(printk_address, printk_address_setup);
+
+
+void early_reserve_printk_buffer(void)
+{
+ if (printk_phys_address)
+ reserve_early(printk_phys_address,
+ printk_phys_address
Re: [PATCH 5/8] IR: extend MCE keymap.
On Thu, 2010-09-09 at 21:37 -0400, Jarod Wilson wrote: On Thu, Sep 9, 2010 at 8:40 PM, Maxim Levitsky maximlevit...@gmail.com wrote: On Wed, 2010-09-08 at 10:47 -0400, Jarod Wilson wrote: On Mon, Sep 6, 2010 at 5:26 PM, Maxim Levitsky maximlevit...@gmail.com wrote: These keys are found on remote bundled with Toshiba Qosmio F50-10q. Found and tested by, Sami R maeses...@gmail.com Signed-off-by: Maxim Levitsky maximlevit...@gmail.com --- drivers/media/IR/keymaps/rc-rc6-mce.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) Tommorow I will resend that patch with even more scancodes. Saw the discussion on irc. Feel your pain big-time on the X server limitation on keycodes. Its put a big damper on efforts to add native support to mythtv. Peter Hutterer's libXi2 cookbook tutorials talk a good game about how libXi2 supports 32-bit keycodes, but neglects to mention that the X server still gobbles up anything above 248 or 255 or whatever it is, and remedying that is no small task. :( I think for mythtv, we're going to end up having a daemon process with elevated privs that reads directly from input devices to get around this annoyance, until such time as the annoyance is gone. Btw, indeed Xi2 still doesn't pass 248 keycodes, just tested that with -git versions of X stack from about 2 months ago. However this can be fixed relatively easily. Maybe even I could do that. The big problem is however about ability to map extended keycodes to actions, thing that should be provided by XKB2, which we will see probably when DNF is released on Phantom console... Also this will need lots of changes in toolkits. Thats the problem I don't have resources to fix. Best regards, Maxim Levitsky -- 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: [RESEND][PATCH 1/2] media: Add timberdale video-in driver
Thanks for the feedback, I will post an updated patch. Comments below.
On 09/08/2010 09:35 PM, Mauro Carvalho Chehab wrote:
Em 02-09-2010 08:56, Richard Röjfors escreveu:
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 video buffers to handle buffers against user space.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjforsrichard.rojf...@pelagicore.com
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f6e4d04..1afbe26 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
To compile this driver as a module, choose M here: the
module will be called hexium_gemini.
+config VIDEO_TIMBERDALE
+ tristate Support for timberdale Video In/LogiWIN
+ depends on VIDEO_V4L2 I2C
+ select TIMB_DMA
+ select VIDEO_ADV7180
+ select VIDEOBUF_DMA_CONTIG
+ ---help---
+ Add support for the Video In peripherial of the timberdale FPGA.
+
source drivers/media/video/cx88/Kconfig
source drivers/media/video/cx23885/Kconfig
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 40f98fb..c93af35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_MXB) += mxb.o
obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
new file mode 100644
index 000..1ccc620
--- /dev/null
+++ b/drivers/media/video/timblogiw.c
@@ -0,0 +1,877 @@
+/*
+ * timblogiw.c timberdale FPGA LogiWin Video In driver
+ * Copyright (c) 2009-2010 Intel 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA LogiWin Video In
+ */
+
+#includelinux/version.h
+#includelinux/platform_device.h
+#includelinux/slab.h
+#includelinux/dmaengine.h
+#includelinux/scatterlist.h
+#includelinux/interrupt.h
+#includelinux/list.h
+#includelinux/i2c.h
+#includemedia/v4l2-ioctl.h
+#includemedia/v4l2-device.h
+#includemedia/videobuf-dma-contig.h
+#includemedia/timb_video.h
+
+#define DRIVER_NAMEtimb-video
+
+#define TIMBLOGIWIN_NAME Timberdale Video-In
+#define TIMBLOGIW_VERSION_CODE 0x04
+
+#define TIMBLOGIW_LINES_PER_DESC 44
+#define TIMBLOGIW_MAX_VIDEO_MEM16
+
+#define TIMBLOGIW_VIDEO_FORMAT V4L2_PIX_FMT_UYVY
Hmm... why are you using a constant here? Does this device provide the standard
UYVY fourcc
format, or does it have a different (proprietary) format?
I will change to use the V4L2 define in the code instead of an own. The framegrabber follows the
standard.
If it uses the standard format, just use the standard definition. Otherwise, we
need to add a
new format to the V4L2 API, to make sure that userspace applications and libv4l
will properly
handle it.
+
+#define TIMBLOGIW_HAS_DECODER(lw) (lw-pdata.encoder.module_name)
+
+
+struct timblogiw {
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev; /* mutual exclusion */
+ struct mutexlock;
+ struct device *dev;
+ struct timb_video_platform_data pdata;
+ struct v4l2_subdev *sd_enc;/* encoder */
+ boolopened;
+};
+
+struct timblogiw_tvnorm {
+ v4l2_std_id std;
+ u16 width;
+ u16 height;
+ u8 fps;
+};
+
+struct timblogiw_fh {
+ struct videobuf_queue vb_vidq;
+ struct timblogiw_tvnorm const *cur_norm;
+ struct list_headcapture;
+ struct dma_chan *chan;
+ spinlock_t queue_lock; /* mutual exclusion */
+ unsigned intframe_count;
+};
+
+struct timblogiw_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct videobuf_buffer vb;
+
[PATCH 0/2 v2] media, mfd: Add timberdale video-in driver
To follow are two patches. The first adds the timberdale video-in driver to the media tree. The second adds it to the timberdale MFD driver. As Mauro pointed out earlier the patch to timberdale should be trivial so I hope Mauro can take the patches via his tree. Thanks --Richard -- 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/2 v2] media: Add timberdale video-in driver
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 video buffers to handle buffers against user space.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index f6e4d04..1afbe26 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -734,6 +734,15 @@ config VIDEO_HEXIUM_GEMINI
To compile this driver as a module, choose M here: the
module will be called hexium_gemini.
+config VIDEO_TIMBERDALE
+ tristate Support for timberdale Video In/LogiWIN
+ depends on VIDEO_V4L2 I2C
+ select TIMB_DMA
+ select VIDEO_ADV7180
+ select VIDEOBUF_DMA_CONTIG
+ ---help---
+ Add support for the Video In peripherial of the timberdale FPGA.
+
source drivers/media/video/cx88/Kconfig
source drivers/media/video/cx23885/Kconfig
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 40f98fb..c93af35 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/
obj-$(CONFIG_VIDEO_MXB) += mxb.o
obj-$(CONFIG_VIDEO_HEXIUM_ORION) += hexium_orion.o
obj-$(CONFIG_VIDEO_HEXIUM_GEMINI) += hexium_gemini.o
+obj-$(CONFIG_VIDEO_TIMBERDALE) += timblogiw.o
obj-$(CONFIG_VIDEOBUF_GEN) += videobuf-core.o
obj-$(CONFIG_VIDEOBUF_DMA_SG) += videobuf-dma-sg.o
diff --git a/drivers/media/video/timblogiw.c b/drivers/media/video/timblogiw.c
new file mode 100644
index 000..549c0be
--- /dev/null
+++ b/drivers/media/video/timblogiw.c
@@ -0,0 +1,881 @@
+/*
+ * timblogiw.c timberdale FPGA LogiWin Video In driver
+ * Copyright (c) 2009-2010 Intel 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA LogiWin Video In
+ */
+
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/slab.h
+#include linux/dmaengine.h
+#include linux/scatterlist.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/i2c.h
+#include media/v4l2-ioctl.h
+#include media/v4l2-device.h
+#include media/videobuf-dma-contig.h
+#include media/timb_video.h
+
+#define DRIVER_NAMEtimb-video
+
+#define TIMBLOGIWIN_NAME Timberdale Video-In
+#define TIMBLOGIW_VERSION_CODE 0x04
+
+#define TIMBLOGIW_LINES_PER_DESC 44
+#define TIMBLOGIW_MAX_VIDEO_MEM16
+
+#define TIMBLOGIW_HAS_DECODER(lw) (lw-pdata.encoder.module_name)
+
+
+struct timblogiw {
+ struct video_device video_dev;
+ struct v4l2_device v4l2_dev; /* mutual exclusion */
+ struct mutexlock;
+ struct device *dev;
+ struct timb_video_platform_data pdata;
+ struct v4l2_subdev *sd_enc;/* encoder */
+ boolopened;
+};
+
+struct timblogiw_tvnorm {
+ v4l2_std_id std;
+ u16 width;
+ u16 height;
+ u8 fps;
+};
+
+struct timblogiw_fh {
+ struct videobuf_queue vb_vidq;
+ struct timblogiw_tvnorm const *cur_norm;
+ struct list_headcapture;
+ struct dma_chan *chan;
+ spinlock_t queue_lock; /* mutual exclusion */
+ unsigned intframe_count;
+};
+
+struct timblogiw_buffer {
+ /* common v4l buffer stuff -- must be first */
+ struct videobuf_buffer vb;
+ struct scatterlist sg[16];
+ dma_cookie_tcookie;
+ struct timblogiw_fh *fh;
+};
+
+const struct timblogiw_tvnorm timblogiw_tvnorms[] = {
+ {
+ .std= V4L2_STD_PAL,
+ .width = 720,
+ .height = 576,
+ .fps= 25
+ },
+ {
+ .std= V4L2_STD_NTSC,
+ .width = 720,
+ .height = 480,
+ .fps= 30
+ }
+};
+
+static int timblogiw_bytes_per_line(const struct timblogiw_tvnorm *norm)
+{
+
[PATCH 2/2 v2] mfd: Add timberdale video-in driver to timberdale
This patch defines platform data for the video-in driver
and adds it to all configurations of timberdale.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
index ac59950..52a651b 100644
--- a/drivers/mfd/timberdale.c
+++ b/drivers/mfd/timberdale.c
@@ -40,6 +40,7 @@
#include linux/spi/mc33880.h
#include media/timb_radio.h
+#include media/timb_video.h
#include linux/timb_dma.h
@@ -238,7 +239,24 @@ static const __devinitconst struct resource
timberdale_uartlite_resources[] = {
},
};
-static const __devinitconst struct resource timberdale_radio_resources[] = {
+static __devinitdata struct i2c_board_info timberdale_adv7180_i2c_board_info =
{
+ /* Requires jumper JP9 to be off */
+ I2C_BOARD_INFO(adv7180, 0x42 1),
+ .irq = IRQ_TIMBERDALE_ADV7180
+};
+
+static __devinitdata struct timb_video_platform_data
+ timberdale_video_platform_data = {
+ .dma_channel = DMA_VIDEO_RX,
+ .i2c_adapter = 0,
+ .encoder = {
+ .module_name = adv7180,
+ .info = timberdale_adv7180_i2c_board_info
+ }
+};
+
+static const __devinitconst struct resource
+timberdale_radio_resources[] = {
{
.start = RDSOFFSET,
.end= RDSEND,
@@ -272,6 +290,18 @@ static __devinitdata struct timb_radio_platform_data
}
};
+static const __devinitconst struct resource timberdale_video_resources[] = {
+ {
+ .start = LOGIWOFFSET,
+ .end= LOGIWEND,
+ .flags = IORESOURCE_MEM,
+ },
+ /*
+ note that the frame buffer is located in DMA area
+ starting at 0x120
+ */
+};
+
static __devinitdata struct timb_dma_platform_data timb_dma_platform_data = {
.nr_channels = 10,
.channels = {
@@ -372,6 +402,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg0[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -430,6 +467,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg1[] = {
.resources = timberdale_mlogicore_resources,
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -478,6 +522,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg2[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
@@ -521,6 +572,13 @@ static __devinitdata struct mfd_cell
timberdale_cells_bar0_cfg3[] = {
.data_size = sizeof(timberdale_gpio_platform_data),
},
{
+ .name = timb-video,
+ .num_resources = ARRAY_SIZE(timberdale_video_resources),
+ .resources = timberdale_video_resources,
+ .platform_data = timberdale_video_platform_data,
+ .data_size = sizeof(timberdale_video_platform_data),
+ },
+ {
.name = timb-radio,
.num_resources = ARRAY_SIZE(timberdale_radio_resources),
.resources = timberdale_radio_resources,
diff --git a/drivers/mfd/timberdale.h b/drivers/mfd/timberdale.h
index c11bf6e..4412acd 100644
--- a/drivers/mfd/timberdale.h
+++ b/drivers/mfd/timberdale.h
@@ -23,7 +23,7 @@
#ifndef MFD_TIMBERDALE_H
#define MFD_TIMBERDALE_H
-#define DRV_VERSION0.2
+#define DRV_VERSION0.3
/* This driver only support versions = 3.8 and 4.0 */
#define TIMB_SUPPORTED_MAJOR 3
--
To unsubscribe from this list: send the line
Re: [GIT PULL FOR 2.6.37] new AF9015 devices
On 09/10/2010 03:54 AM, Stefan Lippers-Hollmann wrote: Another test and some further debugging of the IR core usedby the af9015 branch of this git tree led me to partial success. DVB-T functionality continues to be fine and I've now found the proper values for this remote, however once a key gets pressed, it is never released (unless another key gets pressed which is then struck or unless I ctrl-c it (only works on terminals). Likewise I'm not sure yet how to distinguish between the Cinergy T Dual and my Cinergy T RC MKII: Given that keys, once pressed, remain to be stuck, using both lirc's dev/input and without any dæmon trying to catch keypresses, I have not reached a functional configuration. That`s known issue. Chip configures USB HID polling interval wrongly and due to that HID starts repeating usually. There is USB-ID mapped quirks in HID driver to avoid that, but only for few ADF9015 IDs... I know how to fix that totally. I have been waiting new IR core merge before switch remote from broken HID + polling to memory read based one. But maybe I can do it just now and convert it later to IR core. 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: [GIT PULL FOR 2.6.37] new AF9015 devices
Hi
On Friday 10 September 2010, Antti Palosaari wrote:
sure yet how to distinguish between the
Cinergy T Dual and my Cinergy T RC MKII:
Given that keys, once pressed, remain to be stuck, using both lirc's
dev/input and without any dæmon trying to catch keypresses, I have not
reached a functional configuration.
That`s known issue. Chip configures USB HID polling interval wrongly and
due to that HID starts repeating usually. There is USB-ID mapped quir
Yes, now I see it. A quickly hacked test seems to improve the stuck key
events a lot (some keys still have a tendency to get stuck, but in general
it works):
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -45,6 +45,7 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD
},
{ USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016,
HID_QUIRK_FULLSPEED_INTERVAL },
+ { 0x0ccd, 0x0097, HID_QUIRK_FULLSPEED_INTERVAL },
{ USB_VENDOR_ID_ETURBOTOUCH, USB_DEVICE_ID_ETURBOTOUCH,
HID_QUIRK_MULTI_INPUT },
{ USB_VENDOR_ID_PANTHERLORD,
USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT |
HID_QUIRK_SKIP_OUTPUT_REPORTS },
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
Em 10-09-2010 04:38, Marek Szyprowski escreveu: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. Why? V4L2 API allows to have multiple applications opening and streaming. There's nothing wrong with that, since it is a common practice in Unix to allow multiple opens for the same device. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8 V5] Many fixes for in-kernel decoding and for the ENE driver
On Fri, Sep 10, 2010 at 10:08:24AM +0200, David Härdeman wrote: On Fri, September 10, 2010 04:01, Jarod Wilson wrote: Wuff. None of the three builds is at all stable on my laptop, but I can't actually point the finger at any of the three patchsets, since I'm getting spontaneous lockups doing nothing at all before even plugging in a receiver. I did however get occasional periods of a non-panicking (not starting X seems to help a lot). Initial results: If you get lockups without even plugging in a receiver, does that mean that the rc-core driver hasn't even been loaded at that point? Correct, no rc-core bits loaded at all at this point. -- 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
[PATCH 2/5] cx22702: Drop useless initializations to 0
These variables are either unconditionally set right afterward, or
already set to 0 by kzalloc.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Steven Toth st...@kernellabs.com
---
drivers/media/dvb/frontends/cx22702.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:01:34.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:23:48.0 +0200
@@ -508,7 +508,7 @@ static int cx22702_read_signal_strength(
{
struct cx22702_state *state = fe-demodulator_priv;
- u16 rs_ber = 0;
+ u16 rs_ber;
rs_ber = cx22702_readreg(state, 0x23);
*signal_strength = (rs_ber 8) | rs_ber;
@@ -519,7 +519,7 @@ static int cx22702_read_snr(struct dvb_f
{
struct cx22702_state *state = fe-demodulator_priv;
- u16 rs_ber = 0;
+ u16 rs_ber;
if (cx22702_readreg(state, 0xE4) 0x02) {
/* Realtime statistics */
rs_ber = (cx22702_readreg(state, 0xDE) 0x7F) 7
@@ -590,7 +590,6 @@ struct dvb_frontend *cx22702_attach(cons
/* setup the state */
state-config = config;
state-i2c = i2c;
- state-prevUCBlocks = 0;
/* check if the demod is there */
if (cx22702_readreg(state, 0x1f) != 0x3)
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] cx22702: Some things never change
The init sequence never changes so it can be marked const. Likewise,
cx22702_ops is a template and can thus be made read-only.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Steven Toth st...@kernellabs.com
---
drivers/media/dvb/frontends/cx22702.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c 2009-10-17
14:49:50.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-18
11:44:09.0 +0200
@@ -54,7 +54,7 @@ MODULE_PARM_DESC(debug, Enable verbose
#define dprintkif (debug) printk
/* Register values to initialise the demod */
-static u8 init_tab[] = {
+static const u8 init_tab[] = {
0x00, 0x00, /* Stop aquisition */
0x0B, 0x06,
0x09, 0x01,
@@ -576,7 +576,7 @@ static void cx22702_release(struct dvb_f
kfree(state);
}
-static struct dvb_frontend_ops cx22702_ops;
+static const struct dvb_frontend_ops cx22702_ops;
struct dvb_frontend *cx22702_attach(const struct cx22702_config *config,
struct i2c_adapter *i2c)
@@ -608,7 +608,7 @@ error:
}
EXPORT_SYMBOL(cx22702_attach);
-static struct dvb_frontend_ops cx22702_ops = {
+static const struct dvb_frontend_ops cx22702_ops = {
.info = {
.name = Conexant CX22702 DVB-T,
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC v1 0/7] Videobuf2 framework
On Fri, 2010-09-10 at 10:22 +0200, Hans Verkuil wrote: On Friday, September 10, 2010 09:38:44 Marek Szyprowski wrote: Hello, On 2010-09-10 13:27, Mauro Carvalho Chehab wrote: 1) it lacks implementation of read() method. This means that vivi driver has a regression, as it currently supports it. Yes, read() is not yet implemented. I guess it is not a feature that would be deprecated, right? Yes, there are no plans to deprecate it. Also, some devices like cx88 and bttv allows receiving simultaneous streams, one via mmap, and another via read(). This is used by some applications to allow recording video via ffmpeg/mencoder using read(), while the main application is displaying video using mmap. Well, in my opinion such devices should provide two separate /dev/videoX nodes rather than hacking with mmap and read access types. 1) It is in use so you can't just drop it. 2) The read() API is actually very useful for video devices that deal with compressed video streams. E.g. you can do things like 'cat /dev/video0 foo.mpg' It's been a long standing wish to convert the ivtv and cx18 drivers to videobuf, but it's always been too complex. With a new vb2 implementation it may become actually possible. Steven has mmap() mostly done for the cx18 YUV stream: http://www.kernellabs.com/hg/~stoth/cx18-videobuf/ I provided him a slew of comments on the patchset, The comments were mostly just grunt work to move things around and clean it up than any major flaws. I only saw one problem that must be fixed before it is usable for the masses, IIRC. Maybe if there's a test case for trying out videobuf2, it's the cx18 driver where we want to use mmap() for YUV and read() for MPEG. Note Steven's changes allow one to tell the CX23418 to send YUV data in YUYV format vs. HM12. Regards, Andy -- 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: DIKOM DK300: Kernel hangs after suspend to ram
On Tue, Sep 07, 2010 at 10:47:55PM +0200, andrea.amoros...@gmail.com wrote: I'm trying to use my Dikom DK-300 usb dvb-t device connected to an old laptop used as media player. The device works well but if I suspend the pc to ram (S3) when the Dikom usb stick is plugged in, the system hangs during the resume phase. So I've tried to create two scripts. The first one removes the driver before sleeping (the script is in the /etc/acpi/suspend.d directory) and the second one reloads it during the resume phase (this script is in /etc/acpi/resume.d directory). I've also inserted in the scripts some logs and it seems that the driver is correctly removed before the suspension, but then the pc hangs when resuming. Do you have some suggestion on how to resolve? I suspect that something in the GPIO setting is not corrected, but I don't know very well how to check that (now I've access to a windows xp virtualbox machine and a real windows vista system which maybe I can use to test/debug the correctness of the patch I postes some time ago). Can't help you with the driver, but for general suspend/resume debug: Did you try no_console_suspend to see if there are any errors? See Documentation/kernel-parameters.txt for more info. There are also some debugging hints in Documentation/power/s2ram.txt and basic-pm-debugging.txt. HTH Johannes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] cx22702: Clean up register access functions
Em 10-09-2010 10:27, Jean Delvare escreveu:
* Avoid temporary variables.
* Optimize success paths.
* Make error messages consistently verbose.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Steven Toth st...@kernellabs.com
---
drivers/media/dvb/frontends/cx22702.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c
2009-10-16 09:47:14.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c2009-10-16
09:47:45.0 +0200
@@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
ret = i2c_transfer(state-i2c, msg, 1);
- if (ret != 1)
+ if (ret != 1) {
As a suggestion, if you want to optimize success paths, you should use
unlikely() for error
checks. This tells gcc to optimize the code to avoid cache cleanups for the
likely condition:
if (unlikely(ret != 1)) {
printk(KERN_ERR
%s: error (reg == 0x%02x, val == 0x%02x, ret == %i)\n,
__func__, reg, data, ret);
+ return -1;
+ }
- return (ret != 1) ? -1 : 0;
+ return 0;
}
static u8 cx22702_readreg(struct cx22702_state *state, u8 reg)
{
int ret;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
+ u8 data;
struct i2c_msg msg[] = {
{ .addr = state-config-demod_address, .flags = 0,
- .buf = b0, .len = 1 },
+ .buf = reg, .len = 1 },
{ .addr = state-config-demod_address, .flags = I2C_M_RD,
- .buf = b1, .len = 1 } };
+ .buf = data, .len = 1 } };
ret = i2c_transfer(state-i2c, msg, 2);
- if (ret != 2)
- printk(KERN_ERR %s: readreg error (ret == %i)\n,
- __func__, ret);
+ if (ret != 2) {
Same comment applies here.
+ printk(KERN_ERR %s: error (reg == 0x%02x, ret == %i)\n,
+ __func__, reg, ret);
+ return 0;
+ }
- return b1[0];
+ return data;
}
static int cx22702_set_inversion(struct cx22702_state *state, int inversion)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5 v2] cx22702: Clean up register access functions
Hi Mauro,
On Fri, 10 Sep 2010 12:13:32 -0300, Mauro Carvalho Chehab wrote:
Em 10-09-2010 10:27, Jean Delvare escreveu:
* Avoid temporary variables.
* Optimize success paths.
* Make error messages consistently verbose.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Steven Toth st...@kernellabs.com
---
drivers/media/dvb/frontends/cx22702.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- linux-2.6.32-rc5.orig/drivers/media/dvb/frontends/cx22702.c
2009-10-16 09:47:14.0 +0200
+++ linux-2.6.32-rc5/drivers/media/dvb/frontends/cx22702.c 2009-10-16
09:47:45.0 +0200
@@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
ret = i2c_transfer(state-i2c, msg, 1);
- if (ret != 1)
+ if (ret != 1) {
As a suggestion, if you want to optimize success paths, you should use
unlikely() for error
checks. This tells gcc to optimize the code to avoid cache cleanups for the
likely condition:
if (unlikely(ret != 1)) {
Good point. Updated patch follows:
* * * * *
* Avoid temporary variables.
* Optimize success paths.
* Make error messages consistently verbose.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Steven Toth st...@kernellabs.com
---
Changes in v2:
* Use unlikely() to help gcc optimize the success paths.
drivers/media/dvb/frontends/cx22702.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
--- linux-2.6.35.orig/drivers/media/dvb/frontends/cx22702.c 2010-09-10
14:22:31.0 +0200
+++ linux-2.6.35/drivers/media/dvb/frontends/cx22702.c 2010-09-10
17:39:58.0 +0200
@@ -92,33 +92,36 @@ static int cx22702_writereg(struct cx227
ret = i2c_transfer(state-i2c, msg, 1);
- if (ret != 1)
+ if (unlikely(ret != 1)) {
printk(KERN_ERR
%s: error (reg == 0x%02x, val == 0x%02x, ret == %i)\n,
__func__, reg, data, ret);
+ return -1;
+ }
- return (ret != 1) ? -1 : 0;
+ return 0;
}
static u8 cx22702_readreg(struct cx22702_state *state, u8 reg)
{
int ret;
- u8 b0[] = { reg };
- u8 b1[] = { 0 };
+ u8 data;
struct i2c_msg msg[] = {
{ .addr = state-config-demod_address, .flags = 0,
- .buf = b0, .len = 1 },
+ .buf = reg, .len = 1 },
{ .addr = state-config-demod_address, .flags = I2C_M_RD,
- .buf = b1, .len = 1 } };
+ .buf = data, .len = 1 } };
ret = i2c_transfer(state-i2c, msg, 2);
- if (ret != 2)
- printk(KERN_ERR %s: readreg error (ret == %i)\n,
- __func__, ret);
+ if (unlikely(ret != 2)) {
+ printk(KERN_ERR %s: error (reg == 0x%02x, ret == %i)\n,
+ __func__, reg, ret);
+ return 0;
+ }
- return b1[0];
+ return data;
}
static int cx22702_set_inversion(struct cx22702_state *state, int inversion)
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.26 and up: 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:Fri Sep 10 19:00:12 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15139:6e0befab696a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1c1371c2fe53ded8ede3a0404c9415fbf3321328 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: WARNINGS linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.36-rc2-armv5: ERRORS linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35.3-armv5-davinci: WARNINGS linux-2.6.36-rc2-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35.3-armv5-ixp: WARNINGS linux-2.6.36-rc2-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35.3-armv5-omap2: WARNINGS linux-2.6.36-rc2-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS 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: WARNINGS linux-2.6.36-rc2-i686: ERRORS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.36-rc2-m32r: ERRORS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.36-rc2-mips: ERRORS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.36-rc2-powerpc64: ERRORS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS 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-rc2-x86_64: ERRORS linux-git-Module.symvers: ERRORS linux-git-armv5: ERRORS linux-git-armv5-davinci: ERRORS linux-git-armv5-ixp: ERRORS linux-git-armv5-omap2: ERRORS linux-git-i686: ERRORS linux-git-m32r: ERRORS linux-git-mips: ERRORS linux-git-powerpc64: ERRORS linux-git-x86_64: ERRORS spec: ERRORS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Kernel Oops with Kernel 2.6.32
Hello, Can really nobody give me an advice what I can do to make my Nova-T-Stick work with my Debian Kernel 2.6.32? I want to add the information that I had it working with my Debian Kernel 2.6.26 and sources from linuxtv.org which I downloaded on April 09, 2009. Regards Christoph Hello, I am running a Debian 2.6.32-Kernel (which by the way contains a lot of unresolved symbols in many dvb modules). As this kernel does not support my WinTV Nova-T USB-Stick, I downloaded the latest sources via the web interface from linuxtv.org, compiled the sources and installed the resulting modules. When I now connect the USB stick, the DVB modules are loaded correctly, but when I start an application to watch TV, I get a Kernel Oops. These lines from my kern.log show the kernel actions when connecting the device: Sep 8 19:51:16 superstar kernel: [ 3480.084012] usb 2-5: new high speed USB device using ehci_hcd and address 3 Sep 8 19:51:16 superstar kernel: [ 3480.217755] usb 2-5: New USB device found, idVendor=2040, idProduct=7050 Sep 8 19:51:16 superstar kernel: [ 3480.217758] usb 2-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Sep 8 19:51:16 superstar kernel: [ 3480.217760] usb 2-5: Product: Nova-T Stick Sep 8 19:51:16 superstar kernel: [ 3480.217761] usb 2-5: Manufacturer: Hauppauge Sep 8 19:51:16 superstar kernel: [ 3480.217762] usb 2-5: SerialNumber: 00 Sep 8 19:51:16 superstar kernel: [ 3480.217849] usb 2-5: configuration #1 chosen from 1 choice Sep 8 19:51:16 superstar kernel: [ 3480.332785] dib0700: loaded with support for 14 different device-types Sep 8 19:51:16 superstar kernel: [ 3480.333846] dvb-usb: found a 'Hauppauge Nova-T Stick' in cold state, will try to load a firmware Sep 8 19:51:16 superstar kernel: [ 3480.333851] usb 2-5: firmware: requesting dvb-usb-dib0700-1.20.fw Sep 8 19:51:16 superstar kernel: [ 3480.439083] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' Sep 8 19:51:17 superstar kernel: [ 3480.640502] dib0700: firmware started successfully. Sep 8 19:51:17 superstar kernel: [ 3481.144141] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state. Sep 8 19:51:17 superstar kernel: [ 3481.144540] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Sep 8 19:51:17 superstar kernel: [ 3481.144639] DVB: registering new adapter (Hauppauge Nova-T Stick) Sep 8 19:51:17 superstar kernel: [ 3481.480505] DVB: registering adapter 0 frontend 0 (DiBcom 7000MA/MB/PA/PB/MC)... Sep 8 19:51:17 superstar kernel: [ 3481.498377] MT2060: successfully identified (IF1 = 1218) Sep 8 19:51:18 superstar kernel: [ 3481.975455] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:02.1/usb2/2-5/input/input6 Sep 8 19:51:18 superstar kernel: [ 3481.975500] dvb-usb: schedule remote query interval to 50 msecs. Sep 8 19:51:18 superstar kernel: [ 3481.975503] dvb-usb: Hauppauge Nova-T Stick successfully initialized and connected. Sep 8 19:51:18 superstar kernel: [ 3481.975777] usbcore: registered new interface driver dvb_usb_dib0700 These lines from my kern.log show the Oops event: Sep 8 19:51:28 superstar kernel: [ 3492.321914] BUG: unable to handle kernel NULL pointer dereference at 0012 Sep 8 19:51:28 superstar kernel: [ 3492.321920] IP: [a015e3db] i2c_transfer+0x1c/0xc0 [i2c_core] Sep 8 19:51:28 superstar kernel: [ 3492.321928] PGD 1b8e69067 PUD 1b8e6a067 PMD 0 Sep 8 19:51:28 superstar kernel: [ 3492.321932] Oops: [#1] SMP Sep 8 19:51:28 superstar kernel: [ 3492.321934] last sysfs file: /sys/devices/pci:00/:00:02.1/usb2/2-5/input/input6/capabilities/sw Sep 8 19:51:28 superstar kernel: [ 3492.321936] CPU 0 Sep 8 19:51:28 superstar kernel: [ 3492.321938] Modules linked in: mt2060 dvb_usb_dib0700 dib7000p dib0090 dib7000m dib0070 dvb_usb dib8000 dvb_core dib30 00mc dibx000_common fglrx(P) binfmt_misc rfcomm l2cap crc16 bluetooth rfkill vboxnetadp vboxnetflt vboxdrv battery ppdev lp ext3 jbd mbcache xfs exportfs r eiserfs hwmon_vid eeprom firewire_sbp2 firewire_core crc_itu_t loop snd_hda_codec_atihdmi parport_pc parport psmouse evdev serio_raw snd_emu10k1_synth snd_ emux_synth snd_seq_virmidi snd_seq_midi_emul snd_hda_intel snd_hda_codec snd_emu10k1 snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss snd_seq_midi snd_pcm snd_rawmidi snd_util_mem asus_atk0110 snd_seq_midi_event snd_hwdep snd_seq snd_timer snd_seq_device emu10k1_gp pcspkr gameport snd snd_page_alloc soundcor e k8temp edac_core edac_mce_amd button processor i2c_nforce2 i2c_core jfs dm_mirror dm_region_hash dm_log dm_snapshot dm_mod sg sr_mod cdrom sd_mod crc_t10 dif ata_generic floppy fan pata_amd sata_nv ehci_hcd ohci_hcd libata thermal forcedeth thermal_sys scsi_mod usbcore nls_base [last unloaded: scsi_wait_scan ] Sep 8 19:51:28 superstar kernel: [ 3492.321984] Pid: 26841, comm: kaffeine Tainted: P 2.6.32-bpo.5-amd64 #1 System Product Name Sep 8
[PATCH v2 4/6] SoC Camera: add support for g_parm / s_parm operations
This patch adds support for g_parm / s_parm operations to the SoC Camera
framework. It is usefull for checking/setting camera frame rate.
Example usage can be found in the previous patch from this series,
SoC Camera: add driver for OV6650 sensor.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
drivers/media/video/soc_camera.c | 18 ++
1 file changed, 18 insertions(+)
diff -upr linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c
linux-2.6.36-rc3/drivers/media/video/soc_camera.c
--- linux-2.6.36-rc3.orig/drivers/media/video/soc_camera.c 2010-09-03
22:29:44.0 +0200
+++ linux-2.6.36-rc3/drivers/media/video/soc_camera.c 2010-09-03
22:34:03.0 +0200
@@ -1148,6 +1148,20 @@ static int default_s_crop(struct soc_cam
return v4l2_subdev_call(sd, video, s_crop, a);
}
+static int default_g_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, g_parm, parm);
+}
+
+static int default_s_parm(struct soc_camera_device *icd,
+ struct v4l2_streamparm *parm)
+{
+ struct v4l2_subdev *sd = soc_camera_to_subdev(icd);
+ return v4l2_subdev_call(sd, video, s_parm, parm);
+}
+
static void soc_camera_device_init(struct device *dev, void *pdata)
{
dev-platform_data = pdata;
@@ -1179,6 +1193,10 @@ int soc_camera_host_register(struct soc_
ici-ops-get_crop = default_g_crop;
if (!ici-ops-cropcap)
ici-ops-cropcap = default_cropcap;
+ if (!ici-ops-set_parm)
+ ici-ops-set_parm = default_s_parm;
+ if (!ici-ops-get_parm)
+ ici-ops-get_parm = default_g_parm;
mutex_lock(list_lock);
list_for_each_entry(ix, hosts, list) {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 5/6] OMAP1: Amstrad Delta: add support for camera
This patch adds configuration data and initialization code required for camera
support to the Amstrad Delta board.
Three devices are declared: SoC camera, OMAP1 camera interface and OV6650
sensor.
Default 12MHz clock has been selected for driving the sensor. Pixel clock has
been limited to get reasonable frame rates, not exceeding the board
capabilities. Since both devices (interface and sensor) support both pixel
clock polarities, decision on polarity selection has been left to drivers.
Interface GPIO line has been found not functional, thus not configured.
Created and tested against linux-2.6.36-rc3.
Works on top of previous patches from the series, at least 1/6, 2/6 and 3/6.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/board-ams-delta.c | 45 ++
1 file changed, 45 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
@@ -19,6 +19,8 @@
#include linux/platform_device.h
#include linux/serial_8250.h
+#include media/soc_camera.h
+
#include asm/serial.h
#include mach/hardware.h
#include asm/mach-types.h
@@ -32,6 +34,7 @@
#include plat/usb.h
#include plat/board.h
#include plat/common.h
+#include mach/camera.h
#include mach/ams-delta-fiq.h
@@ -213,10 +216,37 @@ static struct platform_device ams_delta_
.id = -1
};
+static struct i2c_board_info ams_delta_camera_board_info[] = {
+ {
+ I2C_BOARD_INFO(ov6650, 0x60),
+ },
+};
+
+static struct soc_camera_link __initdata ams_delta_iclink = {
+ .bus_id = 0,/* OMAP1 SoC camera bus */
+ .i2c_adapter_id = 1,
+ .board_info = ams_delta_camera_board_info[0],
+ .module_name= ov6650,
+};
+
+static struct platform_device ams_delta_camera_device = {
+ .name = soc-camera-pdrv,
+ .id = 0,
+ .dev= {
+ .platform_data = ams_delta_iclink,
+ },
+};
+
+static struct omap1_cam_platform_data ams_delta_camera_platform_data = {
+ .camexclk_khz = 12000,/* default 12MHz clock, no extra DPLL */
+ .lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
+};
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
ams_delta_led_device,
+ ams_delta_camera_device,
};
static void __init ams_delta_init(void)
@@ -225,6 +255,20 @@ static void __init ams_delta_init(void)
omap_cfg_reg(UART1_TX);
omap_cfg_reg(UART1_RTS);
+ /* parallel camera interface */
+ omap_cfg_reg(H19_1610_CAM_EXCLK);
+ omap_cfg_reg(J15_1610_CAM_LCLK);
+ omap_cfg_reg(L18_1610_CAM_VS);
+ omap_cfg_reg(L15_1610_CAM_HS);
+ omap_cfg_reg(L19_1610_CAM_D0);
+ omap_cfg_reg(K14_1610_CAM_D1);
+ omap_cfg_reg(K15_1610_CAM_D2);
+ omap_cfg_reg(K19_1610_CAM_D3);
+ omap_cfg_reg(K18_1610_CAM_D4);
+ omap_cfg_reg(J14_1610_CAM_D5);
+ omap_cfg_reg(J19_1610_CAM_D6);
+ omap_cfg_reg(J18_1610_CAM_D7);
+
iotable_init(ams_delta_io_desc, ARRAY_SIZE(ams_delta_io_desc));
omap_board_config = ams_delta_config;
@@ -236,6 +280,7 @@ static void __init ams_delta_init(void)
ams_delta_latch2_write(~0, 0);
omap1_usb_init(ams_delta_usb_config);
+ omap1_set_camera_info(ams_delta_camera_platform_data);
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 6/6] OMAP1: Amstrad Delta: add camera controlled LEDS trigger
This patch extends the Amstrad Delta camera support with LEDS trigger that can
be used for automatic control of the on-board camera LED. The led turns on
automatically on camera device open and turns off on camera device close.
Created and tested against linux-2.6.36-rc3.
Works on top of patch 5/6, OMAP1: Amstrad Delta: add support for on-board
camera
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Having no comments received on v1 of this patch, I assume nobody could see any
benefit if I implemented this idea at the SoC camera or OMAP1 camera level,
so I'm leaveing it as an Amstrad Delta only feature, as it originally was for
v1.
Thanks,
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3.
arch/arm/mach-omap1/board-ams-delta.c | 24
1 file changed, 24 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c
linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:01:24.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/board-ams-delta.c 2010-09-10
22:08:29.0 +0200
@@ -16,6 +16,7 @@
#include linux/init.h
#include linux/input.h
#include linux/interrupt.h
+#include linux/leds.h
#include linux/platform_device.h
#include linux/serial_8250.h
@@ -222,11 +223,30 @@ static struct i2c_board_info ams_delta_c
},
};
+#ifdef CONFIG_LEDS_TRIGGERS
+DEFINE_LED_TRIGGER(ams_delta_camera_led_trigger);
+
+static int ams_delta_camera_power(struct device *dev, int power)
+{
+ /*
+* turn on camera LED
+*/
+ if (power)
+ led_trigger_event(ams_delta_camera_led_trigger, LED_FULL);
+ else
+ led_trigger_event(ams_delta_camera_led_trigger, LED_OFF);
+ return 0;
+}
+#else
+#define ams_delta_camera_power NULL
+#endif
+
static struct soc_camera_link __initdata ams_delta_iclink = {
.bus_id = 0,/* OMAP1 SoC camera bus */
.i2c_adapter_id = 1,
.board_info = ams_delta_camera_board_info[0],
.module_name= ov6650,
+ .power = ams_delta_camera_power,
};
static struct platform_device ams_delta_camera_device = {
@@ -281,6 +301,10 @@ static void __init ams_delta_init(void)
omap1_usb_init(ams_delta_usb_config);
omap1_set_camera_info(ams_delta_camera_platform_data);
+#ifdef CONFIG_LEDS_TRIGGERS
+ led_trigger_register_simple(ams_delta_camera,
+ ams_delta_camera_led_trigger);
+#endif
platform_add_devices(ams_delta_devices, ARRAY_SIZE(ams_delta_devices));
#ifdef CONFIG_AMS_DELTA_FIQ
--
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
[RESEND][PATCH v2 2/6] OMAP1: Add support for SoC camera interface
This patch adds support for SoC camera interface to OMAP1 devices.
Created and tested against linux-2.6.36-rc3 on Amstrad Delta.
For successfull compilation, requires a header file provided by PATCH 1/6 from
this series, SoC Camera: add driver for OMAP1 camera interface.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
Resend because of wrapped lines, sorry.
Janusz
v1-v2 changes:
- no functional changes,
- refreshed against linux-2.6.36-rc3
arch/arm/mach-omap1/devices.c | 43 ++
arch/arm/mach-omap1/include/mach/camera.h |8 +
2 files changed, 51 insertions(+)
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c
linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/devices.c 2010-09-03
22:29:00.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/devices.c 2010-09-09
18:42:30.0 +0200
@@ -15,6 +15,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/dma-mapping.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -25,6 +26,7 @@
#include mach/gpio.h
#include plat/mmc.h
#include plat/omap7xx.h
+#include mach/camera.h
/*-*/
@@ -191,6 +193,47 @@ static inline void omap_init_spi100k(voi
}
#endif
+
+#define OMAP1_CAMERA_BASE 0xfffb6800
+
+static struct resource omap1_camera_resources[] = {
+ [0] = {
+ .start = OMAP1_CAMERA_BASE,
+ .end= OMAP1_CAMERA_BASE + OMAP1_CAMERA_IOSIZE - 1,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = INT_CAMERA,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 omap1_camera_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device omap1_camera_device = {
+ .name = omap1-camera,
+ .id = 0, /* This is used to put cameras on this interface */
+ .dev= {
+ .dma_mask = omap1_camera_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+ .num_resources = ARRAY_SIZE(omap1_camera_resources),
+ .resource = omap1_camera_resources,
+};
+
+void __init omap1_set_camera_info(struct omap1_cam_platform_data *info)
+{
+ struct platform_device *dev = omap1_camera_device;
+ int ret;
+
+ dev-dev.platform_data = info;
+
+ ret = platform_device_register(dev);
+ if (ret)
+ dev_err(dev-dev, unable to register device: %d\n, ret);
+}
+
+
/*-*/
static inline void omap_init_sti(void) {}
diff -upr linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h
--- linux-2.6.36-rc3.orig/arch/arm/mach-omap1/include/mach/camera.h
2010-09-03 22:34:03.0 +0200
+++ linux-2.6.36-rc3/arch/arm/mach-omap1/include/mach/camera.h 2010-09-09
18:42:30.0 +0200
@@ -0,0 +1,8 @@
+#ifndef __ASM_ARCH_CAMERA_H_
+#define __ASM_ARCH_CAMERA_H_
+
+#include media/omap1_camera.h
+
+extern void omap1_set_camera_info(struct omap1_cam_platform_data *);
+
+#endif /* __ASM_ARCH_CAMERA_H_ */
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
