Re: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Thu, Feb 19, 2015 at 11:06 AM, Sean Young s...@mess.org wrote:
On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote:
This patch adds support for the Vortex 1 PCIe card from Prospero
Technologies Ltd. The Vortex 1 supports up to 8 tuner modules and
currently ships with 8xDibcom 7090p tuners. The card also has raw
infra-red support and a hardware demuxer.
-snip-
diff --git a/drivers/media/pci/prospero/prospero_ir.c
b/drivers/media/pci/prospero/prospero_ir.c
new file mode 100644
index 000..01e5204
--- /dev/null
+++ b/drivers/media/pci/prospero/prospero_ir.c
@@ -0,0 +1,150 @@
+/*
+ * Infra-red driver for PCIe DVB cards from Prospero Technology Ltd.
+ *
+ * Copyright Prospero Technology Ltd. 2014
+ * Written/Maintained by Philip Downer
+ * Contact: pdow...@prospero-tech.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include media/rc-core.h
+#include prospero_ir.h
+
+#define DURATION_MASK 0x7
+#define PULSE_MASK 0x100
+#define FIFO_FILL_MASK 0xFF
+
+#define FIFO_FILL 0x60
+#define FIFO 0x64
+
+struct prospero_IR {
+ struct prospero_device *pdev;
+ struct rc_dev *dev;
+
+ int users;
The users field is never used.
+
+ char name[32];
+ char phys[32];
+};
+
+static int prospero_ir_open(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users++;
+ return 0;
+
+}
+
+static void prospero_ir_close(struct rc_dev *rc)
+{
+ struct prospero_device *p = rc-priv;
+
+ p-ir-users--;
+
+}
Since the users field is never read these functions are unnecessary and
can be removed.
+
+void ir_interrupt(struct prospero_pci *p_pci)
+{
+
+ struct prospero_device *p = p_pci-p_dev;
+ struct prospero_IR *ir = p-ir;
+ struct ir_raw_event ev;
+ int tmp = 0;
+ int fill = 0;
+ int pulse = 0;
+ int duration = 0;
+
+ pr_debug(Infra: Interrupt!\n);
+
+ tmp = ioread32(p_pci-io_mem + FIFO_FILL);
+ fill = tmp FIFO_FILL_MASK;
+
+ init_ir_raw_event(ev);
+
+ while (fill 0) {
+
+ pr_debug(Infra: fifo fill = %d\n, fill);
+
+ tmp = ioread32(p_pci-io_mem + FIFO);
+ pr_debug(Infra: raw dump = 0x%x\n, tmp);
+ pulse = (tmp PULSE_MASK) 24;
+ duration = (tmp DURATION_MASK) * 1000;/* Convert uS
to nS */
+
+ pr_debug(Infra: pulse = %d; duration = %d\n, pulse,
duration);
+
+ ev.pulse = pulse;
+ ev.duration = duration;
+ ir_raw_event_store_with_filter(ir-dev, ev);
+ fill--;
+ }
+ ir_raw_event_handle(ir-dev);
+
+}
+
+int prospero_ir_init(struct prospero_device *p)
+{
+
+ struct prospero_pci *p_pci = p-bus_specific;
+ struct pci_dev *pci = p_pci-pcidev;
+ struct prospero_IR *ir;
+ struct rc_dev *dev;
+ int err = -ENOMEM;
+
+ ir = kzalloc(sizeof(*ir), GFP_KERNEL);
+
+ dev = rc_allocate_device();
+
+ if (!ir || !dev)
+ goto err_out_free;
+
+ ir-dev = dev;
+
+ snprintf(ir-name, sizeof(ir-name), prospero IR);
+ snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci));
+
+ dev-input_name = ir-name;
+ dev-input_phys = ir-phys;
+ dev-input_id.bustype = BUS_PCI;
+ dev-input_id.version = 1;
+ dev-input_id.vendor = pci-vendor;
+ dev-input_id.product = pci-device;
+
+ dev-dev.parent = pci-dev;
+ dev-map_name = RC_MAP_LIRC;
+
+ dev-driver_name = prospero;
+ dev-priv = p;
+ dev-open = prospero_ir_open;
+ dev-close = prospero_ir_close;
+ dev-driver_type = RC_DRIVER_IR_RAW;
+ dev-timeout = 10 * 1000 * 1000;
If you know the rx_resolution, please provide it. The lirc interface
can query it.
+
+ iowrite32(0x12000, p_pci-io_mem + FIFO_FILL);
+
+ ir-pdev = p;
+ p-ir = ir;
+
+ err = rc_register_device(dev);
+ if (err)
+ goto err_out_free;
+
+ return 0;
+
+ err_out_free:
+ rc_free_device(dev);
+ p-ir = NULL;
+ kfree(ir);
+ return -ENOMEM;
+
+}
Thanks For your feedback Sean, I'll make those changes.
regards,
--
Philip Downer
pdow...@prospero-tech.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: [RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
On Thu, Feb 19, 2015 at 12:40 PM, Sean Young s...@mess.org wrote: On Mon, Feb 16, 2015 at 07:48:46PM +, Philip Downer wrote: -snip- + dev = rc_allocate_device(); + + if (!ir || !dev) + goto err_out_free; + + ir-dev = dev; + + snprintf(ir-name, sizeof(ir-name), prospero IR); + snprintf(ir-phys, sizeof(ir-phys), pci-%s/ir0, pci_name(pci)); + + dev-input_name = ir-name; + dev-input_phys = ir-phys; + dev-input_id.bustype = BUS_PCI; + dev-input_id.version = 1; + dev-input_id.vendor = pci-vendor; + dev-input_id.product = pci-device; + + dev-dev.parent = pci-dev; + dev-map_name = RC_MAP_LIRC; RC_MAP_LIRC isn't really a useful default; no remote will work with that. Other drivers default to RC_MAP_RC6_MCE if no remote was provided with the product. I don't know if this is good choice, but at least it is consistent. + + dev-driver_name = prospero; + dev-priv = p; + dev-open = prospero_ir_open; + dev-close = prospero_ir_close; + dev-driver_type = RC_DRIVER_IR_RAW; + dev-timeout = 10 * 1000 * 1000; There is a MS_TO_NS() macro for this. Ok, thanks Sean, those changes have been made and will be included when I submit the next RFC patch. Thanks again, -- Philip Downer +44 (0)7879 470 969 pdow...@prospero-tech.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: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Hi Antti, On Tue, Feb 17, 2015 at 7:14 PM, Antti Palosaari cr...@iki.fi wrote: On 02/17/2015 08:22 PM, Philip Downer wrote: Hi Mauro, On Mon, Feb 16, 2015 at 11:47 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Em Mon, 16 Feb 2015 22:01:07 +0200 Antti Palosaari cr...@iki.fi escreveu: Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. Yeah, creating one adapter per device is the best solution, if you can't do things like: frontend0 - demux2 - dvr5 Thanks for confirming what Antti said, I'll change the driver and resubmit it. Also, take care to fix issues to meet Kernel coding style and checkpatch.pl requirements where possible. Sure, I had pushed this patch through checkpatch and fixed most things, the only things I'm aware of that aren't fixed are line lengths and one section with too many nested statements. However I've read that line lengths are less of an issue these days in kernel code and the section with too many nested statements came from dibcom therefore I didn't want to refactor this, at least not without a lot of testing. Please let me know if I'm wrong in my assumptions or if I've missed something in generating this patch. -- Philip Downer pdow...@prospero-tech.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: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Hi Mauro, On Mon, Feb 16, 2015 at 11:47 PM, Mauro Carvalho Chehab mche...@osg.samsung.com wrote: Em Mon, 16 Feb 2015 22:01:07 +0200 Antti Palosaari cr...@iki.fi escreveu: Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. Yeah, creating one adapter per device is the best solution, if you can't do things like: frontend0 - demux2 - dvr5 Thanks for confirming what Antti said, I'll change the driver and resubmit it. If such configuration is allowed, then the best is to use the media controller API. The patches for it were just added. Yet, userspace programs are not aware, as this will be merged upstream only for Kernel 3.21. For now, the media controller API is still experimental. Yes, I saw your patches at the weekend, we're obviously quite interested in the media controller API for dvb so I'll be looking to add support for this to the driver when I can. Thanks. -- Philip Downer +44 (0)7879 470 969 pdow...@prospero-tech.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
[RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. I've tested this patch by applying it to current media-master and it applies cleanly and builds without issue for me. More information on the card can be found at: http://prospero-tech.com/vortex-1-dvb-t-pcie-card/ Regards, Philip Downer Philip Downer (1): [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd. drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c -- 2.1.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
[RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
This patch adds support for the Vortex 1 PCIe card from Prospero Technologies Ltd. The Vortex 1 supports up to 8 tuner modules and currently ships with 8xDibcom 7090p tuners. The card also has raw infra-red support and a hardware demuxer. Signed-off-by: Philip Downer pdow...@prospero-tech.com --- drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig index 218144a..5c7c356 100644 --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -46,6 +46,7 @@ source drivers/media/pci/pt3/Kconfig source drivers/media/pci/mantis/Kconfig source drivers/media/pci/ngene/Kconfig source drivers/media/pci/ddbridge/Kconfig +source drivers/media/pci/prospero/Kconfig source drivers/media/pci/smipcie/Kconfig endif diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile index 0baf0d2..d792604 100644 --- a/drivers/media/pci/Makefile +++ b/drivers/media/pci/Makefile @@ -11,6 +11,7 @@ obj-y+= ttpci/ \ mantis/ \ ngene/ \ ddbridge/ \ + prospero/ \ saa7146/\ smipcie/ @@ -26,4 +27,5 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_TW68) += tw68/ obj-$(CONFIG_VIDEO_MEYE) += meye/ obj-$(CONFIG_STA2X11_VIP) += sta2x11/ +obj-$(CONFIG_PROSPERO) += prospero/ obj-$(CONFIG_VIDEO_SOLO6X10) += solo6x10/ diff --git a/drivers/media/pci/prospero/Kconfig b/drivers/media/pci/prospero/Kconfig new file mode 100644 index 000..960f370 --- /dev/null +++ b/drivers/media/pci/prospero/Kconfig @@ -0,0 +1,7 @@ +config DVB_PROSPERO + tristate Prospero cards + depends on DVB_CORE PCI + help + Support for PCIe DVB-T cards from Prospero Technologies Ltd. + + Say Y or M if you own such a device and want to use it. diff --git a/drivers/media/pci/prospero/Makefile b/drivers/media/pci/prospero/Makefile new file mode 100644 index 000..ea35912 --- /dev/null +++ b/drivers/media/pci/prospero/Makefile @@ -0,0 +1,7 @@ +obj-m := prospero.o +prospero-objs := prospero_main.o prospero_fe_main.o prospero_i2c.o prospero_ir.o + +ccflags-y += -Idrivers/media/common/tuners +ccflags-y += -Idrivers/media/dvb-core +ccflags-y += -Idrivers/media/dvb-frontends +ccflags-y += -Idrivers/media/pci/prospero diff --git a/drivers/media/pci/prospero/prospero_common.h b/drivers/media/pci/prospero/prospero_common.h new file mode 100644 index 000..f8aece1 --- /dev/null +++ b/drivers/media/pci/prospero/prospero_common.h @@ -0,0 +1,264 @@ +#ifndef PROSPERO_COMMON + +#define PROSPERO_COMMON + +#include linux/init.h +#include linux/kernel.h +#include linux/module.h +#include linux/pci.h +#include linux/mutex.h +#include linux/dma-mapping.h +#include linux/firmware.h +#include linux/kobject.h +#include linux/list.h +#include linux/timer.h + +#include demux.h +#include dmxdev.h +#include dvb_demux.h +#include dvb_frontend.h +#include dvb_net.h +#include dvbdev.h + +#define MAXIMUM_NUM_OF_FE 8 + +#define MAX_NUM_OF_DEMUXS 8 +#define DEMUX_PER_FE 1 + +#define STREAMS_PER_DEMUX 30 + +#define MAX_STREAMS (STREAMS_PER_DEMUX * MAX_NUM_OF_DEMUXS) + +#define WILD_PID 0x2000 + +#define PROSPERO_REGISTER_BASE 0x000 + +#define PID_TABLE_START (PROSPERO_REGISTER_BASE + 0x4) + +#define I2C_RESETS (PROSPERO_REGISTER_BASE + 0x70) + +#define TS_CAP_ENABLE (PROSPERO_REGISTER_BASE + 0x74) + +#define INTERRUPT_ENABLE (PROSPERO_REGISTER_BASE + 0x78) +#define INTERRUPT_CONTROL (PROSPERO_REGISTER_BASE + 0x40) + +#define PID_TABLE_SLOT_SIZE 0x04 + +#define CONTROL_BITS_OFFSET 0x00 + +/*Control bit masks*/ +#define NULL_PACKET
Re: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Hi Antti, On Mon, Feb 16, 2015 at 8:01 PM, Antti Palosaari cr...@iki.fi wrote: Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. Yes, all those tuners can be operated independently. So would I be correct in saying that in Linux an adapter is an independent tuner? In that case the only time you would have frontend0, frontend1 etc is when there is a single dvb source that is switched between tuners? -- Philip Downer +44 (0)7879 470 969 pdow...@prospero-tech.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
Implementing a hardware dvb pid filter
Hi all, I'm looking to implement a hardware pid filter for a card I'm working on. I've been looking at how other drivers do this however all the drivers I've looked at still seem to call the software filter routines to pass data to user space. For example I've been looking at the flexcop (ie b2c2) driver and whilst that has a hardware filter, the interrupt service routine seems to always call flexcop_pass_dmx_data or flexcop_pass_dmx_packets from dvb/b2c2/flexcop.c which both call dvb_dmx_swfilter_packets or dvb_dmx_swfilter respectively. I had assumed that I would be able to make a ts stream coming from a hardware demux directly available to demux clients and dvr0, but no other budget driver (ie without mpeg/video out) seems to do this without using the swfilter. Can anyone point me at a driver which does similar to what I'm trying to implement or am I just missing something. Thanks in advance, Phil -- 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: Conexant Systems, Inc. Hauppauge Inc. HDPVR-1250 model 1196 (rev 04) [How to make it work?]
Ukko Happonen wrote: How do I make the TV tuner work? lspci -d 14f1:8880 -v says Kernel driver in use: cx23885 Kernel modules: cx23885 Looks to me like it's already working. Do you have a /dev/dvb/adapter0 dir with anything in it? if so see http://www.linuxtv.org/wiki/index.php/Testing_your_DVB_device Phil -- 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: V4L-DVB modules not loading
Stacey wrote: I've built the module okay. It installed correctly and copied the files into /lib/modules/2.6.31-14-generic/kernel/drivers/media/dvb/dvb-usb. After that I rebooted (since it was easier for me). Then I got to the If the Modules load correctly section to find that nothing has worked at all. I've checked my system log and it's recognising the USB device when I enter it but it isn't doing anything with it. The tutorial says you should be able to see the modules in /proc/modules but the modules folder doesn't even exist. The /dev/dvb/ folder has not been created either. Could you post the output of dmesg (just run the command 'dmesg' from a terminal) to the list, that should give us an idea of what is going on. You might want to do this after a clean reboot (with the adapter plugged in) so that there isn't too much information to wade through. Phil -- 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
