Re: [PATCH 1/3] IR: add core lirc device interface
Em 01-06-2010 17:51, Jarod Wilson escreveu:
Add the core lirc device interface (http://lirc.org/).
This is a 99.9% unaltered lirc_dev device interface (only change being
the path to lirc.h), which has been carried in the Fedora kernels and
has been built for numerous other distro kernels for years. In the
next two patches in this series, ir-core will be wired up to make use
of the lirc interface as one of many IR protocol decoder options. In
this case, raw IR will be delivered to the lirc userspace daemon, which
will then handle the decoding.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/Kconfig| 11 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/lirc_dev.c | 850
+++
drivers/media/IR/lirc_dev.h | 228
include/media/lirc.h| 159
5 files changed, 1249 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 7ffa86f..c3010fb 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..7e45800
--- /dev/null
+++ b/drivers/media/IR/lirc_dev.c
@@ -0,0 +1,850 @@
+/*
+ * 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 linux/smp_lock.h
+#ifdef CONFIG_COMPAT
+#include linux/compat.h
+#endif
+
+#include media/lirc.h
+#include lirc_dev.h
+
+static int debug;
+
+#define IRCTL_DEV_NAME BaseRemoteCtl
+#define NOPLUG -1
+#define LOGHEAD lirc_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) {
+
Re: [PATCH 2/2 v2] IR: add mceusb IR receiver driver
Em 01-06-2010 17:32, Jarod Wilson escreveu: This is a new driver for the Windows Media Center Edition/eHome Infrared Remote transceiver devices. Its a port of the current lirc_mceusb driver to ir-core, and currently lacks transmit support, but will grow it back soon enough... This driver also differs from lirc_mceusb in that it borrows heavily from a simplified IR buffer decode routine found in Jon Smirl's earlier ir-mceusb port. This driver has been tested on the original first-generation MCE IR device with the MS vendor ID, as well as a current-generation device with a Topseed vendor ID. Every receiver supported by lirc_mceusb should work equally well. Testing was done primarily with RC6 MCE remotes, but also briefly with a Hauppauge RC5 remote, and all works as expected. v2: fix call to ir_raw_event_handle so repeats work as they should. The driver seems ok, except for a few magic numbers. I'll apply at the tree, to allow more people to test. Please send me later a patch fixing those small issues. Signed-off-by: Jarod Wilson ja...@redhat.com --- drivers/media/IR/Kconfig | 12 + drivers/media/IR/Makefile |1 + drivers/media/IR/mceusb.c | 1085 + 3 files changed, 1098 insertions(+), 0 deletions(-) create mode 100644 drivers/media/IR/mceusb.c diff --git a/drivers/media/IR/Kconfig b/drivers/media/IR/Kconfig index 195c6cf..7ffa86f 100644 --- a/drivers/media/IR/Kconfig +++ b/drivers/media/IR/Kconfig @@ -66,3 +66,15 @@ config IR_IMON To compile this driver as a module, choose M here: the module will be called imon. + +config IR_MCEUSB + tristate Windows Media Center Ed. eHome Infrared Transceiver + depends on USB_ARCH_HAS_HCD + depends on IR_CORE + select USB + ---help--- +Say Y here if you want to use a Windows Media Center Edition +eHome Infrared Transceiver. + +To compile this driver as a module, choose M here: the +module will be called mceusb. diff --git a/drivers/media/IR/Makefile b/drivers/media/IR/Makefile index b998fcc..b43fe36 100644 --- a/drivers/media/IR/Makefile +++ b/drivers/media/IR/Makefile @@ -13,3 +13,4 @@ obj-$(CONFIG_IR_SONY_DECODER) += ir-sony-decoder.o # stand-alone IR receivers/transmitters obj-$(CONFIG_IR_IMON) += imon.o +obj-$(CONFIG_IR_MCEUSB) += mceusb.o diff --git a/drivers/media/IR/mceusb.c b/drivers/media/IR/mceusb.c new file mode 100644 index 000..fe15091 --- /dev/null +++ b/drivers/media/IR/mceusb.c @@ -0,0 +1,1085 @@ +/* + * Driver for USB Windows Media Center Ed. eHome Infrared Transceivers + * + * Copyright (c) 2010 by Jarod Wilson ja...@redhat.com + * + * Based on the original lirc_mceusb and lirc_mceusb2 drivers, by Dan + * Conti, Martin Blatter and Daniel Melander, the latter of which was + * in turn also based on the lirc_atiusb driver by Paul Miller. The + * two mce drivers were merged into one by Jarod Wilson, with transmit + * support for the 1st-gen device added primarily by Patrick Calhoun, + * with a bit of tweaks by Jarod. Debugging improvements and proper + * support for what appears to be 3rd-gen hardware added by Jarod. + * Initial port from lirc driver to ir-core drivery by Jarod, based + * partially on a port to an earlier proposed IR infrastructure by + * Jon Smirl, which included enhancements and simplifications to the + * incoming IR buffer parsing routines. + * + * TODO: + * - add rc-core transmit support, once available + * - enable support for forthcoming ir-lirc-codec interface + * + * + * 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/device.h +#include linux/module.h +#include linux/slab.h +#include linux/usb.h +#include linux/input.h +#include media/ir-core.h +#include media/ir-common.h + +#define DRIVER_VERSION 1.91 +#define DRIVER_AUTHORJarod Wilson ja...@wilsonet.com +#define DRIVER_DESC Windows Media Center Ed. eHome Infrared Transceiver \ + device driver +#define DRIVER_NAME mceusb + +#define USB_BUFLEN 32 /* USB reception buffer length */ +#define IRBUF_SIZE 256 /* IR work buffer length */ + +/* MCE constants */ +#define MCE_CMDBUF_SIZE 384 /* MCE
Re: ir-core multi-protocol decode and mceusb
On Tue, Jun 1, 2010 at 1:22 AM, Jarod Wilson ja...@wilsonet.com wrote:
On Mon, May 31, 2010 at 6:31 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 31-05-2010 18:45, Andy Walls escreveu:
On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the
driver will
change the parameters after registering, and without any userspace request.
Yes, my intent was to handle a user space request to change the
transmitter setup parameters to handle the protocol.
I also don't want to worry about having to code in kernel parameter
tables for any bizzare protocol userspace may know about.
Makes sense.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the
registering function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
A callback is likely needed. I'm not sure I would have chosen the name
change_protocol(), because transmitter parameters can be common between
protocols (at least RC-5 and RC-6 can be supported with one set of
parameters), or not match any existing in-kernel protocol. As long as
it is flexible enough to change individual transmitter parameters
(modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
I just used this name as an example, as the same name exists on RX.
Depending on how we code the userspace API, we may use just one
set_parameters
function, or a set of per-attribute changes.
In other words, if we implement severa sysfs nodes to change several
parameters,
maybe it makes sense to have several callbacks. Another alternative would be
to have a commit sysfs node to apply a set of parameters at once.
Currently LIRC userspace changes Tx parameters using an ioctl(). It
asks the hardware to change transmitter parameters, because the current
model is that the transmitters don't need to know about protocols. (LIRC
userspace knows the parameters of the protocol it wants to use, so the
driver's don't have too).
The list of transmit-related ioctls implemented in the lirc_mceusb driver:
- LIRC_SET_TRANSMITTER_MASK -- these devices have two IR tx outputs,
default is to send the signal out both, but you can also select just a
specific one (i.e., two set top boxes, only want to send command to
one or the other of them).
- LIRC_GET_SEND_MODE -- get current transmit mode
- LIRC_SET_SEND_MODE -- set current transmit mode
- LIRC_SET_SEND_CARRIER -- set the transmit carrier freq
- LIRC_GET_FEATURE -- get both the send and receive capabilities of the device
I notice IR Rx also has a change_protocol() callback that is not
currently in use.
It is used only by em28xx, where the hardware decoder can work either with
RC-5 or NEC (newer chips also support RC-6, but this is currently not
implemented).
The imon driver also implements change_protocol for the current-gen
devices, which are capable of decoding either mce remote signals or
the native imon remote signals. I was originally thinking I'd need to
implement change_protocol for the mceusb driver, but its ultimately a
no-op, since the hardware doesn't give a damn (and there's a note
somewhere that mentions its only relevant for hardware decode devices
that need to be put into a specific mode). Although, on something like
the mceusb driver, change_protocol *could* be wired up to mark only
the desired protocol enabled -- which might reduce complexity for
ir-keytable when loading a new keymap. (I went with a rather simple
approach for marking only the desired decoder enabled at initial
keymap load time which won't help here -- patch coming tomorrow for
that).
If sending raw pulses to userspace, it would be also
nice to expose that callback so userspace could set the receiver
parameters.
Raw pulse transmission is probably the easiest case. Probably, there's
nothing
or a very few things that might need adjustments.
Transmitter mask, carrier frequency and a repeat count are the things
I can see needing to set regularly. From experience, at least with
motorola set top box hardware, you need to send a given signal 2-3
times, not just once, for the hardware to pick it up. There's a
min_repeat parameter in lirc config files only used on the transmit
side of the house to specify how many repeats of each blasted signal
to send.
I keep bouncing between two machines, so I finally got smart(ish) and
pushed a working git tree to have both push and pull from.
http://git.wilsonet.com/linux-2.6-ir-wip.git/
Just pushed 3 patches with which I can now transmit IR via an mceusb
device. I've only added three callbacks to
[PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161 +
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = AM3517 EVM,
+ .ccdc = DM6446 CCDC,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = INT_35XX_CCDC_VD0_IRQ,
+ .end= INT_35XX_CCDC_VD0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_CCDC_VD1_IRQ,
+ .end= INT_35XX_CCDC_VD1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+ .name = CAPTURE_DRV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(vpfe_resources),
+
[PATCH-V1 0/2] Add support for AM3517 VPFE Capture module
From: Vaibhav Hiremath hvaib...@ti.com AM3517 uses similar VPFE-CCDC hardware IP as in Davinci, so reusing the driver. Currently the davinci driver is hardly tied with ARCH_DAVINCI, which was limiting AM3517 to reuse the driver. So created seperate Kconfig file for davinci and added AM3517 to dependancy. Also added board hook up code to board-am3517evm.c file. Changes from last version: - Typo mistake in board-am3517evm.c file fixed - Added DM365 platform support in Kconfig help option Vaibhav Hiremath (2): Davinci: Create seperate Kconfig file for davinci devices AM3517: Add VPFE Capture driver support to board file arch/arm/mach-omap2/board-am3517evm.c | 161 + drivers/media/video/Kconfig | 61 + drivers/media/video/Makefile |2 +- drivers/media/video/davinci/Kconfig | 93 +++ 4 files changed, 256 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig -- 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-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices
From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- drivers/media/video/Kconfig | 61 +-- drivers/media/video/Makefile|2 +- drivers/media/video/davinci/Kconfig | 93 +++ 3 files changed, 95 insertions(+), 61 deletions(-) create mode 100644 drivers/media/video/davinci/Kconfig diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index bdbc9d3..fcdb224 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -570,66 +570,7 @@ config VIDEO_VIVI Say Y here if you want to test video apps or debug V4L devices. In doubt, say N. -config VIDEO_VPSS_SYSTEM - tristate VPSS System module driver - depends on ARCH_DAVINCI - help - Support for vpss system module for video driver - -config VIDEO_VPFE_CAPTURE - tristate VPFE Video Capture Driver - depends on VIDEO_V4L2 ARCH_DAVINCI - select VIDEOBUF_DMA_CONTIG - help - Support for DM VPFE based frame grabber. This is the - common V4L2 module for following DMXXX SoCs from Texas - Instruments:- DM6446 DM355. - - To compile this driver as a module, choose M here: the - module will be called vpfe-capture. - -config VIDEO_DM6446_CCDC - tristate DM6446 CCDC HW module - depends on ARCH_DAVINCI_DM644x VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DaVinci CCD hw module. DaVinci CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from slave decoders. - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_DM355_CCDC - tristate DM355 CCDC HW module - depends on ARCH_DAVINCI_DM355 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables DM355 CCD hw module. DM355 CCDC hw interfaces - with decoder modules such as TVP5146 over BT656 or - sensor module such as MT9T001 over a raw interface. This - module configures the interface and CCDC/ISIF to do - video frame capture from a slave decoders - - To compile this driver as a module, choose M here: the - module will be called vpfe. - -config VIDEO_ISIF - tristate ISIF HW module - depends on ARCH_DAVINCI_DM365 VIDEO_VPFE_CAPTURE - select VIDEO_VPSS_SYSTEM - default y - help - Enables ISIF hw module. This is the hardware module for - configuring ISIF in VPFE to capture Raw Bayer RGB data from - a image sensor or YUV data from a YUV source. - - To compile this driver as a module, choose M here: the - module will be called vpfe. +source drivers/media/video/davinci/Kconfig source drivers/media/video/omap/Kconfig diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index cc93859..aa1ea2f 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -177,7 +177,7 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o -obj-$(CONFIG_ARCH_DAVINCI) += davinci/ +obj-y += davinci/ obj-$(CONFIG_ARCH_OMAP)+= omap/ diff --git a/drivers/media/video/davinci/Kconfig b/drivers/media/video/davinci/Kconfig new file mode 100644 index 000..6b19540 --- /dev/null +++ b/drivers/media/video/davinci/Kconfig @@ -0,0 +1,93 @@ +config DISPLAY_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Display + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + select VIDEO_ADV7343 + select VIDEO_THS7303 + help + Support for DM6467 based display device. + + To compile this driver as a module, choose M here: the + module will be called vpif_display. + +config CAPTURE_DAVINCI_DM646X_EVM + tristate DM646x EVM Video Capture + depends on VIDEO_DEV MACH_DAVINCI_DM6467_EVM + select VIDEOBUF_DMA_CONTIG + select VIDEO_DAVINCI_VPIF + help + Support for DM6467 based capture device. + + To compile this driver as a module, choose M here: the + module will be called vpif_capture. + +config VIDEO_DAVINCI_VPIF + tristate DaVinci VPIF Driver + depends on DISPLAY_DAVINCI_DM646X_EVM + help + Support for DaVinci VPIF Driver. + + To compile this driver as a module, choose M here: the + module will be called vpif. + +config VIDEO_VPSS_SYSTEM + tristate VPSS
Re: AVerTV Hybrid Volar HD
On 06/02/2010 03:44 AM, Leo List wrote: I just did something stupid and bought this USB device, which according to AVerMedia has no Linux driver and no planned support. Yeah, you should have bought the volar HX :-( -- 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: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Mauro Carvalho Chehab mche...@infradead.org writes: Em 02-06-2010 18:09, Andrew Morton escreveu: On Sun, 30 May 2010 14:29:55 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16077 2.6.33 - 2.6.34 performance regression in dvb webcam frame rates. I don't think this is a regression. Probably, the new code is allowing a higher resolution. As the maximum bandwidth from the sensor to the USB bridge doesn't change, and a change from QVGA to VGA implies on 4x more pixels per frame, as consequence, the number of frames per second will likely reduce by a factor of 4x. I've asked the reporter to confirm what resolutions he is setting on 2.6.33 and on 2.6.34, just to double check if my thesis is correct. Well, the two video clips attached to the bug shows the same resolution but a much, much lower video (and overall) bitrate in 2.6.34. Output from mediainfo: General Complete name: 2.6.33-02063303-generic #02063303.ogv Format : OGG File size: 672 KiB Duration : 6s 331ms Overall bit rate : 870 Kbps Video ID : 20423689 (0x137A409) Format : Theora Duration : 6s 333ms Bit rate : 714 Kbps Width: 320 pixels Height : 240 pixels Display aspect ratio : 4:3 Frame rate : 30.000 fps Bits/(Pixel*Frame) : 0.310 Stream size : 552 KiB (82%) Writing library : Xiph.Org libtheora 1.1 20090822 (Thusnelda) Audio ID : 1459180980 (0x56F955B4) Format : Vorbis Format settings, Floor : 1 Duration : 6s 331ms Bit rate mode: Constant Bit rate : 112 Kbps Channel(s) : 2 channels Sampling rate: 44.1 KHz Stream size : 86.6 KiB (13%) Writing library : libVorbis 20090709 (UTC 2009-07-09) General Complete name: 2.6.34-999-generic #201005121008.ogv Format : OGG File size: 276 KiB Duration : 15s 424ms Overall bit rate : 146 Kbps Video ID : 12773534 (0xC2E89E) Format : Theora Duration : 15s 433ms Bit rate : 19.8 Kbps Width: 320 pixels Height : 240 pixels Display aspect ratio : 4:3 Frame rate : 30.000 fps Bits/(Pixel*Frame) : 0.009 Stream size : 37.2 KiB (14%) Writing library : Xiph.Org libtheora 1.1 20090822 (Thusnelda) Audio ID : 1010301390 (0x3C37F9CE) Format : Vorbis Format settings, Floor : 1 Duration : 15s 424ms Bit rate mode: Constant Bit rate : 112 Kbps Channel(s) : 2 channels Sampling rate: 44.1 KHz Stream size : 211 KiB (76%) Writing library : libVorbis 20090709 (UTC 2009-07-09) Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
Vaibhav,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 12:12 PM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board
file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR176
#define LCD_PANEL_BKLIGHT_PWR182
#define LCD_PANEL_PWM181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
Is it necessary to assign to the local variable (vpfe_int_clr)? If not, we can
reduce the size of this routine by two assembly instructions:
One: copying the result to a register
Two: pushing the register value to stack
-Tarun
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = AM3517 EVM,
+ .ccdc
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 12:49 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board
file
Vaibhav,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 12:12 PM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board
file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
Is it necessary to assign to the local variable (vpfe_int_clr)? If not, we
can reduce the size of this routine by two assembly instructions:
One: copying the result to a register
Two: pushing the register value
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 1:41 PM
To: DebBarma, Tarun Kanti; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 12:49 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
Vaibhav,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 12:12 PM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR176
#define LCD_PANEL_BKLIGHT_PWR182
#define LCD_PANEL_PWM181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD1_INT_CLR;
+ break;
+ /* VD2 interrrupt */
+ case INT_35XX_CCDC_VD2_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD2_INT_CLR;
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr,
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 1:44 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board
file
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 1:41 PM
To: DebBarma, Tarun Kanti; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 12:49 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
Vaibhav,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 12:12 PM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR 176
#define LCD_PANEL_BKLIGHT_PWR 182
#define LCD_PANEL_PWM 181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL(V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
+ switch (vdint) {
+ /* VD0 interrrupt */
+ case INT_35XX_CCDC_VD0_IRQ:
+ vpfe_int_clr = ~AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ vpfe_int_clr |= AM35XX_VPFE_CCDC_VD0_INT_CLR;
+ break;
+ /* VD1 interrrupt */
+ case INT_35XX_CCDC_VD1_IRQ:
+ vpfe_int_clr =
Which GIT repository for 2.6.35/2.6.36
Hi Mauro, I am lost with the GIT repositories at LinuxTv.org. My local development repository is based on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git origin and git://linuxtv.org/v4l-dvb.git master When moving any local branch, the kernel is 2.6.33. Looking at 'origin/HEAD', the kernel is 2.6.34. Then, looking at http://git.linuxtv.org/linux-2.6.git, the kernel is 2.6.35-rc1. A problem appeared when some gspca testers signalled compilation errors with kernels 2.6.34. Looking more carefuly, I see that, in the file drivers/media/video/gspca/zc3xx.c there is no #include linux/slab.h in the local branches, nor in v4l-dvb master, while it exists in v4l-dvb devel/for_v2.6.34. Looking at http://git.linuxtv.org/linux-2.6.git, I see that there is a recent change about the files slab.h et gfp.h (commit 5a0e3ad6af8660be21ca98a971cd00f331318c05) which touches gspca files again. I do not think I will put anything more in the new kernel (2.6.35), but what with 2.6.36? Some gspca files have been changed in kernels 2.6.34 and 2.6.35, and these changes don't appear in the v4l-dvb repository. What can I do? - if I continue to develop with v4l-dvb, there will be permanent merge problems with the future kernel. - if I base my local repository directly on the last 2.6.35, there will be problems with v4l-dvb. Otherwise, at LinuxTv.org, is there any development repository in sync with both the last kernel and the video stuff? Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Hi, On 06/03/2010 09:03 AM, Bjørn Mork wrote: Mauro Carvalho Chehabmche...@infradead.org writes: Em 02-06-2010 18:09, Andrew Morton escreveu: On Sun, 30 May 2010 14:29:55 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=16077 2.6.33 - 2.6.34 performance regression in dvb webcam frame rates. I don't think this is a regression. Probably, the new code is allowing a higher resolution. As the maximum bandwidth from the sensor to the USB bridge doesn't change, and a change from QVGA to VGA implies on 4x more pixels per frame, as consequence, the number of frames per second will likely reduce by a factor of 4x. I've asked the reporter to confirm what resolutions he is setting on 2.6.33 and on 2.6.34, just to double check if my thesis is correct. Well, the two video clips attached to the bug shows the same resolution but a much, much lower video (and overall) bitrate in 2.6.34. Output from mediainfo: I notice in the original bug report that you claim that the lower framerate clip with 2.6.34 has much better quality, could you define this a bit better. I think that what is happening is the code for the new (correct) sensor is setting a higher exposure value (and thus a lighter / less dark image), but setting a higher exposure value comes at the cost of framerate. As the framerate can never be higher then 1 / exposure_time_for_1_frame. 2 things: 1) Go the preferences in cheese, and see which resolutions you can select, and make sure you are using the same resolution in 2.6.34 and 2.6.33 2) Start a v4l2 control panel applet, like v4l2ucp or gtk-v4l, and try playing around with the controls (note the controls inside cheese are software not hardware controls so don't use those). Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 16077] New: Drop is video frame rate in kernel .34
Hans de Goede hdego...@redhat.com writes: I notice in the original bug report that you claim that the lower framerate clip with 2.6.34 has much better quality, could you define this a bit better. Sorry for the confusion, but this wasn't me. I just read the bug report. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 1:50 PM
To: DebBarma, Tarun Kanti; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 1:44 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
-Original Message-
From: Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 1:41 PM
To: DebBarma, Tarun Kanti; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 12:49 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support
to
board
file
Vaibhav,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
Sent: Thursday, June 03, 2010 12:12 PM
To: linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-
o...@vger.kernel.org; Hiremath, Vaibhav
Subject: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to
board
file
From: Vaibhav Hiremath hvaib...@ti.com
Also created vpfe master/slave clock aliases, since naming
convention is different in both Davinci and AM3517 devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/board-am3517evm.c | 161
+
1 files changed, 161 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-
omap2/board-am3517evm.c
index c1c4389..f2ff751 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -30,15 +30,168 @@
#include plat/board.h
#include plat/common.h
+#include plat/control.h
#include plat/usb.h
#include plat/display.h
+#include media/tvp514x.h
+#include media/davinci/vpfe_capture.h
+
#include mux.h
#define LCD_PANEL_PWR176
#define LCD_PANEL_BKLIGHT_PWR182
#define LCD_PANEL_PWM181
+/*
+ * VPFE - Video Decoder interface
+ */
+#define TVP514X_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
+
+/* Inputs available at the TVP5146 */
+static struct v4l2_input tvp5146_inputs[] = {
+ {
+ .index = 0,
+ .name = Composite,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+ {
+ .index = 1,
+ .name = S-Video,
+ .type = V4L2_INPUT_TYPE_CAMERA,
+ .std= TVP514X_STD_ALL,
+ },
+};
+
+static struct tvp514x_platform_data tvp5146_pdata = {
+ .clk_polarity = 0,
+ .hs_polarity= 1,
+ .vs_polarity= 1
+};
+
+static struct vpfe_route tvp5146_routes[] = {
+ {
+ .input = INPUT_CVBS_VI1A,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+ {
+ .input = INPUT_SVIDEO_VI2C_VI1C,
+ .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
+ },
+};
+
+static struct vpfe_subdev_info vpfe_sub_devs[] = {
+ {
+ .name = tvp5146,
+ .grp_id = 0,
+ .num_inputs = ARRAY_SIZE(tvp5146_inputs),
+ .inputs = tvp5146_inputs,
+ .routes = tvp5146_routes,
+ .can_route = 1,
+ .ccdc_if_params = {
+ .if_type = VPFE_BT656,
+ .hdpol = VPFE_PINPOL_POSITIVE,
+ .vdpol = VPFE_PINPOL_POSITIVE,
+ },
+ .board_info = {
+ I2C_BOARD_INFO(tvp5146, 0x5C),
+ .platform_data = tvp5146_pdata,
+ },
+ },
+};
+
+static void am3517_evm_clear_vpfe_intr(int vdint)
+{
+ unsigned int vpfe_int_clr;
+
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
+
RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board file
-Original Message-
From: DebBarma, Tarun Kanti
Sent: Thursday, June 03, 2010 2:46 PM
To: Hiremath, Vaibhav; linux-media@vger.kernel.org
Cc: mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org
Subject: RE: [PATCH-V1 2/2] AM3517: Add VPFE Capture driver support to board
file
snip
+ break;
+ /* Clear all interrrupts */
+ default:
+ vpfe_int_clr = ~(AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ vpfe_int_clr |= (AM35XX_VPFE_CCDC_VD0_INT_CLR |
+ AM35XX_VPFE_CCDC_VD1_INT_CLR |
+ AM35XX_VPFE_CCDC_VD2_INT_CLR);
+ break;
+ }
+ omap_ctrl_writel(vpfe_int_clr, AM35XX_CONTROL_LVL_INTR_CLEAR);
+ vpfe_int_clr = omap_ctrl_readl(AM35XX_CONTROL_LVL_INTR_CLEAR);
Is it necessary to assign to the local variable (vpfe_int_clr)? If
not,
we
can reduce the size of this routine by two assembly instructions:
One: copying the result to a register
Two: pushing the register value to stack
[Hiremath, Vaibhav] How are you going to achieve this? How are you
going
to define the switch case values here?
[Tarun] I am only referring to the last statement, outside the switch()
statement.
[Hiremath, Vaibhav] Ohhh Ok.
It is required; actually the read operation is required to push/reflect
the value written to register. In the past we have seen issues like write
is not getting reflected immediately leading to spurious interrupts.
[Tarun Kanti DebBarma]
Well, I understand agree that the read is needed. What I am saying is
whether the assignment to local variable is needed.
[Hiremath, Vaibhav] Tarun,
Don't you think compiler will anyway take care of this, below is the output of
objdump
c003aef8: e3000594movwr0, #1428 ; 0x594
c003aef0: e3001594movwr1, #1428 ; 0x594
c003aef4: ebffe7fbbl c0034ee8 omap_ctrl_writel
c003aefc: e8bd4010pop {r4, lr}
c003af00: eaffe7e9b c0034eac omap_ctrl_readl
Thanks,
Vaibhav
Thanks,
Vaibhav
Also currently this covers only VPFE Capture related interrupts but
this
function may required for other modules which are part of IPSS, like
HECC,
EMAC and USBOTG.
Thanks,
Vaibhav
-Tarun
+}
+
+static struct vpfe_config vpfe_cfg = {
+ .num_subdevs= ARRAY_SIZE(vpfe_sub_devs),
+ .i2c_adapter_id = 3,
+ .sub_devs = vpfe_sub_devs,
+ .clr_intr = am3517_evm_clear_vpfe_intr,
+ .card_name = AM3517 EVM,
+ .ccdc = DM6446 CCDC,
+};
+
+static struct resource vpfe_resources[] = {
+ {
+ .start = INT_35XX_CCDC_VD0_IRQ,
+ .end= INT_35XX_CCDC_VD0_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = INT_35XX_CCDC_VD1_IRQ,
+ .end= INT_35XX_CCDC_VD1_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
+static struct platform_device vpfe_capture_dev = {
+ .name = CAPTURE_DRV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(vpfe_resources),
+ .resource = vpfe_resources,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = vpfe_cfg,
+ },
+};
+
+static struct resource am3517_ccdc_resource[] = {
+ /* CCDC Base address */
+ {
+ .start = AM35XX_IPSS_VPFE_BASE,
+ .end= AM35XX_IPSS_VPFE_BASE + 0x,
+ .flags = IORESOURCE_MEM,
+ },
+};
+
+static struct platform_device am3517_ccdc_dev = {
+ .name = dm644x_ccdc,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(am3517_ccdc_resource),
+ .resource = am3517_ccdc_resource,
+ .dev = {
+ .dma_mask = vpfe_capture_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
static struct i2c_board_info __initdata am3517evm_i2c_boardinfo[]
= {
{
I2C_BOARD_INFO(s35390a, 0x30),
@@ -46,6 +199,7 @@ static struct i2c_board_info __initdata
am3517evm_i2c_boardinfo[] = {
},
};
+
/*
* RTC - S35390A
*/
@@ -261,6 +415,8 @@ static struct omap_board_config_kernel
am3517_evm_config[] __initdata = {
changed em28xx-cards-c; Plextor ConvertX AV100U now works!
Hi all,
I'm new to this. I wanted to get the Plextor ConvertX AV100U (with a eMPIA
EM2820 chip) to run in Ubuntu 10.04. This was made circa 2004 and
to the best of my knowledge the only official drives for it are Windows XP.
This is the device:
http://www.overclockersonline.net/reviews/5000198/
and this is the board:
http://www.overclockersonline.net/images/articles/plextor/av100u/large/pcb.jpg
and by adding this code to em28xx-cards-c
{ USB_DEVICE(0x093b, 0xa003),
.driver_info = EM2820_BOARD_PINNACLE_DVC_90 }, /* Plextor Corp.
ConvertX AV100U A/V Capture Audio */
It works!
I'm opening it as a capture device in VLC Player. Video is high quality, only
defect is a green bar on maybe the lower 15% of the screen. So three questions:
1) how do I address the green bar?
2) how to I get audio? I can see the device in Ubuntu under sound preferences.
How do I identify what the audio device name is?
3) What is the process to submit this change to em28xx-cards-c for v4l2?
Thanks,
Don Kramer
Atlanta, GA.
--
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: [Bugme-new] [Bug 16050] New: The ibmcam driver is not working
Hi, On 06/01/2010 07:19 PM, Bill Davidsen wrote: Hans de Goede wrote: In case you don't have this information, here is a line from lsusb: Bus 003 Device 002: ID 0545:8080 Xirlink, Inc. IBM C-It Webcam Hopefully the items you have ordered are the same model. I have the same usb-id, but I'm working on the driver now and it seems XirLink distinguishes between different models by bcdversion, instead of using different usb ids for each product. Can you send me a mail with the output of lsusb -v, then I can see if you have the same version as I have for testing. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
Didn't have time to look for gpios, tomorrow I will have. But I can tell that this change is not working for me: case SAA7134_BOARD_VIDEOMATE_T750: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8082c000, 0x8082c000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8082c000, 0x0080c000); break; Thanx for testing it out, If it doesn't work, try this: saa_andorl(SAA7134_GPIO_GPMODE0 2, /* keep */ 0x8082c000, /* keep */ 0x8082c000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, /* keep */ 0x8082c000, /* modify */ 0x0080c000); modify only the indicated number, try 0, try 0x8082c000 and if you have time try all combinations of bits 0x8082c000 optionally set to 0 e.g. 0x8002c000, 0x8080c000, 0x80828000, 0x0080c000 etc... It is possible that you and I don't have same revision of the card and you need a slightly different initialization procedure. If you get something to work for your card then I can try it back at mine there's a changes that we get a common setup which works for both. OK, I'm not having any personal opinion about the keys nor a application which I'm using, I'm just noticed that the keys differ against standard keys defined at linuxtv wiki. But if the keys at wiki are not correct, then perhaps should we change them there and let all use the same keys. If we have standard keys, than userspace applications programmers can make a use of it and assign the keys to their applications and to have just work experience to their users. But maybe I'm terrible wrong... Yeah I know, almost every remote has its own logic so it seems my version is yet-another-bla... I'm hoping for upcoming X11 xinput2 layer hopefully get full support of MCE remotes and nicely integrate with X applications therefore I produced MCE stuff here for a challenge to the xinput2 For integrated TV and PC to work well we need all remote keys be different than any other existing key used by keyboard. Without this, when X11 based TV view application gets out of input focus means it becomes irresponsive to ambiguity keys on the remote controller (in this example cursor keys) and we need to first use mouse to click on TV application and then continue using cursors on remote control (imagine how practical it is to make mouse click when watching TV from sofa) best regards, d. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-core multi-protocol decode and mceusb
Em 03-06-2010 03:27, Jarod Wilson escreveu:
On Tue, Jun 1, 2010 at 1:22 AM, Jarod Wilson ja...@wilsonet.com wrote:
On Mon, May 31, 2010 at 6:31 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Em 31-05-2010 18:45, Andy Walls escreveu:
On Mon, 2010-05-31 at 17:58 -0300, Mauro Carvalho Chehab wrote:
I may be wrong (since we didn't write any TX support), but I think that a
rc_set_tx_parameters() wouldn't be necessary, as I don't see why the
driver will
change the parameters after registering, and without any userspace
request.
Yes, my intent was to handle a user space request to change the
transmitter setup parameters to handle the protocol.
I also don't want to worry about having to code in kernel parameter
tables for any bizzare protocol userspace may know about.
Makes sense.
If we consider that some userspace sysfs nodes will allow changing some
parameters,
then the better is to have a callback function call, passed via the
registering function,
that will allow calling a function inside the driver to change the TX
parameters.
For example, something like:
struct rc_tx_props {
...
int (*change_protocol)(...);
...
};
rc_register_tx(..., struct rc_tx_props *props)
A callback is likely needed. I'm not sure I would have chosen the name
change_protocol(), because transmitter parameters can be common between
protocols (at least RC-5 and RC-6 can be supported with one set of
parameters), or not match any existing in-kernel protocol. As long as
it is flexible enough to change individual transmitter parameters
(modulated/baseband, carrier freq, duty cycle, etc.) it will be fine.
I just used this name as an example, as the same name exists on RX.
Depending on how we code the userspace API, we may use just one
set_parameters
function, or a set of per-attribute changes.
In other words, if we implement severa sysfs nodes to change several
parameters,
maybe it makes sense to have several callbacks. Another alternative would be
to have a commit sysfs node to apply a set of parameters at once.
Currently LIRC userspace changes Tx parameters using an ioctl(). It
asks the hardware to change transmitter parameters, because the current
model is that the transmitters don't need to know about protocols. (LIRC
userspace knows the parameters of the protocol it wants to use, so the
driver's don't have too).
The list of transmit-related ioctls implemented in the lirc_mceusb driver:
- LIRC_SET_TRANSMITTER_MASK -- these devices have two IR tx outputs,
default is to send the signal out both, but you can also select just a
specific one (i.e., two set top boxes, only want to send command to
one or the other of them).
- LIRC_GET_SEND_MODE -- get current transmit mode
- LIRC_SET_SEND_MODE -- set current transmit mode
- LIRC_SET_SEND_CARRIER -- set the transmit carrier freq
- LIRC_GET_FEATURE -- get both the send and receive capabilities of the
device
I notice IR Rx also has a change_protocol() callback that is not
currently in use.
It is used only by em28xx, where the hardware decoder can work either with
RC-5 or NEC (newer chips also support RC-6, but this is currently not
implemented).
The imon driver also implements change_protocol for the current-gen
devices, which are capable of decoding either mce remote signals or
the native imon remote signals. I was originally thinking I'd need to
implement change_protocol for the mceusb driver, but its ultimately a
no-op, since the hardware doesn't give a damn (and there's a note
somewhere that mentions its only relevant for hardware decode devices
that need to be put into a specific mode). Although, on something like
the mceusb driver, change_protocol *could* be wired up to mark only
the desired protocol enabled -- which might reduce complexity for
ir-keytable when loading a new keymap. (I went with a rather simple
approach for marking only the desired decoder enabled at initial
keymap load time which won't help here -- patch coming tomorrow for
that).
If sending raw pulses to userspace, it would be also
nice to expose that callback so userspace could set the receiver
parameters.
Raw pulse transmission is probably the easiest case. Probably, there's
nothing
or a very few things that might need adjustments.
Transmitter mask, carrier frequency and a repeat count are the things
I can see needing to set regularly. From experience, at least with
motorola set top box hardware, you need to send a given signal 2-3
times, not just once, for the hardware to pick it up. There's a
min_repeat parameter in lirc config files only used on the transmit
side of the house to specify how many repeats of each blasted signal
to send.
I keep bouncing between two machines, so I finally got smart(ish) and
pushed a working git tree to have both push and pull from.
http://git.wilsonet.com/linux-2.6-ir-wip.git/
Just pushed 3 patches with which I can now transmit IR via an
Re: Which GIT repository for 2.6.35/2.6.36
Em 03-06-2010 05:39, Jean-Francois Moine escreveu: Hi Mauro, I am lost with the GIT repositories at LinuxTv.org. My local development repository is based on git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git origin and git://linuxtv.org/v4l-dvb.git master When moving any local branch, the kernel is 2.6.33. Looking at 'origin/HEAD', the kernel is 2.6.34. Then, looking at http://git.linuxtv.org/linux-2.6.git, the kernel is 2.6.35-rc1. A problem appeared when some gspca testers signalled compilation errors with kernels 2.6.34. Looking more carefuly, I see that, in the file drivers/media/video/gspca/zc3xx.c there is no #include linux/slab.h in the local branches, nor in v4l-dvb master, while it exists in v4l-dvb devel/for_v2.6.34. Looking at http://git.linuxtv.org/linux-2.6.git, I see that there is a recent change about the files slab.h et gfp.h (commit 5a0e3ad6af8660be21ca98a971cd00f331318c05) which touches gspca files again. I do not think I will put anything more in the new kernel (2.6.35), but what with 2.6.36? Some gspca files have been changed in kernels 2.6.34 and 2.6.35, and these changes don't appear in the v4l-dvb repository. What can I do? - if I continue to develop with v4l-dvb, there will be permanent merge problems with the future kernel. - if I base my local repository directly on the last 2.6.35, there will be problems with v4l-dvb. Otherwise, at LinuxTv.org, is there any development repository in sync with both the last kernel and the video stuff? I'm experimenting some adjustments on the procedures I'm using to handle patches, in order to solve some troubles I've identified during the last merge period. During this time, the better thing to do is to base your tree at Linus tree. As I've created separate staging trees, per subject, each branch can be based on different object references, provided that they are already merged upstream. 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: [Bugme-new] [Bug 16050] New: The ibmcam driver is not working
Hans de Goede wrote: Hi, On 06/01/2010 07:19 PM, Bill Davidsen wrote: Hans de Goede wrote: In case you don't have this information, here is a line from lsusb: Bus 003 Device 002: ID 0545:8080 Xirlink, Inc. IBM C-It Webcam Hopefully the items you have ordered are the same model. I have the same usb-id, but I'm working on the driver now and it seems XirLink distinguishes between different models by bcdversion, instead of using different usb ids for each product. Can you send me a mail with the output of lsusb -v, then I can see if you have the same version as I have for testing. Sure, attached. -- Bill Davidsen david...@tmr.com We can't solve today's problems by using the same thinking we used in creating them. - Einstein Bus 004 Device 002: ID 058f:6362 Alcor Micro Corp. Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External) Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 idVendor 0x058f Alcor Micro Corp. idProduct 0x6362 Hi-Speed 21-in-1 Flash Card Reader/Writer (Internal/External) bcdDevice1.29 iManufacturer 1 Generic iProduct2 Mass Storage Device iSerial 3 058F312D81B bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 250mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk (Zip) iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes2 Transfer TypeBulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 Device Qualifier (for other device speed): bLength10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize064 bNumConfigurations 1 Device Status: 0x (Bus Powered) Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass9 Hub bDeviceSubClass 0 Unused bDeviceProtocol 0 Full speed (or root) hub bMaxPacketSize064 idVendor 0x1d6b Linux Foundation idProduct 0x0001 1.1 root hub bcdDevice2.06 iManufacturer 3 Linux 2.6.33.5-112.fc13.x86_64 uhci_hcd iProduct2 UHCI Host Controller iSerial 1 :00:1d.3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 25 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xe0 Self Powered Remote Wakeup MaxPower0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 1 bInterfaceClass 9 Hub bInterfaceSubClass 0 Unused bInterfaceProtocol 0 Full speed (or root) hub iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes3 Transfer TypeInterrupt Synch Type None Usage Type Data wMaxPacketSize 0x0002 1x 2 bytes bInterval 255 Hub Descriptor: bLength 9 bDescriptorType 41 nNbrPorts 2 wHubCharacteristic 0x000a No power switching (usb 1.0) Per-port overcurrent protection
New multiplex list for Boulogne sur mer / France
Hi, Since very first times of DVB-T at Boulogne sur mer / France, I tried to use fr-Boulogne regular lists for my scans (I'm a vdr user) but it worked very badly; as there was only one frequency correct. (DVB-T began in 2007 december here in Boulogne sur mer). So i managed to create my own list, from the official channel numbers. So here following is the list i use since then; that works perfectly for me. I want to share this little thing with others ... Cheers Jean-michel Déchamps / Boulogne sur mer / France # Boulogne - France (DVB-T transmitter of Boulogne ( MontLambert ) ) # Boulogne - France (signal DVB-T transmis depuis l'émetteur de MontLambert ) # # Si vous constatez des problemes et voulez apporter des # modifications au fichier, envoyez le fichier modifie a # l'adresse linux-media@vger.kernel.org (depot des fichiers d'init dvb) # # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy Boulogne - MontLambert # (Boulogne sur mer) #R1 T 53000 8MHz AUTO NONE QAM64 8k AUTO NONE #R2 T 58600 8MHz AUTO NONE QAM64 8k AUTO NONE #R3 T 63400 8MHz AUTO NONE QAM64 8k AUTO NONE #R4 T 65800 8MHz AUTO NONE QAM64 8k AUTO NONE #R5 T 69800 8MHz AUTO NONE QAM64 8k AUTO NONE #R6 T 71400 8MHz AUTO NONE QAM64 8k AUTO NONE -- 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-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices
On Thu, 3 Jun 2010 12:12:00 +0530 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Hi, What are IP's? thanks, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 C DVB-C card problems
Hi, I've got a terratec cinergy c dvb-c card, fresh install of ubuntu 10.04 lucid i386. Card is here: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C I followed the install instructions under Driver, installing the one from http://mercurial.intuxication.org/hg/s2-liplianin dmesg output afterwards: http://dpaste.com/202745/ and lsmod/lspci: http://dpaste.com/202150/ The previous install that worked nicely was hardy, using mantis-a9ecd19a37c9 that refused to compile with lucid's more recent kernel. Any ideas? Billy -- 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-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices
-Original Message- From: Randy Dunlap [mailto:rdun...@xenotime.net] Sent: Thursday, June 03, 2010 8:57 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org Subject: Re: [PATCH-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices On Thu, 3 Jun 2010 12:12:00 +0530 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Hi, What are IP's? [Hiremath, Vaibhav] Actually we have various DM series devices and IP's from it are being re-used for some of the OMAP/AM/DM devices as well. We do have some AM18x/AM17x parts which are coming to list in the near future which will again re-use drivers from here. Thanks, Vaibhav thanks, --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices
On Thu, 3 Jun 2010 21:03:27 +0530 Hiremath, Vaibhav wrote: -Original Message- From: Randy Dunlap [mailto:rdun...@xenotime.net] Sent: Thursday, June 03, 2010 8:57 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org Subject: Re: [PATCH-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices On Thu, 3 Jun 2010 12:12:00 +0530 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Hi, What are IP's? [Hiremath, Vaibhav] Actually we have various DM series devices and IP's from it are being re-used for some of the OMAP/AM/DM devices as well. We do have some AM18x/AM17x parts which are coming to list in the near future which will again re-use drivers from here. Since you didn't answer the question: So IP's are Intellectual Property logic blocks? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices
-Original Message- From: Randy Dunlap [mailto:rdun...@xenotime.net] Sent: Thursday, June 03, 2010 9:07 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org Subject: Re: [PATCH-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices On Thu, 3 Jun 2010 21:03:27 +0530 Hiremath, Vaibhav wrote: -Original Message- From: Randy Dunlap [mailto:rdun...@xenotime.net] Sent: Thursday, June 03, 2010 8:57 PM To: Hiremath, Vaibhav Cc: linux-media@vger.kernel.org; mche...@redhat.com; Karicheri, Muralidharan; linux-o...@vger.kernel.org Subject: Re: [PATCH-V1 1/2] Davinci: Create seperate Kconfig file for davinci devices On Thu, 3 Jun 2010 12:12:00 +0530 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@ti.com Currently VPFE Capture driver and DM6446 CCDC driver is being reused for AM3517. So this patch is preparing the Kconfig/makefile for re-use of such IP's. Hi, What are IP's? [Hiremath, Vaibhav] Actually we have various DM series devices and IP's from it are being re-used for some of the OMAP/AM/DM devices as well. We do have some AM18x/AM17x parts which are coming to list in the near future which will again re-use drivers from here. Since you didn't answer the question: So IP's are Intellectual Property logic blocks? [Hiremath, Vaibhav] ohhh man. You were asking what's the meaning of IP here? Ohhh Thanks, Vaibhav --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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] tm6000: bugfix unkown symbol tm6000_debug
From: Stefan Ringel stefan.rin...@arcor.de
May 30 07:54:09 linux-v5dy kernel: [ 2555.727426] tm6000: Unknown symbol
tm6000_debug
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-core.c |2 ++
drivers/staging/tm6000/tm6000-dvb.c |4 ++--
drivers/staging/tm6000/tm6000-video.c |2 +-
drivers/staging/tm6000/tm6000.h |2 --
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 2fbf4f6..350770e 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -29,6 +29,8 @@
#include media/v4l2-common.h
#include media/tuner.h
+static int tm6000_debug;
+
#define USB_TIMEOUT5*HZ /* ms */
int tm6000_read_write_usb(struct tm6000_core *dev, u8 req_type, u8 req,
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index 3ccc466..34dc8e5 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -38,9 +38,9 @@ MODULE_SUPPORTED_DEVICE({{Trident, tm5600},
{{Trident, tm6000},
{{Trident, tm6010});
-static int debug
+static int tm6000_debug;
-module_param(debug, int, 0644);
+module_param_named(debug, tm6000_debug, int, 0644);
MODULE_PARM_DESC(debug, enable debug message);
static inline void print_err_status(struct tm6000_core *dev,
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 1e348ac..1663dd2 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -55,7 +55,7 @@ static unsigned int vid_limit = 16; /* Video memory limit,
in Mb */
static int video_nr = -1; /* /dev/videoN, -1 for autodetect */
/* Debug level */
-int tm6000_debug;
+static int tm6000_debug;
/* supported controls */
static struct v4l2_queryctrl tm6000_qctrl[] = {
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 4b65094..ed7fece 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -318,8 +318,6 @@ int tm6000_queue_init(struct tm6000_core *dev);
/* Debug stuff */
-extern int tm6000_debug;
-
#define dprintk(dev, level, fmt, arg...) do {\
if (tm6000_debug level) \
printk(KERN_INFO (%lu) %s %s :fmt, jiffies, \
--
1.7.0.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 16050] New: The ibmcam driver is not working
Hans de Goede wrote: Hi, On 06/03/2010 04:58 PM, Bill Davidsen wrote: Hans de Goede wrote: Hi, On 06/01/2010 07:19 PM, Bill Davidsen wrote: Hans de Goede wrote: In case you don't have this information, here is a line from lsusb: Bus 003 Device 002: ID 0545:8080 Xirlink, Inc. IBM C-It Webcam Hopefully the items you have ordered are the same model. I have the same usb-id, but I'm working on the driver now and it seems XirLink distinguishes between different models by bcdversion, instead of using different usb ids for each product. Can you send me a mail with the output of lsusb -v, then I can see if you have the same version as I have for testing. Sure, attached. Thx, Your device has a revision of 3.0a (the firmware programmers did not seem to fully grasp the concept of the d in bcd (it stands for decimal), which is different from mine which is revision 3.01 . Your version is referred to as a model2 by the old driver, where as mine is a model3. This is both bad and good news, the bad news is I cannot give you an already tested driver to fix your issues. The good news is, that this means that, assuming that you are willing to help out with testing, we can now also verify that model 2 cams will work with the new driver. So would you be willing to test the new driver (when it is finished) ? Sure, just let me know what kernel the patch is against. As you say, my cams are Model2 in the old nomenclature. Interesting that the size is set to 352x240 rather than CIF 352x288. And while xawtv sort of works with the latest 2.6.33.5-112.fc13.x86_64 koji kernel, cheese doesn't, not that I need it, but it worked on the early kernels. -- Bill Davidsen david...@tmr.com We can't solve today's problems by using the same thinking we used in creating them. - Einstein -- 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 C DVB-C card problems
Billy Brumley bbrum...@gmail.com writes: I've got a terratec cinergy c dvb-c card, fresh install of ubuntu 10.04 lucid i386. Card is here: http://www.linuxtv.org/wiki/index.php/TerraTec_Cinergy_C_DVB-C I don't know what's wrong with your installation, but you may want to try installing the mantis driver without completely replacing the dvb-core. FYI, the mantis driver will be included in the next Debian 2.6.32 based kernel release thanks to the excellent Debian kernel team: http://bugs.debian.org/57724 . I guess that means that it will be available in Unbuntu soon as well. Anyway, the patch from that bug report should easily apply to any 2.6.32 kernel without having to mess with the whole DVB system. Bjørn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Compro Videomate T750F Vista digital+analog support
On Thu, 03 Jun 2010 16:04:07 +0200, Davor Emard davorem...@gmail.com wrote: Didn't have time to look for gpios, tomorrow I will have. But I can tell that this change is not working for me: case SAA7134_BOARD_VIDEOMATE_T750: dev-has_remote = SAA7134_REMOTE_GPIO; saa_andorl(SAA7134_GPIO_GPMODE0 2, 0x8082c000, 0x8082c000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, 0x8082c000, 0x0080c000); break; Thanx for testing it out, If it doesn't work, try this: saa_andorl(SAA7134_GPIO_GPMODE0 2, /* keep */ 0x8082c000, /* keep */ 0x8082c000); saa_andorl(SAA7134_GPIO_GPSTATUS0 2, /* keep */ 0x8082c000, /* modify */ 0x0080c000); modify only the indicated number, try 0, try 0x8082c000 and if you have time try all combinations of bits 0x8082c000 optionally set to 0 e.g. 0x8002c000, 0x8080c000, 0x80828000, 0x0080c000 etc... It is possible that you and I don't have same revision of the card and you need a slightly different initialization procedure. If you get something to work for your card then I can try it back at mine there's a changes that we get a common setup which works for both. OK, do I need to do cold boot or reboot anytime I try different gpio value? -- 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:Thu Jun 3 19:00:24 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14875:304cfde05b3f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 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: ERRORS 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: ERRORS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-armv5-ixp: ERRORS 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: ERRORS 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: ERRORS 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: ERRORS 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: ERRORS 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: ERRORS 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: ERRORS 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/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] IR: add core lirc device interface
On Thu, Jun 03, 2010 at 03:02:11AM -0300, Mauro Carvalho Chehab wrote:
Em 01-06-2010 17:51, Jarod Wilson escreveu:
Add the core lirc device interface (http://lirc.org/).
This is a 99.9% unaltered lirc_dev device interface (only change being
the path to lirc.h), which has been carried in the Fedora kernels and
has been built for numerous other distro kernels for years. In the
next two patches in this series, ir-core will be wired up to make use
of the lirc interface as one of many IR protocol decoder options. In
this case, raw IR will be delivered to the lirc userspace daemon, which
will then handle the decoding.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/Kconfig| 11 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/lirc_dev.c | 850
+++
drivers/media/IR/lirc_dev.h | 228
include/media/lirc.h| 159
5 files changed, 1249 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
...
+#ifdef CONFIG_COMPAT
+#define LIRC_GET_FEATURES_COMPAT32 _IOR('i', 0x, __u32)
+
+#define LIRC_GET_SEND_MODE_COMPAT32_IOR('i', 0x0001, __u32)
+#define LIRC_GET_REC_MODE_COMPAT32 _IOR('i', 0x0002, __u32)
+
+#define LIRC_GET_LENGTH_COMPAT32 _IOR('i', 0x000f, __u32)
+
+#define LIRC_SET_SEND_MODE_COMPAT32_IOW('i', 0x0011, __u32)
+#define LIRC_SET_REC_MODE_COMPAT32 _IOW('i', 0x0012, __u32)
+
+long lirc_dev_fop_compat_ioctl(struct file *file,
+ unsigned int cmd32,
+ unsigned long arg)
+{
+ mm_segment_t old_fs;
+ int ret;
+ unsigned long val;
+ unsigned int cmd;
+
+ switch (cmd32) {
+ case LIRC_GET_FEATURES_COMPAT32:
+ case LIRC_GET_SEND_MODE_COMPAT32:
+ case LIRC_GET_REC_MODE_COMPAT32:
+ case LIRC_GET_LENGTH_COMPAT32:
+ case LIRC_SET_SEND_MODE_COMPAT32:
+ case LIRC_SET_REC_MODE_COMPAT32:
+ /*
+* These commands expect (unsigned long *) arg
+* but the 32-bit app supplied (__u32 *).
+* Conversion is required.
+*/
+ if (get_user(val, (__u32 *)compat_ptr(arg)))
+ return -EFAULT;
+ lock_kernel();
Hmm... BKL? Are you sure you need it here? As BKL are being removed, please
rewrite
it to use another kind of lock.
On a first glance, I suspect that you should be locking ir-irctl_lock inside
lirc_dev_fop_ioctl() and just remove the BKL calls on
lirc_dev_fop_compat_ioctl().
Ew, yeah, looks like there's some missing locking in lirc_dev_fop_ioctl(),
though its never been a problem in practice, from what I've seen... Okay,
will add locking there.
As for the compat bits... I actually pulled them out of the Fedora kernel
and userspace for a while, and there were only a few people who really ran
into issues with it, but I think if the new userspace and kernel are rolled
out at the same time in a new distro release (i.e., Fedora 14, in our
particular case), it should be mostly transparent to users. Christoph
wasn't a fan of the change, and actually asked me to revert it, so I'm
cc'ing him here for further feedback, but I'm inclined to say that if this
is the price we pay to get upstream, so be it.
Btw, as this is the first in-tree kernel driver for lirc, I would just define
the
lirc ioctls with __u32 and remove the entire compat stuff.
I've pushed a patch into my ir-wip tree, ir branch, that does this:
http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/ir
I've tested it out, and things still work as expected w/my mceusb port and
the ir-lirc-codec ir-core bridge driver, after rebuilding the lirc
userspace (64-bit host) to match up the ioctl definitions.
+/*
+ * from the next key press on the driver will send
+ * LIRC_MODE2_FREQUENCY packets
+ */
+#define LIRC_MEASURE_CARRIER_ENABLE_IO('i', 0x0021)
+#define LIRC_MEASURE_CARRIER_DISABLE _IO('i', 0x0022)
+
+#endif
Wow! There are lots of ioctls that aren't currently used. IMO, the better is
to add
at the file just the ioctls that are currently in usage, and to put some
documentation
about them at /Documentation.
Several of the ioctls were only very recently (past 4 months) added, but I
haven't a clue what they're actually used for... Adding something to
Documentation/ would definitely be prudent in any case.
--
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
Re: [PATCH 2/2 v2] IR: add mceusb IR receiver driver
On Thu, Jun 03, 2010 at 03:04:14AM -0300, Mauro Carvalho Chehab wrote: Em 01-06-2010 17:32, Jarod Wilson escreveu: This is a new driver for the Windows Media Center Edition/eHome Infrared Remote transceiver devices. Its a port of the current lirc_mceusb driver to ir-core, and currently lacks transmit support, but will grow it back soon enough... This driver also differs from lirc_mceusb in that it borrows heavily from a simplified IR buffer decode routine found in Jon Smirl's earlier ir-mceusb port. This driver has been tested on the original first-generation MCE IR device with the MS vendor ID, as well as a current-generation device with a Topseed vendor ID. Every receiver supported by lirc_mceusb should work equally well. Testing was done primarily with RC6 MCE remotes, but also briefly with a Hauppauge RC5 remote, and all works as expected. v2: fix call to ir_raw_event_handle so repeats work as they should. The driver seems ok, except for a few magic numbers. I'll apply at the tree, to allow more people to test. Please send me later a patch fixing those small issues. I'll get something in flight tonight or tomorrow. All those uglies are in the 1st-gen init code, which needs some further work anyway to kill off a warning about the driver mapping memory from stack. I've got a number of other 1st-gen tx and debug output fixes queued up as well. -- 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
FW: DVB-T af9015 K world device problem, only gets channels from one multiplex
Message Received: Jun 02 2010, 11:01 AM From: john ryan To: linux-media@vger.kernel.org Cc: Subject: DVB-T af9015 (K world) device problem, only gets channels from one multiplex Hi, I'm running: System uname: Linux-2.6.32-gentoo-r7-x86_64-Quad-Core_AMD_Opteron-tm-_Processor_1352-with-gentoo-1.12.13 I have a K World DVB-T USB device. When I run W-scan, all frequencies are scanned, but it only picks up individual stations on one multiplex. At the end of the scan it tries to tune in the other multiplexes but cannot. I am reasonably sure the problem is not with W-scan, but I am unsure what has gone wrong or what I can change to fix it - I am a Linux n00bie ! This is a dump of W-scan log w_scan version 20100529 (compiled for DVB API 5.0) GB atsc1 dvb2 frontend2 using settings for UNITED KINGDOM DVB aerial DVB-T GB frontend_type DVB-T, channellist 6 output format vdr-1.6 Info: using DVB adapter auto detection. /dev/dvb/adapter0/frontend0 - DVB-T Afatech AF9013 DVB-T: good :-) Using DVB-T frontend (adapter /dev/dvb/adapter0/frontend0) -_-_-_-_ Getting frontend capabilities-_-_-_-_ Using DVB API 3.2 frontend Afatech AF9013 DVB-T supports INVERSION_AUTO QAM_AUTO TRANSMISSION_MODE_AUTO GUARD_INTERVAL_AUTO HIERARCHY_AUTO FEC_AUTO -snip--- base_offset=-1, channel=133, step=800 channellist=6, base_offset=-1, channel=133, step=800 tune to: QAM_16 f = 578166 kHz I999B8C34D0T2G32Y0 (time: 06:37) set_frontend: using DVB API 3.2 tuning status == 0x03 tuning status == 0x1f PAT = parse_pat len = 94 0x00: 00 00 E0 10 64 40 E3 E9 64 80 E3 EA 64 C0 E3 EB : d@ d d 0x10: 65 40 E3 ED 6B 00 E3 F7 6B 40 E3 F8 6B 80 E3 F9 : e@ k k@ k 0x20: 6B C0 E3 FA 6C 00 E4 08 6C 40 E4 09 6C 80 E4 0A : k l l@ l 0x30: 6C C0 E4 0B 6D 00 E4 0C 6D 80 E4 0D 69 80 E4 07 : l m m i 0x40: 68 40 E4 05 68 00 E4 04 67 C0 E4 03 66 C0 E3 FF : h@ h g f 0x50: 66 80 E3 FE 66 40 E3 FD 67 00 E4 00 6A 00 : f f@ g j PMT 0x03f8 for service 0x6b40 = parse_pmt len = 47 0x00: FF FF F0 00 0B E8 9E F0 28 52 01 65 66 0D 01 06 : (R ef 0x10: 01 01 00 07 01 05 01 01 6F FF FF 13 05 00 00 00 : o 0x20: 01 00 14 0D 00 65 00 00 08 FF FF FF FF FF FF : e DSM-CC U-N Messages : PID 0x089e PMT 0x0403 for service 0x67c0 = parse_pmt len = 61 0x00: E6 A5 F0 00 04 E6 A5 F0 09 52 01 01 0A 04 65 6E : R en 0x10: 67 00 0B E6 A6 F0 28 52 01 65 66 0D 01 06 01 01 : g (R ef 0x20: 00 07 01 05 01 01 6F FF FF 13 05 00 00 00 01 00 : o 0x30: 14 0D 00 65 00 00 08 FF FF FF FF FF FF : e AUDIO : PID 0x06a5 DSM-CC U-N Messages : PID 0x06a6 PMT 0x03e9 for service 0x6440 = parse_pmt len = 65 0x00: E0 65 F0 00 02 E0 65 F0 03 52 01 01 04 E0 66 F0 : e e R f 0x10: 09 52 01 02 0A 04 65 6E 67 00 0B E0 69 F0 12 52 : R eng i R 0x20: 01 6E 13 05 00 00 00 01 00 66 06 01 06 01 01 00 : n f 0x30: 00 06 E0 67 F0 0D 52 01 03 59 08 65 6E 67 10 00 : g R Y eng 0x40: 02 : VIDEO : PID 0x0065 AUDIO : PID 0x0066 DSM-CC U-N Messages : PID 0x0069 SUBTITLING: PID 0x0067 PMT 0x0400 for service 0x6700 = parse_pmt len = 61 0x00: E5 79 F0 00 04 E5 79 F0 09 52 01 01 0A 04 65 6E : y y R en 0x10: 67 00 0B E5 7A F0 28 52 01 65 66 0D 01 06 01 01 : g z (R ef 0x20: 00 07 01 05 01 01 6F FF FF 13 05 00 00 00 01 00 : o 0x30: 14 0D 00 65 00 00 08 FF FF FF FF FF FF : e AUDIO : PID 0x0579 DSM-CC U-N Messages : PID 0x057a PMT 0x040a for service 0x6c80 = parse_pmt len = 47 0x00: FF FF F0 00 0B E9 16 F0 28 52 01 65 66 0D 01 06 : (R ef 0x10: 01 01 00 07 01 05 01 01 6F FF FF 13 05 00 00 00 : o 0x20: 01 00 14 0D 00 65 00 00 08 FF FF FF FF FF FF : e DSM-CC U-N Messages : PID 0x0916 PMT 0x03fd for service 0x6640 = parse_pmt len = 61 0x00: E4 4D F0 00 04 E4 4D F0 09 52 01 01 0A 04 65 6E : M M R en 0x10: 67 00 0B E4 4E F0 28 52 01 65 66 0D 01 06 01 01 : g N (R ef 0x20: 00 07 01 05 01 01 6F FF FF 13 05 00 00 00 01 00 : o 0x30: 14 0D 00 65 00 00 08 FF FF FF FF FF FF : e AUDIO : PID 0x044d DSM-CC U-N Messages : PID 0x044e PMT 0x03ea for service 0x6480 = parse_pmt
Re: What ever happened to standardizing signal level?
Hi, Am Sonntag, den 30.05.2010, 00:01 -0700 schrieb VDR User: On Sat, May 29, 2010 at 10:52 PM, hermann pitton hermann-pit...@arcor.de wrote: ...troll spam removed... Hermann, you're a known troll with clearly nothing to contribute to this thread therefore you're comments are unwelcome. Your mostly incoherent rant sounds like the ramblings of somebody who has consumed too much alcohol, and you're obviously using this mailing list as a cry for attention. I'll ask you kindly to stop wasting everyones time with your moronic nonsense and direct your harassment elsewhere. I'm sure you can find something better to do with your time then polluting this mailing list and making yourself look foolish. To everyone else, please disregard this post and the imbecile in which I'm replying to. I tried in vain, several times, to get the VDR User to some ground. To participate in development is about patches, as a minimum. Driver maintainers are on a much higher level and can disregard patches. If patches go to mainline, one has to allow to be authenticated. There is no other way to get any stuff in else, with reasons. If one is acting under some anonymous name and email account, there is no way to fulfill this first requirement. So, anything coming in from such, is taken as trolling. Especially, if one did already qualify for taking it all over, rule the personal engaged and so on ... I'm not sure, if we have to improve the wiki for those never ever sending any patches, since this is the first on what we meet. But some, taking it all over, seem still to be in urgent need about how to improve that ;) Cheers, Hermann -- 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
success
Hi, had success in activating analog tuner in: http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards Philips TV/Radio Card CTX918, (Medion 7134), PCI In my case, device is labeled: MEDION Type: TV-Tuner 7134 V.92 Data/Fax Modem Rev: CTX918_V2 DVB-T/TV P/N: 20024179 Label on tuner (other side of PCB) offers info on tuner type: Label reads: 3139 147 22491c# FMD1216ME/I H-3 SV21 6438 Made in INONESIA So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3, NOT tuner=63 as detected by system. Please check and alter if applicable. Suspect different Hardware revs come with identical hardware ID's. Will provide additional info if told hot to obtain (hardware ID or whatever), but have to take a nap right now. It's 4 in the morning. Have a nice one...and thanks for all the work Your's Alex -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 -- 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: success
Hi, Am Freitag, den 04.06.2010, 03:59 +0200 schrieb Alexander Apostolatos: Hi, had success in activating analog tuner in: http://linuxtv.org/wiki/index.php/DVB-T_PCI_Cards Philips TV/Radio Card CTX918, (Medion 7134), PCI In my case, device is labeled: MEDION Type: TV-Tuner 7134 V.92 Data/Fax Modem Rev: CTX918_V2 DVB-T/TV P/N: 20024179 Label on tuner (other side of PCB) offers info on tuner type: Label reads: 3139 147 22491c# FMD1216ME/I H-3 SV21 6438 Made in INONESIA So I suppose tuner=78 is the compatible type for FMD1216ME/I H-3, NOT tuner=63 as detected by system. Please check and alter if applicable. Suspect different Hardware revs come with identical hardware ID's. Will provide additional info if told hot to obtain (hardware ID or whatever), but have to take a nap right now. It's 4 in the morning. I have such stuff with some known flaws, easily to circumvent. The CTX918 V2 needs to be in the original dual bus master capable blue MSI/Medion PCI slot. Else, it can become very tricky. Cheers, Hermann -- 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
Em 03-06-2010 19:06, Jarod Wilson escreveu:
On Thu, Jun 03, 2010 at 03:02:11AM -0300, Mauro Carvalho Chehab wrote:
Em 01-06-2010 17:51, Jarod Wilson escreveu:
Add the core lirc device interface (http://lirc.org/).
This is a 99.9% unaltered lirc_dev device interface (only change being
the path to lirc.h), which has been carried in the Fedora kernels and
has been built for numerous other distro kernels for years. In the
next two patches in this series, ir-core will be wired up to make use
of the lirc interface as one of many IR protocol decoder options. In
this case, raw IR will be delivered to the lirc userspace daemon, which
will then handle the decoding.
Signed-off-by: Jarod Wilson ja...@redhat.com
---
drivers/media/IR/Kconfig| 11 +
drivers/media/IR/Makefile |1 +
drivers/media/IR/lirc_dev.c | 850
+++
drivers/media/IR/lirc_dev.h | 228
include/media/lirc.h| 159
5 files changed, 1249 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
...
+#ifdef CONFIG_COMPAT
+#define LIRC_GET_FEATURES_COMPAT32 _IOR('i', 0x, __u32)
+
+#define LIRC_GET_SEND_MODE_COMPAT32_IOR('i', 0x0001, __u32)
+#define LIRC_GET_REC_MODE_COMPAT32 _IOR('i', 0x0002, __u32)
+
+#define LIRC_GET_LENGTH_COMPAT32 _IOR('i', 0x000f, __u32)
+
+#define LIRC_SET_SEND_MODE_COMPAT32_IOW('i', 0x0011, __u32)
+#define LIRC_SET_REC_MODE_COMPAT32 _IOW('i', 0x0012, __u32)
+
+long lirc_dev_fop_compat_ioctl(struct file *file,
+ unsigned int cmd32,
+ unsigned long arg)
+{
+ mm_segment_t old_fs;
+ int ret;
+ unsigned long val;
+ unsigned int cmd;
+
+ switch (cmd32) {
+ case LIRC_GET_FEATURES_COMPAT32:
+ case LIRC_GET_SEND_MODE_COMPAT32:
+ case LIRC_GET_REC_MODE_COMPAT32:
+ case LIRC_GET_LENGTH_COMPAT32:
+ case LIRC_SET_SEND_MODE_COMPAT32:
+ case LIRC_SET_REC_MODE_COMPAT32:
+ /*
+* These commands expect (unsigned long *) arg
+* but the 32-bit app supplied (__u32 *).
+* Conversion is required.
+*/
+ if (get_user(val, (__u32 *)compat_ptr(arg)))
+ return -EFAULT;
+ lock_kernel();
Hmm... BKL? Are you sure you need it here? As BKL are being removed, please
rewrite
it to use another kind of lock.
On a first glance, I suspect that you should be locking ir-irctl_lock
inside
lirc_dev_fop_ioctl() and just remove the BKL calls on
lirc_dev_fop_compat_ioctl().
Ew, yeah, looks like there's some missing locking in lirc_dev_fop_ioctl(),
though its never been a problem in practice, from what I've seen... Okay,
will add locking there.
Ok, thanks. Well, in the past, the ioctl where already blocked by BKL. So, the
lock
is/will probably needed only with newer kernels.
As for the compat bits... I actually pulled them out of the Fedora kernel
and userspace for a while, and there were only a few people who really ran
into issues with it, but I think if the new userspace and kernel are rolled
out at the same time in a new distro release (i.e., Fedora 14, in our
particular case), it should be mostly transparent to users.
For sure this will happen on all distros that follows upstream: they'll update
lirc
to fulfill the minimal requirement at Documentation/Changes.
The issue will appear only to people that manually compile kernel and lirc.
Those
users are likely smart enough to upgrade to a newer lirc version if they notice
a
trouble, and to check at the forums.
Christoph
wasn't a fan of the change, and actually asked me to revert it, so I'm
cc'ing him here for further feedback, but I'm inclined to say that if this
is the price we pay to get upstream, so be it.
I understand Christoph view, but I think that having to deal with compat stuff
forever
is a high price to pay, as the impact of this change is transitory and shouldn't
be hard to deal with.
Btw, as this is the first in-tree kernel driver for lirc, I would just
define the
lirc ioctls with __u32 and remove the entire compat stuff.
I've pushed a patch into my ir-wip tree, ir branch, that does this:
http://git.wilsonet.com/linux-2.6-ir-wip.git/?a=shortlog;h=refs/heads/ir
I've tested it out, and things still work as expected w/my mceusb port and
the ir-lirc-codec ir-core bridge driver, after rebuilding the lirc
userspace (64-bit host) to match up the ioctl definitions.
Patches look sane on my eyes.
+/*
+ * from the next key press on the driver will send
+ * LIRC_MODE2_FREQUENCY packets
+ */
+#define LIRC_MEASURE_CARRIER_ENABLE_IO('i', 0x0021)
+#define LIRC_MEASURE_CARRIER_DISABLE _IO('i', 0x0022)
+
+#endif
Wow! There are lots of ioctls that aren't currently used. IMO, the better
Re: [PATCH 2/2 v2] IR: add mceusb IR receiver driver
Em 03-06-2010 19:10, Jarod Wilson escreveu: On Thu, Jun 03, 2010 at 03:04:14AM -0300, Mauro Carvalho Chehab wrote: Em 01-06-2010 17:32, Jarod Wilson escreveu: This is a new driver for the Windows Media Center Edition/eHome Infrared Remote transceiver devices. Its a port of the current lirc_mceusb driver to ir-core, and currently lacks transmit support, but will grow it back soon enough... This driver also differs from lirc_mceusb in that it borrows heavily from a simplified IR buffer decode routine found in Jon Smirl's earlier ir-mceusb port. This driver has been tested on the original first-generation MCE IR device with the MS vendor ID, as well as a current-generation device with a Topseed vendor ID. Every receiver supported by lirc_mceusb should work equally well. Testing was done primarily with RC6 MCE remotes, but also briefly with a Hauppauge RC5 remote, and all works as expected. v2: fix call to ir_raw_event_handle so repeats work as they should. The driver seems ok, except for a few magic numbers. I'll apply at the tree, to allow more people to test. Please send me later a patch fixing those small issues. I'll get something in flight tonight or tomorrow. All those uglies are in the 1st-gen init code, which needs some further work anyway to kill off a warning about the driver mapping memory from stack. I've got a number of other 1st-gen tx and debug output fixes queued up as well. Ok, great. 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: What ever happened to standardizing signal level?
hermann pitton hermann-pit...@arcor.de, you are contributing absolutely nothing to this thread aside of annoying people with your by trolling and half incoherent nonsense. It's quite ironic you suggest _I_ am the one trolling when this is a thread _I_ created. And further, several people have posted legitimate responses to -- clearly you are the only one suffering from your delusion. Additionally you've been stalking me in email as well. Your behavior is not only uncalled for, it's abusive of both this mailing list and the people willingly participating in the discussion. As I understand it, this is not the first time you've been the source of harassment. Do us all a favor -- go find some other thread to infect with your childishness, find some other user(s) to harass/stalk/obsess over, or simply grow up and stop wasting everyone's time. In case you haven't noticed there has been absolutely nobody supporting your rants. Take a hint. -- 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
