Re: [GIT PATCHES FOR 2.6.37] BKL removal patch series
On Friday, November 26, 2010 18:41:32 Laurent Pinchart wrote: Hi Hans, On Friday 26 November 2010 11:09:38 Hans Verkuil wrote: Changes since the last patch series: - Fix a race condition between video_unregister_device and v4l2_open. - Return -ERESTART if the mutex_lock_interruptible returns non-zero. What's the difference between ERESTART and ERESTARTSYS ? Grrr, I picked the wrong one. I respun my tree, now using ERESTARTSYS. Thanks for catching this! Regards, Hans - Return POLLERR|POLLHUP when poll is used on an unregistered device. -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v2.6.38] [media] [FOR, 2.6.37] Revert V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit
On Friday, November 26, 2010 21:41:02 Mauro Carvalho Chehab wrote: This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] [FOR, 2.6.37] Revert V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit Author: Laurent Pinchart laurent.pinch...@ideasonboard.com Date:Mon Nov 22 07:21:27 2010 -0300 Removing the mutex_lock/unlock around clear_bit allowed device_unregister() to race with v4l2_open(). The device can be unregistered between the video_devdata() and video_get() calls. Revert the patch to fix the problem. This reverts commit dd0daf2a6fb6bec436a3ef68bd585ea09a2a54b7. Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hverk...@xs4all.nl Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com Hmm, this shouldn't have been applied. The full fix for this race is in my BKL removal tree for 2.6.37. Regards, Hans drivers/media/video/v4l2-dev.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=a287789447cecc7a82ffc4451cbaf16a5c1dccc0 diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 03f7f46..f777da6 100644 --- a/drivers/media/video/v4l2-dev.c +++ b/drivers/media/video/v4l2-dev.c @@ -596,7 +596,9 @@ void video_unregister_device(struct video_device *vdev) if (!vdev || !video_is_registered(vdev)) return; + mutex_lock(videodev_lock); clear_bit(V4L2_FL_REGISTERED, vdev-flags); + mutex_unlock(videodev_lock); device_unregister(vdev-dev); } EXPORT_SYMBOL(video_unregister_device); -- Hans Verkuil - video4linux developer - sponsored by Cisco -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ngene Satix-S2 dual problems
On 21/11/2010 19:48, Robert Longbottom wrote: On 21/11/2010 19:23, Andre wrote: On 21 Nov 2010, at 17:23, Robert Longbottom wrote: Oh, I also get the three extra dvb adapters, in my case 1,2 3. (I already have two other dvb cards in this box that take 0 and 4) Thats using these module parameters: That's definitely odd, it's the ngene that's generating them not any of the other cards I have. I just managed to get everything to fit in the default 8 adaptors, I can't use one_adaptor=1 as dvbloopback doesn't work with that. Yes, it's definitely ngene thats creating them, because if I rmmod it, then they dissapear. My other two cards use other drivers. The extra nodes seem to be a harmless oddity and this driver is a massive improvement, big thank you to Oliver. Indeed, they don't seem to break anything or stop the Satix card from working. And yes, this driver is a massive improvement in terms of being able to use both tuners. Report back in a few days, my system records ~ 10 hours of HD a day, small percentage of which I actually watch so it should get a workout. I've run a few tests this evening with MythTv recording up to 6 simultaneous programs across the two tuners on the Satix and it seems to be holding up so far. A mixture of SD and HD. It did have a couple of instances where it didn't immediately get a lock on a couple of channels when I was surfing livetv, but I'm willing to put that down to just bedding in for now. I'm just debating whether to leave it as the active card and see how it gets on. Assuming it manages this evenings recordings ok, I think I will probably will. Well, I did leave it as the active (and only) card in my MythTV box and it's been working fine for a week now doing my usual recording schedule across both inputs. I've not seen any failed recordings, or any problems with the recordings it's made. So it seems that it is working fine now. I still have the problem with the additional dvb adapters, but they don't seem to be causing a problem so far as I can tell. Thanks go to Oliver for these drivers - hopefully we can see these changes in the kernel sometime soon :-) Robert. -- 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][Update_for_2.6.38] DM04/QQBOX Frontend attach change.
Driver Version v1.73 - Frontend attach change.
To stop double rc registration in multi tuner environment or firmware change.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index 1455c23..dc3172f 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -584,6 +584,7 @@ static int lme2510_int_service(struct dvb_usb_adapter *adap)
ret = lme2510_int_read(adap);
if (ret 0) {
rc_unregister_device(rc);
+ info(INT Unable to start Interupt Service);
return -ENODEV;
}
@@ -674,7 +675,7 @@ static void lme_coldreset(struct usb_device *dev)
return;
}
-static void lme_firmware_switch(struct usb_device *udev, int cold)
+static int lme_firmware_switch(struct usb_device *udev, int cold)
{
const struct firmware *fw = NULL;
char lme2510c_s7395[] = dvb-usb-lme2510c-s7395.fw;
@@ -685,7 +686,7 @@ static void lme_firmware_switch(struct usb_device *udev,
int cold)
cold = (cold 0) ? (cold 1) : 0;
if (udev-descriptor.idProduct == 0x1122)
- return;
+ return 0;
switch (dvb_usb_lme2510_firmware) {
case 0:
@@ -715,10 +716,12 @@ static void lme_firmware_switch(struct usb_device *udev,
int cold)
release_firmware(fw);
- if (cold)
+ if (cold) {
lme_coldreset(udev);
+ return -ENODEV;
+ }
- return;
+ return ret;
}
static int lme2510_kill_urb(struct usb_data_stream *stream)
@@ -786,45 +789,43 @@ static int dm04_lme2510_set_voltage(struct dvb_frontend
*fe,
return (ret 0) ? -ENODEV : 0;
}
+static int lme_name(struct dvb_usb_adapter *adap)
+{
+ struct lme2510_state *st = adap-dev-priv;
+ const char *desc = adap-dev-desc-name;
+ char *fe_name[] = {, LG TDQY-P001F, SHARP:BS2F7HZ7395};
+ char *name = adap-fe-ops.info.name;
+
+ strcpy(name, desc);
+ strcat(name, fe_name[st-tuner_config]);
+
+ return 0;
+}
+
static int dm04_lme2510_frontend_attach(struct dvb_usb_adapter *adap)
{
- int ret = 0;
struct lme2510_state *st = adap-dev-priv;
- /* Interupt Start */
- ret = lme2510_int_service(adap);
- if (ret 0) {
- info(INT Unable to start Interupt Service);
- return -ENODEV;
- }
+ int ret = 0;
st-i2c_talk_onoff = 1;
- st-i2c_gate = 4;
+ st-i2c_gate = 4;
adap-fe = dvb_attach(tda10086_attach, tda10086_config,
adap-dev-i2c_adap);
if (adap-fe) {
info(TUN Found Frontend TDA10086);
- memcpy(adap-fe-ops.info.name,
- DM04_LG_TDQY-P001F DVB-S, 24);
- adap-fe-ops.set_voltage = dm04_lme2510_set_voltage;
st-i2c_tuner_gate_w = 4;
st-i2c_tuner_gate_r = 4;
st-i2c_tuner_addr = 0xc0;
- if (dvb_attach(tda826x_attach, adap-fe, 0xc0,
- adap-dev-i2c_adap, 1)) {
- info(TUN TDA8263 Found);
- st-tuner_config = TUNER_LG;
- if (dvb_usb_lme2510_firmware != 1) {
- dvb_usb_lme2510_firmware = 1;
- lme_firmware_switch(adap-dev-udev, 1);
- } else /*stops LG/Sharp multi tuner problems*/
- dvb_usb_lme2510_firmware = 0;
- return 0;
- }
- kfree(adap-fe);
- adap-fe = NULL;
+ st-tuner_config = TUNER_LG;
+ if (dvb_usb_lme2510_firmware != 1) {
+ dvb_usb_lme2510_firmware = 1;
+ ret = lme_firmware_switch(adap-dev-udev, 1);
+ } else /*stops LG/Sharp multi tuner problems*/
+ dvb_usb_lme2510_firmware = 0;
+ goto end;
}
st-i2c_gate = 5;
@@ -833,28 +834,64 @@ static int dm04_lme2510_frontend_attach(struct
dvb_usb_adapter *adap)
if (adap-fe) {
info(FE Found Stv0288);
- memcpy(adap-fe-ops.info.name,
- DM04_SHARP:BS2F7HZ7395, 22);
- adap-fe-ops.set_voltage = dm04_lme2510_set_voltage;
st-i2c_tuner_gate_w = 4;
st-i2c_tuner_gate_r = 5;
st-i2c_tuner_addr = 0xc0;
- if (dvb_attach(ix2505v_attach , adap-fe, lme_tuner,
- adap-dev-i2c_adap)) {
- st-tuner_config = TUNER_S7395;
- info(TUN Sharp IX2505V silicon tuner);
- if (dvb_usb_lme2510_firmware != 0) {
- dvb_usb_lme2510_firmware = 0;
-
Re: [PATCH v2 0/6] davinci vpbe: display driver for DM644X
Manjunath, Could you re-send the patch 1/6? I can't find it either at my inbox or mailing list. On Wed, Nov 24, 2010 at 9:08 AM, Manjunath Hadli manjunath.ha...@ti.com wrote: This driver is written for Texas Instruments's DM644X VPBE IP. This SoC supports 2 video planes and 2 OSD planes as part of its OSD (On Screen Display) block. At present, the patches conatin the basic support of DM644X V4L2 driver, and subsequent patch sets would add support for external encoders,other DMXXX family SoC and fbdev support. VPBE V4L2 driver design == File partitioning - V4L2 display device driver drivers/media/video/davinci/vpbe_display.c drivers/media/video/davinci/vpbe_display.h VPBE display controller drivers/media/video/davinci/vpbe.c drivers/media/video/davinci/vpbe.h VPBE venc sub device driver drivers/media/video/davinci/vpbe_venc.c drivers/media/video/davinci/vpbe_venc.h drivers/media/video/davinci/vpbe_venc_regs.h VPBE osd driver drivers/media/video/davinci/vpbe_osd.c drivers/media/video/davinci/vpbe_osd.h drivers/media/video/davinci/vpbe_osd_regs.h Functional partitioning --- Consists of following (in the same order as the list under file partitioning):- 1. V4L2 display driver Implements video2 and video3 device nodes and provides v4l2 device interface to manage VID0 and VID1 layers. 2. Display controller Loads up venc, osd and external encoders such as ths8200. It provides a set of API calls to V4L2 drivers to set the output/standards in the venc or external sub devices. It also provides a device object to access the services from osd sub device using sub device ops. The connection of external encoders to venc LCD controller port is done at init time based on default output and standard selection or at run time when application change the output through V4L2 IOCTLs. When connetected to an external encoder, vpbe controller is also responsible for setting up the interface between venc and external encoders based on board specific settings (specified in board-xxx-evm.c). This allowes interfacing external encoders such as ths8200. The setup_if_config() is implemented for this as well as configure_venc() (part of the next patch) API to set timings in venc for a specific display resolution.As of this patch series, the interconnection and enabling ans setting of the external encoders is not present, and would be a part of the next patch series. 3. Venc sub device Responsible for setting outputs provides through internal dacs and also setting timings at LCD controller port when external encoders are connected at the port or LCD panel timings required. When external encoder/LCD panel is connected, the timings for a specific standard/preset is retrieved from the board specific table and the values are used to set the timings in venc using non-standard timing mode. Support LCD Panel displays using the venc. For example to support a Logic PD display, it requires setting up the LCD controller port with a set of timings for the resolution supported and setting the dot clock. So we could add the available outputs as a board specific entry ( i.e add the LogicPD output name to board-xxx-evm.c). A table of timings for various LCDs supported cab be maintained in the board specific setup file to support various LCD displays. 4. osd sub device Osd sub device implements all osd layer management and hardware specific features. In the legacy drivers (LSPxxx), the hardware specific features are configured through proprietary IOCTLs at the fb device interface. Since sub devices are going to support device nodes, application will be able to configure the hardware feayture directly by opening the osd sub device node and by calling the related IOCTL. So these proprietary IOCTLs are to be removed from the FB Device driver when doing up port of these drivers to mainline kernel. The V4L2 and FB device nodes supports only IOCTLS as per the associated spec. The rest of the IOCTLs are to be moved to osd and venc sub devices. Current status:- A build tested version of vpbe controller is available. Following are TBDs. vpbe display controller - review and modify the handling of external encoders. - add support for selecting external encoder as default at probe time. vpbe venc sub device - add timings for supporting ths8200 - add support for LogicPD LCD. v4l2 driver - A version is already developed which is to be cleaned up and unit tested FB drivers - Add support for fbdev drivers.- Ready and part of subsequent patches. Manjunath Hadli (6): davinci vpbe: V4L2 display driver for DM644X SoC davinci vpbe: VPBE display driver davinci vpbe: OSD(On Screen
Re: [PATCH v2 5/6] davinci vpbe: platform specific additions
+static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode)
+{
+ unsigned int val = 0;
+ int ret = 0;
+
+ switch (pixcode) {
+ case V4L2_MBUS_FMT_FIXED:
+ /* Analog out.do nothing */
+ break;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ /* BT656 */
+ val = (112);
+ /*set VDMD in VMOD */
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ /* Set YCCTL */
+ dm644x_reg_modify(venc_ycctl_reg, 1, 1);
+ break;
+ case V4L2_MBUS_FMT_YUYV10_1X20:
+ /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum accordingly
+ * when the right one gets into open source */
+ val = 0 12;
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ dm644x_reg_modify(venc_ycctl_reg, 1, 1);
+ break;
+ case V4L2_MBUS_FMT_SGRBG8_1X8:
+ /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum accordingly
+ * when the right one gets into open source */
+ val = 2 12;
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
The media bus format was added to sub device interface sometime back
to configure the media data format (8 bit, 16 bit etc) and there is
also a set of APIs to set the pad configuration (done by Laurent)
which is being reviewed. In the context of that, I believe the venc
VMOD configuration can be handled by implementing s_mbus_fmt() sub
device API at venc. Currently OSD sub device has set_layer_config()
which consists of setting the pixel format, frame format and
sub-frame(crop). I think this can be replaced by s_mbus_fmt(). So on a
board file, we could define the pad configuration which will include
the mbus code such as V4L2_MBUS_FMT_YUYV8_2X8 + addition pad
configurations such as embedded sync enabled etc. So once sub device
is selected, vpbe controller will set the pad configuration (obtained
from board file for each of the ?). The pad in this case is the link
between venc lcd port to external encoder. When S_FMT/S_CROP is called
on the video node, the controller calls s_mbus_fmt() on the osd and
venc sub device to set the mbus formats.
Since the external encoder support is a TBD, I am okay if you
implement this after this patch series is merged to the tree.
Murali
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01C72400,
+ .end = 0x01C72400 + 0x180,
+ .flags = IORESOURCE_MEM,
+ },
+
+};
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_pinmux = dm644x_vpbe_setup_pinmux,
+ .setup_clock = dm644x_venc_setup_clock,
+ .setup_if_config = dm644x_set_if_config,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
+ .resource = dm644x_venc_resources,
+ .dev = {
+ .dma_mask = dm644x_venc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = (void *)dm644x_venc_pdata,
+ },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
+ .name = vpbe_controller,
+ .id = -1,
+ .dev = {
+ .dma_mask = dm644x_vpbe_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+void dm644x_set_vpbe_display_config(struct vpbe_display_config *cfg)
+{
+ dm644x_vpbe_dev.dev.platform_data = cfg;
+}
+
/*--*/
static struct map_desc dm644x_io_desc[] = {
@@ -767,20 +977,36 @@ void __init dm644x_init(void)
davinci_common_init(davinci_soc_info_dm644x);
}
+static struct platform_device *dm644x_video_devices[] __initdata = {
+ dm644x_vpss_device,
+ dm644x_ccdc_dev,
+ vpfe_capture_dev,
+ dm644x_osd_dev,
+ dm644x_venc_dev,
+
Re: [PATCH v2 5/6] davinci vpbe: platform specific additions
Just want to add one more point. Probably it is a good idea to keep
this function in venc. Why this function has to be platform specific?
On Sat, Nov 27, 2010 at 10:22 AM, Muralidharan Karicheri
mkarich...@gmail.com wrote:
+static int dm644x_set_if_config(enum v4l2_mbus_pixelcode pixcode)
+{
+ unsigned int val = 0;
+ int ret = 0;
+
+ switch (pixcode) {
+ case V4L2_MBUS_FMT_FIXED:
+ /* Analog out.do nothing */
+ break;
+ case V4L2_MBUS_FMT_YUYV8_2X8:
+ /* BT656 */
+ val = (112);
+ /*set VDMD in VMOD */
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ /* Set YCCTL */
+ dm644x_reg_modify(venc_ycctl_reg, 1, 1);
+ break;
+ case V4L2_MBUS_FMT_YUYV10_1X20:
+ /* This was VPBE_DIGITAL_IF_YCC16.BT656.Replace the enum accordingly
+ * when the right one gets into open source */
+ val = 0 12;
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ dm644x_reg_modify(venc_ycctl_reg, 1, 1);
+ break;
+ case V4L2_MBUS_FMT_SGRBG8_1X8:
+ /* This was VPBE_DIGITAL_IF_PRGB/SRGB.Replace the enum accordingly
+ * when the right one gets into open source */
+ val = 2 12;
+ dm644x_reg_modify(venc_vmod_reg, val, (7 12));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+ return ret;
+}
The media bus format was added to sub device interface sometime back
to configure the media data format (8 bit, 16 bit etc) and there is
also a set of APIs to set the pad configuration (done by Laurent)
which is being reviewed. In the context of that, I believe the venc
VMOD configuration can be handled by implementing s_mbus_fmt() sub
device API at venc. Currently OSD sub device has set_layer_config()
which consists of setting the pixel format, frame format and
sub-frame(crop). I think this can be replaced by s_mbus_fmt(). So on a
board file, we could define the pad configuration which will include
the mbus code such as V4L2_MBUS_FMT_YUYV8_2X8 + addition pad
configurations such as embedded sync enabled etc. So once sub device
is selected, vpbe controller will set the pad configuration (obtained
from board file for each of the ?). The pad in this case is the link
between venc lcd port to external encoder. When S_FMT/S_CROP is called
on the video node, the controller calls s_mbus_fmt() on the osd and
venc sub device to set the mbus formats.
Since the external encoder support is a TBD, I am okay if you
implement this after this patch series is merged to the tree.
Murali
+
+static u64 vpbe_display_dma_mask = DMA_BIT_MASK(32);
+
+static struct resource dm644x_v4l2_disp_resources[] = {
+ {
+ .start = IRQ_VENCINT,
+ .end = IRQ_VENCINT,
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .start = 0x01C72400,
+ .end = 0x01C72400 + 0x180,
+ .flags = IORESOURCE_MEM,
+ },
+
+};
+static struct platform_device vpbe_v4l2_display = {
+ .name = vpbe-v4l2,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_v4l2_disp_resources),
+ .resource = dm644x_v4l2_disp_resources,
+ .dev = {
+ .dma_mask = vpbe_display_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+struct venc_platform_data dm644x_venc_pdata = {
+ .venc_type = DM644X_VPBE,
+ .setup_pinmux = dm644x_vpbe_setup_pinmux,
+ .setup_clock = dm644x_venc_setup_clock,
+ .setup_if_config = dm644x_set_if_config,
+};
+
+static struct platform_device dm644x_venc_dev = {
+ .name = VPBE_VENC_SUBDEV_NAME,
+ .id = -1,
+ .num_resources = ARRAY_SIZE(dm644x_venc_resources),
+ .resource = dm644x_venc_resources,
+ .dev = {
+ .dma_mask = dm644x_venc_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = (void *)dm644x_venc_pdata,
+ },
+};
+
+static u64 dm644x_vpbe_dma_mask = DMA_BIT_MASK(32);
+
+static struct platform_device dm644x_vpbe_dev = {
+ .name = vpbe_controller,
+ .id = -1,
+ .dev = {
+ .dma_mask = dm644x_vpbe_dma_mask,
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ },
+};
+
+void dm644x_set_vpbe_display_config(struct vpbe_display_config *cfg)
+{
+ dm644x_vpbe_dev.dev.platform_data = cfg;
+}
+
/*--*/
static struct map_desc dm644x_io_desc[] = {
@@ -767,20 +977,36 @@ void __init dm644x_init(void)
Problems with using dvb_usb_rtl2832u
Hi I am using this driver with USB 1b80:s395 Modules load scandvb gets channels /dev/dvb gets created dvbtune seems to tune to transponder however none of the other dvb utilities seem to work ie: dvbdate dvbsnoop (except forfeinfo) dvbtraffic dvbstream example dvbsnoop -s feinfo dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: Realtek RTL2832 DVB-T RTL2836 DTMB Frontend-type: OFDM (DVB-T) Frequency (min): 174000.000 kHz Frequency (max): 862000.000 kHz Frequency stepsiz: 166.667 kHz Frequency tolerance: 0.000 kHz Symbol rate (min): 0.00 MSym/s Symbol rate (max): 0.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QPSK QAM 16 QAM 64 QAM AUTO auto transmission mode auto guard interval auto hierarchy Current parameters: Frequency: 497833.000 kHz Inversion: OFF Bandwidth: 8 MHz Stream code rate (hi prio): FEC 2/3 Stream code rate (lo prio): FEC AUTO Modulation: QAM 64 Transmission mode: 2k mode Guard interval: 1/32 Hierarchy: none dvbdate . dvbdate: timeout - try tuning to a multiplex? dvbdate: Unable to get time from multiplex. any ideas? -- 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
Problems with using dvb_usb_rtl2832u
Hi I am using this driver with USB 1b80:s395 Modules load scandvb gets channels /dev/dvb gets created dvbtune seems to tune to transponder however none of the other dvb utilities seem to work ie: dvbdate dvbsnoop (except forfeinfo) dvbtraffic dvbstream example dvbsnoop -s feinfo dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/ - FrontEnd Info... - Device: /dev/dvb/adapter0/frontend0 Basic capabilities: Name: Realtek RTL2832 DVB-T RTL2836 DTMB Frontend-type: OFDM (DVB-T) Frequency (min): 174000.000 kHz Frequency (max): 862000.000 kHz Frequency stepsiz: 166.667 kHz Frequency tolerance: 0.000 kHz Symbol rate (min): 0.00 MSym/s Symbol rate (max): 0.00 MSym/s Symbol rate tolerance: 0 ppm Notifier delay: 0 ms Frontend capabilities: auto inversion FEC 1/2 FEC 2/3 FEC 3/4 FEC 5/6 FEC 7/8 FEC AUTO QPSK QAM 16 QAM 64 QAM AUTO auto transmission mode auto guard interval auto hierarchy Current parameters: Frequency: 497833.000 kHz Inversion: OFF Bandwidth: 8 MHz Stream code rate (hi prio): FEC 2/3 Stream code rate (lo prio): FEC AUTO Modulation: QAM 64 Transmission mode: 2k mode Guard interval: 1/32 Hierarchy: none dvbdate . dvbdate: timeout - try tuning to a multiplex? dvbdate: Unable to get time from multiplex. any ideas? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Problems with using dvb_usb_rtl2832u
On 27 November 2010 16:33, Anca Emanuel anca.eman...@gmail.com wrote: On Sat, Nov 27, 2010 at 6:14 PM, Mike Martin redt...@gmail.com wrote: Hi I am using this driver with USB 1b80:s395 It's not possible to be s395, please send what lsusb prints. And if you have other info, like the product info, etc. sorry typo 1b80:d395 -- 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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid ATSC (17de:a134) Are you sure you don't mean the PC120-U ? -- I can't find such a product. A PC150-U model, on the other hand I see the drivers for both TDA18271HDC2 and TDA8290 loaded. I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is the digital channel decoder different from the digital tuner?? Should be looking for a different chip? they are detected by chip IDs. The tda8290 is the IF demodulator for global analog TV. In case of the saa7135 it is an extra chip on the PCB, which most often can also control the tuner over an i2c gate. The tda18271hdc2 is a global hybrid tuner for analog and digital terrestrial TV. It can also provide a FM radio IF. Further processing and stereo separation for that is done on capable bridges like saa7133/35/31e, not on the tda 8290. Yes, for any terrestrial digital TV you need an extra channel decoder and all known details about it. http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards In case of terrestrial ATSC, it must be able to deal with 8VSB modulation. From the pics on newegg ( http://www.newegg.com/Product/Product.aspx?Item=N82E16815260032 ), it appears that they have used a Samsung demodulator -- 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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
Yes. Typo. It's a PC150-U.
I found the digital decoder. It's a Samsung s5h1411.
Unfortunately no saa7134 card uses s5h1411, so I'm trying to copy come
code from a saa7164 card. But my C coding skills are very very
limited.
I currently trying to play around with these (copied from a saa7164
card!). I don't know if I'm in the right direction or not!
static struct s5h1411_config kworld_s5h1411_config = {
.output_mode = S5H1411_SERIAL_OUTPUT,
.gpio = S5H1411_GPIO_ON,
.qam_if= S5H1411_IF_4000,
.vsb_if= S5H1411_IF_3250,
.inversion = S5H1411_INVERSION_ON,
.status_mode = S5H1411_DEMODLOCKING,
.mpeg_timing = S5H1411_MPEGTIMING_CONTINOUS_NONINVERTING_CLOCK,
};
Hooman
On Sat, Nov 27, 2010 at 12:14 PM, CityK ci...@rogers.com wrote:
I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid
ATSC (17de:a134)
Are you sure you don't mean the PC120-U ? -- I can't find such a product.
A PC150-U model, on the other hand
I see the drivers for both TDA18271HDC2 and TDA8290 loaded.
I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is
the digital channel decoder different from the digital tuner??
Should be looking for a different chip?
they are detected by chip IDs.
The tda8290 is the IF demodulator for global analog TV.
In case of the saa7135 it is an extra chip on the PCB, which most often
can also control the tuner over an i2c gate.
The tda18271hdc2 is a global hybrid tuner for analog and digital
terrestrial TV. It can also provide a FM radio IF. Further processing
and stereo separation for that is done on capable bridges like
saa7133/35/31e, not on the tda 8290.
Yes, for any terrestrial digital TV you need an extra channel decoder
and all known details about it.
http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards
In case of terrestrial ATSC, it must be able to deal with 8VSB
modulation.
From the pics on newegg (
http://www.newegg.com/Product/Product.aspx?Item=N82E16815260032 ), it
appears that they have used a Samsung demodulator
--
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: WARNINGS
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:Sat Nov 27 19:00:27 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: tuner demodulator: Montage versus STMicroelectronics
On Saturday 27 November 2010 03:12:32 Zbigniew Luszpinski wrote: Hello, I'm going to buy my first DVB-S2 USB tuner. I see that there are two best demod/tuner solutions: 1. Montage Technology M88TS2020/2 tuner and M88DS3000/2 demodulator 2. STMicroelectronics STB6100 tuner and STV0903BAC demodulator Can you please tell me which is better for Linux user like me (STM or Montage)? I haven't seen a driver for Montage in v4l-dvb.git, so your best choise is to go with the STV0903. But then it also depends whether the USB part of your device is supported already or not. What device are you think about? regards, -- Patrick -- 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: ATSC Tuner in KWorld PC120-U PCI Hybrid ATSC (17de:a134)
More precisely I call:
fe0-dvb.frontend = dvb_attach(s5h1411_attach,
kworld_s5h1411_config,
dev-i2c_adap);
Where kworld_s5h1411_config is:
static struct s5h1411_config kworld_s5h1411_config = {
.output_mode = S5H1411_SERIAL_OUTPUT,
.gpio = S5H1411_GPIO_ON,
.qam_if= S5H1411_IF_4000,
.vsb_if= S5H1411_IF_3250,
.inversion = S5H1411_INVERSION_ON,
.status_mode = S5H1411_DEMODLOCKING,
.mpeg_timing =
S5H1411_MPEGTIMING_CONTINOUS_NONINVERTING_CLOCK,
};
But fe0-dvb.frontend is null:
[ 318.881811] WARNING: You're using an experimental version of the
DVB stack. As the driver
[ 318.881818] is backported to an older kernel, it doesn't
offer enough quality for
[ 318.881824] its usage in production.
[ 318.881827] Use it with care.
[ 318.910782] dvb_init() allocating 1 frontend
[ 319.132737] s5h1411_readreg: readreg error (ret == -5)
[ 319.133113] saa7133[0]/dvb: frontend initialization failed
On Sat, Nov 27, 2010 at 12:49 PM, Hooman B. li...@hoomanb.com wrote:
Yes. Typo. It's a PC150-U.
I found the digital decoder. It's a Samsung s5h1411.
Unfortunately no saa7134 card uses s5h1411, so I'm trying to copy come
code from a saa7164 card. But my C coding skills are very very
limited.
I currently trying to play around with these (copied from a saa7164
card!). I don't know if I'm in the right direction or not!
static struct s5h1411_config kworld_s5h1411_config = {
.output_mode = S5H1411_SERIAL_OUTPUT,
.gpio = S5H1411_GPIO_ON,
.qam_if = S5H1411_IF_4000,
.vsb_if = S5H1411_IF_3250,
.inversion = S5H1411_INVERSION_ON,
.status_mode = S5H1411_DEMODLOCKING,
.mpeg_timing = S5H1411_MPEGTIMING_CONTINOUS_NONINVERTING_CLOCK,
};
Hooman
On Sat, Nov 27, 2010 at 12:14 PM, CityK ci...@rogers.com wrote:
I've been trying to get the ATSC tuner in my KWorld PC120-U PCI Hybrid
ATSC (17de:a134)
Are you sure you don't mean the PC120-U ? -- I can't find such a product.
A PC150-U model, on the other hand
I see the drivers for both TDA18271HDC2 and TDA8290 loaded.
I thought TDA18271HDC2 was the digital channel decoder, isn't it? Is
the digital channel decoder different from the digital tuner??
Should be looking for a different chip?
they are detected by chip IDs.
The tda8290 is the IF demodulator for global analog TV.
In case of the saa7135 it is an extra chip on the PCB, which most often
can also control the tuner over an i2c gate.
The tda18271hdc2 is a global hybrid tuner for analog and digital
terrestrial TV. It can also provide a FM radio IF. Further processing
and stereo separation for that is done on capable bridges like
saa7133/35/31e, not on the tda 8290.
Yes, for any terrestrial digital TV you need an extra channel decoder
and all known details about it.
http://linuxtv.org/wiki/index.php/Category:ATSC_PCI_Cards
In case of terrestrial ATSC, it must be able to deal with 8VSB
modulation.
From the pics on newegg (
http://www.newegg.com/Product/Product.aspx?Item=N82E16815260032 ), it
appears that they have used a Samsung demodulator
--
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
gnutv: move channel_name to flag to allow piped output
I need to capture ATSC QAM closed captioning to file, and at the same
time the mpeg-ts stream to a different file. I've been looking for an
app that will let me do this.
A simple cat works:
cat /dev/dvb/adapter0/dvr0 | tee $FIL.mpg | zvbi-atsc-cc --atsc -m -C
$FIL.txt -T KCBS
But there is naturally no tuner or timer in cat, so closing the
processes at the end of the recording is a hassle; there may be other
issues cat doesn't handle optimally. I looked around and found gnutv in
the dvb-apps project.
gnutv is actively maintained, tunes ATSC QAM-256, handles individual
channels well, and has a timer -- but it has a small, show-stopper problem.
gnutv mandates that the channel name be placed at the end of the user
input. There is a great -out stdout option, but you can't use it to
pipe, since the channel name has to be placed afterwards.
I suggest we move the channel name into a flag, like the other user
values, so that we can pipe the output like this:
gnutv -adapter 0 -channel_list ~/.azap/channels.conf -timeout 10
-channel_name KCBS \
-out stdout | tee $FIL.mpg | zvbi-atsc-cc --atsc -T -9 $FIL.txt -n KCBS
With a simple patch against the today's mercurial tree, as below, this
works great. For clarity, I renamed channels to channels_list; I'll be
happy to remove that change if it breaks too many scripts. I don't know
how to make the change to channel_name so that it's backwardly
compatible, but maybe we don't need to.
Cheers,
Dave
--- gnutv.c2010-11-27 10:56:57.0 -0800
+++ gnutv-new.c2010-11-27 11:34:41.0 -0800
@@ -54,7 +54,8 @@
-frontend idfrontend to use (default 0)\n
-demux iddemux to use (default 0)\n
-caslotnum idca slot number to use (default 0)\n
- -channels filenamechannels.conf file.\n
+ -channel_list filenamechannels.conf file.\n
+ -channel_name name Name of the channel to tune to.\n
-secfile filenameOptional sec.conf file.\n
-secid secidID of the SEC configuration to use, one of:\n
* UNIVERSAL (default) - Europe, 10800 to 11800
MHz and 11600 to 12700 Mhz,\n
@@ -82,8 +83,7 @@
-timeout secsNumber of seconds to output channel for\n
(0=exit immediately after successful tuning,
default is to output forever)\n
-cammenuShow the CAM menu\n
- -nomovecaDo not attempt to move CA descriptors from
stream to programme level\n
- channel name\n;
+ -nomovecaDo not attempt to move CA descriptors from
stream to programme level\n;
fprintf(stderr, %s\n, _usage);
exit(1);
@@ -154,11 +154,16 @@
if (sscanf(argv[argpos+1], %i, caslot_num) != 1)
usage();
argpos+=2;
-} else if (!strcmp(argv[argpos], -channels)) {
+} else if (!strcmp(argv[argpos], -channel_list)) {
if ((argc - argpos) 2)
usage();
chanfile = argv[argpos+1];
argpos+=2;
+} else if (!strcmp(argv[argpos], -channel_name)) {
+if ((argc - argpos) 2)
+usage();
+channel_name = argv[argpos+1];
+argpos+=2;
} else if (!strcmp(argv[argpos], -secfile)) {
if ((argc - argpos) 2)
usage();
@@ -235,11 +240,6 @@
} else if (!strcmp(argv[argpos], -cammenu)) {
cammenu = 1;
argpos++;
-} else {
-if ((argc - argpos) != 1)
-usage();
-channel_name = argv[argpos];
-argpos++;
}
}
--
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
