DVB-C Twinhan DCT-CI (VP-2031) ... card can't get a lock
As the subject says I am using a DVB-C PCI card from Twinhan. Model is VP-2031. The kernel is 2.6.32 on Debian squeeze (v6.0). So first of all this card is over 5 years old and has had various emails sent to linux-dvb mailing list. However in my situation I can't seem to get it working. The card worked on a Vista 64-bit machine, so it isn't broken. The card also has a valid RF input as I tried it with a DVB-C Set-Top-Box. At first I was receiving checksum errors, I fixed this by following Manu's instructions from http://www.mail-archive.com/linux-...@linuxtv.org/msg18716.html As soon as I changed it, I wasn't getting any checksum errors, however I couldn't tune to a frequency. When tuning to frequency 466MHz with 6875 kS/s the dst driver sends the following byte sequence 09 00 07 1c 50 00 1a db 00 8f. The response from the card is 09 00 00 00 00 00 1a db 00 02. Now I have no idea what a proper response should look like, but it seems that the card returned back everything exactly the same except the frequency ... 07 1c 50 = 466000kHz. The symbol rate is ok 1a db = 6875 My problem is almost exactly the same as http://www.spinics.net/lists/linux-dvb/msg02032.html, but the fix that was posted is wrong. http://www.spinics.net/lists/linux-dvb/msg02101.html The fix changed the where decode_lock is being read from. It read it from the 1st byte of the symbol rate. I hope anyone with a bit more knowledge on this can help with this. Regards Igor Below you can see the module options, the dmesg output when the card was initialized and a test with scan and czap. * Loading the necessary module * # modprobe -v dvb_bt8xx insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/video/tveeprom.ko insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/video/btcx-risc.ko insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/video/videodev.ko insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/video/v4l2-common.ko insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/video/bt8xx/bttv.ko i2c_hw=10 i2c_debug=10 bttv_verbose=10 bttv_debug=10 insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/dvb/bt8xx/bt878.ko debug=10 verbose=10 insmod /lib/modules/2.6.32-5-686/kernel/drivers/media/dvb/dvb-core/dvb-core.ko debug=10 dvbdev_debug=10 * dmesg output * [15760.720575] bt878_mem: 0xfcfb. [15760.720603] bt878 :01:00.1: PCI INT A disabled [15760.723779] bttv0: unloading [15760.747565] Linux video capture interface: v2.00 [15760.761286] bttv: driver version 0.9.18 loaded [15760.761290] bttv: using 8 buffers with 2080k (520 pages) each for capture [15760.761345] bttv: Bt8xx card found (0). [15760.761360] bttv0: Bt878 (rev 17) at :01:00.0, irq: 17, latency: 64, mmio: 0xfdefe000 [15760.761496] bttv0: detected: Twinhan VisionPlus DVB [card=113], PCI subsystem ID is 1822:0001 [15760.761499] bttv0: using: Twinhan DST + clones [card=113,autodetected] [15760.761502] IRQ 17/bttv0: IRQF_DISABLED is not guaranteed on shared IRQs [15760.761721] bttv0: risc main @ 350b4000 [15760.761728] bttv0: gpio: en=, out= in=00f100fd [init] [15760.761861] bttv0: tuner absent [15760.761881] bttv0: add subdevice dvb0 [15760.762162] bt-i2c:bt-i2c:bt-i2c:bt-i2c:bt-i2c: ERR: -5 [15760.763985] bt878: AUDIO driver version 0.0.0 loaded [15760.764627] bt878: Bt878 AUDIO function found (0). [15760.764642] bt878 :01:00.1: PCI INT A - GSI 17 (level, low) - IRQ 17 [15760.764646] bt878_probe: card id=[0x11822],[ Twinhan VisionPlus DVB ] has DVB functions. [15760.764654] bt878(0): Bt878 (rev 17) at 01:00.1, irq: 17, latency: 64, memory: 0xfdeff000 [15760.764797] IRQ 17/bt878: IRQF_DISABLED is not guaranteed on shared IRQs [15760.773205] dvb_bt8xx: identified card0 as bttv0 [15760.773209] DVB: registering new adapter (bttv0) [15760.773683] DVB: register adapter0/demux0 @ minor: 0 (0x00) [15760.773715] DVB: register adapter0/dvr0 @ minor: 1 (0x01) [15760.773746] DVB: register adapter0/net0 @ minor: 2 (0x02) [15760.880019] dst(0) dst_comm_init: Initializing DST. [15760.880027] dst(0) dst_gpio_outb: mask=[], enbb=[0001], outhigh=[] [15760.882020] dst(0) rdc_reset_state: Resetting state machine [15760.882025] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[] [15760.896013] dst(0) dst_gpio_outb: mask=[0002], enbb=[0002], outhigh=[0002] [15761.012007] writing [ 00 06 00 00 00 00 00 fa ] [15761.012019] bt-i2c: W aa 00 06 00 00 00 00 00 fa [15761.013196] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [15761.014194] bt-i2c: R ab =ff [15761.014428] dst(0) read_dst: reply is 0xff [15761.028021] dst(0) dst_wait_dst_ready: dst wait ready after 1 [15761.028027] bt-i2c: R ab =00 =44 =43 =54 =2d =43 =49 =6c [15761.029206] dst(0) read_dst: reply is 0x0 [15761.029210] 0x44 0x43 0x54 0x2d 0x43 0x49 0x6c [15761.029219] dst(0) dst_gpio_outb: mask=[], enbb=[], outhigh=[] [15761.030218] dst(0) dst_get_device_id: Recognise [DCT-CI] [15761.030223] dst(0) dst_type_print: DST type:
V4L2 radio drivers for TI-WL7
Hi, We have/in process of developing a V4L2 driver for the FM Radio on the Texas Instruments WiLink 7 module. For transport/communication with the chip, we intend to use the shared transport driver currently staged in mainline at drivers/staging/ti-st/. To which tree should I generate patches against? is the tree git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git fine ? to be used with the v4l_for_2.6.35 branch ? Also, this is over the UART/TTY unlike the WL1273 i2c mfd driver... Please suggest. Thanks Regards, Pavan Savoy -- 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: macbook webcam no longer works on .35-rc
On Wed, 2010-06-30 at 23:11 +0200, Johannes Berg wrote: I'm pretty sure this was a regression in .34, but haven't checked right now, can bisect when I find time but wanted to inquire first if somebody had ideas. All I get is: [57372.078968] uvcvideo: Failed to query (130) UVC control 5 (unit 3) : -32 (exp. 1). Didn't have to bisect it. The problem is caused by commit 59529081e092506edb81a42d914e2d0522f65ca7 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Sat Jan 23 06:30:20 2010 -0300 V4L/DVB: uvcvideo: Cache control min, max, res and def query results which reverts cleanly, but then the driver doesn't compile and one also needs to revert commit cf7a50eeb6f462a0b7d1619fcb27a727a2981769 Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Sun Apr 25 16:27:14 2010 -0300 V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0 and commit e54532e591cd5b9ce77dbc8d9786ae9f600f101a Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date: Sat Jan 23 07:07:53 2010 -0300 V4L/DVB: uvcvideo: Clamp control values to the minimum and maximum values in that order. These are commits introduced in the .34/.35 cycles. Please fix. Can we revert things that are regressions pre-dating the current kernel version? 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
TerraTec Cinergy Hybrid Stick [0ccd:00a5] - worth trying?
Hi, I'm really pissed that whenever I try to find a TV-USB-stick (analog in my case), it's not in the shops any longer or it's not listed on the linuxtv validated sticks. The names of the USB sticks are only slightly changed, which may mean, this is only a rebranding or a completely new hardware (even without name change). Therefore is the support for these sticks kind of a lottery and one first have to buy them, check the USB id and whether it's supported or not. Seems, that the product cycles are too short for us linux-users :( Ok, genug gekotzt, now to the facts: I've purchased the USB-stick TerraTec Cinergy Hybrid Stick, although it's a little older (1/2 year) it is still in the shops. Vendor: TerraTec Model: Cinergy Hybrid Stick Vendor/Product ID: 0ccd:00a5 Supports DVB-T and Analog Cable (tested already successful on Windows) I'm using the latest snapshot of v4l-dvb (incl. experimental driver) on Ubuntu 10.04 Tests made: - plug in and out into USB 2.0 slot Only the message appears in dmesg, that an USB device is connected or disconnected when pluggin in or out. When loading the driver by hand (i've tried em28xx) there is nothing which relates to this stick: The driver will not unload when unplugging the stick, nor loaded when the stick is plugged in. To be honest I have no clue, what kind of chips are used in there and which one to load - that does not happen automatically. My question now is: is it worth trying to have a look at this hardware since there already seem to be some in the field? Or is it working and I don't know? Or has everybody already given up? Thanks for help. I'm also open for providing some information and tests with this stick if anybody is interested in it. Thanks, Dirk -- GMX DSL: Internet-, Telefon- und Handy-Flat ab 19,99 EUR/mtl. Bis zu 150 EUR Startguthaben inklusive! http://portal.gmx.net/de/go/dsl -- 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: Question on uvcvideo driver's power management
Hi Samuel, On Tuesday 29 June 2010 12:12:13 Samuel Xu wrote: Question on uvcvideo driver's power management: Q1: We found some USB material mentioned : Relationship between ACPI Dx states and USB PM states (active/suspended) is orthogonal. Suspend/resume might not effect device Dx state(e.g. D0/D1/D3). Is it a correct statement for general usb device and uvcvideo usb device? Q2: How to tell USB uvcvideo device’s ACPI Dx state. It seems lsusb can’t tell us those info. (lspci works for PCI device’s Dx state) Q3: How to tell USB uvcvideo device’s suspension state? will any query via urb will cause resume of uvcvideo device? Q4: should USB uvcvideo device driver response to do some device-specific power action (e.g. device register writing) to put a specific USB camera into low power state when responding to suspend action? (I didn't find such device-specific power code inside uvcvideo src code) Q5: If Q4 is Yes, should device vendor respond for those device-specific code? Power management for UVC devices is handled at the USB level. There's nothing UVC-specific to it. You've received answers to those questions on the linux- usb list so I won't go into a lot of details (there are developers more knowledgeable about USB power management on linux-usb). In a nutshell, USB devices have a single suspended state instead of ACPI Dx states. Devices must suspend themselves if they don't see any bus activity for at 3ms (idle bus). Activity doesn't require the driver to perform any action explicitly, the USB host controller will send a Start Of Frame packet every millisecond on its own. Stopping activity is achieved by sending a SET_FEATURE(PORT_SUSPEND) request to the hub the device is connected to (either root hub, or external hub) asking it to stop USB traffic on the device port. Resuming activity is then done with the CLEAR_FEATURE(PORT_SUSPEND) request. The job of the driver, before suspend, is to save the device state (if required) and kill all URBs. On resume the driver will then restore the device state and resubmit the URBs. -- 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: Question on newly build uvcvideo.ko
Hi Samuel, On Friday 25 June 2010 12:01:42 Samuel Xu wrote: One correction: After make and make install, uvcvideo module can't auto loaded any more. I must manually insmod uvcvideo.ko to load it. Here is lsmod result, I never have chance to make uvcvideo module used bit to 1 :( [r...@user-desktop uvc]# lsmod Module Size Used by uvcvideo 46182 0 rt2860sta 406917 1 battery 7968 0 After 2 questions, there is dmesg from uvcvideo after my manually insmod, any idea? Another question is: If newest v4l code tree has been advanced much than src tree inside 2.6.33 kernel, which v4l src label is nearest from src tree inside 2.6.33 kernel? 3rdd question is: if I want to build v4l driver from src inside 2.6.33 kernel directly. How should I do? (I tried to make menuconfig and make modules from a clean kernel, while insmod the newly build uvcvideo.ko reports: insmod: error inserting './uvcvideo.ko': -1 Invalid module format You can checkout the latest v4l-dvb source from mercurial (or download a snapshot), and run make SRCDIR=/path/to/your/kernel/2.6.33/source/tree Make sure your kernel source tree has been configured (you might need to compile it as well, not sure about that). [ 78.446109] uvcvideo: Found UVC 1.00 device CNF7129 (04f2:b071) [ 78.462540] [ cut here ] [ 78.462569] WARNING: at drivers/media/video/v4l2-dev.c:420 __video_register_device+0x44/0x3d7() [snip] I'm pretty sure this is a mismatch between the uvcvideo and videodev kernel modules. Please reinstall the whole v4l-dvb subsystem, either from your distribution packages or from the v4l-dvb repository. Make sure both the uvcvideo driver and the v4l-dvb core come from the same source. -- 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
Support for cx24120?
Hi, I recently got an TechniSat SkyStar S2 [13d0:2103] which uses an FlexCop2-Bridge, which is supported, but an unsupported? CX24120 Demod. (This card is rather cheap, 45€ LowProfile incl. IR-Remote, otherwise i'd just have sent it back.) TechniSat provides a Binary Driver ( http://www.technisat-daun.de/download/soft/soft_linux-driver_12-2008_6611.zip ) which contains an cx24120 blob (32/64) +Firmware, but requires an Dec2008 V4L-checkout ( I need a newer rev for my E3C EC168 USB-DVBT-Stick) Anyway I can get this working? Can I help in any way? Thanks, Paul lspci Network controller: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card (rev 02) Subsystem: Techsan Electronics Co Ltd B2C2 FlexCopII DVB chip / Technisat SkyStar2 DVB card Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: Memory at feae (32-bit, non-prefetchable) [size=64K] Region 1: I/O ports at bc00 [size=32] Kernel modules: b2c2-flexcop-pci dmesg [ 17.355268] b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully [ 17.357454] flexcop-pci: will use the HW PID filter. [ 17.357460] flexcop-pci: card revision 2 [ 17.357469] b2c2_flexcop_pci :05:04.0: PCI INT A - GSI 17 (level, low) - IRQ 17 [ 17.391402] DVB: registering new adapter (FlexCop Digital TV device) [ 17.393043] b2c2-flexcop: MAC address = xx:xx:xx:xx:d0:02 [ 17.393555] CX24123: wrong demod revision: 84 [ 17.628997] mt352_read_register: readreg error (reg=127, ret==-121) [ 17.636769] nxt200x: nxt200x_readbytes: i2c read error (addr 0x0a, err == -121) [ 17.636772] Unknown/Unsupported NXT chip: 00 00 00 00 00 [ 17.645121] lgdt330x: i2c_read_demod_bytes: addr 0x59 select 0x02 error (ret == -121) [ 17.661886] stv0297_readreg: readreg error (reg == 0x80, ret == -121) [ 17.671433] mt312_read: ret == -121 [ 17.671508] b2c2-flexcop: no frontend driver found for this B2C2/FlexCop adapter [ 17.671805] b2c2_flexcop_pci :05:04.0: PCI INT A disabled -- 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: TerraTec Cinergy Hybrid Stick [0ccd:00a5] - worth trying?
Dirk Langner dirko...@gmx.de writes:
I'm really pissed that whenever I try to find a TV-USB-stick (analog
in my case), it's not in the shops any longer or it's not listed on
the linuxtv validated sticks. The names of the USB sticks are only
slightly changed, which may mean, this is only a rebranding or a
completely new hardware (even without name change). Therefore is the
support for these sticks kind of a lottery and one first have to buy
them, check the USB id and whether it's supported or not. Seems, that
the product cycles are too short for us linux-users :(
Ok, genug gekotzt, now to the facts: I've purchased the USB-stick
TerraTec Cinergy Hybrid Stick, although it's a little older (1/2 year)
it is still in the shops.
Well, Terratec are more helpful than most vendors, so that might not be
a bad choice. Did you see http://linux.terratec.de/ ?
I'm afraid your card isn't there, but...
Vendor: TerraTec
Model: Cinergy Hybrid Stick
Vendor/Product ID: 0ccd:00a5
Supports DVB-T and Analog Cable (tested already successful on Windows)
This card is supported by the tm6000 driver currently in staging:
bj...@canardo:~$ grep 00A5 /usr/local/src/git/linux-2.6/drivers/staging/tm6000/*
/usr/local/src/git/linux-2.6/drivers/staging/tm6000/tm6000-cards.c: {
USB_DEVICE(0x0ccd, 0x00A5), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
You may want to try that. I have no idea how well it works, if at all...
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
Is there any limit in stb6100 driver that prevents tuning SR 1 Msps
Hi, i tried tuning to a channel that has a SR 1 Msps in DVB-S with szap and I get using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' FE_SET_FRONTEND failed: Invalid argument is there any limit in driver that doesn't allow my TT S2-3200 to try to tune into that tranponder? I know according to specification card only supports tuning from 1 Mbps - 30 Mbps, but that's specification for most cards. Most of the cards can also lock at signals with lower SRs. There are some low SR channels on Astra 3a http://flysat.com/astra23.php 12660 V and 12661 V with Technisat Skystar 2 it's working without a problem. kind regards Newspaperman -- 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] v4l: Add MPC5121e VIU video capture driver
Adds support for Video-In (VIU) unit of Freescale
MPC5121e. The driver supports RGB888/RGB565 formats,
capture and overlay on MPC5121e DIU frame buffer.
Signed-off-by: Hongjun Chen hong-jun.c...@freescale.com
Signed-off-by: Anatolij Gustschin ag...@denx.de
---
Please review and consider for inclusion in 2.6.36. Thanks!
Changes since first patch version:
- fixed problems with DMA auto-deinterlace while capturing
- reworked and simplified interrupt handler
- moved a number of global variables into driver's private
structure
- reworked and simplified overlay enable code
- reworked viu_dma_stop() to ensure the DMA transfer really
stops after calling
drivers/media/video/Kconfig | 12 +
drivers/media/video/Makefile |1 +
drivers/media/video/fsl-viu.c | 1632 +
3 files changed, 1645 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/fsl-viu.c
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index bdbc9d3..45bef41 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -557,6 +557,18 @@ config VIDEO_DAVINCI_VPIF
To compile this driver as a module, choose M here: the
module will be called vpif.
+config VIDEO_VIU
+ tristate Freescale VIU Video Driver
+ depends on VIDEO_V4L2 PPC_MPC512x
+ select VIDEOBUF_DMA_CONTIG
+ default y
+ ---help---
+ Support for Freescale VIU video driver. This device captures
+ video data, or overlays video on DIU frame buffer.
+
+ Say Y here if you want to enable VIU device on MPC5121e Rev2+.
+ In doubt, say N.
+
config VIDEO_VIVI
tristate Virtual Video Driver
depends on VIDEO_DEV VIDEO_V4L2 !SPARC32 !SPARC64 FONTS
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index cc93859..542d786 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -151,6 +151,7 @@ obj-$(CONFIG_USB_S2255) += s2255drv.o
obj-$(CONFIG_VIDEO_IVTV) += ivtv/
obj-$(CONFIG_VIDEO_CX18) += cx18/
+obj-$(CONFIG_VIDEO_VIU) += fsl-viu.o
obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_MEM2MEM_TESTDEV) += mem2mem_testdev.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
diff --git a/drivers/media/video/fsl-viu.c b/drivers/media/video/fsl-viu.c
new file mode 100644
index 000..8f1c94f
--- /dev/null
+++ b/drivers/media/video/fsl-viu.c
@@ -0,0 +1,1632 @@
+/*
+ * Copyright 2008-2010 Freescale Semiconductor, Inc. All Rights Reserved.
+ *
+ * Freescale VIU video driver
+ *
+ * Authors: Hongjun Chen hong-jun.c...@freescale.com
+ * Porting to 2.6.35 by DENX Software Engineering,
+ * Anatolij Gustschin ag...@denx.de
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2 of the License, or (at your
+ * option) any later version.
+ *
+ */
+
+#include linux/module.h
+#include linux/clk.h
+#include linux/kernel.h
+#include linux/i2c.h
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/of_platform.h
+#include linux/version.h
+#include media/v4l2-common.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include media/videobuf-dma-contig.h
+
+#define DRV_NAME fsl_viu
+#define VIU_MAJOR_VERSION 0
+#define VIU_MINOR_VERSION 5
+#define VIU_RELEASE0
+#define VIU_VERSIONKERNEL_VERSION(VIU_MAJOR_VERSION, \
+ VIU_MINOR_VERSION, \
+ VIU_RELEASE)
+
+#define BUFFER_TIMEOUT msecs_to_jiffies(500) /* 0.5 seconds */
+
+#defineVIU_VID_MEM_LIMIT 4 /* Video memory limit, in Mb */
+
+/* I2C address of video decoder chip is 0x4A */
+#define VIU_VIDEO_DECODER_ADDR 0x25
+
+/* supported controls */
+static struct v4l2_queryctrl viu_qctrl[] = {
+ {
+ .id= V4L2_CID_BRIGHTNESS,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Brightness,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 1,
+ .default_value = 127,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_CONTRAST,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Contrast,
+ .minimum = 0,
+ .maximum = 255,
+ .step = 0x1,
+ .default_value = 0x10,
+ .flags = 0,
+ }, {
+ .id= V4L2_CID_SATURATION,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = Saturation,
+ .minimum = 0,
+ .maximum = 255,
+
Re: em28xx/xc3028 - kernel driver vs. Markus Rechberger's driver
Am Freitag, 2. Juli 2010, um 02:59:57 schrieb Douglas Schilling Landgraf: humm, not really :-/ Are you sure em28xx/device get loaded when your device is plugged? A good test: - unplug your device - dmesg -c (clear the dmesg) - plug your device - check your dmesg, see if there is any error or message and please send to us the output. - lsmod could help also. - if it's ok, load the i2c modules The em28xx device gets not loaded because the usb id has changed and e1ba:2871 is not associated to the em28xx-cards. the usb id is wrong like i mentioned before - that may be the cause. I provide you with dmesg later on. Maybe i need the patch Thorsten did too, to patch the em28xx-cards.c to get the new wrong usb id regognized as a em28xx device so that i can reflash the eeprom of the device. I might give this a try later this day. @Thorsten: Did you reflash the device eeprom with your patched em28xx driver or without the patch? What's the message of rewirte_eeprom.pl? The same as Throsten? No, all ok.My distribution is lacking any i2c_smbus module - can't load this one. Maybe Ubuntu does not build or 2.6.32 does not habe this one (looking through the source i did not find it yet - maybe i missed that). @Thorsten, in my case never needed to load modprobed i2c-smbus also. That's why rewrite_eeprom failed to you, the script is not looking to load this module. Thanks for the feedback. -- Bitte senden Sie mir keine Word- oder PowerPoint-Anhänge. Siehe http://www.gnu.org/philosophy/no-word-attachments.de.html Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect. -- Linus Torvalds smime.p7s Description: S/MIME cryptographic signature
vivi videobuf bug with tvtime
There's a problem with the tvtime application that affects recent v4l2
drivers. The tvtime application works fine the first time you run it,
but the second time tvtime is run, the call to VIDIOC_REQBUFS fails with
EBUSY.
The problem is that tvtime does a VIDIOC_STREAMOFF, then VIDIOC_QBUF a
few times before closing the fd. This only affects v4l2 drivers that
store the 'struct videobuf_queue vb_vidq' in the dev struct. It doesn't
affect older drivers that store that struct in the driver fh struct.
The videobuf_reqbufs call is returning from this statement:
videobuf-core.c: in videobuf_reqbufs()
if (!list_empty(q-stream)) {
dprintk(1, reqbufs: stream running\n);
retval = -EBUSY;
goto done;
}
Is tvtime abusing the API, or is this a videobuf buf? My opinion is
that applications shouldn't be able to force the driver into an unusable
state.
Here's the debug kernel log starting at the streamoff:
[ 4862.871055] vivi: VIDIOC_STREAMOFF
[ 4862.871061] vivi-000: buffer_release
[ 4862.871063] vivi-000: free_buffer, state: 6
[ 4862.871065] vivi-000: free_buffer: freed
[ 4862.871066] vivi-000: buffer_release
[ 4862.871068] vivi-000: free_buffer, state: 5
[ 4862.871069] vivi-000: free_buffer: freed
[ 4862.871071] vivi-000: buffer_release
[ 4862.871073] vivi-000: free_buffer, state: 5
[ 4862.871074] vivi-000: free_buffer: freed
[ 4862.871076] vivi-000: buffer_release
[ 4862.871077] vivi-000: free_buffer, state: 6
[ 4862.871079] vivi-000: free_buffer: freed
[ 4862.871081] vivi-000: vivi_stop_generating
[ 4862.871087] vivi-000: thread: exit
[ 4862.871108] vivi: VIDIOC_QBUF
[ 4862.87] vbuf: qbuf: requesting next field
[ 4862.871113] vivi-000: buffer_prepare, field=4
[ 4862.871138] vbuf: qbuf: succeded
[ 4862.871140] vivi: VIDIOC_QBUF
[ 4862.871142] vbuf: qbuf: requesting next field
[ 4862.871144] vivi-000: buffer_prepare, field=4
[ 4862.871167] vbuf: qbuf: succeded
[ 4862.871169] vivi: VIDIOC_QBUF
[ 4862.871171] vbuf: qbuf: requesting next field
[ 4862.871173] vivi-000: buffer_prepare, field=4
[ 4862.871196] vbuf: qbuf: succeded
[ 4862.871198] vivi: VIDIOC_QBUF
[ 4862.871200] vbuf: qbuf: requesting next field
[ 4862.871202] vivi-000: buffer_prepare, field=4
[ 4862.871225] vbuf: qbuf: succeded
[ 4862.871498] vivi-000: vivi_stop_generating
[ 4862.871500] vivi-000: close called (dev=video0)
[ 4865.031222] vivi: VIDIOC_QUERYCAP
[ 4865.031232] vivi: VIDIOC_ENUMINPUT
[ 4865.031235] vivi: VIDIOC_ENUMINPUT
[ 4865.031238] vivi: VIDIOC_ENUMINPUT
[ 4865.031241] vivi: VIDIOC_ENUMINPUT
[ 4865.031244] vivi: VIDIOC_ENUMINPUT
[ 4865.031265] vivi: v4l1 ioctl 'v', dir=r-, #198 (0x800476c6)
[ 4865.031273] vivi: VIDIOC_S_INPUT
[ 4865.031298] vivi: VIDIOC_G_INPUT
[ 4865.031305] vivi: VIDIOC_ENUMINPUT
[ 4865.031312] vivi: VIDIOC_G_STD
[ 4865.031318] vivi: VIDIOC_S_STD
[ 4865.031324] vivi: VIDIOC_G_TUNER
[ 4865.031482] vivi: VIDIOC_S_FMT
[ 4865.031490] vivi: VIDIOC_TRY_FMT
[ 4865.031497] vivi: VIDIOC_REQBUFS
[ 4865.031504] vbuf: reqbufs: stream running
[ 4865.031519] vivi-000: vivi_stop_generating
[ 4865.031525] vivi-000: close called (dev=video0)
--
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.22 and up: ERRORS, 2.6.16-2.6.21: 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 Jul 2 19:00:18 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 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: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-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-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS 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: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS 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: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: 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
[PATCH] V4L/DVB: mantis: Rename gpio_set_bits to mantis_gpio_set_bits
This function is declared extern and exported, and should not be given
a generic name which may conflict with gpiolib in future.
Signed-off-by: Ben Hutchings b...@decadent.org.uk
---
drivers/media/dvb/mantis/hopper_vp3028.c |4 ++--
drivers/media/dvb/mantis/mantis_core.c |2 +-
drivers/media/dvb/mantis/mantis_dvb.c| 14 +++---
drivers/media/dvb/mantis/mantis_ioc.c|4 ++--
drivers/media/dvb/mantis/mantis_ioc.h|2 +-
drivers/media/dvb/mantis/mantis_vp1034.c |8
drivers/media/dvb/mantis/mantis_vp3030.c |4 ++--
7 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/media/dvb/mantis/hopper_vp3028.c
b/drivers/media/dvb/mantis/hopper_vp3028.c
index 96674c7..d958449 100644
--- a/drivers/media/dvb/mantis/hopper_vp3028.c
+++ b/drivers/media/dvb/mantis/hopper_vp3028.c
@@ -47,11 +47,11 @@ static int vp3028_frontend_init(struct mantis_pci *mantis,
struct dvb_frontend *
struct mantis_hwconfig *config = mantis-hwconfig;
int err = 0;
- gpio_set_bits(mantis, config-reset, 0);
+ mantis_gpio_set_bits(mantis, config-reset, 0);
msleep(100);
err = mantis_frontend_power(mantis, POWER_ON);
msleep(100);
- gpio_set_bits(mantis, config-reset, 1);
+ mantis_gpio_set_bits(mantis, config-reset, 1);
err = mantis_frontend_power(mantis, POWER_ON);
if (err == 0) {
diff --git a/drivers/media/dvb/mantis/mantis_core.c
b/drivers/media/dvb/mantis/mantis_core.c
index 8113b23..1ac4d12 100644
--- a/drivers/media/dvb/mantis/mantis_core.c
+++ b/drivers/media/dvb/mantis/mantis_core.c
@@ -201,7 +201,7 @@ int mantis_core_exit(struct mantis_pci *mantis)
}
/* Turn the given bit on or off. */
-void gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8 value)
+void mantis_gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8 value)
{
u32 cur;
diff --git a/drivers/media/dvb/mantis/mantis_dvb.c
b/drivers/media/dvb/mantis/mantis_dvb.c
index 99d82ee..a8e5719 100644
--- a/drivers/media/dvb/mantis/mantis_dvb.c
+++ b/drivers/media/dvb/mantis/mantis_dvb.c
@@ -47,15 +47,15 @@ int mantis_frontend_power(struct mantis_pci *mantis, enum
mantis_power power)
switch (power) {
case POWER_ON:
dprintk(MANTIS_DEBUG, 1, Power ON);
- gpio_set_bits(mantis, config-power, POWER_ON);
+ mantis_gpio_set_bits(mantis, config-power, POWER_ON);
msleep(100);
- gpio_set_bits(mantis, config-power, POWER_ON);
+ mantis_gpio_set_bits(mantis, config-power, POWER_ON);
msleep(100);
break;
case POWER_OFF:
dprintk(MANTIS_DEBUG, 1, Power OFF);
- gpio_set_bits(mantis, config-power, POWER_OFF);
+ mantis_gpio_set_bits(mantis, config-power, POWER_OFF);
msleep(100);
break;
@@ -73,13 +73,13 @@ void mantis_frontend_soft_reset(struct mantis_pci *mantis)
struct mantis_hwconfig *config = mantis-hwconfig;
dprintk(MANTIS_DEBUG, 1, Frontend RESET);
- gpio_set_bits(mantis, config-reset, 0);
+ mantis_gpio_set_bits(mantis, config-reset, 0);
msleep(100);
- gpio_set_bits(mantis, config-reset, 0);
+ mantis_gpio_set_bits(mantis, config-reset, 0);
msleep(100);
- gpio_set_bits(mantis, config-reset, 1);
+ mantis_gpio_set_bits(mantis, config-reset, 1);
msleep(100);
- gpio_set_bits(mantis, config-reset, 1);
+ mantis_gpio_set_bits(mantis, config-reset, 1);
msleep(100);
return;
diff --git a/drivers/media/dvb/mantis/mantis_ioc.c
b/drivers/media/dvb/mantis/mantis_ioc.c
index de148de..e97cb63 100644
--- a/drivers/media/dvb/mantis/mantis_ioc.c
+++ b/drivers/media/dvb/mantis/mantis_ioc.c
@@ -82,7 +82,7 @@ int mantis_get_mac(struct mantis_pci *mantis)
EXPORT_SYMBOL_GPL(mantis_get_mac);
/* Turn the given bit on or off. */
-void gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8 value)
+void mantis_gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8 value)
{
u32 cur;
@@ -97,7 +97,7 @@ void gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8
value)
mmwrite(mantis-gpio_status, MANTIS_GPIF_ADDR);
mmwrite(0x00, MANTIS_GPIF_DOUT);
}
-EXPORT_SYMBOL_GPL(gpio_set_bits);
+EXPORT_SYMBOL_GPL(mantis_gpio_set_bits);
int mantis_stream_control(struct mantis_pci *mantis, enum
mantis_stream_control stream_ctl)
{
diff --git a/drivers/media/dvb/mantis/mantis_ioc.h
b/drivers/media/dvb/mantis/mantis_ioc.h
index 188fe5a..d56e002 100644
--- a/drivers/media/dvb/mantis/mantis_ioc.h
+++ b/drivers/media/dvb/mantis/mantis_ioc.h
@@ -44,7 +44,7 @@ enum mantis_stream_control {
};
extern int mantis_get_mac(struct mantis_pci *mantis);
-extern void gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8 value);
+extern void mantis_gpio_set_bits(struct mantis_pci *mantis, u32 bitpos, u8
value);
Fwd: Firmware for HVR-1110
I'm confused as to what firmware in needed for the HVR-1110. Scouring the web, everywhere claims that the dvb-fe-tda10046 is required; however, dmesg logs show that this fails to be uploaded, and instead it is looking for dvb-fe-tda-10048: If I use tda-10048 then this seems to successfully loaded, but I am unable to find any channels with a scan; the dvb nodes within /dev/ are created and modules loaded, but dvbscan fails to tune. -- dmesg $ dmesg |grep firmware tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... saa7134 :03:04.0: firmware: requesting dvb-fe-tda10048-1.0.fw tda10048_firmware_upload: firmware read 24878 bytes. tda10048_firmware_upload: firmware uploading tda10048_firmware_upload: firmware uploaded Any tips? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] IR: add core lirc device interface
On Fri, Jun 4, 2010 at 2:38 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: ... From my side, as I said before, I'd like to see a documentation of the defined API bits, and the removal of the currently unused ioctls (they can be added later, together with the patches that will introduce the code that handles them) to give my final ack. Thanks to Christoph and me spending an exciting Friday night doing docbook formatting for the first time ever, I've finally got a start of a LIRC device interface API docbook doc together, along with all the lirc_dev bits and ir-lirc-codec bridge, all me-tested-and-approved w/four different mceusb devices, both send and receive. I'm about to head out of town for the weekend, but hope to get patches in flight either before then, or from the road. In the interim, the interested can take a look here: http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/patches Nb: this branch has been non-fast-forward-ably updated against latest linuxtv staging/rc. The prior variant there left too much lirc-specific tx bits in mceusb, which have now all been moved into ir-lirc-codec. -- Jarod Wilson ja...@wilsonet.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 v3] IR/mceusb: kill pinnacle-device-specific nonsense
I have pinnacle hardware now. None of this pinnacle-specific crap is at
all necessary (in fact, some of it needed to be removed to actually make
it work). The only thing unique about this device is that it often
transfers inbound data w/a header of 0x90, meaning 16 bytes of IR data
following it, so I had to make adjustments for that, and now its working
perfectly fine.
v2: stillborn
v3: remove completely unnecessary usb_reset_device() call that only served
to piss off the pinnacle device regularly and unify/simplify some of the
generation-specific device initialization code.
post-mortem: it seems the pinnacle hardware actually still gets pissed off
from time to time, but I can (try) to fix that later (if possible). The
patch is still quite helpful from a code reduction standpoint.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
Makefile |2 +-
drivers/media/IR/mceusb.c | 110 +
2 files changed, 22 insertions(+), 90 deletions(-)
diff --git a/Makefile b/Makefile
index 6e39ec7..0417c74 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 35
-EXTRAVERSION = -rc1
+EXTRAVERSION = -rc1-ir
NAME = Sheep on Meth
# *DOCUMENTATION*
diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c
index 756f718..640e2e6 100644
--- a/drivers/media/IR/mceusb.c
+++ b/drivers/media/IR/mceusb.c
@@ -68,7 +68,7 @@
#define MCE_PULSE_BIT 0x80 /* Pulse bit, MSB set == PULSE else SPACE */
#define MCE_PULSE_MASK 0x7F /* Pulse mask */
#define MCE_MAX_PULSE_LENGTH 0x7F /* Longest transmittable pulse symbol */
-#define MCE_PACKET_LENGTH_MASK 0xF /* Packet length mask */
+#define MCE_PACKET_LENGTH_MASK 0x1F /* Packet length mask */
/* module parameters */
@@ -209,11 +209,6 @@ static struct usb_device_id gen3_list[] = {
{}
};
-static struct usb_device_id pinnacle_list[] = {
- { USB_DEVICE(VENDOR_PINNACLE, 0x0225) },
- {}
-};
-
static struct usb_device_id microsoft_gen1_list[] = {
{ USB_DEVICE(VENDOR_MICROSOFT, 0x006d) },
{}
@@ -542,6 +537,7 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
{
struct ir_raw_event rawir = { .pulse = false, .duration = 0 };
int i, start_index = 0;
+ u8 hdr = MCE_CONTROL_HEADER;
/* skip meaningless 0xb1 0x60 header bytes on orig receiver */
if (ir-flags.microsoft_gen1)
@@ -551,15 +547,16 @@ static void mceusb_process_ir_data(struct mceusb_dev *ir,
int buf_len)
if (ir-rem == 0) {
/* decode mce packets of the form (84),AA,BB,CC,DD */
/* IR data packets can span USB messages - rem */
- ir-rem = (ir-buf_in[i] MCE_PACKET_LENGTH_MASK);
- ir-cmd = (ir-buf_in[i] ~MCE_PACKET_LENGTH_MASK);
+ hdr = ir-buf_in[i];
+ ir-rem = (hdr MCE_PACKET_LENGTH_MASK);
+ ir-cmd = (hdr ~MCE_PACKET_LENGTH_MASK);
dev_dbg(ir-dev, New data. rem: 0x%02x, cmd: 0x%02x\n,
ir-rem, ir-cmd);
i++;
}
- /* Only cmd 0x8bytes is IR data, don't process MCE commands */
- if (ir-cmd != 0x80) {
+ /* don't process MCE commands */
+ if (hdr == MCE_CONTROL_HEADER || hdr == 0xff) {
ir-rem = 0;
return;
}
@@ -649,47 +646,18 @@ static void mceusb_gen1_init(struct mceusb_dev *ir)
int i, ret;
int partial = 0;
struct device *dev = ir-dev;
- char *junk, *data;
-
- junk = kmalloc(2 * USB_BUFLEN, GFP_KERNEL);
- if (!junk) {
- dev_err(dev, %s: memory allocation failed!\n, __func__);
- return;
- }
+ char *data;
data = kzalloc(USB_CTRL_MSG_SZ, GFP_KERNEL);
if (!data) {
dev_err(dev, %s: memory allocation failed!\n, __func__);
- kfree(junk);
return;
}
/*
-* Clear off the first few messages. These look like calibration
-* or test data, I can't really tell. This also flushes in case
-* we have random ir data queued up.
-*/
- for (i = 0; i MCE_G1_INIT_MSGS; i++)
- usb_bulk_msg(ir-usbdev,
- usb_rcvbulkpipe(ir-usbdev,
- ir-usb_ep_in-bEndpointAddress),
- junk, sizeof(junk), partial, HZ * 10);
-
- /* Get Status */
- ret = usb_control_msg(ir-usbdev, usb_rcvctrlpipe(ir-usbdev, 0),
- USB_REQ_GET_STATUS, USB_DIR_IN,
- 0, 0, data, USB_CTRL_MSG_SZ, HZ * 3);
-
- /*ret = usb_get_status( ir-usbdev, 0, 0, data ); */
- dev_dbg(dev, %s - ret = %d status = 0x%x 0x%x\n, __func__,
- ret,
[PATCH v2 0/3] IR: add lirc support to ir-core
On Tue, Jun 01, 2010 at 04:50:05PM -0400, Jarod Wilson wrote: This patch series adds the core lirc device interface, lirc_dev, and an ir-core bridge driver. Currently, only the receive side is wired up in the bridge driver, but adding transmit support is up next. Currently, adding this code allows any raw IR ir-core device driver to pass raw IR out to the lirc userspace, without the driver having to have any actual knowledge of lirc -- its just feeding data to another IR protocol decoder engine. This also (hopefully) makes life easier for any currently out-of-tree pure lirc device drivers, as they can count on the lirc core bits being present. This is a Good Thing(tm) while we work on porting additional lirc device drivers to ir-core, and also makes life easier for users to migrate from lirc decoding to in-kernel decoding (where possible) when their device's driver gets ported. This patchset has been tested with the ir-core mceusb driver, and IR receive behaves 100% identical in lirc mode to the old lirc_mceusb. [PATCH 1/3] IR: add core lirc device interface [PATCH 2/3] IR: add an empty lirc protocol keymap [PATCH 3/3] IR: add ir-core to lirc interface bridge driver Version 2 moves a good chunk of ir tx details that are (probably) specific to providing raw IR data from userspace via lirc into the ir-core lirc bridge driver, instead of having them in the hardware-specific drivers themselves. This greatly reduced the complexity of the mceusb driver's ir tx function, and generalized the tx interface better for a non-lirc tx implementation. -- 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 1/3] IR: add lirc device interface
v2: currently unused ioctls are included, but #if 0'd out
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/Kconfig| 11 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/lirc_dev.c | 761 +++
drivers/media/IR/lirc_dev.h | 226 +
include/media/lirc.h| 163 +
5 files changed, 1162 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/IR/lirc_dev.c
create mode 100644 drivers/media/IR/lirc_dev.h
create mode 100644 include/media/lirc.h
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index bbd2435..5a32b99 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -8,6 +8,17 @@ config VIDEO_IR
depends on IR_CORE
default IR_CORE
+config LIRC
+ tristate
+ default y
+
+ ---help---
+ Enable this option to build the Linux Infrared Remote
+ Control (LIRC) core device interface driver. The LIRC
+ interface passes raw IR to and from userspace, where the
+ LIRC daemon handles protocol decoding for IR reception ann
+ encoding for IR transmitting (aka blasting).
+
source drivers/media/IR/keymaps/Kconfig
config IR_NEC_DECODER
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index b43fe36..3ba00bb 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -5,6 +5,7 @@ obj-y += keymaps/
obj-$(CONFIG_IR_CORE) += ir-core.o
obj-$(CONFIG_VIDEO_IR) += ir-common.o
+obj-$(CONFIG_LIRC) += lirc_dev.o
obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
diff --git a/drivers/media/IR/lirc_dev.c b/drivers/media/IR/lirc_dev.c
new file mode 100644
index 000..9e141d5
--- /dev/null
+++ b/drivers/media/IR/lirc_dev.c
@@ -0,0 +1,761 @@
+/*
+ * LIRC base driver
+ *
+ * by Artur Lipowski alipow...@interia.pl
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/errno.h
+#include linux/ioctl.h
+#include linux/fs.h
+#include linux/poll.h
+#include linux/completion.h
+#include linux/errno.h
+#include linux/mutex.h
+#include linux/wait.h
+#include linux/unistd.h
+#include linux/kthread.h
+#include linux/bitops.h
+#include linux/device.h
+#include linux/cdev.h
+
+#include media/lirc.h
+#include lirc_dev.h
+
+static int debug;
+
+#define IRCTL_DEV_NAME BaseRemoteCtl
+#define NOPLUG -1
+#define LOGHEADlirc_dev (%s[%d]):
+
+static dev_t lirc_base_dev;
+
+struct irctl {
+ struct lirc_driver d;
+ int attached;
+ int open;
+
+ struct mutex irctl_lock;
+ struct lirc_buffer *buf;
+ unsigned int chunk_size;
+
+ struct task_struct *task;
+ long jiffies_to_wait;
+
+ struct cdev cdev;
+};
+
+static DEFINE_MUTEX(lirc_dev_lock);
+
+static struct irctl *irctls[MAX_IRCTL_DEVICES];
+
+/* Only used for sysfs but defined to void otherwise */
+static struct class *lirc_class;
+
+/* helper function
+ * initializes the irctl structure
+ */
+static void init_irctl(struct irctl *ir)
+{
+ dev_dbg(ir-d.dev, LOGHEAD initializing irctl\n,
+ ir-d.name, ir-d.minor);
+ mutex_init(ir-irctl_lock);
+ ir-d.minor = NOPLUG;
+}
+
+static void cleanup(struct irctl *ir)
+{
+ dev_dbg(ir-d.dev, LOGHEAD cleaning up\n, ir-d.name, ir-d.minor);
+
+ device_destroy(lirc_class, MKDEV(MAJOR(lirc_base_dev), ir-d.minor));
+
+ if (ir-buf != ir-d.rbuf) {
+ lirc_buffer_free(ir-buf);
+ kfree(ir-buf);
+ }
+ ir-buf = NULL;
+}
+
+/* helper function
+ * reads key codes from driver and puts them into buffer
+ * returns 0 on success
+ */
+static int add_to_buf(struct irctl *ir)
+{
+ if (ir-d.add_to_buf) {
+ int res = -ENODATA;
+ int got_data = 0;
+
+ /*
+* service the device as long as it is returning
+* data and we have space
+*/
+get_data:
+ res = ir-d.add_to_buf(ir-d.data, ir-buf);
+ if (res == 0) {
+ got_data++;
+ goto get_data;
+
[PATCH v2 2/3] IR: add ir-core to lirc userspace decoder bridge driver
v2: copy of buffer data from userspace done inside this plugin/driver,
keeping the actual drivers minimal, and more flexible in what we can
deliver to them later on (they may be fed from within kernelspace later
on, by an in-kernel IR encoder).
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/Kconfig | 10 ++
drivers/media/IR/Makefile|1 +
drivers/media/IR/ir-core-priv.h | 13 ++
drivers/media/IR/ir-lirc-codec.c | 284 ++
drivers/media/IR/ir-raw-event.c |1 +
drivers/media/IR/ir-sysfs.c |8 +
include/media/rc-map.h |4 +-
7 files changed, 320 insertions(+), 1 deletions(-)
create mode 100644 drivers/media/IR/ir-lirc-codec.c
diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig
index 5a32b99..d8e5c73 100644
--- a/drivers/media/IR/Kconfig
+++ b/drivers/media/IR/Kconfig
@@ -67,6 +67,16 @@ config IR_SONY_DECODER
Enable this option if you have an infrared remote control which
uses the Sony protocol, and you need software decoding support.
+config IR_LIRC_CODEC
+ tristate Enable IR to LIRC bridge
+ depends on IR_CORE
+ depends on LIRC
+ default y
+
+ ---help---
+ Enable this option to pass raw IR to and from userspace via
+ the LIRC interface.
+
config IR_IMON
tristate SoundGraph iMON Receiver and Display
depends on USB_ARCH_HAS_HCD
diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile
index 3ba00bb..2ae4f3a 100644
--- a/drivers/media/IR/Makefile
+++ b/drivers/media/IR/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
obj-$(CONFIG_IR_JVC_DECODER) += ir-jvc-decoder.o
obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o
+obj-$(CONFIG_IR_LIRC_CODEC) += ir-lirc-codec.o
# stand-alone IR receivers/transmitters
obj-$(CONFIG_IR_IMON) += imon.o
diff --git a/drivers/media/IR/ir-core-priv.h b/drivers/media/IR/ir-core-priv.h
index 0a82b22..babd520 100644
--- a/drivers/media/IR/ir-core-priv.h
+++ b/drivers/media/IR/ir-core-priv.h
@@ -73,6 +73,11 @@ struct ir_raw_event_ctrl {
bool first;
bool toggle;
} jvc;
+ struct lirc_codec {
+ struct ir_input_dev *ir_dev;
+ struct lirc_driver *drv;
+ int lircdata;
+ } lirc;
};
/* macros for IR decoders */
@@ -164,4 +169,12 @@ void ir_raw_init(void);
#define load_sony_decode() 0
#endif
+/* from ir-lirc-codec.c */
+#ifdef CONFIG_IR_LIRC_CODEC_MODULE
+#define load_lirc_codec() request_module(ir-lirc-codec)
+#else
+#define load_lirc_codec() 0
+#endif
+
+
#endif /* _IR_RAW_EVENT */
diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c
new file mode 100644
index 000..aff31d1
--- /dev/null
+++ b/drivers/media/IR/ir-lirc-codec.c
@@ -0,0 +1,284 @@
+/* ir-lirc-codec.c - ir-core to classic lirc interface bridge
+ *
+ * Copyright (C) 2010 by Jarod Wilson ja...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation version 2 of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/sched.h
+#include linux/wait.h
+#include media/lirc.h
+#include media/ir-core.h
+#include ir-core-priv.h
+#include lirc_dev.h
+
+#define LIRCBUF_SIZE 256
+
+/**
+ * ir_lirc_decode() - Send raw IR data to lirc_dev to be relayed to the
+ * lircd userspace daemon for decoding.
+ * @input_dev: the struct input_dev descriptor of the device
+ * @duration: the struct ir_raw_event descriptor of the pulse/space
+ *
+ * This function returns -EINVAL if the lirc interfaces aren't wired up.
+ */
+static int ir_lirc_decode(struct input_dev *input_dev, struct ir_raw_event ev)
+{
+ struct ir_input_dev *ir_dev = input_get_drvdata(input_dev);
+
+ if (!(ir_dev-raw-enabled_protocols IR_TYPE_LIRC))
+ return 0;
+
+ if (!ir_dev-raw-lirc.drv || !ir_dev-raw-lirc.drv-rbuf)
+ return -EINVAL;
+
+ IR_dprintk(2, LIRC data transfer started (%uus %s)\n,
+ TO_US(ev.duration), TO_STR(ev.pulse));
+
+ ir_dev-raw-lirc.lircdata += ev.duration / 1000;
+ if (ev.pulse)
+ ir_dev-raw-lirc.lircdata |= PULSE_BIT;
+
+ lirc_buffer_write(ir_dev-raw-lirc.drv-rbuf,
+ (unsigned char *) ir_dev-raw-lirc.lircdata);
+ wake_up(ir_dev-raw-lirc.drv-rbuf-wait_poll);
+
+ ir_dev-raw-lirc.lircdata = 0;
+
+ return 0;
+}
+
+static ssize_t ir_lirc_transmit_ir(struct file *file, const char *buf,
+
[PATCH v2 3/3] IR: add empty lirc pseudo-keymap
v2: No changes from prior submission here.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/keymaps/Makefile |1 +
drivers/media/IR/keymaps/rc-lirc.c | 41
include/media/rc-map.h |1 +
3 files changed, 43 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/IR/keymaps/rc-lirc.c
diff --git a/drivers/media/IR/keymaps/Makefile
b/drivers/media/IR/keymaps/Makefile
index 08e5a10..7dffd41 100644
--- a/drivers/media/IR/keymaps/Makefile
+++ b/drivers/media/IR/keymaps/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
rc-kaiomy.o \
rc-kworld-315u.o \
rc-kworld-plus-tv-analog.o \
+ rc-lirc.o \
rc-manli.o \
rc-msi-tvanywhere.o \
rc-msi-tvanywhere-plus.o \
diff --git a/drivers/media/IR/keymaps/rc-lirc.c
b/drivers/media/IR/keymaps/rc-lirc.c
new file mode 100644
index 000..43fcf90
--- /dev/null
+++ b/drivers/media/IR/keymaps/rc-lirc.c
@@ -0,0 +1,41 @@
+/* rc-lirc.c - Empty dummy keytable, for use when its preferred to pass
+ * all raw IR data to the lirc userspace decoder.
+ *
+ * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include media/ir-core.h
+
+static struct ir_scancode lirc[] = {
+ { },
+};
+
+static struct rc_keymap lirc_map = {
+ .map = {
+ .scan= lirc,
+ .size= ARRAY_SIZE(lirc),
+ .ir_type = IR_TYPE_LIRC,
+ .name= RC_MAP_LIRC,
+ }
+};
+
+static int __init init_rc_map_lirc(void)
+{
+ return ir_register_map(lirc_map);
+}
+
+static void __exit exit_rc_map_lirc(void)
+{
+ ir_unregister_map(lirc_map);
+}
+
+module_init(init_rc_map_lirc)
+module_exit(exit_rc_map_lirc)
+
+MODULE_LICENSE(GPL);
+MODULE_AUTHOR(Jarod Wilson ja...@redhat.com);
diff --git a/include/media/rc-map.h b/include/media/rc-map.h
index 63b35e4..056d0e4 100644
--- a/include/media/rc-map.h
+++ b/include/media/rc-map.h
@@ -91,6 +91,7 @@ void rc_map_init(void);
#define RC_MAP_KAIOMYrc-kaiomy
#define RC_MAP_KWORLD_315U rc-kworld-315u
#define RC_MAP_KWORLD_PLUS_TV_ANALOG rc-kworld-plus-tv-analog
+#define RC_MAP_LIRC rc-lirc
#define RC_MAP_MANLI rc-manli
#define RC_MAP_MSI_TVANYWHERE_PLUS rc-msi-tvanywhere-plus
#define RC_MAP_MSI_TVANYWHERErc-msi-tvanywhere
--
1.7.1
--
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 4/3] IR/lirc: add docbook info covering lirc device interface
First ever crack at creating docbook documentation... Contains a bevy of
information on the various lirc device interface ioctls, as well as a
bit about the read and write interfaces.
Forgot about this in 0/3, so this is patch 4/3. Oops.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
.../DocBook/v4l/lirc_device_interface.xml | 235
1 files changed, 235 insertions(+), 0 deletions(-)
create mode 100644 Documentation/DocBook/v4l/lirc_device_interface.xml
diff --git a/Documentation/DocBook/v4l/lirc_device_interface.xml
b/Documentation/DocBook/v4l/lirc_device_interface.xml
new file mode 100644
index 000..a6244ed
--- /dev/null
+++ b/Documentation/DocBook/v4l/lirc_device_interface.xml
@@ -0,0 +1,235 @@
+titleLIRC Device Interface/title
+
+
+section id=lirc_dev_intro
+titleIntroduction/title
+
+paraThe LIRC device interface is a bi-directional interface for
+transporting raw IR data between userspace and kernelspace. Fundamentally,
+it is just a chardev (/dev/lircX, for X = 0, 1, 2, ...), with a number
+of standard struct file_operations defined on it. With respect to
+transporting raw IR data to and fro, the essential fops are read, write
+and ioctl./para
+
+paraExample dmesg output upon a driver registering w/LIRC:/para
+ blockquote
+para$ dmesg |grep lirc_dev/para
+paralirc_dev: IR Remote Control driver registered, major 248/para
+pararc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor
= 0/para
+ /blockquote
+para
+
+paraWhat you should see for a chardev:/para
+ blockquote
+para$ ls -l /dev/lirc*/para
+paracrw-rw 1 root root 248, 0 Jul 2 22:20 /dev/lirc0/para
+ /blockquote
+/para
+
+
+section id=lirc_read
+titleLIRC read fop/title
+
+paraThe lircd userspace daemon reads raw IR data from the LIRC chardev. The
+exact format of the data depends on what modes a driver supports, and what
+mode has been selected. lircd obtains supported modes and sets the active mode
+via the ioctl interface, detailed at xref linkend=lirc_ioctl. The
generally
+preferred mode is LIRC_MODE_MODE2, in which packets containing an int value
+describing an IR signal are read from the chardev./para
+
+paraSee also ulink
url=http://www.lirc.org/html/technical.html;http://www.lirc.org/html/technical.html/
for more info./para
+
+
+section id=lirc_write
+titleLIRC write fop/title
+
+paraThe data written to the chardev is a pulse/space sequence of integer
+values. Pulses and spaces are only marked implicitly by their position. The
+data must start and end with a pulse, therefore, the data must always include
+an unevent number of samples. The write function must block until the data has
+been transmitted by the hardware./para
+
+
+section id=lirc_ioctl
+title LIRC ioctl fop/title
+
+paraThe LIRC device's ioctl definition is bound by the ioctl function
+definition of struct file_operations, leaving us with an unsigned int
+for the ioctl command and an unsigned long for the arg. For the purposes
+of ioctl portability across 32-bit and 64-bit, these values are capped
+to their 32-bit sizes./para
+
+paraThe following ioctls can be used to change specific hardware settings.
+In general each driver should have a default set of settings. The driver
+implementation is expected to re-apply the default settings when the device
+is closed by user-space, so that every application opening the device can rely
+on working with the default settings initially./para
+
+variablelist
+ varlistentry
+termLIRC_GET_FEATURES/term
+listitem
+ toObviously, get the underlying hardware device's features. If a
driver
+ does not announce support of certain features, calling of the
corresponding
+ ioctls is undefined./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_GET_SEND_MODE/term
+listitem
+ toGet supported transmit mode. Only LIRC_MODE_PULSE is supported by
lircd./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_GET_REC_MODE/term
+listitem
+ toGet supported receive modes. Only LIRC_MODE_MODE2 and
LIRC_MODE_LIRCCODE
+ are supported by lircd./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_GET_SEND_CARRIER/term
+listitem
+ toGet carrier frequency (in Hz) currently used for transmit./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_GET_REC_CARRIER/term
+listitem
+ toGet carrier frequency (in Hz) currently used for IR reception./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_{G,S}ET_{SEND,REC}_DUTY_CYCLE/term
+listitem
+ toGet/set the duty cycle (from 0 to 100) of the carrier signal.
Currently,
+ no special meaning is defined for 0 or 100, but this could be used to
switch
+ off carrier generation in the future, so these values should be
reserved./to
+/listitem
+ /varlistentry
+ varlistentry
+termLIRC_GET_REC_RESOLUTION/term
+listitem
+ toSome receiver have maximum
