Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
On Thu, 2009-08-06 at 15:25 -0700, Russell King - ARM Linux wrote: > On Thu, Aug 06, 2009 at 11:46:14AM -0700, David Xiao wrote: > > On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: > > > Hi Ben, > > > > > > On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > > > > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > > > [snip] > > > > > > > > > > The second problem is to ensure cache coherency. As the userspace > > > > > application will read data from the video buffers, those buffers will > > > > > end > > > > > up being cached in the processor's data cache. The driver does need to > > > > > invalidate the cache before starting the DMA operation (userspace > > > > > could > > > > > in theory write to the buffers, but the data will be overwritten by > > > > > DMA > > > > > anyway, so there's no need to clean the cache). > > > > > > > > You'll need to clean the write buffers, otherwise the CPU may have data > > > > queued that it has yet to write back to memory. > > > > > > Good points, thanks. > > > >I thought this should have been taken care of by the CPU specific > > dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, > > v7_dma_inv_range does not drain the write buffer; and the > > v6_dma_inv_range does that in the end of all the cache maintenance > > operaitons. > > There's no such thing as "drain write buffer" in ARMv7. There are > barriers instead, in particular dsb, which replaces the original > "drain write buffer" instruction. > Sorry, I overlooked the "DSB" inst in the end; yes, it looks like the CP15 related "drain write buffer" inst is deprecated in V7. > As far as userspace DMA coherency, the only way you could do it with > current kernel APIs is by using get_user_pages(), creating a scatterlist > from those, and then passing it to dma_map_sg(). While the device has > ownership of the SG, userspace must _not_ touch the buffer until after > DMA has completed. > > However, that won't work with ARMv7's speculative prefetching. I'm > afraid with such things, DMA direct into userspace mappings becomes a > _lot_ harder, and lets face it, lots of Linux drivers just aren't going > to bother supporting this - we can't currently get agreement to have an > API to map DMA coherent pages into userspace! The V7 speculative prefetching will then probably apply to DMA coherency issue in general, both kernel and user space DMAs. Could this be addressed by inside the dma_unmap_sg/single() calling dma_cache_maint() when the direction is DMA_FROM_DEVICE/DMA_BIDIRECTIONAL, to basically invalidate the related cache lines in case any filled by prefetching? Assuming dma_unmap_sg/single() is called after each DMA operation is completed. David -- 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: PVR x50 corrupts ATSC 115 streams
On Tue, Feb 17, 2009 at 09:53:35AM -0600, David Engel wrote: > I moved the disks and tuner cards (2 Kworld ATSC 115s, 1 Hauppauge PVR > 250 and 1 Hauppauge PVR 350) to the new system (AMD X2 3600 CPU and > Biostar TForce 550 motherboard). Things went fairly smoothly and I > seemed to have full stability again for the first time in several > weeks. > > Then, I started noticing frequent corruption in some of my claar QAM > recordings from the ATSC 115 cards. When the corruption is present, > it occurs every few seconds -- a splotch of garbage in the picture > here, a stutter and a skipped frame there. Sure enough, MythTV and > mplayer both report CRC, damage, splice and other errors when playing > the streams. > > I finally determined the stream corruption happens if and only if one > of the PVR x50 cards is being used at the same time. If only the ATSC > 115s are used, there is no corruption. As soon as either of the PVr > X50 is used with an ATSC 115, there is corruption. I tested with the > stock drivers from the 2.6.27.17 kernel and from current Hg. The > corruption happens with both sets of drivers. FWIW, I haven't noticed > any corruption with the analog recordings from the PVR x50s. > > Does anyone know what might be going on? These very same tuner cards > worked fine in the old system (Intel P4 3.0GHz CPU and Abit IC7 > motherboard) for close to two years. I want to follow up on this for the benefit of anyone who runs across it in the archives. The short version is the problem appears to have been caused by the motherboard. My guess is noise or a grounding problem. The slightly longer version is I've been using a non-optimal arrangement of tuner cards to avoid the corruption problems described above. About two weeks ago, I started having problems with one and then multiple SATA disks. Process of elimination led to the motherboard. I tried the previously troublesome combination of cards today with the new motherboard and no longer see the problem. David -- David Engel da...@istwok.net -- 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 v0 5/5] V4L: vpif capture - Kconfig and Makefile changes
From: Muralidharan Karicheri Adds Kconfig and Makefile changes required for vpif capture driver Mandatory reviewer: Hans Verkuil NOTE: This is only for review. Final patch for merge will be sent later. This patch is dependent on the patch from Chaithrika for vpif display Signed-off-by: Muralidharan Karicheri --- drivers/media/video/Kconfig | 15 +-- drivers/media/video/davinci/Makefile |2 ++ 2 files changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 8460013..f3feb6b 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -501,10 +501,21 @@ config DISPLAY_DAVINCI_DM646X_EVM select VIDEO_ADV7343 select VIDEO_THS7303 help - Support for DaVinci based display device. + Support for DM6467 based display device. To compile this driver as a module, choose M here: the - module will be called davincihd_display. + 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" diff --git a/drivers/media/video/davinci/Makefile b/drivers/media/video/davinci/Makefile index f44cad2..1a8b8f3 100644 --- a/drivers/media/video/davinci/Makefile +++ b/drivers/media/video/davinci/Makefile @@ -7,6 +7,8 @@ obj-$(CONFIG_VIDEO_DAVINCI_VPIF) += vpif.o #DM646x EVM Display driver obj-$(CONFIG_DISPLAY_DAVINCI_DM646X_EVM) += vpif_display.o +#DM646x EVM Capture driver +obj-$(CONFIG_CAPTURE_DAVINCI_DM646X_EVM) += vpif_capture.o # Capture: DM6446 and DM355 obj-$(CONFIG_VIDEO_VPSS_SYSTEM) += vpss.o -- 1.6.0.4 -- 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 v0 3/5] V4L: vpif display - updates to support vpif capture on DM6467
From: Muralidharan Karicheri
The structure name for vpif display driver changed since it was not unique. So
this
update is done to reflect the same. Also removed the code related to register
address space iomap. Uses v4l2_i2c_new_subdev_board() instead of
v4l2_i2c_new_probed_subdev() so that platform data can be added for subdevice
configuration for polarities.
NOTE: This is only for review. Final patch for merge will be
sent later. This patch is dependent on the patch from Chaithrika for vpif
display.
Mandatory reviewers : Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
drivers/media/video/davinci/vpif_display.c | 52 +++
1 files changed, 14 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 8ea65d7..ccc38b3 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -683,7 +683,7 @@ static int vpif_release(struct file *filep)
static int vpif_querycap(struct file *file, void *priv,
struct v4l2_capability *cap)
{
- struct vpif_config *config = vpif_dev->platform_data;
+ struct vpif_display_config *config = vpif_dev->platform_data;
cap->version = VPIF_DISPLAY_VERSION_CODE;
cap->capabilities = V4L2_CAP_VIDEO_OUTPUT | V4L2_CAP_STREAMING;
@@ -1053,7 +1053,7 @@ static int vpif_streamon(struct file *file, void *priv,
struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX];
struct channel_obj *oth_ch = vpif_obj.dev[!ch->channel_id];
struct vpif_params *vpif = &ch->vpifparams;
- struct vpif_config *vpif_config_data =
+ struct vpif_display_config *vpif_config_data =
vpif_dev->platform_data;
unsigned long addr = 0;
int ret = 0;
@@ -1239,7 +1239,7 @@ static int vpif_enum_output(struct file *file, void *fh,
struct v4l2_output *output)
{
- struct vpif_config *config = vpif_dev->platform_data;
+ struct vpif_display_config *config = vpif_dev->platform_data;
if (output->index >= config->output_count) {
vpif_dbg(1, debug, "Invalid output index\n");
@@ -1422,10 +1422,10 @@ vpif_init_free_channel_objects:
*/
static __init int vpif_probe(struct platform_device *pdev)
{
- const struct vpif_subdev_info *subdevdata;
+ struct vpif_subdev_info *subdevdata;
int i, j = 0, k, q, m, err = 0;
struct i2c_adapter *i2c_adap;
- struct vpif_config *config;
+ struct vpif_display_config *config;
struct common_obj *common;
struct channel_obj *ch;
struct video_device *vfd;
@@ -1433,30 +1433,14 @@ static __init int vpif_probe(struct platform_device
*pdev)
int subdev_count;
vpif_dev = &pdev->dev;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- v4l2_err(vpif_dev->driver,
- "Error getting platform resource\n");
- return -ENOENT;
- }
- if (!request_mem_region(res->start, res->end - res->start + 1,
- vpif_dev->driver->name)) {
- v4l2_err(vpif_dev->driver, "VPIF: failed request_mem_region\n");
- return -ENXIO;
- }
+ err = initialize_vpif();
- vpif_base = ioremap_nocache(res->start, res->end - res->start + 1);
- if (!vpif_base) {
- v4l2_err(vpif_dev->driver, "Unable to ioremap VPIF reg\n");
- err = -ENXIO;
- goto resource_exit;
+ if (err) {
+ v4l2_err(vpif_dev->driver, "Error initializing vpif\n");
+ return err;
}
- vpif_base_addr_init(vpif_base);
-
- initialize_vpif();
-
err = v4l2_device_register(vpif_dev, &vpif_obj.v4l2_dev);
if (err) {
v4l2_err(vpif_dev->driver, "Error registering v4l2 device\n");
@@ -1489,7 +1473,7 @@ static __init int vpif_probe(struct platform_device *pdev)
video_device_release(ch->video_dev);
}
err = -ENOMEM;
- goto video_dev_alloc_exit;
+ goto vpif_int_err;
}
/* Initialize field of video device */
@@ -1566,10 +1550,11 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
for (i = 0; i < subdev_count; i++) {
- vpif_obj.sd[i] = v4l2_i2c_new_probed_subdev(&vpif_obj.v4l2_dev,
+ vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(&vpif_obj.v4l2_dev,
i2c_adap, subdevdata[i].name,
- subdevdata[i].name,
- &subdevdata[i].addr);
+
[PATCH v0 2/5] V4L : vpif updates for DM6467 vpif capture driver
From: Muralidharan Karicheri
Following changes done for vpif driver to support vpif capture:-
1) Current version of display driver defined vpif register
space as part for vpif display platform driver resource
This is not correct since vpif is common across capture
and display drivers. So the resource iomap function is
moved to this module
2) Since there are common registers, a spinlock is added for
mutual exclusion.
NOTE: This is only for review. Final patch for merge will be sent later
This patch is dependent on the patch from Chaithrika for vpif display
Mandatory reviewer: Hans Verkuil
Signed-off-by: Muralidharan Karicheri
---
drivers/media/video/davinci/vpif.c | 76 ---
drivers/media/video/davinci/vpif.h | 48 ++-
2 files changed, 98 insertions(+), 26 deletions(-)
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
index aa77126..3b8eac3 100644
--- a/drivers/media/video/davinci/vpif.c
+++ b/drivers/media/video/davinci/vpif.c
@@ -19,7 +19,11 @@
#include
#include
+#include
+#include
#include
+#include
+#include
#include "vpif.h"
@@ -31,6 +35,12 @@ MODULE_LICENSE("GPL");
#define VPIF_CH2_MAX_MODES (15)
#define VPIF_CH3_MAX_MODES (02)
+static resource_size_t res_len;
+static struct resource *res;
+spinlock_t vpif_lock;
+
+void __iomem *vpif_base;
+
static inline void vpif_wr_bit(u32 reg, u32 bit, u32 val)
{
if (val)
@@ -151,17 +161,17 @@ static void config_vpif_params(struct vpif_params
*vpifparams,
else if (config->capture_format) {
/* Set the polarity of various pins */
vpif_wr_bit(reg, VPIF_CH_FID_POLARITY_BIT,
- vpifparams->params.raw_params.fid_pol);
+ vpifparams->iface.fid_pol);
vpif_wr_bit(reg, VPIF_CH_V_VALID_POLARITY_BIT,
- vpifparams->params.raw_params.vd_pol);
+ vpifparams->iface.vd_pol);
vpif_wr_bit(reg, VPIF_CH_H_VALID_POLARITY_BIT,
- vpifparams->params.raw_params.hd_pol);
+ vpifparams->iface.hd_pol);
value = regr(reg);
/* Set data width */
value &= ((~(unsigned int)(0x3)) <<
VPIF_CH_DATA_WIDTH_BIT);
- value |= ((vpifparams->params.raw_params.data_sz) <<
+ value |= ((vpifparams->params.data_sz) <<
VPIF_CH_DATA_WIDTH_BIT);
regw(value, reg);
}
@@ -227,8 +237,60 @@ int vpif_channel_getfid(u8 channel_id)
}
EXPORT_SYMBOL(vpif_channel_getfid);
-void vpif_base_addr_init(void __iomem *base)
+static int __init vpif_probe(struct platform_device *pdev)
+{
+ int status = 0;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res)
+ return -ENOENT;
+
+ res_len = res->end - res->start + 1;
+
+ res = request_mem_region(res->start, res_len, res->name);
+ if (!res)
+ return -EBUSY;
+
+ vpif_base = ioremap(res->start, res_len);
+ if (!vpif_base) {
+ status = -EBUSY;
+ goto fail;
+ }
+
+ spin_lock_init(&vpif_lock);
+ dev_info(&pdev->dev, "vpif probe success\n");
+ return 0;
+
+fail:
+ release_mem_region(res->start, res_len);
+ return status;
+}
+
+static int vpif_remove(struct platform_device *pdev)
{
- vpif_base = base;
+ iounmap(vpif_base);
+ release_mem_region(res->start, res_len);
+ return 0;
}
-EXPORT_SYMBOL(vpif_base_addr_init);
+
+static struct platform_driver vpif_driver = {
+ .driver = {
+ .name = "vpif",
+ .owner = THIS_MODULE,
+ },
+ .remove = __devexit_p(vpif_remove),
+ .probe = vpif_probe,
+};
+
+static void vpif_exit(void)
+{
+ platform_driver_unregister(&vpif_driver);
+}
+
+static int __init vpif_init(void)
+{
+ return platform_driver_register(&vpif_driver);
+}
+subsys_initcall(vpif_init);
+module_exit(vpif_exit);
+
diff --git a/drivers/media/video/davinci/vpif.h
b/drivers/media/video/davinci/vpif.h
index fca26dc..188841b 100644
--- a/drivers/media/video/davinci/vpif.h
+++ b/drivers/media/video/davinci/vpif.h
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
/* Maximum channel allowed */
#define VPIF_NUM_CHANNELS (4)
@@ -26,7 +27,9 @@
#define VPIF_DISPLAY_NUM_CHANNELS (2)
/* Macros to read/write registers */
-static void __iomem *vpif_base;
+extern void __iomem *vpif_base;
+extern spinlock_t vpif_lock;
+
#define regr(reg)
[PATCH v0 1/5] DaVinci - re-structuring code to support vpif capture driver
From: Muralidharan Karicheri
This patch makes the following changes:-
1) Modify vpif_subdev_info to add board_info, routing information
and vpif interface configuration. Remove addr since it is
part of board_info
2) Add code to setup channel mode and input decoder path for
vpif capture driver
NOTE: This patch is dependent on the patch from Chaithrika for vpif display.
Also
the arch sepcific files are manually merged to linux-davinci tree before
creating
this patch. So this is only for review. Final patch to be merged will be created
later
Mandatory reviewers : Hans Verkuil
Kevin Hilman
Signed-off-by: Muralidharan Karicheri
---
arch/arm/mach-davinci/board-dm646x-evm.c| 179 +-
arch/arm/mach-davinci/dm646x.c | 54 +++-
arch/arm/mach-davinci/include/mach/dm646x.h | 50 +++-
3 files changed, 263 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 38a1022..cb4246b 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -33,7 +33,7 @@
#include
#include
#include
-
+#include
#include
#include
#include
@@ -75,6 +75,14 @@
#define VIDCH2CLK (BIT(10))
#define VIDCH3CLK (BIT(11))
+#define VIDCH1CLK (BIT(4))
+#define TVP7002_INPUT (BIT(4))
+#define TVP5147_INPUT (~BIT(4))
+#define VPIF_INPUT_ONE_CHANNEL (BIT(5))
+#define VPIF_INPUT_TWO_CHANNEL (~BIT(5))
+#define TVP5147_CH0"tvp514x-0"
+#define TVP5147_CH1"tvp514x-1"
+
static struct davinci_uart_config uart_config __initdata = {
.enabled_uarts = (1 << 0),
@@ -348,7 +356,7 @@ static struct i2c_board_info __initdata i2c_info[] = {
I2C_BOARD_INFO("cpld_reg0", 0x3a),
},
{
- I2C_BOARD_INFO("cpld_video", 0x3B),
+ I2C_BOARD_INFO("cpld_video", 0x3b),
},
};
@@ -400,14 +408,18 @@ static int set_vpif_clock(int mux_mode, int hd)
return 0;
}
-static const struct vpif_subdev_info dm646x_vpif_subdev[] = {
+static struct vpif_subdev_info dm646x_vpif_subdev[] = {
{
- .addr = 0x2A,
.name = "adv7343",
+ .board_info = {
+ I2C_BOARD_INFO("adv7343", 0x2a),
+ },
},
{
- .addr = 0x2C,
.name = "ths7303",
+ .board_info = {
+ I2C_BOARD_INFO("ths7303", 0x2c),
+ },
},
};
@@ -417,7 +429,7 @@ static const char *output[] = {
"S-Video",
};
-static struct vpif_config dm646x_vpif_config = {
+static struct vpif_display_config dm646x_vpif_display_config = {
.set_clock = set_vpif_clock,
.subdevinfo = dm646x_vpif_subdev,
.subdev_count = ARRAY_SIZE(dm646x_vpif_subdev),
@@ -426,6 +438,158 @@ static struct vpif_config dm646x_vpif_config = {
.card_name = "DM646x EVM",
};
+/**
+ * setup_vpif_input_path()
+ * @channel: channel id (0 - CH0, 1 - CH1)
+ * @sub_dev_name: ptr sub device name
+ *
+ * This will set vpif input to capture data from tvp514x or
+ * tvp7002.
+ */
+static int setup_vpif_input_path(int channel, const char *sub_dev_name)
+{
+ int err = 0;
+ int val;
+
+ /* for channel 1, we don't do anything */
+ if (channel != 0)
+ return 0;
+
+ if (NULL == cpld_client)
+ return -EFAULT;
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val < 0)
+ return val;
+
+ if (!strcmp(sub_dev_name, TVP5147_CH0) ||
+ !strcmp(sub_dev_name, TVP5147_CH1))
+ val &= TVP5147_INPUT;
+ else
+ val |= TVP7002_INPUT;
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+ return 0;
+}
+
+/**
+ * setup_vpif_input_channel_mode()
+ * @mux_mode: mux mode. 0 - 1 channel or (1) - 2 channel
+ *
+ * This will setup input mode to one channel (TVP7002) or 2 channel (TVP5147)
+ */
+static int setup_vpif_input_channel_mode(int mux_mode)
+{
+ int err = 0;
+ int val;
+ u32 value;
+ void __iomem *base = IO_ADDRESS(DAVINCI_SYSTEM_MODULE_BASE);
+
+ val = i2c_smbus_read_byte(cpld_client);
+ if (val < 0)
+ return val;
+
+ value = __raw_readl(base + VSCLKDIS_OFFSET);
+ if (mux_mode) {
+ val &= VPIF_INPUT_TWO_CHANNEL;
+ value |= VIDCH1CLK;
+ } else {
+ val |= VPIF_INPUT_ONE_CHANNEL;
+ value &= ~VIDCH1CLK;
+ }
+ __raw_writel(value, base + VSCLKDIS_OFFSET);
+
+ err = i2c_smbus_write_byte(cpld_client, val);
+ if (err)
+ return err;
+
+ return 0;
+}
+
+static struct tvp514x_platform_data
[PATCH v0 0/5] V4L: vpif_capture driver for DM6467
From: Muralidharan Karicheri This patch series add support for VPIF Capture Driver on DM6467. VPIF (Video Port Interface) has two channels for capture video or Raw image data. Currently only video capture is supported using TVP5147 on each of the channel. That means two simultaneous capture of NTSC/PAL video is possible using this driver. Following are the patches in this series:- 1) DaVinci - re-structuring code to support vpif capture driver 2) V4L : vpif updates for DM6467 vpif capture driver 3) V4L : vpif display - updates to support vpif capture on DM6467 4) V4L : vpif_capture driver for DM6467 5) V4L : vpif capture - Kconfig and Makefile changes Mandatory reviewers : Hans Verkuil Kevin Hilman Signed-off-by: Muralidharan Karicheri -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 2/9] drivers/media/video/cx88/cx88: add support for WinFast DTV2000H rev. J
From: Vlastimil Labsky
I updated and simplyfied patch from Zbynek Hrabovsky for recent kernel.
It enables autodetection of card, sound in analog TV , sound in FM radio
and switching between antenna and cable RF input. Radio tuner still
doesn't work, I don't even know how it works. Some guys wrote me that FM
radio works with TV tuner used instead of radio part (symlink video0 ->
radio0).
Signed-off-by: Vlastimil Labsky
Cc: Gerd Knorr
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/video/cx88/cx88-cards.c | 49
drivers/media/video/cx88/cx88-dvb.c |1
drivers/media/video/cx88/cx88-input.c |1
drivers/media/video/cx88/cx88.h |1
4 files changed, 52 insertions(+)
diff -puN
drivers/media/video/cx88/cx88-cards.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
drivers/media/video/cx88/cx88-cards.c
---
a/drivers/media/video/cx88/cx88-cards.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
+++ a/drivers/media/video/cx88/cx88-cards.c
@@ -1283,6 +1283,51 @@ static const struct cx88_board cx88_boar
},
.mpeg = CX88_MPEG_DVB,
},
+ [CX88_BOARD_WINFAST_DTV2000H_J] = {
+ .name = "WinFast DTV2000 H rev. J",
+ .tuner_type = TUNER_PHILIPS_FMD1216ME_MK3,
+ .radio_type = UNSET,
+ .tuner_addr = ADDR_UNSET,
+ .radio_addr = ADDR_UNSET,
+ .tda9887_conf = TDA9887_PRESENT,
+ .input = {{
+ .type = CX88_VMUX_TELEVISION,
+ .vmux = 0,
+ .gpio0 = 0x00017300,
+ .gpio1 = 0x8207,
+ .gpio2 = 0x,
+ .gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_TELEVISION,
+ .vmux = 0,
+ .gpio0 = 0x00018300,
+ .gpio1 = 0xf207,
+ .gpio2 = 0x00017304,
+ .gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_COMPOSITE1,
+ .vmux = 1,
+ .gpio0 = 0x00018301,
+ .gpio1 = 0xf207,
+ .gpio2 = 0x00017304,
+ .gpio3 = 0x0200,
+ },{
+ .type = CX88_VMUX_SVIDEO,
+ .vmux = 2,
+ .gpio0 = 0x00018301,
+ .gpio1 = 0xf207,
+ .gpio2 = 0x00017304,
+ .gpio3 = 0x0200,
+ }},
+ .radio = {
+.type = CX88_RADIO,
+.gpio0 = 0x00015702,
+.gpio1 = 0xf207,
+.gpio2 = 0x00015702,
+.gpio3 = 0x0200,
+ },
+ .mpeg = CX88_MPEG_DVB,
+ },
[CX88_BOARD_GENIATECH_DVBS] = {
.name = "Geniatech DVB-S",
.tuner_type= TUNER_ABSENT,
@@ -2282,6 +2327,10 @@ static const struct cx88_subid cx88_subi
.subdevice = 0x665e,
.card = CX88_BOARD_WINFAST_DTV2000H,
},{
+ .subvendor = 0x107d,
+ .subdevice = 0x6f2b,
+ .card = CX88_BOARD_WINFAST_DTV2000H_J,
+ },{
.subvendor = 0x18ac,
.subdevice = 0xd800, /* FusionHDTV 3 Gold (original revision) */
.card = CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q,
diff -puN
drivers/media/video/cx88/cx88-dvb.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
drivers/media/video/cx88/cx88-dvb.c
---
a/drivers/media/video/cx88/cx88-dvb.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
+++ a/drivers/media/video/cx88/cx88-dvb.c
@@ -695,6 +695,7 @@ static int dvb_register(struct cx8802_de
}
break;
case CX88_BOARD_WINFAST_DTV2000H:
+ case CX88_BOARD_WINFAST_DTV2000H_J:
case CX88_BOARD_HAUPPAUGE_HVR1100:
case CX88_BOARD_HAUPPAUGE_HVR1100LP:
case CX88_BOARD_HAUPPAUGE_HVR1300:
diff -puN
drivers/media/video/cx88/cx88-input.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
drivers/media/video/cx88/cx88-input.c
---
a/drivers/media/video/cx88/cx88-input.c~drivers-media-video-cx88-cx88-add-support-for-winfast-dtv2000h-rev-j
+++ a/drivers/media/video/cx88/cx88-input.c
@@ -225,6 +225,7 @@ int cx88_ir_init(struct cx88_core *core,
ir->sampling = 1;
break;
case CX88_BOARD_WINFAST_DTV2000H:
+ case CX88_BOARD_WINFAST_DTV2000H_J:
case CX88_BOARD_WINFAST_DTV1800H:
ir_codes = ir_codes_winfast;
[patch 9/9] drivers/media/video/gspca: introduce missing kfree
From: Julia Lawall
Error handling code following a kmalloc should free the allocated data.
The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@r exists@
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
@@
x...@p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
when != if (...) { <+...x...+> }
(
x->f1 = E
|
(x->f1 == NULL || ...)
|
f(...,x->f1,...)
)
...>
(
return \(0\|<+...x...+>\|ptr\);
|
ret...@p2 ...;
)
@script:python@
p1 << r.p1;
p2 << r.p2;
@@
print "* file: %s kmalloc %s return %s" % (p1[0].file,p1[0].line,p2[0].line)
//
Signed-off-by: Julia Lawall
Acked-by: Erik Andren
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/video/gspca/m5602/m5602_s5k83a.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN
drivers/media/video/gspca/m5602/m5602_s5k83a.c~drivers-media-video-gspca-introduce-missing-kfree
drivers/media/video/gspca/m5602/m5602_s5k83a.c
---
a/drivers/media/video/gspca/m5602/m5602_s5k83a.c~drivers-media-video-gspca-introduce-missing-kfree
+++ a/drivers/media/video/gspca/m5602/m5602_s5k83a.c
@@ -178,8 +178,10 @@ sensor_found:
sens_priv->settings =
kmalloc(sizeof(s32)*ARRAY_SIZE(s5k83a_ctrls), GFP_KERNEL);
- if (!sens_priv->settings)
+ if (!sens_priv->settings) {
+ kfree(sens_priv);
return -ENOMEM;
+ }
sd->gspca_dev.cam.cam_mode = s5k83a_modes;
sd->gspca_dev.cam.nmodes = ARRAY_SIZE(s5k83a_modes);
_
--
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 8/9] media/zr364xx: fix build errors
From: Randy Dunlap Fix build errors in zr364xx by adding selects: zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon' zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf' zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf' zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf' zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs' zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy' zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free' zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock' zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper' zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream' zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one' zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free' zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init' zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff' zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc' zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff' drivers/built-in.o: In function `free_buffer': zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free' drivers/built-in.o: In function `zr364xx_open': zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init' drivers/built-in.o: In function `read_pipe_completion': zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc' Signed-off-by: Randy Dunlap Cc: Antoine Jacquet Cc: Mauro Carvalho Chehab Signed-off-by: Andrew Morton --- drivers/media/video/Kconfig |2 ++ 1 file changed, 2 insertions(+) diff -puN drivers/media/video/Kconfig~media-zr364xx-fix-build-errors drivers/media/video/Kconfig --- a/drivers/media/video/Kconfig~media-zr364xx-fix-build-errors +++ a/drivers/media/video/Kconfig @@ -1000,6 +1000,8 @@ source "drivers/media/video/pwc/Kconfig" config USB_ZR364XX tristate "USB ZR364XX Camera support" depends on VIDEO_V4L2 + select VIDEOBUF_GEN + select VIDEOBUF_VMALLOC ---help--- Say Y here if you want to connect this type of camera to your computer's USB port. _ -- 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 7/9] stk-webcam: read buffer overflow
From: Roel Kluin
It tested the value of stk_sizes[i].m before checking whether i was in range.
Signed-off-by: Roel Kluin
Cc: Mauro Carvalho Chehab
Cc: Hans Verkuil
Cc: Trent Piepho
Signed-off-by: Andrew Morton
---
drivers/media/video/stk-webcam.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/media/video/stk-webcam.c~stk-webcam-read-buffer-overflow
drivers/media/video/stk-webcam.c
--- a/drivers/media/video/stk-webcam.c~stk-webcam-read-buffer-overflow
+++ a/drivers/media/video/stk-webcam.c
@@ -1050,8 +1050,8 @@ static int stk_setup_format(struct stk_c
depth = 1;
else
depth = 2;
- while (stk_sizes[i].m != dev->vsettings.mode
- && i < ARRAY_SIZE(stk_sizes))
+ while (i < ARRAY_SIZE(stk_sizes) &&
+ stk_sizes[i].m != dev->vsettings.mode)
i++;
if (i == ARRAY_SIZE(stk_sizes)) {
STK_ERROR("Something is broken in %s\n", __func__);
_
--
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 6/9] drivers/media/dvb: Use dst_type field instead of type_flags
From: Julia Lawall
It seems from other code that it is the dst_type field rather than the
type_flags field that contains values of the form DST_TYPE_IS...
The type_flags field contains values of the form DST_TYPE_HAS...
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
//
@@ struct dst_state E; @@
(
*E.type_flags ==
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
|
*E.type_flags !=
\( DST_TYPE_IS_SAT\|DST_TYPE_IS_TERR\|DST_TYPE_IS_CABLE\|DST_TYPE_IS_ATSC \)
)
//
Signed-off-by: Julia Lawall
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/dvb/bt8xx/dst.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/media/dvb/bt8xx/dst.c~drivers-media-dvb-use-dst_type-field-instead-of-type_flags
drivers/media/dvb/bt8xx/dst.c
---
a/drivers/media/dvb/bt8xx/dst.c~drivers-media-dvb-use-dst_type-field-instead-of-type_flags
+++ a/drivers/media/dvb/bt8xx/dst.c
@@ -1059,7 +1059,7 @@ static int dst_get_tuner_info(struct dst
dprintk(verbose, DST_ERROR, 1, "DST type has TS=188");
}
if (state->board_info[0] == 0xbc) {
- if (state->type_flags != DST_TYPE_IS_ATSC)
+ if (state->dst_type != DST_TYPE_IS_ATSC)
state->type_flags |= DST_TYPE_HAS_TS188;
else
state->type_flags |= DST_TYPE_HAS_NEWTUNE_2;
_
--
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 5/9] drivers/media/video/bw-qcam.c: fix read buffer overflow
From: Roel Kluin
parport[n] is checked before n < MAX_CAMS
Signed-off-by: Roel Kluin
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/video/bw-qcam.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN
drivers/media/video/bw-qcam.c~drivers-media-video-bw-qcamc-fix-read-buffer-overflow
drivers/media/video/bw-qcam.c
---
a/drivers/media/video/bw-qcam.c~drivers-media-video-bw-qcamc-fix-read-buffer-overflow
+++ a/drivers/media/video/bw-qcam.c
@@ -992,7 +992,7 @@ static int accept_bwqcam(struct parport
if (parport[0] && strncmp(parport[0], "auto", 4) != 0) {
/* user gave parport parameters */
- for(n=0; parport[n] && nhttp://vger.kernel.org/majordomo-info.html
[patch 4/9] siano: read buffer overflow
From: Roel Kluin
With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.
Signed-off-by: Roel Kluin
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/dvb/siano/smscoreapi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/media/dvb/siano/smscoreapi.c~siano-read-buffer-overflow
drivers/media/dvb/siano/smscoreapi.c
--- a/drivers/media/dvb/siano/smscoreapi.c~siano-read-buffer-overflow
+++ a/drivers/media/dvb/siano/smscoreapi.c
@@ -816,7 +816,7 @@ int smscore_set_device_mode(struct smsco
sms_debug("set device mode to %d", mode);
if (coredev->device_flags & SMS_DEVICE_FAMILY2) {
- if (mode < DEVICE_MODE_DVBT || mode > DEVICE_MODE_RAW_TUNER) {
+ if (mode < DEVICE_MODE_DVBT || mode >= DEVICE_MODE_RAW_TUNER) {
sms_err("invalid mode specified %d", mode);
return -EINVAL;
}
_
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/9] video: initial support for ADV7180
From: Richard Röjfors
This is an initial driver for Analog Devices ADV7180 Video Decoder.
So far it only supports query standard.
Signed-off-by: Richard Röjfors
Cc: Mauro Carvalho Chehab
Signed-off-by: Andrew Morton
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile|1
drivers/media/video/adv7180.c | 221 ++
include/media/v4l2-chip-ident.h |3
4 files changed, 234 insertions(+)
diff -puN drivers/media/video/Kconfig~video-initial-support-for-adv7180
drivers/media/video/Kconfig
--- a/drivers/media/video/Kconfig~video-initial-support-for-adv7180
+++ a/drivers/media/video/Kconfig
@@ -265,6 +265,15 @@ config VIDEO_SAA6588
comment "Video decoders"
+config VIDEO_ADV7180
+ tristate "Analog Devices ADV7180 decoder"
+ depends on VIDEO_V4L2 && I2C
+ ---help---
+ Support for the Analog Devices ADV7180 video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called adv7180.
+
config VIDEO_BT819
tristate "BT819A VideoStream decoder"
depends on VIDEO_V4L2 && I2C
diff -puN drivers/media/video/Makefile~video-initial-support-for-adv7180
drivers/media/video/Makefile
--- a/drivers/media/video/Makefile~video-initial-support-for-adv7180
+++ a/drivers/media/video/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_VIDEO_SAA7185) += saa7185.o
obj-$(CONFIG_VIDEO_SAA7191) += saa7191.o
obj-$(CONFIG_VIDEO_ADV7170) += adv7170.o
obj-$(CONFIG_VIDEO_ADV7175) += adv7175.o
+obj-$(CONFIG_VIDEO_ADV7180) += adv7180.o
obj-$(CONFIG_VIDEO_ADV7343) += adv7343.o
obj-$(CONFIG_VIDEO_VPX3220) += vpx3220.o
obj-$(CONFIG_VIDEO_BT819) += bt819.o
diff -puN /dev/null drivers/media/video/adv7180.c
--- /dev/null
+++ a/drivers/media/video/adv7180.c
@@ -0,0 +1,221 @@
+/*
+ * adv7180.c Analog Devices ADV7180 video decoder driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define ADV7180_INPUT_CONTROL_REG 0x00
+#define ADV7180_INPUT_CONTROL_PAL_BG_NTSC_J_SECAM 0x00
+#define ADV7180_AUTODETECT_ENABLE_REG 0x07
+#define ADV7180_AUTODETECT_DEFAULT 0x7f
+
+
+#define ADV7180_STATUS1_REG 0x10
+#define ADV7180_STATUS1_AUTOD_MASK 0x70
+#define ADV7180_STATUS1_AUTOD_NTSM_M_J 0x00
+#define ADV7180_STATUS1_AUTOD_NTSC_4_43 0x10
+#define ADV7180_STATUS1_AUTOD_PAL_M0x20
+#define ADV7180_STATUS1_AUTOD_PAL_60 0x30
+#define ADV7180_STATUS1_AUTOD_PAL_B_G 0x40
+#define ADV7180_STATUS1_AUTOD_SECAM0x50
+#define ADV7180_STATUS1_AUTOD_PAL_COMB 0x60
+#define ADV7180_STATUS1_AUTOD_SECAM_5250x70
+
+#define ADV7180_IDENT_REG 0x11
+#define ADV7180_ID_7180 0x18
+
+
+static unsigned short normal_i2c[] = { 0x42 >> 1, I2C_CLIENT_END };
+
+I2C_CLIENT_INSMOD;
+
+struct adv7180_state {
+ struct v4l2_subdev sd;
+};
+
+static v4l2_std_id determine_norm(struct i2c_client *client)
+{
+ u8 status1 = i2c_smbus_read_byte_data(client, ADV7180_STATUS1_REG);
+
+ switch (status1 & ADV7180_STATUS1_AUTOD_MASK) {
+ case ADV7180_STATUS1_AUTOD_NTSM_M_J:
+ return V4L2_STD_NTSC_M_JP;
+ case ADV7180_STATUS1_AUTOD_NTSC_4_43:
+ return V4L2_STD_NTSC_443;
+ case ADV7180_STATUS1_AUTOD_PAL_M:
+ return V4L2_STD_PAL_M;
+ case ADV7180_STATUS1_AUTOD_PAL_60:
+ return V4L2_STD_PAL_60;
+ case ADV7180_STATUS1_AUTOD_PAL_B_G:
+ return V4L2_STD_PAL;
+ case ADV7180_STATUS1_AUTOD_SECAM:
+ return V4L2_STD_SECAM;
+ case ADV7180_STATUS1_AUTOD_PAL_COMB:
+ return V4L2_STD_PAL_Nc | V4L2_STD_PAL_N;
+ case ADV7180_STATUS1_AUTOD_SECAM_525:
+ return V4L2_STD_SECAM;
+ default:
+ return V4L2_STD_UNKNOWN;
+ }
+}
+
+static inline struct adv7180_state *to_state(struct v4l2_subdev *sd)
+{
+ return container_of(sd, struct adv7180_state, sd);
+}
+
+static int adv7180_querystd(struct v4l2_subdev *sd, v4l2_std_id *std)
+{
+ struct i2c_client *client = v4l2_get_subdevdata(sd);
+
+ *(v4l2_std_id *)std = determine_norm(client);
+ return 0;
+}
+
+static int adv7180_g_ctrl(struct v4l2_subdev *sd, struct v4l2_control *ctrl)
+{
+ return -EINVAL;
+}
+
+st
[patch 3/9] media: strncpy does not null terminate string
From: Roel Kluin strlcpy() will always null terminate the string. Signed-off-by: Roel Kluin Cc: Mauro Carvalho Chehab Signed-off-by: Andrew Morton --- drivers/media/dvb/dvb-usb/dvb-usb-i2c.c |2 +- drivers/media/video/pwc/pwc-v4l.c |2 +- drivers/media/video/zoran/zoran_card.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff -puN drivers/media/dvb/dvb-usb/dvb-usb-i2c.c~media-strncpy-does-not-null-terminate-string drivers/media/dvb/dvb-usb/dvb-usb-i2c.c --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c~media-strncpy-does-not-null-terminate-string +++ a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c @@ -19,7 +19,7 @@ int dvb_usb_i2c_init(struct dvb_usb_devi return -EINVAL; } - strncpy(d->i2c_adap.name, d->desc->name, sizeof(d->i2c_adap.name)); + strlcpy(d->i2c_adap.name, d->desc->name, sizeof(d->i2c_adap.name)); d->i2c_adap.class = I2C_CLASS_TV_DIGITAL, d->i2c_adap.algo = d->props.i2c_algo; d->i2c_adap.algo_data = NULL; diff -puN drivers/media/video/pwc/pwc-v4l.c~media-strncpy-does-not-null-terminate-string drivers/media/video/pwc/pwc-v4l.c --- a/drivers/media/video/pwc/pwc-v4l.c~media-strncpy-does-not-null-terminate-string +++ a/drivers/media/video/pwc/pwc-v4l.c @@ -1033,7 +1033,7 @@ long pwc_video_do_ioctl(struct file *fil if (std->index != 0) return -EINVAL; std->id = V4L2_STD_UNKNOWN; - strncpy(std->name, "webcam", sizeof(std->name)); + strlcpy(std->name, "webcam", sizeof(std->name)); return 0; } diff -puN drivers/media/video/zoran/zoran_card.c~media-strncpy-does-not-null-terminate-string drivers/media/video/zoran/zoran_card.c --- a/drivers/media/video/zoran/zoran_card.c~media-strncpy-does-not-null-terminate-string +++ a/drivers/media/video/zoran/zoran_card.c @@ -1169,7 +1169,7 @@ zoran_setup_videocodec (struct zoran *zr m->type = 0; m->flags = CODEC_FLAG_ENCODER | CODEC_FLAG_DECODER; - strncpy(m->name, ZR_DEVNAME(zr), sizeof(m->name)); + strlcpy(m->name, ZR_DEVNAME(zr), sizeof(m->name)); m->data = zr; switch (type) _ -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
On Thu, Aug 06, 2009 at 11:46:14AM -0700, David Xiao wrote: > On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: > > Hi Ben, > > > > On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > > > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > > [snip] > > > > > > > > The second problem is to ensure cache coherency. As the userspace > > > > application will read data from the video buffers, those buffers will > > > > end > > > > up being cached in the processor's data cache. The driver does need to > > > > invalidate the cache before starting the DMA operation (userspace could > > > > in theory write to the buffers, but the data will be overwritten by DMA > > > > anyway, so there's no need to clean the cache). > > > > > > You'll need to clean the write buffers, otherwise the CPU may have data > > > queued that it has yet to write back to memory. > > > > Good points, thanks. > >I thought this should have been taken care of by the CPU specific > dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, > v7_dma_inv_range does not drain the write buffer; and the > v6_dma_inv_range does that in the end of all the cache maintenance > operaitons. There's no such thing as "drain write buffer" in ARMv7. There are barriers instead, in particular dsb, which replaces the original "drain write buffer" instruction. As far as userspace DMA coherency, the only way you could do it with current kernel APIs is by using get_user_pages(), creating a scatterlist from those, and then passing it to dma_map_sg(). While the device has ownership of the SG, userspace must _not_ touch the buffer until after DMA has completed. However, that won't work with ARMv7's speculative prefetching. I'm afraid with such things, DMA direct into userspace mappings becomes a _lot_ harder, and lets face it, lots of Linux drivers just aren't going to bother supporting this - we can't currently get agreement to have an API to map DMA coherent pages into userspace! -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thu, 6 Aug 2009, Hans Verkuil wrote: > On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: > > On Thu, 6 Aug 2009, Hans Verkuil wrote: > > > > Why do you need two routines that will always return zero? Why to > > > > create a > > > > code > > > > that will never be used? v4l2-compat-ioctl32.c is already complex enough > > > > without adding any bogus code. > > > > > > When the RDS encoder driver from Eduardo is added, then he will add the > > > string controls to ctrl_is_pointer() since his driver is the first to > > > actually implement string controls. > > > > Could one of the upper bits of the control id be used as a flag? It would > > make it a lot easier to check the control's type than by using some inline > > function with a giant case statement that needs to be updated each time a > > new control is added. > > No, you can't. That would require users to OR that flag each time you want > to use such a control. My original plan was to just check for a non-zero There is no reason we need to allocated control IDs sequentially, is there? So just give string controls IDs in the range 0x8000 to 0x and then one can tell if a control is a string control be ANDing the id with (1<<31). -- 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: sn9c20x driver seems ok, but no video
Chris, The sn9c20x module only supports jpeg, bayer and its own yuv420 format. most applications do not nativly understand these formats and will therefore require the use of libv4l a user space library able to convert between formats in order to work. This library was first included on ubuntu with intrepid, since you are using hardy you will have to manually download it and compile it yourself or upgrade your ubuntu system to at least intrepid. If you don't decide to upgrade you can download the latest version of libv4l at http://people.atrpms.net/~hdegoede/ Also the driver you are using while it certainly should work fine when using libv4l for conversion, there is now a gspca based version of that driver included in the latest v4l-dvb as well as kernel repositories, You should be able to upgrade from your jaunty kernel to the current karmic kernel and have the gspca sn9c20x driver included. You still will need to use the libv4l for handling format conversions though. Regards, Brian Johnson On Thu, Aug 6, 2009 at 4:29 PM, Chris Hallinan wrote: > Hi folks, > > Trying to get a usb webcam based on SN9C20x driver working on Ubuntu. > > Loading the module, everything looks good (log output trimmed for easy > reading): > > kernel: usb 7-3: new high speed USB device using ehci_hcd and address 4 > kernel: usb 7-3: configuration #1 chosen from 1 choice > kernel: sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:628F plugged-in. > kernel: sn9c20x: Detected OV9650 Sensor. > kernel: sn9c20x: Webcam device 0C45:628F is now controlling video > device /dev/video0 > kernel: input: SN9C20X Webcam as /class/input/input10 > kernel: sn9c20x: No ack from I2C slave 0x30 for write to address 0x17 > kernel: sn9c20x: Using yuv420 output format > > However, I've tried several different apps (cheese, Xsane, gstreamer, > etc) but cannot > see any video output. I confess to being completely ignorant on > issues video, etc. :) > > If I type 'cat /dev/video0 >j.dump', the green LED on camera comes on, > and j.dump is filled with binary data. > > However, gst-launch shows this: > # gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink > Setting pipeline to PAUSED ... > ERROR: Pipeline doesn't want to pause. > WARNING: from element /pipeline0/v4l2src0: Failed to get current input > on device '/dev/video0'. May be it is a radio device > Additional debug info: > v4l2_calls.c(756): gst_v4l2_get_input (): /pipeline0/v4l2src0: system > error: Invalid argument > ERROR: from element /pipeline0/v4l2src0: Could not negotiate format > Additional debug info: > gstbasesrc.c(2387): gst_base_src_start (): /pipeline0/v4l2src0: > Check your filtered caps, if any > Setting pipeline to NULL ... > FREEING pipeline ... > > I'm running Ubuntu Jaunty kernel (2.6.28) with Hardy userland. > > Any input/pointers would be most appreciated! And if there is a > better list to post such a question, I'd appreciate it. I posted on > micro...@googlegroups.com, but that list hasn't had a single message > in more than 24 hours! > > Thanks, > > Chris > > -- > Life is like Linux - it never stands still. > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-900HD support?
#1) http://www.hauppauge.de/de/index.htm (scroll down to middle of the page) #2) http://www.hauppauge.de/de/site/products/data_hvr1900.html #3) http://www.hauppauge.com/site/press/presspictures/HVR-1900_German_1251.jpg #4) http://www.hauppauge.com/site/press/presspictures/HVR-1900_4lang_1179.png #5) http://www.hauppauge.com/site/support/linux.html -Mike Ok so from this it seems the the 1900 isn't available in the UK where I am based! As I said before the HVR 900 does seem supported and it is readily available from any UK retailer so it might be a better option just as it's less hassle so I don't need to buy from Germany. Interesting.. --Kaya -- 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: Hauppauge Nova-T 500 regression in dib0700
On Thursday 06 August 2009 02:09:06 Devin Heitmueller wrote: > On Wed, Aug 5, 2009 at 6:37 PM, Derek > > Jennings wrote: > > Hi > > I have been chasing a problem with my Hauppauge Nova-T 500 Dual DVB-T > > card and think it is the same problem reported here > > http://osdir.com/ml/linux-media/2009-02/msg00948.html > > > > The card worked perfectly with kernel-2.6.27 with firmware > > dvb-usb-dib0700-1.10.fw (I had to rename the firmware to > > dvb-usb-dib0700-1.20.fw to get it to load) > > > > With kernel-2.6.29 or 2.6.31 and firmware 1.10 the card would not Lock to > > the signal (using mythtv) > > Using firmware 1.20 the card would lock to the signal, but after 1 or 2 > > minutes the usb driver would fail > > > > klogd: usb 2-1: new high speed USB device using ehci_hcd and address 2 > > klogd: usb 2-1: New USB device found, idVendor=2040, idProduct=9950 > > klogd: usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 > > klogd: usb 2-1: Product: WinTV Nova-DT > > klogd: usb 2-1: Manufacturer: Hauppauge > > klogd: usb 2-1: SerialNumber: 4028965283 > > klogd: usb 2-1: configuration #1 chosen from 1 choice > > klogd: dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. > > klogd: dvb-usb: will pass the complete MPEG2 transport stream to the > > software demuxer. > > klogd: DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) > > klogd: DVB: registering adapter 0 frontend 0 (DiBcom 3000MC/P)... > > klogd: MT2060: successfully identified (IF1 = 1239) > > klogd: dvb-usb: will pass the complete MPEG2 transport stream to the > > software demuxer. > > klogd: DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) > > klogd: DVB: registering adapter 1 frontend 0 (DiBcom 3000MC/P)... > > klogd: MT2060: successfully identified (IF1 = 1222) > > klogd: input: IR-receiver inside an USB DVB receiver > > as /devices/pci:00/:00:1e.0/:04:00.2/usb2/2-1/input/input3 > > klogd: dvb-usb: schedule remote query interval to 50 msecs. > > klogd: dvb-usb: Hauppauge Nova-T 500 Dual DVB-T successfully initialized > > and connected. > > > > After a few minutes of operation > > > > klogd: ehci_hcd :04:00.2: force halt; handhake f8018014 4000 > > -> -110 > > > > I downloaded and compiled the current v4l source and confirmed it had the > > same problem. > > > > I then removed this commit mentioned in the earlier post from the current > > v4l source http://linuxtv.org/hg/v4l-dvb/rev/561b447ade77 > > and recompiled the module. > > > > SUCCESS! with the commit removed the card works with kernel 2.6.29 and > > the 1.10 firmware, but not with the 1.20 firmware which will not Lock to > > the signal. > > > > I have no idea why that commit causes problems, but with it removed the > > operation of the card is just as good as it was under the 2.6.27 kernel. > > > > Thanks > > > > Derek > > Well that is pretty annoying. :-) > > There have been almost no changes to the core dib0700 driver in recent > releases, suggesting that the issue is that something got broken in > the onboard Via USB host controller chipset driver which causes it to > not properly handle bulk read timeouts (the bulk pipe for the IR > support is on a different endpoint than the data transport so they in > theory should be unrelated). This would also explain why nobody is > reporting problems with any of the other dib0700 designs. > > A user mailed me a card which arrived last week. I will have to see > if I can take a look when I get a chance. > > In the meantime, if you want to try to bisect the kernel between the > patch you reverted and the current 2.6.31 and see when it stops > working, that would be very useful (if we can nail it down to one of > the patches made to the via controller). While rolling back the patch > in question appears to make the problem go away, I don't believe it is > the actual cause of the problem, but rather that it exposed a bug > introduced later in the Via driver. > > Devin I tried today with kernel-2.27.29 - Worked OK and also with kernel-2.28.2 - Failed Looking at the changelog I see the patch I reverted was introduced in 2.28.1 so it is no surprise the 2.27.29 kernel works. I will try applying the latest v4l to an earlier 2.27 kernel until I find one in which it works. Thanks for your help Derek -- 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
sn9c20x driver seems ok, but no video
Hi folks, Trying to get a usb webcam based on SN9C20x driver working on Ubuntu. Loading the module, everything looks good (log output trimmed for easy reading): kernel: usb 7-3: new high speed USB device using ehci_hcd and address 4 kernel: usb 7-3: configuration #1 chosen from 1 choice kernel: sn9c20x: SN9C20X USB 2.0 Webcam - 0C45:628F plugged-in. kernel: sn9c20x: Detected OV9650 Sensor. kernel: sn9c20x: Webcam device 0C45:628F is now controlling video device /dev/video0 kernel: input: SN9C20X Webcam as /class/input/input10 kernel: sn9c20x: No ack from I2C slave 0x30 for write to address 0x17 kernel: sn9c20x: Using yuv420 output format However, I've tried several different apps (cheese, Xsane, gstreamer, etc) but cannot see any video output. I confess to being completely ignorant on issues video, etc. :) If I type 'cat /dev/video0 >j.dump', the green LED on camera comes on, and j.dump is filled with binary data. However, gst-launch shows this: # gst-launch-0.10 v4l2src ! ffmpegcolorspace ! ximagesink Setting pipeline to PAUSED ... ERROR: Pipeline doesn't want to pause. WARNING: from element /pipeline0/v4l2src0: Failed to get current input on device '/dev/video0'. May be it is a radio device Additional debug info: v4l2_calls.c(756): gst_v4l2_get_input (): /pipeline0/v4l2src0: system error: Invalid argument ERROR: from element /pipeline0/v4l2src0: Could not negotiate format Additional debug info: gstbasesrc.c(2387): gst_base_src_start (): /pipeline0/v4l2src0: Check your filtered caps, if any Setting pipeline to NULL ... FREEING pipeline ... I'm running Ubuntu Jaunty kernel (2.6.28) with Hardy userland. Any input/pointers would be most appreciated! And if there is a better list to post such a question, I'd appreciate it. I posted on micro...@googlegroups.com, but that list hasn't had a single message in more than 24 hours! Thanks, Chris -- Life is like Linux - it never stands still. -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
David Xiao wrote: > Another approach is working from a different direction: the kernel > allocates the non-cached buffer and then mmap() into user space. I have > done that in similar situation to try to achieve "zero-copy". open(O_DIRECT) does DMA to arbitrary pages allocated by userspace, and O_DIRECT is used by some important applications, so the problem still needs to be solved in general. -- Jamie -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thursday 06 August 2009 20:10:38 Trent Piepho wrote: > On Thu, 6 Aug 2009, Hans Verkuil wrote: > > > Why do you need two routines that will always return zero? Why to create a > > > code > > > that will never be used? v4l2-compat-ioctl32.c is already complex enough > > > without adding any bogus code. > > > > When the RDS encoder driver from Eduardo is added, then he will add the > > string controls to ctrl_is_pointer() since his driver is the first to > > actually implement string controls. > > Could one of the upper bits of the control id be used as a flag? It would > make it a lot easier to check the control's type than by using some inline > function with a giant case statement that needs to be updated each time a > new control is added. No, you can't. That would require users to OR that flag each time you want to use such a control. My original plan was to just check for a non-zero size field, the theory being that applications would set the old reserved field to 0. Unfortunately, several apps do not init those reserved fields, so they would fail. Note to ourselves: the next time we require apps to zero reserved fields we really have to check that they do and return an error otherwise... Anyway, I expect that these functions are a temporary measure anyway. Once we can move the control handling to the v4l2 framework this sort of info should be available readily from the framework without requiring such ugly switches. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - v4l: introduce string control support. - v4l2-spec: document the new string control type. - v4l2-ctl: modulator bug fixes - v4l2-ctl: add support for string controls It's the same as the previous version, except for reverting the variable renaming and for improving the comments above the ctrl_is_value64 and ctrl_is_pointer functions. I've decided to keep the ctrl_is_value64() function because I want to keep the correct value64 conversion code in compat32 rather than having to do that work again at some point in the future. Also note that it is very likely that these two functions will disappear again in a few months: once the v4l framework has proper control support these functions should no longer be needed since this information can then be obtained directly from the framework. Thanks, Hans diffstat: linux/drivers/media/video/v4l2-common.c |2 linux/drivers/media/video/v4l2-compat-ioctl32.c | 62 - linux/drivers/media/video/v4l2-ioctl.c | 10 linux/include/linux/videodev2.h |6 v4l2-apps/util/v4l2-ctl.cpp | 257 +++- v4l2-spec/Makefile |1 v4l2-spec/compat.sgml |3 v4l2-spec/controls.sgml |5 v4l2-spec/v4l2.sgml |4 v4l2-spec/vidioc-g-ext-ctrls.sgml | 72 +- v4l2-spec/vidioc-queryctrl.sgml | 42 ++- 11 files changed, 323 insertions(+), 141 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
> -Original Message- > From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel- > ow...@vger.kernel.org] On Behalf Of David Xiao > Sent: Thursday, August 06, 2009 2:46 PM > To: Laurent Pinchart > Cc: Ben Dooks; Hugh Dickins; Robin Holt; linux-ker...@vger.kernel.org; > v4l2_linux; linux-arm-ker...@lists.arm.linux.org.uk > Subject: Re: How to efficiently handle DMA and cache on ARMv7 ? (was "Is > get_user_pages() enough to prevent pages from being swapped out ?") > > On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: > > Hi Ben, > > > > On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > > > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > > [snip] > > > > > > > > The second problem is to ensure cache coherency. As the userspace > > > > application will read data from the video buffers, those buffers > will end > > > > up being cached in the processor's data cache. The driver does need > to > > > > invalidate the cache before starting the DMA operation (userspace > could > > > > in theory write to the buffers, but the data will be overwritten by > DMA > > > > anyway, so there's no need to clean the cache). > > > > > > You'll need to clean the write buffers, otherwise the CPU may have > data > > > queued that it has yet to write back to memory. > > > > Good points, thanks. > >I thought this should have been taken care of by the CPU specific > dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, > v7_dma_inv_range does not drain the write buffer; and the > v6_dma_inv_range does that in the end of all the cache maintenance > operaitons. >So this is probably something Russel can clarify. > Something non-related. I haven't used this specific api but ARM1156 has an issue. If you use the clean-cache-block mcr feature then it might result in memory-corruption. So be careful. I'm not sure which of these(ARM1156T2-S or ARM1156T2F-S) variants has that errata. Chetan -- 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
Syntek Driver ...
Greetings ... I was wondering if anybody has looked at the Syntek Driver stk11xx at http://sourceforge.net/projects/syntekdriver/files/ ... This driver is meant to have updates for the EasyCap USB video capture device ... Would be great to have included in the main line Video4Linux and then up stream Kernel ... Pretty please!! Mailed LeeT P.S. Hans de Goede suggested I post here ... -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
On Thu, 2009-08-06 at 06:06 -0700, Laurent Pinchart wrote: > Hi Ben, > > On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > [snip] > > > > > > The second problem is to ensure cache coherency. As the userspace > > > application will read data from the video buffers, those buffers will end > > > up being cached in the processor's data cache. The driver does need to > > > invalidate the cache before starting the DMA operation (userspace could > > > in theory write to the buffers, but the data will be overwritten by DMA > > > anyway, so there's no need to clean the cache). > > > > You'll need to clean the write buffers, otherwise the CPU may have data > > queued that it has yet to write back to memory. > > Good points, thanks. I thought this should have been taken care of by the CPU specific dma_inv_range routine. However, In arch/arm/mm/cache-v7.c, v7_dma_inv_range does not drain the write buffer; and the v6_dma_inv_range does that in the end of all the cache maintenance operaitons. So this is probably something Russel can clarify. > > > > As the cache is of the VIPT (Virtual Index Physical Tag) type, cache > > > invalidation can either be done globally (in which case the cache is > > > flushed instead of being invalidated) or based on virtual addresses. In > > > the last case the processor will need to look physical addresses up, > > > either in the TLB or through hardware table walk. > > > > > > I can see three solutions to the DMA/cache problem. > > > > > > 1. Flushing the whole data cache right before starting the DMA transfer. > > > There's no API for that in the ARM architecture, so a whole I+D cache is > > > required. This is quite costly, we're talking about around 30 flushes per > > > second, but it doesn't involve the MMU. That's the solution that I > > > currently use. > > > > > > 2. Invalidating only the cache lines that store video buffer data. This > > > requires a TLB lookup or a hardware table walk, so the userspace > > > application MM context needs to be available (no problem there as where's > > > flushing in userspace context) and all pages need to be mapped properly. > > > This can be a problem as, as Hugh pointed out, pages can still be > > > unmapped from the userspace context after get_user_pages() returns. I > > > have experienced one oops due to a kernel paging request failure: > > > > If you already know the virtual addresses of the buffers, why do you need > > a TLB lookup (or am I being dense here?) > > The virtual address is used to compute the cache lines index, and the > physical > address is then used when comparing the cache line tag. So the processor (or > actually the CP15 coprocessor if I'm not wrong) does a TLB lookup to get the > physical address during cache invalidation/flushing. > > > > Unable to handle kernel paging request at virtual address > > > 44e12000 pgd = c8698000 > > > [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= > > > Internal error: Oops: 817 [#1] PREEMPT > > > PC is at v7_dma_inv_range+0x2c/0x44 > > > > > > Fixing this requires more investigation, and I'm not sure how to proceed > > > to find out if the page fault is really caused by pages being unmapped > > > from the userspace context. Help would be appreciated. > > > > > > 3. Mark the pages as non-cacheable. Depending on how the buffers are then > > > used by userspace, the additional cache misses might destroy any benefit > > > I would get from not flushing the cache before DMA. I'm not sure how to > > > mark a bunch of pages as non-cacheable though. What usually happens is > > > that video drivers allocate DMA-coherent memory themselves, but in this > > > case I need to deal with an arbitrary buffer allocated by userspace. If > > > someone has any experience with this, it would be appreciated. > Another approach is working from a different direction: the kernel allocates the non-cached buffer and then mmap() into user space. I have done that in similar situation to try to achieve "zero-copy". David -- 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: WARNINGS, 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 Aug 6 19:00:05 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12397:042f15af3ac4 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc5-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29.1-armv5-ixp: OK linux-2.6.30-armv5-ixp: OK linux-2.6.31-rc5-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29.1-armv5-omap2: OK linux-2.6.30-armv5-omap2: OK linux-2.6.31-rc5-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29.1-i686: OK linux-2.6.30-i686: WARNINGS linux-2.6.31-rc5-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc5-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc5-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29.1-powerpc64: OK linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-rc5-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc5-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc5): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK 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 V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: Hauppauge WinTV HVR-900HD support?
On Thu, Aug 6, 2009 at 12:06 PM, Kaya Saman wrote: > >> >> No, I recommended the HVR1900 because *IT* is fully supported, and is >> *not* getting replaced. HVR900 got replaced. HVR1900 is not as large >> as a set top box, but it is bigger than the usb sticks, and uses a >> power brick, for the mpeg encoder. >> >> It is on the Hauppauge web site, you probably just overlooked it. >> >> -Mike >> > > Ok, now I am so sorry and I feel really silly but I can't find it. > > I have tried hauppauge.co.uk and under HVR-external all I get is 900HD, 900, > and 1400: > > http://www.hauppauge.co.uk/site/products/prods_hvr_external.html > > now, I even did a search for the 1900 and found nothing on hauppauge search > link??? Sure it came up with the 1950 model but no 1900. > > On top of that I tried www.dabs.com and www.misco.co.uk both of which have > the 900 but no 1900. > > am I missing something or have I just totally gone insane over the last few > hours??? #1) http://www.hauppauge.de/de/index.htm (scroll down to middle of the page) #2) http://www.hauppauge.de/de/site/products/data_hvr1900.html #3) http://www.hauppauge.com/site/press/presspictures/HVR-1900_German_1251.jpg #4) http://www.hauppauge.com/site/press/presspictures/HVR-1900_4lang_1179.png #5) http://www.hauppauge.com/site/support/linux.html -Mike -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
On Thu, 6 Aug 2009, Hans Verkuil wrote: > > Why do you need two routines that will always return zero? Why to create a > > code > > that will never be used? v4l2-compat-ioctl32.c is already complex enough > > without adding any bogus code. > > When the RDS encoder driver from Eduardo is added, then he will add the > string controls to ctrl_is_pointer() since his driver is the first to > actually implement string controls. Could one of the upper bits of the control id be used as a flag? It would make it a lot easier to check the control's type than by using some inline function with a giant case statement that needs to be updated each time a new control is added. -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
Ok, I've tried to tune analog tv with tvtime-scanner and all the channels have been tuned corretly. However, even if I use the following command to redirect the audio from the device to the audio card: sox -r 48000 -t alsa hw:1,0 -t alsa default & no audio is present when I start tv time and sox exits with the output as in the attached file. If it is possible to fix this, this device can be added to the fully supported ones. Xwang Devin Heitmueller ha scritto: On Thu, Aug 6, 2009 at 11:16 AM, wrote: Ok, I've made the change and now the digital tv works perfectly. So now I should test the analog tv, but I fear to have another kernel panic. Is there something I can do before testing so that to be sure that at least all the file system are in a safety condition even if a kernel panic happens. I'm wondering if it is the case, for example, to umount them and remount in read only mode so that if I have to turn off the pc, nothing can be corrupted (is it so?). What do you suggest? In case, how can I temporarly umount and remout the file systems in read only mode? Should I use alt+sys+S followed by alt+sys+U? Can I use such commands while I'm in KDE? Thank you, Xwang Glad to hear it's working now. I will add the patch and issue a PULL request to get it into the mainline (I had to do this already for several other boards). Regarding your concerns on panic, as long as you have a modern filesystem like ext3, and you don't have alot of applications running which are doing writes, a panic is a pretty safe event. I panic my machine many times a week and never have any problems. Cheers, Devin <>
Re: Hauppauge WinTV HVR-900HD support?
No, I recommended the HVR1900 because *IT* is fully supported, and is *not* getting replaced. HVR900 got replaced. HVR1900 is not as large as a set top box, but it is bigger than the usb sticks, and uses a power brick, for the mpeg encoder. It is on the Hauppauge web site, you probably just overlooked it. -Mike Ok, now I am so sorry and I feel really silly but I can't find it. I have tried hauppauge.co.uk and under HVR-external all I get is 900HD, 900, and 1400: http://www.hauppauge.co.uk/site/products/prods_hvr_external.html now, I even did a search for the 1900 and found nothing on hauppauge search link??? Sure it came up with the 1950 model but no 1900. On top of that I tried www.dabs.com and www.misco.co.uk both of which have the 900 but no 1900. am I missing something or have I just totally gone insane over the last few hours??? --K -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
On Thu, Aug 6, 2009 at 11:16 AM, wrote: > Ok, > I've made the change and now the digital tv works perfectly. > So now I should test the analog tv, but I fear to have another kernel panic. > Is there something I can do before testing so that to be sure that at least > all the file system are in a safety condition even if a kernel panic > happens. > I'm wondering if it is the case, for example, to umount them and remount in > read only mode so that if I have to turn off the pc, nothing can be > corrupted (is it so?). > What do you suggest? > In case, how can I temporarly umount and remout the file systems in read > only mode? Should I use alt+sys+S followed by alt+sys+U? Can I use such > commands while I'm in KDE? > Thank you, > Xwang Glad to hear it's working now. I will add the patch and issue a PULL request to get it into the mainline (I had to do this already for several other boards). Regarding your concerns on panic, as long as you have a modern filesystem like ext3, and you don't have alot of applications running which are doing writes, a panic is a pretty safe event. I panic my machine many times a week and never have any problems. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issues with Empire Dual Pen: request for help and suggestions!!!
Ok, I've made the change and now the digital tv works perfectly. So now I should test the analog tv, but I fear to have another kernel panic. Is there something I can do before testing so that to be sure that at least all the file system are in a safety condition even if a kernel panic happens. I'm wondering if it is the case, for example, to umount them and remount in read only mode so that if I have to turn off the pc, nothing can be corrupted (is it so?). What do you suggest? In case, how can I temporarly umount and remout the file systems in read only mode? Should I use alt+sys+S followed by alt+sys+U? Can I use such commands while I'm in KDE? Thank you, Xwang Douglas Schilling Landgraf ha scritto: Hello Xwang, Could you please try the bellow suggestion? If you want I can make this change in my development tree and you can test from there. Let me know the results Cheers, Douglas On Thu, 6 Aug 2009 10:17:28 -0400 Devin Heitmueller wrote: On Thu, Aug 6, 2009 at 9:54 AM, wrote: Hi, I want to inform you that thanks to Douglas Schilling Landgraf, the first point (automatic recognition of the device when plugged in) ha been resolved (using his development tree driver). I've tried to scan for digital channels again and the result has not changed but in the dmesg attached there are a lot of messages created during the scan process. I hope they are useful to solve at list the issue related with the digital scanning. Thank you, Xwang Yeah, I've seen that before. Open up em28xx-dvb.c, and move the following: case EM2880_BOARD_EMPIRE_DUAL_TV: from line 402 to line 492. So it should look like this: case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900: case EM2880_BOARD_EMPIRE_DUAL_TV: dvb->frontend = dvb_attach(zl10353_attach, &em28xx_zl10353_xc3028_no_i2c_gate, dev->i2c_adap); Then unplug the device, recompile, reinstall and see if the dvb starts working. Devin -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH,RFC] Drop non-unlocked ioctl support in v4l2-dev.c
Hi Laurent, > Hi everybody, > > this patch moves the BKL one level down by removing the non-unlocked ioctl > in > v4l2-dev.c and calling lock_kernel/unlock_kernel in the unlocked_ioctl > handler > if the driver only supports locked ioctl. > > Opinions/comments/applause/kicks ? I've been thinking about this as well, and my idea was to properly implement this by letting the v4l core serialize ioctls if the driver doesn't do its own serialization (either through mutexes or lock_kernel). The driver can just set a flag in video_device if it wants to do serialization manually, otherwise the core will serialize using a mutex and we should be able to completely remove the BKL from all v4l drivers. I was actually planning an RFC for this myself, but you've beaten me to it :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Linux Plumbers Conference 2009: V4L2 API discussions
> -Original Message- > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Hiremath, Vaibhav > Sent: Tuesday, August 04, 2009 12:13 PM > To: Hans Verkuil; linux-media@vger.kernel.org > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus Damm; > Dongsoo, Nathaniel Kim > Subject: RE: Linux Plumbers Conference 2009: V4L2 API discussions > > > > > -Original Message- > > From: davinci-linux-open-source-boun...@linux.davincidsp.com > > [mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On > > Behalf Of Hans Verkuil > > Sent: Tuesday, August 04, 2009 12:42 PM > > To: linux-media@vger.kernel.org > > Cc: eduardo.valen...@nokia.com; davinci-linux-open- > > sou...@linux.davincidsp.com; linux-o...@vger.kernel.org; Magnus > > Damm; Dongsoo, Nathaniel Kim > > Subject: Linux Plumbers Conference 2009: V4L2 API discussions > > > > Hi all, > > > > During this years Plumbers Conference I will be organizing a session > > (or > > possibly more than one) on what sort of new V4L2 APIs are needed to > > support the new SoC devices. These new APIs should also solve the > > problem > > of how to find all the related alsa/fb/ir/dvb devices that a typical > > video > > device might create. > > > > A proposal was made about a year ago (note that this is a bit > > outdated > > by now, but the basics are still valid): > > > > http://www.archivum.info/video4linux-list%40redhat.com/2008- > > 07/msg00371.html > > > > In the past year the v4l2 core has evolved enough so that we can > > finally > > start thinking about this for real. > > > > I would like to know who will be attending this conference. I also > > urge > > anyone who is working in this area and who wants to have a say in > > this to > > attend the conference. The goal is to prepare a new RFC with a > > detailed > > proposal on the new APIs that are needed to fully support all the > > new > > SoCs. So the more input we get, the better the end-result will be. > > > [Hiremath, Vaibhav] Hi Hans, > > I will be attending the conference and along with above mentioned RFC I > would want to discuss some of the open issues, forthcoming TI devices, > their complexity and required software interfaces (media processor (as you > mentioned above)) and similar stuff. Hans, Vaibhav, I'll be attending this conference too. I just got approval from my boss ;). I'm starting to take the v4l2_subdev migration task as a high priority now, since most of the stability related issues in some proprietary platform are gone now. :) Actually, I'm also interested on the discussions about the Preview/Resizer Wrappers. Meet you there. Regards, Sergio > > > I will work with you offline before sharing the details here with the > community. > > Thanks, > Vaibhav Hiremath > > > Early-bird registration is still possible up to August 5th (that's > > tomorrow :-) ). > > > > Regards, > > > > Hans > > > > -- > > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > > > > ___ > > Davinci-linux-open-source mailing list > > davinci-linux-open-sou...@linux.davincidsp.com > > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open- > > source > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH,RFC] Drop non-unlocked ioctl support in v4l2-dev.c
Hi everybody,
this patch moves the BKL one level down by removing the non-unlocked ioctl in
v4l2-dev.c and calling lock_kernel/unlock_kernel in the unlocked_ioctl handler
if the driver only supports locked ioctl.
Opinions/comments/applause/kicks ?
Regards,
Laurent Pinchart
diff -r 4533a406fddb linux/drivers/media/video/v4l2-dev.c
--- a/linux/drivers/media/video/v4l2-dev.c Thu Aug 06 16:41:17 2009 +0200
+++ b/linux/drivers/media/video/v4l2-dev.c Thu Aug 06 17:04:37 2009 +0200
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -211,28 +212,22 @@
return vdev->fops->poll(filp, poll);
}
-static int v4l2_ioctl(struct inode *inode, struct file *filp,
- unsigned int cmd, unsigned long arg)
-{
- struct video_device *vdev = video_devdata(filp);
-
- if (!vdev->fops->ioctl)
- return -ENOTTY;
- /* Allow ioctl to continue even if the device was unregistered.
- Things like dequeueing buffers might still be useful. */
- return vdev->fops->ioctl(filp, cmd, arg);
-}
-
static long v4l2_unlocked_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg)
{
struct video_device *vdev = video_devdata(filp);
+ int ret = -ENOTTY;
- if (!vdev->fops->unlocked_ioctl)
- return -ENOTTY;
/* Allow ioctl to continue even if the device was unregistered.
Things like dequeueing buffers might still be useful. */
- return vdev->fops->unlocked_ioctl(filp, cmd, arg);
+ if (vdev->fops->ioctl) {
+ lock_kernel();
+ ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
+ unlock_kernel();
+ } else if (vdev->fops->unlocked_ioctl)
+ ret = vdev->fops->unlocked_ioctl(filp, cmd, arg);
+
+ return ret;
}
#ifdef CONFIG_MMU
@@ -320,22 +315,6 @@
.llseek = no_llseek,
};
-static const struct file_operations v4l2_fops = {
- .owner = THIS_MODULE,
- .read = v4l2_read,
- .write = v4l2_write,
- .open = v4l2_open,
- .get_unmapped_area = v4l2_get_unmapped_area,
- .mmap = v4l2_mmap,
- .ioctl = v4l2_ioctl,
-#ifdef CONFIG_COMPAT
- .compat_ioctl = v4l2_compat_ioctl32,
-#endif
- .release = v4l2_release,
- .poll = v4l2_poll,
- .llseek = no_llseek,
-};
-
/**
* get_index - assign stream number based on parent device
* @vdev: video_device to assign index number to, vdev->parent should be
assigned
@@ -534,15 +513,9 @@
goto cleanup;
}
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2, 6, 17)
- if (vdev->fops->unlocked_ioctl)
- vdev->cdev->ops = &v4l2_unlocked_fops;
- else
- vdev->cdev->ops = &v4l2_fops;
+ vdev->cdev->ops = &v4l2_unlocked_fops;
#else
- if (vdev->fops->unlocked_ioctl)
- vdev->cdev->ops = (struct file_operations *)&v4l2_unlocked_fops;
- else
- vdev->cdev->ops = (struct file_operations *)&v4l2_fops;
+ vdev->cdev->ops = (struct file_operations *)&v4l2_unlocked_fops;
#endif
vdev->cdev->owner = vdev->fops->owner;
ret = cdev_add(vdev->cdev, MKDEV(VIDEO_MAJOR, vdev->minor), 1);
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-900HD support?
On Thu, Aug 6, 2009 at 9:33 AM, Kaya Saman wrote: > Michael Krufky wrote: >> >> >> >> HVR1400 is expresscard. >> >> HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. >> (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog >> standards) >> >> HVR1900 is the one I am recommending for you. Maybe the website >> you're looking at needs updating -- the HVR1900 has been available >> already for quite some time. >> >> Regards, >> >> Mike >> > > Thanks Mike, I managed to find it finally on Amazon.co.uk which claimed that > it was available from June 2007! > > That might explain why it's not on the Hauppauge website as it is most > likely getting replaced > > I actually expected this to be one of those cute USB keys but this thing > resembles a set top box :-) > > I think the WinTV HVR-900 maybe a better option as it is supported. I am > guessing that this is the same thing as the H model without the HD support? No, I recommended the HVR1900 because *IT* is fully supported, and is *not* getting replaced. HVR900 got replaced. HVR1900 is not as large as a set top box, but it is bigger than the usb sticks, and uses a power brick, for the mpeg encoder. It is on the Hauppauge web site, you probably just overlooked it. -Mike -- 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: Issues with Empire Dual Pen: request for help and suggestions!!!
On Thu, Aug 6, 2009 at 9:54 AM, wrote: > Hi, > I want to inform you that thanks to Douglas Schilling Landgraf, the first > point (automatic recognition of the device when plugged in) ha been resolved > (using his development tree driver). > I've tried to scan for digital channels again and the result has not changed > but in the dmesg attached there are a lot of messages created during the > scan process. I hope they are useful to solve at list the issue related with > the digital scanning. > Thank you, > Xwang Yeah, I've seen that before. Open up em28xx-dvb.c, and move the following: case EM2880_BOARD_EMPIRE_DUAL_TV: from line 402 to line 492. So it should look like this: case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900: case EM2880_BOARD_EMPIRE_DUAL_TV: dvb->frontend = dvb_attach(zl10353_attach, &em28xx_zl10353_xc3028_no_i2c_gate, dev->i2c_adap); Then unplug the device, recompile, reinstall and see if the dvb starts working. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-900HD support?
I just wanted to mention that the WinTV-HVR-900 is supported but I think only certain revisions. I have one, which doesn't work, a 65018/B3C0. Kaya Saman wrote: > Michael Krufky wrote: >> >> >> >> HVR1400 is expresscard. >> >> HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. >> (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog >> standards) >> >> HVR1900 is the one I am recommending for you. Maybe the website >> you're looking at needs updating -- the HVR1900 has been available >> already for quite some time. >> >> Regards, >> >> Mike >> > > Thanks Mike, I managed to find it finally on Amazon.co.uk which > claimed that it was available from June 2007! > > That might explain why it's not on the Hauppauge website as it is most > likely getting replaced > > I actually expected this to be one of those cute USB keys but this > thing resembles a set top box :-) > > I think the WinTV HVR-900 maybe a better option as it is supported. I > am guessing that this is the same thing as the H model without the HD > support? > > It maybe ok what do you think?? Also you can use this with a remote > too can't you?? > > Kaya > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-900HD support?
Michael Krufky wrote: HVR1400 is expresscard. HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog standards) HVR1900 is the one I am recommending for you. Maybe the website you're looking at needs updating -- the HVR1900 has been available already for quite some time. Regards, Mike Thanks Mike, I managed to find it finally on Amazon.co.uk which claimed that it was available from June 2007! That might explain why it's not on the Hauppauge website as it is most likely getting replaced I actually expected this to be one of those cute USB keys but this thing resembles a set top box :-) I think the WinTV HVR-900 maybe a better option as it is supported. I am guessing that this is the same thing as the H model without the HD support? It maybe ok what do you think?? Also you can use this with a remote too can't you?? Kaya -- 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: Hauppauge WinTV HVR-900HD support?
On Thu, Aug 6, 2009 at 9:07 AM, Kaya Saman wrote: > Michael Krufky wrote: >> >> Kaya, >> >> On Thu, Aug 6, 2009 at 7:53 AM, Kaya Saman wrote: >> >>> >>> >> >> I don't think that's true -- I didn't see your earlier post, but I can >> only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 >> chipsets, supported by the usbvision driver -- did you try that? >> >> >> Better off getting a new one anyway, since analog TV will disappear >> eventually and DTV is all that will be around. >> The HVR-900H is currently *not* supported under Linux, and it does not >> seem that it will get such support anytime in the near future, >> unfortunately. Please note, I am only speaking for the HVR-900H ... >> other flavors of the HVR900 are fully functional and supported, just >> not the "H" version. >> >> If you're looking for a well-supported USB hybrid device, I would >> recommend one of the standard "HVR-900" sticks, or even better, the >> HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and >> analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder >> -- this is perfect if you intend to use the device for recordings. >> HVR1900 is fully supported under Linux. >> >> I hope this helps. >> >> Regards, >> >> Mike >> > > Thanks for the response Mike! > > You claim there is a Hauppauge HVR-1900... I am looking on the > www.hauppauge.co.uk website and all I see is a 1400 which is SMC slot?? HVR1400 is expresscard. HVR1900 is usb2. HVR1950 is the NTSC/ATSC/QAM version of the HVR1900. (HVR1900 is PAL/DVB-T, but can also do NTSC, and other analog standards) HVR1900 is the one I am recommending for you. Maybe the website you're looking at needs updating -- the HVR1900 has been available already for quite some time. Regards, Mike -- 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: Hauppauge WinTV HVR-900HD support?
Michael Krufky wrote: Kaya, On Thu, Aug 6, 2009 at 7:53 AM, Kaya Saman wrote: I don't think that's true -- I didn't see your earlier post, but I can only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 chipsets, supported by the usbvision driver -- did you try that? Better off getting a new one anyway, since analog TV will disappear eventually and DTV is all that will be around. The HVR-900H is currently *not* supported under Linux, and it does not seem that it will get such support anytime in the near future, unfortunately. Please note, I am only speaking for the HVR-900H ... other flavors of the HVR900 are fully functional and supported, just not the "H" version. If you're looking for a well-supported USB hybrid device, I would recommend one of the standard "HVR-900" sticks, or even better, the HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder -- this is perfect if you intend to use the device for recordings. HVR1900 is fully supported under Linux. I hope this helps. Regards, Mike Thanks for the response Mike! You claim there is a Hauppauge HVR-1900... I am looking on the www.hauppauge.co.uk website and all I see is a 1400 which is SMC slot?? In fact just checked hauppauge.com and there seems to be a 1950 model! Perhaps it hasn't been released yet or maybe I haven't found it. Is it HD compatible like the HVR-900H model? --This is not so important but a nicety none the less :-) I will forward my previous post to you directly! Regards, Kaya -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
Hi Ben, On Thursday 06 August 2009 13:46:19 Ben Dooks wrote: > On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: [snip] > > > > The second problem is to ensure cache coherency. As the userspace > > application will read data from the video buffers, those buffers will end > > up being cached in the processor's data cache. The driver does need to > > invalidate the cache before starting the DMA operation (userspace could > > in theory write to the buffers, but the data will be overwritten by DMA > > anyway, so there's no need to clean the cache). > > You'll need to clean the write buffers, otherwise the CPU may have data > queued that it has yet to write back to memory. Good points, thanks. > > As the cache is of the VIPT (Virtual Index Physical Tag) type, cache > > invalidation can either be done globally (in which case the cache is > > flushed instead of being invalidated) or based on virtual addresses. In > > the last case the processor will need to look physical addresses up, > > either in the TLB or through hardware table walk. > > > > I can see three solutions to the DMA/cache problem. > > > > 1. Flushing the whole data cache right before starting the DMA transfer. > > There's no API for that in the ARM architecture, so a whole I+D cache is > > required. This is quite costly, we're talking about around 30 flushes per > > second, but it doesn't involve the MMU. That's the solution that I > > currently use. > > > > 2. Invalidating only the cache lines that store video buffer data. This > > requires a TLB lookup or a hardware table walk, so the userspace > > application MM context needs to be available (no problem there as where's > > flushing in userspace context) and all pages need to be mapped properly. > > This can be a problem as, as Hugh pointed out, pages can still be > > unmapped from the userspace context after get_user_pages() returns. I > > have experienced one oops due to a kernel paging request failure: > > If you already know the virtual addresses of the buffers, why do you need > a TLB lookup (or am I being dense here?) The virtual address is used to compute the cache lines index, and the physical address is then used when comparing the cache line tag. So the processor (or actually the CP15 coprocessor if I'm not wrong) does a TLB lookup to get the physical address during cache invalidation/flushing. > > Unable to handle kernel paging request at virtual address > > 44e12000 pgd = c8698000 > > [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= > > Internal error: Oops: 817 [#1] PREEMPT > > PC is at v7_dma_inv_range+0x2c/0x44 > > > > Fixing this requires more investigation, and I'm not sure how to proceed > > to find out if the page fault is really caused by pages being unmapped > > from the userspace context. Help would be appreciated. > > > > 3. Mark the pages as non-cacheable. Depending on how the buffers are then > > used by userspace, the additional cache misses might destroy any benefit > > I would get from not flushing the cache before DMA. I'm not sure how to > > mark a bunch of pages as non-cacheable though. What usually happens is > > that video drivers allocate DMA-coherent memory themselves, but in this > > case I need to deal with an arbitrary buffer allocated by userspace. If > > someone has any experience with this, it would be appreciated. Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV HVR-900HD support?
Kaya, On Thu, Aug 6, 2009 at 7:53 AM, Kaya Saman wrote: > Hi, > > in an earlier post I was responded to that my old WinTV USB 1 Tuner would > never work under Linux due to bad and complicated coding which (since no one > uses that tuner anymore) will never be looked at. I don't think that's true -- I didn't see your earlier post, but I can only assume that your WinTV USB 1 Tuner uses the NT003 / NT004 chipsets, supported by the usbvision driver -- did you try that? > So I am in need of a new tuner! Better off getting a new one anyway, since analog TV will disappear eventually and DTV is all that will be around. > This is a dilemma as I need analog TV since I will be using it for > watching stuff through a satellite receiver but also analog terrestrial TV > too as where I will be taking it to doesn't have digital TV at best the have > cable. > > I was considering going for the Hauppauge WinTV HVR-900HD. I am not sure if > it will be compatible though with the global regions I will use it in which > is UK that I know it has support for as I will buy from here which is PAL I > but then also Turkey which I think is PAL Beta if I'm not mistaken?? > > More importantly though is it supported under Linux?? I use KUbuntu 9.04 > which is pretty up to date. I am just a bit worried about this part since > the site says that as of June 2008 there is no support... of course we are > in August 2009 so maybe in a year it might have been integrated into the > later kernels?? > Taken from here: > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H > > What's everyone's verdict? Any suggestions would be great! The HVR-900H is currently *not* supported under Linux, and it does not seem that it will get such support anytime in the near future, unfortunately. Please note, I am only speaking for the HVR-900H ... other flavors of the HVR900 are fully functional and supported, just not the "H" version. If you're looking for a well-supported USB hybrid device, I would recommend one of the standard "HVR-900" sticks, or even better, the HVR-1900 . The HVR1900 is a usb device that does Digital DVB-T and analog (PAL / NTSC) both. The analog side has a hardware mpeg encoder -- this is perfect if you intend to use the device for recordings. HVR1900 is fully supported under Linux. I hope this helps. Regards, Mike -- 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: RFC: adding ISDB-T/ISDB-Tsb to DVB-API 5
Hi Michael, thanks for your response. On Wed, 5 Aug 2009, Michael Krufky wrote: It's extremely exciting to finally see this surfacing to the mailing lists -- It will be a great addition to linux-dvb to have support for the ISDB digital standards. Thanks, but I have to say it again, as I said it to Akihiro already. Those patches are not adding ISDB-S nor ISDB-C to the API. I'm not sure how different ISDB-S and ISDB-C are compared to their corresponding DVB pendants; however my patches are just adding support for ISDB-T and ISDB-Tsb. One thing that I see missing right now is userspace utilities. Do you have any plans to add ISDB scanning support to dvb-apps, and tuning support to the *zap utility? This would be the best way to get the application developers started on incorporating ISDB support into the apps shipping today. Yeah this is in preparation. The scan works rather simply, as the section tables are partially identical to the ones in DVB (there is an SDT for service-names, there is a NIT, for network name) - so as a first shot it should be sufficient to add ISDB-T initial tuning data parsing to scan; this will also show how to tuning an ISDB-T channel. See attached for a first draft of the initial tuning data file for Tokyo. best regards, -- Patrick Boettcher - Kernel Labs http://www.kernellabs.com/# list of ISDB-T frequencies used in Tokyo, Japan (2009-08-06) # identifier (IT/ISB) # central-frequency # | transmission-mode # | | guard-interval # | | |partial-reception-bit # | | || c-rate (A) # | | || | modulation (A) # | | || | | segment-count (A) # | | || | | | interleaving (A) # | | || | | | | c-rate (B) # | | || | | | | |modulation (B) # | | || | | | | || segment-count (B) # | | || | | | | || | interleaving (B) # | | || | | | | || | | c-rate (C) # | | || | | | | || | | | modulation (C) # | | || | | | | || | | || segment-count (C) # | | || | | | | || | | ||| interleaving (C) IT 515143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # Tokyo Metroplitan TV IT 521143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # Fuji TV IT 527143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # TBS TV IT 533143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # TV Tokyo IT 539143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # TV Asahi IT 545143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # Nihon TV IT 551143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # NHK Education IT 557143000 8K 1/8 1 FEC_2_3 QPSK 1 3 FEC_3_4 QAM64 12 2 FEC_NONE AUTO 0 0 # NHK Sogo IT 563143000 8K 1/4 0 FEC_3_4 QAM64 13 2 FEC_NONE AUTO 0 0 FEC_NONE AUTO 0 0 # Broadcasting University # example for ISDB-Tsb # # identifier (IT/ISB) #central-frequency #| transmission-mode #| | guard-interval #| | |partial-reception-bit #| | || segment-idx #| | || | segment-total-count #| | || | | subchannel_id #| | || | | | c-rate (A) #| | || | | | | modulation (A) #| | || | | | | |segment-count (A) #| | || | | | | || interleaving (A) #| | || | | | | || | c-rate (B) #| | || | | | | || | | modulation (B) #| | || | | | | || | | | segment-count (B) #| | || | | | | || | | | | interleaving (B) #ISB 17000 8K 1/32 0 1 8 2 FEC_1_2 QPSK 1 0 FEC_NONE AUTO 0 0 #ISB 170429000 8K 1/32 0 2 8 6 FEC_1_2 QPSK 1 0 FEC_NONE AUTO 0 0 #ISB 170868000 8K 1/32 0 3 8 10 FEC_1_2 QPSK 1 0 FEC_NONE AUTO 0 0 #ISB 171726000 8K 1/32 0 5 8 18 FEC_1_2 QPSK 1 0 FEC_NONE AUTO 0 0 #ISB 172584000 8K 1/32 0 7 8 26 FEC_1_2 QPSK 1 0 FEC_1_2 QPSK 2 0 #ISB 173013000 8K 1/32 0 8 8 30 FEC_1_2 QPSK 1 0 FEC_NONE AUTO 0 0
Hauppauge WinTV HVR-900HD support?
Hi, in an earlier post I was responded to that my old WinTV USB 1 Tuner would never work under Linux due to bad and complicated coding which (since no one uses that tuner anymore) will never be looked at. So I am in need of a new tuner! This is a dilemma as I need analog TV since I will be using it for watching stuff through a satellite receiver but also analog terrestrial TV too as where I will be taking it to doesn't have digital TV at best the have cable. I was considering going for the Hauppauge WinTV HVR-900HD. I am not sure if it will be compatible though with the global regions I will use it in which is UK that I know it has support for as I will buy from here which is PAL I but then also Turkey which I think is PAL Beta if I'm not mistaken?? More importantly though is it supported under Linux?? I use KUbuntu 9.04 which is pretty up to date. I am just a bit worried about this part since the site says that as of June 2008 there is no support... of course we are in August 2009 so maybe in a year it might have been integrated into the later kernels?? Taken from here: http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-900H What's everyone's verdict? Any suggestions would be great! --Kaya -- 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: How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
On Thu, Aug 06, 2009 at 12:08:21PM +0200, Laurent Pinchart wrote: > [Resent with an updated subject, this time CC'ing linux-arm-kernel] > > I've spent the last few days "playing" with get_user_pages() and mlock() and > got some interesting results. It turned out that cache coherency comes into > play at some point, making the overall problem more complex. > > Here's my current setup: > > - OMAP processor, based on an ARMv7 core > - MMU and IOMMU > - VIPT non-aliasing data cache > - video capture driver that transfers data to memory using DMA > - video capture application that pass userspace pointers to video buffers to > the driver > > My goal is to make sure that, upon DMA completion, the correct data will be > available to the userspace application. > > The first problem was to pin pages to memory, to make sure they will not be > freed when the DMA is in progress. videobug-dma-sg uses get_user_pages() for > that, and Hugh Dickins nicely explained to me why this is enough. > > The second problem is to ensure cache coherency. As the userspace application > will read data from the video buffers, those buffers will end up being cached > in the processor's data cache. The driver does need to invalidate the cache > before starting the DMA operation (userspace could in theory write to the > buffers, but the data will be overwritten by DMA anyway, so there's no need > to > clean the cache). You'll need to clean the write buffers, otherwise the CPU may have data queued that it has yet to write back to memory. > As the cache is of the VIPT (Virtual Index Physical Tag) type, cache > invalidation can either be done globally (in which case the cache is flushed > instead of being invalidated) or based on virtual addresses. In the last case > the processor will need to look physical addresses up, either in the TLB or > through hardware table walk. > > I can see three solutions to the DMA/cache problem. > > 1. Flushing the whole data cache right before starting the DMA transfer. > There's no API for that in the ARM architecture, so a whole I+D cache is > required. This is quite costly, we're talking about around 30 flushes per > second, but it doesn't involve the MMU. That's the solution that I currently > use. > > 2. Invalidating only the cache lines that store video buffer data. This > requires a TLB lookup or a hardware table walk, so the userspace application > MM context needs to be available (no problem there as where's flushing in > userspace context) and all pages need to be mapped properly. This can be a > problem as, as Hugh pointed out, pages can still be unmapped from the > userspace context after get_user_pages() returns. I have experienced one oops > due to a kernel paging request failure: If you already know the virtual addresses of the buffers, why do you need a TLB lookup (or am I being dense here?) > Unable to handle kernel paging request at virtual address 44e12000 > pgd = c8698000 > [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= > Internal error: Oops: 817 [#1] PREEMPT > PC is at v7_dma_inv_range+0x2c/0x44 > > Fixing this requires more investigation, and I'm not sure how to proceed to > find out if the page fault is really caused by pages being unmapped from the > userspace context. Help would be appreciated. > > 3. Mark the pages as non-cacheable. Depending on how the buffers are then > used > by userspace, the additional cache misses might destroy any benefit I would > get from not flushing the cache before DMA. I'm not sure how to mark a bunch > of pages as non-cacheable though. What usually happens is that video drivers > allocate DMA-coherent memory themselves, but in this case I need to deal with > an arbitrary buffer allocated by userspace. If someone has any experience > with > this, it would be appreciated. > > Regards, > > Laurent Pinchart > > > --- > List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel > FAQ:http://www.arm.linux.org.uk/mailinglists/faq.php > Etiquette: http://www.arm.linux.org.uk/mailinglists/etiquette.php -- -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- 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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
> Em Sun, 2 Aug 2009 12:10:04 +0200
> Hans Verkuil escreveu:
>
>> Hi Mauro,
>>
>> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
>> following:
>>
>> - v4l: introduce string control support.
>
> Hans,
>
> This looks very weird:
>
> +/* The following two functions really belong in v4l2-common, but that
> causes
> + a circular dependency between modules. We need to think about this,
> but
> + for now this will do. */
> +
> +/* Return non-zero if this control is of type VALUE64.
> + *
> + * This information is used inside v4l2_compat_ioctl32. */
> +static int ctrl_is_value64(u32 id)
> +{
> + return 0;
> +}
> +
> +/* Return non-zero if this control is a pointer type. Currently only
> + * type STRING is a pointer type.
> + *
> + * This information is used inside v4l2_compat_ioctl32. */
> +static int ctrl_is_pointer(u32 id)
> +{
> + return 0;
> +}
> +
> ...
> + } else if (ctrl_is_value64(kctrl->id)) {
> + if (copy_in_user(&kctrl->value64, &uctrl->value64,
> +sizeof(uctrl->value64)))
> + return -EFAULT;
> ...
> + if (ctrl_is_value64(kctrl->id)) {
> + if (copy_in_user(&uctrl->value64, &kctrl->value64,
> +sizeof(uctrl->value64)))
> + return -EFAULT;
> + } else if (!ctrl_is_pointer(kctrl->id) &&
> + copy_in_user(&uctrl->value, &kctrl->value,
> +sizeof(uctrl->value))) {
>
> Why do you need two routines that will always return zero? Why to create a
> code
> that will never be used? v4l2-compat-ioctl32.c is already complex enough
> without adding any bogus code.
When the RDS encoder driver from Eduardo is added, then he will add the
string controls to ctrl_is_pointer() since his driver is the first to
actually implement string controls.
There is indeed no value64 control yet, but I think it is wise to at least
have the code in place to correctly handle such controls. I can remove
that if you want.
>
> I noticed that you're also renaming the names of some fields there:
>
> - struct v4l2_ext_control __user *ucontrols;
> - struct v4l2_ext_control __user *kcontrols = kp->controls;
> + struct v4l2_ext_control __user *uctrl;
> + struct v4l2_ext_control __user *kctrl = kp->controls;
>
> I dunno why you decided to do it, but having this together with the
> changes at
> v4l2-compat-ioctl32.c makes the code even harder to understand. Could you
> please move the v4l2-compat-ioctl32 "cosmetic" changes like above into a
> separate patch?
OK. It was done to avoid creating lots of 'longer than 80 characters'
warnings.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Em Sun, 2 Aug 2009 12:10:04 +0200
Hans Verkuil escreveu:
> Hi Mauro,
>
> Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the
> following:
>
> - v4l: introduce string control support.
Hans,
This looks very weird:
+/* The following two functions really belong in v4l2-common, but that causes
+ a circular dependency between modules. We need to think about this, but
+ for now this will do. */
+
+/* Return non-zero if this control is of type VALUE64.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_value64(u32 id)
+{
+ return 0;
+}
+
+/* Return non-zero if this control is a pointer type. Currently only
+ * type STRING is a pointer type.
+ *
+ * This information is used inside v4l2_compat_ioctl32. */
+static int ctrl_is_pointer(u32 id)
+{
+ return 0;
+}
+
...
+ } else if (ctrl_is_value64(kctrl->id)) {
+ if (copy_in_user(&kctrl->value64, &uctrl->value64,
+sizeof(uctrl->value64)))
+ return -EFAULT;
...
+ if (ctrl_is_value64(kctrl->id)) {
+ if (copy_in_user(&uctrl->value64, &kctrl->value64,
+sizeof(uctrl->value64)))
+ return -EFAULT;
+ } else if (!ctrl_is_pointer(kctrl->id) &&
+ copy_in_user(&uctrl->value, &kctrl->value,
+sizeof(uctrl->value))) {
Why do you need two routines that will always return zero? Why to create a code
that will never be used? v4l2-compat-ioctl32.c is already complex enough
without adding any bogus code.
I noticed that you're also renaming the names of some fields there:
- struct v4l2_ext_control __user *ucontrols;
- struct v4l2_ext_control __user *kcontrols = kp->controls;
+ struct v4l2_ext_control __user *uctrl;
+ struct v4l2_ext_control __user *kctrl = kp->controls;
I dunno why you decided to do it, but having this together with the changes at
v4l2-compat-ioctl32.c makes the code even harder to understand. Could you
please move the v4l2-compat-ioctl32 "cosmetic" changes like above into a
separate patch?
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
How to efficiently handle DMA and cache on ARMv7 ? (was "Is get_user_pages() enough to prevent pages from being swapped out ?")
[Resent with an updated subject, this time CC'ing linux-arm-kernel] I've spent the last few days "playing" with get_user_pages() and mlock() and got some interesting results. It turned out that cache coherency comes into play at some point, making the overall problem more complex. Here's my current setup: - OMAP processor, based on an ARMv7 core - MMU and IOMMU - VIPT non-aliasing data cache - video capture driver that transfers data to memory using DMA - video capture application that pass userspace pointers to video buffers to the driver My goal is to make sure that, upon DMA completion, the correct data will be available to the userspace application. The first problem was to pin pages to memory, to make sure they will not be freed when the DMA is in progress. videobug-dma-sg uses get_user_pages() for that, and Hugh Dickins nicely explained to me why this is enough. The second problem is to ensure cache coherency. As the userspace application will read data from the video buffers, those buffers will end up being cached in the processor's data cache. The driver does need to invalidate the cache before starting the DMA operation (userspace could in theory write to the buffers, but the data will be overwritten by DMA anyway, so there's no need to clean the cache). As the cache is of the VIPT (Virtual Index Physical Tag) type, cache invalidation can either be done globally (in which case the cache is flushed instead of being invalidated) or based on virtual addresses. In the last case the processor will need to look physical addresses up, either in the TLB or through hardware table walk. I can see three solutions to the DMA/cache problem. 1. Flushing the whole data cache right before starting the DMA transfer. There's no API for that in the ARM architecture, so a whole I+D cache is required. This is quite costly, we're talking about around 30 flushes per second, but it doesn't involve the MMU. That's the solution that I currently use. 2. Invalidating only the cache lines that store video buffer data. This requires a TLB lookup or a hardware table walk, so the userspace application MM context needs to be available (no problem there as where's flushing in userspace context) and all pages need to be mapped properly. This can be a problem as, as Hugh pointed out, pages can still be unmapped from the userspace context after get_user_pages() returns. I have experienced one oops due to a kernel paging request failure: Unable to handle kernel paging request at virtual address 44e12000 pgd = c8698000 [44e12000] *pgd=8a4fd031, *pte=8cfda1cd, *ppte= Internal error: Oops: 817 [#1] PREEMPT PC is at v7_dma_inv_range+0x2c/0x44 Fixing this requires more investigation, and I'm not sure how to proceed to find out if the page fault is really caused by pages being unmapped from the userspace context. Help would be appreciated. 3. Mark the pages as non-cacheable. Depending on how the buffers are then used by userspace, the additional cache misses might destroy any benefit I would get from not flushing the cache before DMA. I'm not sure how to mark a bunch of pages as non-cacheable though. What usually happens is that video drivers allocate DMA-coherent memory themselves, but in this case I need to deal with an arbitrary buffer allocated by userspace. If someone has any experience with this, it would be appreciated. Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Problem with OSPrey 240e
Hello, all: I'm new to capture card. I have a osprey 240e card. But I don't know how to make it work. I read the cardlist.bttv, there is no 240e in it. I modprobe bttv, and it can't recognise the card. Anyone knows how to do with it? Thanks all. yours hongqian -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Linux Plumbers Conference 2009: V4L2 API discussions
On Tue, Aug 4, 2009 at 4:12 PM, Hans Verkuil wrote: > Hi all, > > During this years Plumbers Conference I will be organizing a session (or > possibly more than one) on what sort of new V4L2 APIs are needed to > support the new SoC devices. These new APIs should also solve the problem > of how to find all the related alsa/fb/ir/dvb devices that a typical video > device might create. > > A proposal was made about a year ago (note that this is a bit outdated > by now, but the basics are still valid): > > http://www.archivum.info/video4linux-list%40redhat.com/2008-07/msg00371.html > > In the past year the v4l2 core has evolved enough so that we can finally > start thinking about this for real. > > I would like to know who will be attending this conference. I also urge > anyone who is working in this area and who wants to have a say in this to > attend the conference. The goal is to prepare a new RFC with a detailed > proposal on the new APIs that are needed to fully support all the new > SoCs. So the more input we get, the better the end-result will be. > > Early-bird registration is still possible up to August 5th (that's > tomorrow :-) ). > > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom > I've been hardly trying to attend the conference but I'm afraid not gonna make it. But going to try to arrange the characteristics of the H/W I'm working on in a brief document and also expected new V4P2 APIs. I'll let you know when I finish my documentation. I know this is a good chance to discuss about where the video4linux for SoC platforms to go and I'm desperately looking forward to participate. but my business trip depends on the approval of my boss. Thus I'm very disappointed that I can't make it. Cheers, Nate -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media & Communications R&D Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.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
