Re: [linux-dvb] [PATCH] DMX_OUT_TSDEMUX_TAP: record two streams from same mux
On Wed, 27 Feb 2008, Andreas Oberritter wrote: Peter Hartley wrote: The attached patch adds a new value for dmx_output_t: DMX_OUT_TSDEMUX_TAP, which sends TS to the demux0 device. The main question I have, is, seeing as this was such a simple change, why didn't it already work like that? Does everyone else who wants to capture multiple video streams, take the whole multiplex into userspace and demux it themselves? Or do they take PES from each demux0 device and Yes, they all demux in userspace themselves. If you search the archives, I've pointed out this same problem. One thing you do lose with the kernel demuxing system is the relationship between the different streams. For instance, a PMT change takes effect for all packets that follow it, but with the demuxed streams, you don't know where that is. Of course if you want to work with existing systems, you have to demux in userspace since no one will have this new feature yet. And if you're doing that anyway, it's more work to add additional support for demuxed TS streams to your software. That probably why no one has bothered to add this feature. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] saa7134-dvb: add missing dvb_attach call (for tda10046_attach)
On Sat, 26 Jan 2008, Hartmut Hackmann wrote: Matthias Schwarzott schrieb: Hi there! The attached small patch adds a missing dvb_attach wrapping around tda10046_attach. So it removes the hard dependency of saa7134-dvb on tda1004x module. I have only tested compiling as I don not have the hardware. I don't have this hardware either but your patch is right. Can you please resend it with your signature like The lack of the dvb_attach() was probably a bug. An attach must be matched be a detach when the device is removed. If they're unbalanced, you end up with messed up module use counts and modules that can't be un-loaded. There was probably already a detach, since all the other cards already used dvb_attach(). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Pinnacle 800i driver analog audio issues
On Mon, 21 Jan 2008, Timothy E. Krantz wrote: After compiling the latest Pinnacle 800i driver from the tree I have the following : cx88_alsa: disagrees about version of symbol snd_ctl_add cx88_alsa: Unknown symbol snd_ctl_add Have you compiled and installed an out of kernel tree version of ALSA? Trying to compile both v4l-dvb and ALSA out of tree at the same time is problematic. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check
On Sun, 20 Jan 2008, Mauro Carvalho Chehab wrote:
On Sat, 19 Jan 2008 05:28:49 -0800 (PST)
Trent Piepho [EMAIL PROTECTED] wrote:
I wish people would use the patch creating system from Hg, since it would
the format mistakes evident in this patch.
1. no patch title
2. s-o-b's in wrong order
3. diffstat included
4. patch against git source and not hg
On Sat, 19 Jan 2008, Akinobu Mita wrote:
From: Akinobu Mita [EMAIL PROTECTED]
This patch moves the subsystem ID and subsystem vendor ID check from
probing
function to the PCI generic function by describing subsystem IDs in
pci_device_id table. This enables to add new PCI IDs to a device driver
pci_ids
table at runtime by new_id file in sysfs pci driver tree.
This patch also changes the driver from having a pci alias to auto-load for
all bt878 cards to instead only auto-load for specific cards. Some
distributions will probably want to adjust their modprobe rules. I know
some have delt with both snd-bt87x and bt878 loading for the same devices
in various ways, e.g. adding one or the other to their modprobe blacklist
files.
The proper solution here seems to be moving snd-bt87x to our tree, and create
some shared code to be used by snd-bt87x, dvb-bt8xx, to avoid the
driver conflicts.
That doesn't solve the problem. It's inherent in the bt878 design, as it
uses the same pci function for either sound or dvb. So a bt878 chip
function 1 can load one and only one driver from ALSA, OSS, or DVB. For
most chips, there is only one driver that applies to a given pci device and
function.
In some cases it is possible to tell which driver to use via
sub-vendor/device data, but not always. The ALSA driver only auto-loads
for known good subdata, and has a module option to force loading when that
won't work. The DVB driver has the wildcard sub-vendor/device in the alias
table, IMHO a mistake, and will try to load for for all bt878 chips.
The DVB driver used to load for cards with sub-vendor/device 0x,0x,
but a previous patch changed that. An effect that that _should_ have been
mentioned in the description of the patch responsible, but was not.
This patch changes the DVB driver to not auto-load for all bt878 chips. A
rather significant change that should be described in the patch
description, but is not.
+static const char * __devinit card_name(const struct pci_device_id *id)
+{
+ if (id = bt878_pci_tbl
+ id bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
+ return (const char *)id-driver_data;
Are you sure this is safe? I don't remember reading that the pci_device_id
passed to the pci driver probe method must be from the device id table.
Couldn't the device id be a local variable from whatever calls probe, as
long as driver_data is set to the correct value? I looked at the current
pci bus code, and it does always pass a pointer into the driver's pci id
table. But that could change.
It seems like a better method would just be to check if driver_data is 0,
which will be the case if the id was added dynamically.
This data can't be changed by pci core, since driver_data is a priv element.
It
is used as a pointer on some drivers, while others use it as an integer value
to
an array (like most V4L/DVB and ALSA drivers). The above code should work
properly. If pci touches on this value, it would break the support for the
rest
of v4l/dvb drivers, so I think we don't need to worry about this.
I don't think you understand. That code checks if the pci_device_id
pointer passed to the probe function points to a spot in the driver's pci
id table. It has nothing to do with the driver_data field being modified.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check
On Mon, 21 Jan 2008, Manu Abraham wrote:
Trent Piepho wrote:
The DVB driver used to load for cards with sub-vendor/device 0x,0x,
but a previous patch changed that. An effect that that _should_ have been
mentioned in the description of the patch responsible, but was not.
This doesn't have anything to do with accessing the wrong PCI function
as what
you have been trying to explain, as PCI function is based on Device ID
and not
SubDevice ID .. (pointless)
I never said anything about access the wrong pci function. That's not a
problem. The problem is that there are different mutually exclusive
drivers for the same pci function.
This patch changes the DVB driver to not auto-load for all bt878 chips. A
rather significant change that should be described in the patch
description, but is not.
A noise out for nothing, that shouldn't have mattered ? But anyhow, the
patch a
while back changed that behaviour, the driver being loaded for all the
devices.
So how come this patch needs to have that description ?
No, the previous patch changed a different behavior. You don't seem to be
aware there is a difference between what the pci driver's probe function
will pass, and what PCI aliases are encoded into the module for
auto-loading purposes. An older applied patch had the *undocumented
side-effect* of changing the pci probe function to not drive devices with
the sub-vendor and sub-device of 0. This patch has the undocumented
side-effect of changing the pci aliases embedded in the module so that it
will not be auto-loaded for all sub-vendors/devices.
+static const char * __devinit card_name(const struct pci_device_id *id)
+{
+if (id = bt878_pci_tbl
+id bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
+return (const char *)id-driver_data;
Are you sure this is safe? I don't remember reading that the
pci_device_id
passed to the pci driver probe method must be from the device id table.
Couldn't the device id be a local variable from whatever calls probe, as
long as driver_data is set to the correct value? I looked at the current
pci bus code, and it does always pass a pointer into the driver's pci id
table. But that could change.
It seems like a better method would just be to check if driver_data is 0,
which will be the case if the id was added dynamically.
This data can't be changed by pci core, since driver_data is a priv
element. It
is used as a pointer on some drivers, while others use it as an integer
value to
an array (like most V4L/DVB and ALSA drivers). The above code should work
properly. If pci touches on this value, it would break the support for the
rest
of v4l/dvb drivers, so I think we don't need to worry about this.
I don't think you understand. That code checks if the pci_device_id
pointer passed to the probe function points to a spot in the driver's pci
id table. It has nothing to do with the driver_data field being modified.
what's the harm in it ?
If the pci layer ever changes certain internal implementation details it
will stop working. AFAIK, there is no guarantee that the pci_device_id
must point to in the driver's table. Only that is points to the correct id
for the pci_device that was passed and that the driver_data is correct.
It's poor programming to assume otherwise. It's obviously better to just
check if driver_data is NULL. That makes no unnecessary assumptions about
internal details and is simpler to boot.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check
I wish people would use the patch creating system from Hg, since it would
the format mistakes evident in this patch.
1. no patch title
2. s-o-b's in wrong order
3. diffstat included
4. patch against git source and not hg
On Sat, 19 Jan 2008, Akinobu Mita wrote:
From: Akinobu Mita [EMAIL PROTECTED]
This patch moves the subsystem ID and subsystem vendor ID check from probing
function to the PCI generic function by describing subsystem IDs in
pci_device_id table. This enables to add new PCI IDs to a device driver
pci_ids
table at runtime by new_id file in sysfs pci driver tree.
This patch also changes the driver from having a pci alias to auto-load for
all bt878 cards to instead only auto-load for specific cards. Some
distributions will probably want to adjust their modprobe rules. I know
some have delt with both snd-bt87x and bt878 loading for the same devices
in various ways, e.g. adding one or the other to their modprobe blacklist
files.
I think that new_id will only work if hotplug is turned on. Without
hotplug, there will be no way to load the driver for other devices (such as
those with eprom trouble).
+static const char * __devinit card_name(const struct pci_device_id *id)
+{
+ if (id = bt878_pci_tbl
+ id bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
+ return (const char *)id-driver_data;
Are you sure this is safe? I don't remember reading that the pci_device_id
passed to the pci driver probe method must be from the device id table.
Couldn't the device id be a local variable from whatever calls probe, as
long as driver_data is set to the correct value? I looked at the current
pci bus code, and it does always pass a pointer into the driver's pci id
table. But that could change.
It seems like a better method would just be to check if driver_data is 0,
which will be the case if the id was added dynamically.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [PATCH 1/2] bt878: remove handcrafted PCI subsystem ID check
On Sun, 20 Jan 2008, Akinobu Mita wrote:
+static const char * __devinit card_name(const struct pci_device_id *id)
+{
+ if (id = bt878_pci_tbl
+ id bt878_pci_tbl + ARRAY_SIZE(bt878_pci_tbl) - 1)
+ return (const char *)id-driver_data;
Are you sure this is safe? I don't remember reading that the pci_device_id
passed to the pci driver probe method must be from the device id table.
Couldn't the device id be a local variable from whatever calls probe, as
long as driver_data is set to the correct value? I looked at the current
pci bus code, and it does always pass a pointer into the driver's pci id
table. But that could change.
Yes, that could change. And then it always returns Unknown.
Which would be wrong.
The safe way is:
static const char * __devinit card_name(const struct pci_device_id *id)
{
int i;
for (i = 0; i ARRAY_SIZE(bt878_pci_tbl) - 1; i++) {
if (bt878_pci_tbl[i].vendor = id-vendor
bt878_pci_tbl[i].device = id-device
bt878_pci_tbl[i].subvendor = id-subvendor
bt878_pci_tbl[i].subdevice = id-subdevice)
return (const char *)bt878_pci_tbl.driver_data;
}
return Unknown;
}
The pci layer has a function to do this for you. But it's unnecessary.
It seems like a better method would just be to check if driver_data is 0,
which will be the case if the id was added dynamically.
driver_data can be non-zero value. we can set it through new_id.
But there are many possibilities to break kernel by writing
Nope, driver_data will always be 0. Try it. You must set
dynids.use_driver_data to allow driver data to be passed via sysfs for just
this reason.
Acutually I don't have a special preference for any of which.
Because we can remove the function card_name() after submitting
all the card name information that bt878.c holds to PCI ID repository.
(http://pci-ids.ucw.cz/iii/?i=109e0878)
Then we can get the card name from lspci instead of seeing dmesg.
It nice to know that the driver identified the card. It would be nice if
all four bt8x8 drivers could share a card database, but that's not so easy.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with dvb_ttpci
On Thu, 8 Nov 2007, alexw wrote: On Wednesday 07 November 2007 22:19:54 Trent Piepho wrote: On Wed, 7 Nov 2007, VDR User wrote: With recent copies of fresh v4l I started getting the following error upon trying to load drivers for my nexus-s: dvb_ttpci: Unknown symbol ttpci_eeprom_parse_mac After searching on google I found that this problem existed once before and here is a patch that reflects the fix Did you remember to run depmod after installed new modules? The ttpci-eeprom module should be automatically loaded by modprobe. I did experience the same issue. When you are upgrading the v4l source from repository do not forget to verify that the old .config is still valid. Unfortunately there is no make oldconfig option available. the only way to enable ttpci_eeprom config is to do a make menu config and to deselect ttpci support and select it back. If you compare the 2 .config file you will see that the ttpci_eeprom is now selected. You are probably right about this problem, VDR user probably has a stale config file, which will not work. One can also delete the .config file, or run make allyesconfig, which will remake the config file. This isn't done by default when a Kconfig change is detected because many Kconfig changes don't invalidate the .config file. Overwriting a custimized .config file and then rebuilding everything would be very annoying in these cases. Unless one knows what they are doing, it's best to run make distclean after updating a repository in place. Is it possible to create a oldconfig label to check the .config file integrity? (in make_kconfig.pl or make_myconfig.pl) In the past it was working, I don't know why it was dropped. An oldconfig style system would be nice, but it's not supported, and never has been. The kernel build system has this feature, but the v4l-dvb build system doesn't. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with dvb_ttpci
On Wed, 7 Nov 2007, VDR User wrote: With recent copies of fresh v4l I started getting the following error upon trying to load drivers for my nexus-s: dvb_ttpci: Unknown symbol ttpci_eeprom_parse_mac After searching on google I found that this problem existed once before and here is a patch that reflects the fix Did you remember to run depmod after installed new modules? The ttpci-eeprom module should be automatically loaded by modprobe. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] [saa7134] Fwd: [PATCH] Spezial Lifeview DVB-S Card without eeprom
On Wed, 17 Oct 2007, Oliver Endriss wrote:
since there was no reply on the DVB ML:
Is anyone maintaining the DVB part of the saa7134 driver?
Can this patch be accepted?
It has a few problems:
Is there no sub-system data for this board? It should be added to
saa7134_pci_tbl
#include isl6421.h
+#include tua6100.h
+#include stv0299.h
Why is tua6100.h included when it's not used?
+
+static int philips_su1278_ty_ci_tuner_set_params(struct dvb_frontend *fe,
+struct dvb_frontend_parameters
*params)
+{
This looks like code for a perfectly normal i2c pll tuner. Add it to dvb-pll
and use that driver.
+
+static struct stv0299_config lifeview = {
Make this const
+ case SAA7134_BOARD_LIFEVIEW_DVBS:
+ dev-dvb.frontend = dvb_attach(stv0299_attach, lifeview,
+ dev-i2c_adap);
+ if (dev-dvb.frontend) {
+ dev-dvb.frontend-ops.tuner_ops.set_params =
+ philips_su1278_ty_ci_tuner_set_params;
+#if 0
+ if (dvb_attach(tua6100_attach, dev-dvb.frontend, 0x61,
+ dev-i2c_adap) == NULL) {
+ printk(%s: No tua6100 found!\n, __FUNCTION__);
+ }
+#endif
What's the #if 0 stuff for?
diff -ur v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134.h
v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134.h
--- v4l-dvb-ea93c93f1547-orig/linux/drivers/media/video/saa7134/saa7134.h
2007-10-11 14:09:06.0 +0200
+++ v4l-dvb-ea93c93f1547/linux/drivers/media/video/saa7134/saa7134.h
2007-10-14 17:48:49.0 +0200
@@ -247,6 +247,7 @@
#define SAA7134_BOARD_SABRENT_TV_PCB05 115
#define SAA7134_BOARD_10MOONSTVMASTER3 116
#define SAA7134_BOARD_AVERMEDIA_SUPER_007 117
+#define SAA7134_BOARD_LIFEVIEW_DVBS128
118 comes after 117
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
On Sun, 7 Oct 2007, Mauro Carvalho Chehab wrote:
I took a look at cx23885 code. It seems that there's a serious error on
the way you're using cx23885_buffer there:
cx23885-dvb.c: return cx23885_buf_prepare(q, port, (struct
cx23885_buffer*)vb, field);
cx23885-dvb.c: cx23885_buf_queue(port, (struct cx23885_buffer*)vb);
cx23885-dvb.c: cx23885_free_buffer(q, (struct cx23885_buffer*)vb);
It seems that you are forcing videobuf_buffer to be cx23885_buffer. This
is not right!
This is what is defined on cx23885.h:
struct cx23885_buffer {
/* common v4l buffer stuff -- must be first */
struct videobuf_buffer vb;
I'm not sure that it is competely wrong. Say one has a cx23885_buffer that
contains a videobuf_buffer. Now suppose you have a pointer to the
videobuf_buffer, and you want to get a pointer to the cx23885_buffer that
contains it. What you should write is:
struct videobuf_buffer *vb = ...;
struct cx23885_buffer *buf = container_of(vb, struct cx23885_buffer, vb);
But since vb is the first field of the cx23885_buffer struct, the container_of
will turn into just '(struct cx23885_buffer *)(vb)'
This code in videobuf-dma-sg.c looks odd to me:
/* Allocated area consists on 3 parts:
struct video_buffer
struct driver_buffer (cx88_buffer, saa7134_buf, ...)
struct videobuf_pci_sg_memory
static void *__videobuf_alloc(size_t size)
{
struct videbuf_pci_sg_memory *mem;
struct videobuf_buffer *vb;
vb = kzalloc(size+sizeof(*mem),GFP_KERNEL);
mem = vb-priv = ((char *)vb)+size;
What is 'size', is that the size of the driver buffer? Shouldn't you be
allocating size + sizeof(*vb) + sizeof(*mem)?
Is there documentation for videobuf anywhere? It doesn't look like any of
the videobuf functions have descriptions of that they do or what the
parameters are.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC-final] videobuf tree
On Sat, 6 Oct 2007, Michael Krufky wrote: I've tested the master branch under the following conditions: 1) cx88 raw analog video 2) cx88-blackbird encoded mpeg stream 3) cx88-dvb mpeg TS I'm pleased to report that the above three tests worked out successfully. However, cx23885 is now broken. Upon starting a DVB stream, the following OOPS is generated: Did you get this recent patch? changeset: 6284:7dba1f554c4a user:Trent Piepho [EMAIL PROTECTED] date:Thu Oct 04 01:28:45 2007 -0700 summary: cx23885: Update to new videobuf code You can compile cx23885 with no warnings without the patch, because the kernel still provides the old video_buf_dvb include files. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Reloading DVB drivers broken since 2.6.22, worked in 2.6.21
After a dvb card driver is unloaded and then loaded again, it is no longer possible to access the dvr device. Example: cat /dev/dvb/adapter0/dvr0 kill with ^C rmmod cx88-dvb modprobre cx88-dvb cat /dev/dvb/adapter0/dvr0 cat: /dev/dvb/adapter0/dvr0: No such device On kernel 2.6.21, this worked fine. In order to get dvb working again, it's necessary to unload and reload the dvb-core modules. I strongly suspect commit 57861b432bda77f8bfafda2fb6f5a922d5f3aef1 is somehow related to this problem. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] RE : RE : RE : RE : linux-dvb and Dektec [was: DVB API update]
On Thu, 4 Oct 2007, Thierry Lelegard wrote: What do you do about devices having HW filters ? Then you will need to implement them in userland, in your view, which brings in inconsistent userspace interfaces. I addressed this in a previous mail of this thread. The device driver should report capabilities in a standard way: able to demux PIDs, able to demux PES packets, etc. The public API of the userland library offers a standard demux API to the application. Internally, the library checks if the frontend device can do hardware demux. It it can, the library invokes it. If it can't, the library reads the TS and does software demux. This is more or less what is done now, except that everything is in the kernel. There is an advantage to doing software filtering in the kernel. Often a TS has many more programs that one is interested in, and so many frames will be filter out by the demuxer. By doing demuxing in the kernel, one can filter out the uninteresting packets as soon as possible. Now, filtered packets never make it out of the device DMA buffer into the dvr buffer and are never copied out of the dvr buffer into userspace. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] compiling is broken
On Thu, 4 Oct 2007, hermann pitton wrote: Am Mittwoch, den 03.10.2007, 22:59 +0200 schrieb e9hack: this changset: Fix Kconfig dependency author Mauro Carvalho Chehab [EMAIL PROTECTED] Tue Oct 02 11:16:16 2007 -0300 (30 hours ago) changeset 6260 48badb1df2ed breaks compiling. I get the following error: /usr/src/v4l-dvb/v4l/saa7134-dvb.c:415: error: 'struct saa7134_dev' has no member named 'original_demod_sleep' That patch (in combination with some others) renamed the config variable VIDEO_BUF_DVB to VIDEOBUF_DVB. Some code, like saa7134.h, was not updated and is still looking at CONFIG_VIDEO_BUF_DVB. There is a script I wrote called check_config_defines.pl that should find stuff like this, but in this case it misses it. The kernel source defines CONFIG_VIDEO_BUF_DVB since it has all the old code in it, so it doesn't appear to be missing. I fixed the script so it uses the v4l-dvb Kconfig replace the corresponding kernel files, as opposed to be combined when them. Now it finds the errors: Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/cx23885/cx23885.h:31 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/cx88/cx88-i2c.c:156 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/cx88/cx88.h:34 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/cx88/cx88.h:320 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/cx88/cx88.h:494 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/saa7134/saa7134.h:51 Unknown config CONFIG_VIDEO_BUF_DVB in linux/drivers/media/video/saa7134/saa7134.h:562 I wonder if instead of changing these to CONFIG_VIDEOBUF_DVB, it would be better to use CONFIG_VIDEO_SAA7134_DVB, CONFIG_VIDEO_CX88_DVB, etc. One could always have a cx88 card with DVB and a saa7134 card without dvb. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
On Thu, 6 Sep 2007, Manu Abraham wrote: Trent Piepho wrote: At least for many demods, the frequency range supported is determined by the tuner. One could have a chip that combines the demod and tuner functions, or a system where the demod is somehow involved in tuning and has some limit. But that is not the case here. Fmclk 2 * Fsmax * Viterbi Doesn't apply to a tuner Of course! Why didn't I see that? You've made it perfectly clear now. Using this formula, what is the allowed range for a tda10046 demod with a TDA827X tuner? How about with a TDA827XA tuner? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
On Thu, 6 Sep 2007, Andreas Oberritter wrote: Trent Piepho wrote: But, 2147483647 is not a valid DVB-T frequency. It looks like some random number. It's not that random: 2147483647 equals INT_MAX and also LONG_MAX on 32 bit systems. Quoting from the manpage of strtol(): The strtol() function returns the result of the conversion, unless the value would underflow or overflow. If an underflow occurs, strtol() returns LONG_MIN. If an overflow occurs, strtol() returns LONG_MAX. In both cases, errno is set to ERANGE. Precisely the same holds for strtoll() (with LLONG_MIN and LLONG_MAX instead of LONG_MIN and LONG_MAX). My conclusion: Your channels.conf contains invalid frequency values. Tzap uses strtol() to parse those values and returns LONG_MAX. Very clever, I bet you are right about that! Previously the frequency range wasn't checked, so something like this could go undetected. There wouldn't be any error returned when FE_SET_FRONTEND was called. The tuner driver would either reject the value when the tuning thread tried to set it, or it would program the tuner so some bogus setting. Either no signal would be detected, or the frequency would remain unchanged from whatever it was at before, and so the last channel tuned might appear, as if it was at 2147483647 Hz. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
On Thu, 6 Sep 2007, Mauro Carvalho Chehab wrote: The limits are comming from the tda10046 info. I think the correct thing to do here is to not have the tda1004x driver define frequency limits, as it's the tuner that has the limits. Nak. You must not remove these limits unless you make sure that all tuner drivers which might be attached to this demod have non-zero frequency limits. So the incorrect limits should be left there? That isn't right either. IMO, the better would be not to initialize frequency ranges at the demods (since this is tuner stuff). At least for many demods, the frequency range supported is determined by the tuner. One could have a chip that combines the demod and tuner functions, or a system where the demod is somehow involved in tuning and has some limit. But that is not the case here. If you are afraid of having a tuner driver with improper values, add a check can be added, at dvb frontend core, to use the maximum allowed frequency range, if frequency_max is not defined. The better, however, is to fix the tuner drivers without frequency limits. This would be easy to do. There is already a function, dvb_frontend_get_frequeny_limits(), that does this. It prints a warning message if neither the demod nor the tuner define a limit. In this case, it returns zero for the max frequency, so any attempt to tune with a driver broken like this will fail. It could easily return ULONG_MAX in this case, so tuning would work but there would still be the warning message. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Asys P7131 Hybrid: DVB out of range
On Thu, 6 Sep 2007, hermann pitton wrote:
Am Mittwoch, den 05.09.2007, 13:29 +0200 schrieb Paolo Dell'Aquila:
Than I've done some test with Mythtv and auto-scanning
for channels... and now...
...now I'm having the following (BIG) problem:
dvb-t doesn't work anymore (also in kaffeiene or tzap).
dmesg has the following error:
DVB: frontend 0 frequency 2147483647 out of range (5100..85800)
That sounds really mad, especially as you are in freq. limits of the
tda8275 and not of the tda8275a, which for sure you have.
The limits are comming from the tda10046 info. I think the correct thing
to do here is to not have the tda1004x driver define frequency limits, as
it's the tuner that has the limits.
But, 2147483647 is not a valid DVB-T frequency. It looks like some random
number.
---
# HG changeset patch
# User Trent Piepho [EMAIL PROTECTED]
# Date 1189035269 25200
# Node ID 0f6fa7f9db1241806c7d91ff6a9775f12fe1d6dd
# Parent 1387dc197077ad89fdc4014c927c4d8c9ae56193
tda1004x: Remove frequency limits
From: Trent Piepho [EMAIL PROTECTED]
The frequency limits are defined by the tuner. The demodulator's input comes
in at a fixed intermediate frequency, and it doesn't care or know what
frequency it was at originally.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff -r 1387dc197077 -r 0f6fa7f9db12
linux/drivers/media/dvb/frontends/tda1004x.c
--- a/linux/drivers/media/dvb/frontends/tda1004x.c Sun Sep 02 07:56:18
2007 +0100
+++ b/linux/drivers/media/dvb/frontends/tda1004x.c Wed Sep 05 16:34:29
2007 -0700
@@ -1216,8 +1216,6 @@ static struct dvb_frontend_ops tda10045_
.info = {
.name = Philips TDA10045H DVB-T,
.type = FE_OFDM,
- .frequency_min = 5100,
- .frequency_max = 85800,
.frequency_stepsize = 17,
.caps =
FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
@@ -1275,8 +1273,6 @@ static struct dvb_frontend_ops tda10046_
.info = {
.name = Philips TDA10046H DVB-T,
.type = FE_OFDM,
- .frequency_min = 5100,
- .frequency_max = 85800,
.frequency_stepsize = 17,
.caps =
FE_CAN_FEC_1_2 | FE_CAN_FEC_2_3 | FE_CAN_FEC_3_4 |
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
On Tue, 28 Aug 2007, Manu Abraham wrote:
Trent Piepho wrote:
That's really inefficient. You've got about 250k of table there. I don't
think a 250k+ module is going to be very popular.
I do agree that's not the most effecient way. But given the short time
span and lack of FP operations, the quick way that came to my mind was
precomputed values.
That said, the popularity of a module is not defined by it's size. as an
eg: the nVidia module is over 1 Meg. Considering the quality/performance
of the tuners in the tree we have, i don't think there would even be a
popularity contest, coming anywhere near.
But nobody likes how huge the nvidia module is.
That said, if it can be optimized, there is no reason why it shouldn't
be done.
I had a comment from Andrew Morton as well on it: It's large, but heck,
it's not a lot of memory. The nvidia driver is a meg or something.
Huge tables like that can be a problem just for the code itself. Huge
patches, show checkouts and diffs, slow compiles, etc.
There are also problems with maintaining such code. Say you need to tweak
the tuning algorithm? Instead of just changing one constant or making an
expression round up instead of down, you have to create a whole new table.
And what if there is a new device revision, which is slightly different?
You have to have another huge table, when you could probably support both
with just a small addition to the code. Or say someone has a fake Russian
copy, that uses a 26 Mhz crystal instead of 27 MHz? Much harder to support
if you look at the driver and just see some huge table with no idea what
made it, instead of one simple constant to change.
For instance, when radio support for my tuner didn't work, I was able to
figure out from the tuner-simple code that it was using the wrong 1st IF
offset for the tda9887 radio demodulator and 2nd IF output. If there was
just some huge table of random settings, it would have been much harder to
fix.
If anyone's interested, the original version with FP is here:
http://paste.debian.net/35554
It 's a userspace application with which i did some crude tests.
The tables are here
http://jusst.de/manu/1086M_36.125M.c
http://jusst.de/manu/1086M_36.166M.c
I looked at this code, but there is code there that isn't used, so I'm not
sure exactly what it's supposed to.
There is a 'optimal_settings_index' parameter to mc44s80x_set_1st_lo(), but
it's never used.
There is still a huge table, 'tuner_step', where did that come from? The
whole table isn't used, only index 1. And lo2_divider isn't used either.
Is there some kind of formula that can calculate this table?
The 'lo1_adjustment' code is very odd. Are you sure it's really doing what
it's supposed to do?
The actual code in mc44s80x_set_1st_lo() is just a round-about way of doing
a rather simple bit of math.
So, here is a integer version of your floating point code. It's actually
_more_ accurate than the FP version. For your sample (22650 Hz,
lo1_divider 13, lo1_adjustment 0), my code finds the same divider as yours,
630. But the 'first_lo' value I find is 1,312,615,385 Hz, while your FP
code returns 1,312,615,336 Hz. Mine is within 1 Hz of the true value of
1312615384.615384.
#ifdef __KERNEL__
#include asm/div64.h
#else
#define do_div(n, base) ({ unsigned long __rem = (n)%(base); (n)/=(base);
__rem; })
typedef unsigned long long u64;
#endif
/* freq = input frequency in Hz
refdiv1 = first reference frequency divisor (10 to 15, or 26)
adj1 = mystery adjustment (signed number!) */
/* To turn the lo1_adjustment value into adj1, do this:
adj1 = (lo1_adjustment+1) / ((lo1_adjustment1)?-2:2); */
#define REF_FREQ2700 /* 27 MHz reference */
#define IF1 108600
void mc44s80x_set_1st_lo(unsigned int freq, unsigned int refdiv1, int adj1)
{
u64 div1;
unsigned int remainder, freq1, if1, lo1ref;
signed int if1_offset;
div1 = ((u64)freq + IF1) * refdiv1 + REF_FREQ/2; /* Subtract 1 to
round XXX.5 down instead of up */
printf(freq+IF * refdiv1 = %llu\n, div1);
remainder = do_div(div1, REF_FREQ);
/* adjustment sign is flipped if we didn't round div1 down.
Very stange, I don't understand what this is for. */
if (remainder = REF_FREQ/2)
adj1 *= -1;
div1 += adj1;
/* Actual frequency PLL tuned, taking into account step size, the IF
* offset, and the mystery adjustment. */
freq1 = (div1 * REF_FREQ + refdiv1/2) / refdiv1;
/* Actual IF used, taking into acount everything freq1 does */
if1 = freq1 - freq;
/* Offset of actual IF from nominal IF */
if1_offset = if1 - IF1;
/* LO1REF, whatever that is */
/* BTW, do you really want to round down, not to the nearest? */
lo1ref = 15 * (8/2) * div1 / refdiv1;
/* The n+2 divider */
div1 = (div12) ? 0 : div1-2;
printf
Re: [linux-dvb] Large arrays
On Tue, 28 Aug 2007, Manu Abraham wrote: * use integer math calculations * precompute the values where double precision is needed. That said, the first option i tried for a while, after a few days (i almost gave up ?) got really irritated with it. The second option seemed a bit more comfortable, to precalculate the values. The disadvantage in such a case is that the array which holds the precomputed value is quite large in size, with that in mind, a different question arose in my mind, whether such large arrays would be frowned upon in kernel The precomputed array is here http://www.jusst.de/manu/mc44s80x_array.c Any thoughts ? That's really inefficient. You've got about 250k of table there. I don't think a 250k+ module is going to be very popular. The table could be packed a lot better. None of the fields need to be 64-bit, so don't use unsigned long which is 64 bits on 64 bit platforms. Most of those fields don't even have 32 bits that change. For example, I can see that the last 12-bits of the refdiv field are always 0x9b2. You could put that field in 8-bits (or less, it looks like only 5 bits change). The freq field looks like it's just every 1/6th MHz from 50 Mhz to 1 GHz. Why do you need to store that? It should be trivial to calculate. unsigned int x; /* must be unsigned! Good to x=8589 1.4815 GHz*/ tuner_step_166k[x].freq = (x * 50 + 1)/3 + 5000; Or the other way around, table index from frequency: unsigned int freq, x; x = ((freq - 5000) * 3 + 25) / 50; ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem using mplayer.
On Tue, 28 Aug 2007, kevin liu wrote: Dear Nicola Mplayer can give a perfect HDTV effects, but after a period of time, it gives such complaints: Too many video packets in the buffer: (148 in 8421326 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A:69414.9 V:69410.6 A-V: 4.281 ct: 8.984 14445/14445 44% 0% 3.6% 130 0 Too many video packets in the buffer: (148 in 8402931 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. What's the problem? mplayer has a very had time if there are any errors in mpeg TS streams. If your reception is 100% not perfect, it's difficult to watch with mplayer. When it gets an error, mplayer somehow gets confused and starts playing the video back slowly. The audio and video get out of sync and you get that error. You can sometimes fix it by telling mplayer to do a short seek, i.e. push the left arrow key. When you do this there is a random chance that mplayer will un-confuse itself and start playing ok again. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
On Fri, 17 Aug 2007, Markus Rechberger wrote: as I wrote earlier the thread can be idle/closed even before the node gets closed (you can test that with kaffeine, and you can test the other case with the scan utility) How can this happen? Afaics the fe thread may continue to exist after the device node was closed, but not vice-versa. Yes, how can that happen? What will make the dvb frontend thread exit before the device is closed? Maybe it would be a good idea to do what Andreas suggested and have the frontend release function block until the frontend thread has exited. AFAIK, the thread hanging around after the device is closed does nothing but cause problems. It's a very common FAQ, Q: Why does it mythtv not work if I change from a digital channel to an analog one? A: You need to set dvb_shutdown_timeout to 0. What's the purpose of dvb_shutdown_timeout 0? ts_bus_ctrl does a kind of reference counting. For readers: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called during close For the one and only writer: - fe-ops.ts_bus_ctrl(fe,1) is called during open - fe-ops.ts_bus_ctrl(fe,0) is called when the thread exits, usually after close So, how do you tell if the ts bus is already locked? I didn't want to write it but this is also what I would do, and I would also include the other dvb device nodes.. it doesn't make sense to keep them open as non functional dummies, or even allow people to open these nodes if the dvb mode is locked. What about a device with two frontends? Maybe the DVB-T/Analog frontend is locked by the V4L device, but you can still use a DVB-S frontend with dvb. In that case the demux could still be opened and used. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] dvb_net hotplugging support
On Fri, 17 Aug 2007, Oliver Endriss wrote: Markus Rechberger wrote: Since this didn't get commented here, Trent did that patch already 2 months ago but it's not included yet. So I recommend to include his patch. http://article.gmane.org/gmane.linux.kernel/543689 Acked-by: Markus Rechberger [EMAIL PROTECTED] Are you talking about this tiny patch? struct dvb_net *dvbnet = dvbdev-priv; - if (!dvbdev) - return -ENODEV; If yes, Acked-by: Oliver Endriss [EMAIL PROTECTED] Btw, why is this patch important? Basically it doesn't change anything. It checks if dvbdev is NULL after dvbdev already been used. Coverity spots this as a programming mistake (which it is), and Adrian Bunk posts patches to fix it. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [patch] dvb_net hotplugging support
On Fri, 17 Aug 2007, Oliver Endriss wrote: Trent Piepho wrote: On Fri, 17 Aug 2007, Oliver Endriss wrote: Markus Rechberger wrote: Since this didn't get commented here, Trent did that patch already 2 months ago but it's not included yet. So I recommend to include his patch. http://article.gmane.org/gmane.linux.kernel/543689 Acked-by: Markus Rechberger [EMAIL PROTECTED] Are you talking about this tiny patch? struct dvb_net *dvbnet = dvbdev-priv; - if (!dvbdev) - return -ENODEV; If yes, Acked-by: Oliver Endriss [EMAIL PROTECTED] Btw, why is this patch important? Basically it doesn't change anything. It checks if dvbdev is NULL after dvbdev already been used. Coverity spots this as a programming mistake (which it is), and Adrian Bunk posts patches to fix it. Sure, but the patch does exactly the same. It's just hidden behind a function call... Exactly, now Coverity won't spot it! Actually, it's not wrong anymore, since dvb_generic_open is used from multiple places, so it could be called from somewhere else where dvbdev is NULL and isn't used before the check. Though I really doubt that dvbdev can be NULL anywhere, so the check in dvb_generic_open can probably be removed. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
On Thu, 9 Aug 2007, Markus Rechberger wrote: On 8/9/07, Markus Rechberger [EMAIL PROTECTED] wrote: On 8/9/07, Steven Toth [EMAIL PROTECTED] wrote: Markus Rechberger wrote: Following patch adds a rather primitive way to temporary lock dvb devicenodes, this can be useful for hybrid devices which use the video4linux framework for the analogue TV part and the dvb framework for digital TV if only one mode can be accessed at a time. I want to allow a user to use one mode at a time, so either DVB or V4L. The device requires a different firmware for V4L and DVB also different GPIO values and some special register writes. This code looks like it's full of race conditions. How do you prevent the dvb code and the v4l code from accessing the lock field at the same time? For example, in your em28xx code, what happens if the dvb devices is opened after the call to -get_status on line 230 and before the call to -dvb_lock on line 234? Why do you need to add locks to the frontend, dvr, demux, and net devices? Is it necessary to lock anything besides the frontend? Some devices, like the demux device, are multiple open. How do you know when to lock and unlock them? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] WinTV Nova-T PCI 500 new issues
On Tue, 7 Aug 2007, Chris Murton wrote: Trent Piepho wrote: Can you try this with the latest v4l-dvb? Load the mt2060 driver, modprobe symbol:mt2060_attach Make sure the dvb-usb-dib0700 driver is unloaded! Load the dvb-usb-dib0700 driver Does that still give the Unable to find symbol mt2060_attach() error? If that works, then try this. Unload dvb_usb_dib0700 Unload mt2060 Make sure they are really unloaded! modprobe dvb-usb-dib0700 Does that work, or is the error still present? Right, very interesting. The first way works. If i'm in the OS, unload the dvb_usb_dib0700 module and then load mt2060 and load dvb_usb_dib0700 I get :- MT2060: successfully identified (IF1 = 1220) but the second does not, I get the usual symbol issue with mt2060_attach(). Hmm, for some reason symbol_request() doesn't work for you. If /proc/config.gz or /proc/config exist, can you tell me what the value of CONFIG_KMOD is? Or if they don't, what the value of CONFIG_KMOD from your kernel .config file is? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix for Air2PC HD5000
On Wed, 8 Aug 2007, Geoffrey Hausheer wrote: On 8/8/07, Michael Krufky mkrufky-at-linuxtv.org wrote: On 8/7/07, Geoffrey Hausheer wrote: Although your patch may appear to fix your problem, I suspect that it is really curing a symptom of the problem, and not the cause. This is possible. I don't know anything at all about i2c. I just tried to reverted the negative consequences of the patch which broke my system. The real problem is with the flexcop i2c support. It only allows a very limited set of a i2c commands, and a one byte read command like the pll probe uses isn't supported. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix for Air2PC HD5000
On Wed, 8 Aug 2007, Michael Krufky wrote: On Wed, 8 Aug 2007, Geoffrey Hausheer wrote: On 8/8/07, Michael Krufky mkrufky-at-linuxtv.org wrote: On 8/7/07, Geoffrey Hausheer wrote: Although your patch may appear to fix your problem, I suspect that it is really curing a symptom of the problem, and not the cause. This is possible. I don't know anything at all about i2c. I just tried to reverted the negative consequences of the patch which broke my system. The real problem is with the flexcop i2c support. It only allows a very limited set of a i2c commands, and a one byte read command like the pll probe uses isn't supported. Trent, If that is the case, then why do you think Geoffrey is having this problem while others are not? The HD-5000 is the only flexcop card that uses dvb-pll with a pll directly attached to the I2C bus. The flexcop driver doesn't check the return value of dvb_pll_attach, so there is no error message. It will just not work correctly. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix for Air2PC HD5000
On Wed, 8 Aug 2007, Michael Krufky wrote: The HD-5000 is the only flexcop card that uses dvb-pll with a pll directly attached to the I2C bus. The flexcop driver doesn't check the return value of dvb_pll_attach, so there is no error message. It will just not work correctly. Perhaps I worded my question incorrectly... When I said, others are not, I meant other users of the HD5000. If you look back to earlier in this thread, I gave an explanation of the testing that I have done last weekend. Using 2.6.22, the initial tuning params work properly and all attempts afterwards do not. Regardless, things are now beginning to make sense, although I do not understand why the latest HG works fine with that card for me against eariler kernel revisions. Perhaps I made a mistake in one of my tests. Now I know exactly what needs testing. How to fix this cleanly, that I am still not sure of, without affecting other drivers. Maybe we'll have to hack the flexcop i2c handling to fake a good i2c reply. I'll look into it when I get back home. What should happen is that there aren't any errors, even when loading the driver or when tuner. But the frequency won't change. If the frequency was set using older drivers, there is probably nothing to reset it when changing drivers or rebooting. So if you tune to a channel before testing after the change, and then try the same channels, it will appear to be working fine. If you try to tune to a new channel, it will _appear_ to work, except you'll keep getting the old channel. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] frequency out of range - Problems
On Mon, 6 Aug 2007, Michael Krufky wrote: Manu Abraham wrote: In frontends/tda8083.c Look for this: 446 .frequency_min = 95, /* FIXME: guessed! */ 447 .frequency_max = 140,/* FIXME: guessed! */ change to line: #447 to .frequency_max = 215, This should fix your problem. Manu I did that and it looks good - at least I can switch to the channels again and can grab a picture inside vdradmin, I am a bit too far away from my VDR currently :) N' joy :) Manu, Do you have a spec for that demod? If so, would you kindly update the driver so that users don't have to worry about this issue? The spec sheet for the TDA8083 is available, but it's the tuner that controls the input frequency range. The demod doesn't know what frequency the signal was at before the tuner. It looks like the TDA8083 is used along with a TSA5522 PLL in a Grundig 29504-451 NIM. The TSA5522 datasheet says its RF input frequency range is 64 to 1400 MHz. The TSA5522 is configured to use a 1/16 MHz step size, but the code is using a 1/8 MHz step size. So, the tuner probably has a divide by 2 prescaler. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] WinTV Nova-T PCI 500 new issues
On Mon, 6 Aug 2007, Chris Murton wrote: The aerial configuration has not changed, I have line of sight to the transmitter in question and dmesg looks reasonably healthy: dib0700: loaded with support for 5 different device-types usb 3-3: reset full speed USB device using ohci_hcd and address 2 dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering frontend 0 (DiBcom 3000MC/P)... DVB: Unable to find symbol mt2060_attach() dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (Hauppauge Nova-T 500 Dual DVB-T) DVB: registering frontend 1 (DiBcom 3000MC/P)... DVB: Unable to find symbol mt2060_attach() That is your problem. You didn't compile the mt2060 module, or it's not installed, or your modprobe information is out of date (run depmod), or your module utils version is too old (need 3.2). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] WinTV Nova-T PCI 500 new issues
On Mon, 6 Aug 2007, Chris Murton wrote: Trent Piepho wrote: DVB: Unable to find symbol mt2060_attach() That is your problem. You didn't compile the mt2060 module, or it's not installed, or your modprobe information is out of date (run depmod), or your module utils version is too old (need 3.2). Thanks for your pointers, I've just taken a look to check :- basil:~# modinfo mt2060 filename: /lib/modules/2.6.21/kernel/drivers/media/dvb/frontends/mt2060.ko author: Olivier DANET description:Microtune MT2060 silicon tuner driver license:GPL vermagic: 2.6.21 mod_unload depends: parm: debug:Turn on/off debugging (default:off). (int) It modprobes fine, but I don't get anything to say it's seen the tuner in dmesg (which looking at the source code of mt2060.c, I should do) and i still have no luck. It won't print anything when you load it. Did you check your module utils version? Run depmod? Check the dates on the mt2060.ko file and the other drivers you are loading, like dvb-usb-dib0700.ko and make sure they are the same. You could be mixing old modules and new modules. Should mt2060 be manually probed in at some point in the boot process? No. It should be loaded automatically by the dib0700 driver. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Fix the min/max frequencies of some DVB-C frontends
On Tue, 7 Aug 2007, Manu Abraham wrote: On 8/7/07, Trent Piepho [EMAIL PROTECTED] wrote: Most demodulators don't have frequency ranges. They just take whatever the tuner gives them at a fixed intermediate frequency. It's really the tuner that has the frequency range. Not true: look at the MB86A16. It is a DC (Direct Conversion) receiver. There is no tuner used alongwith (a similar case goes for the MB86A15, but that is far from being similar) and hence no IF. But in either case, absolutely _no_ tuner. Look at what I wrote. Most demodulators ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] LITE-ON DVBT USB adapter
On Thu, 19 Jul 2007, Pedro Aranda wrote: Hi folks, Problem: MT-2060 doesn't register = no frontend Solution: attached patch Request: include it in the mainstream ASAP: I'm really sick of having to recompile the DVB subsystem everytime a kernel update happens THANKS a lot Try reading README.patches and following the guidlines for submitting a patch. You might also try not writing html emails, they don't seem to be very popular on linux-centric lists. Anyway, I don't think think patch adds the delay in the right place. You're adding a 1 second delay to all usb dvb devices. Obviously they don't all need it. I think the problem is not enough delay after the power control, but I don't have any information. I'm CCing Patrick since he's the only one who really knows anything about the dibcom stuff. Anyway, try this patch. If that doesn't work, increase the 100 to 250 then 500 then 1000 and see what it takes. diff -r 3929198de6a7 linux/drivers/media/dvb/dvb-usb/dibusb-common.c --- a/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Tue Jul 17 16:36:20 2007 -0300 +++ b/linux/drivers/media/dvb/dvb-usb/dibusb-common.c Thu Jul 19 02:46:28 2007 -0700 @@ -63,7 +63,7 @@ int dibusb_power_ctrl(struct dvb_usb_dev b[1] = DIBUSB_IOCTL_CMD_POWER_MODE; b[2] = onoff ? DIBUSB_IOCTL_POWER_WAKEUP : DIBUSB_IOCTL_POWER_SLEEP; ret = dvb_usb_generic_write(d,b,3); - msleep(10); + msleep(onoff ? 100 : 10); return ret; } EXPORT_SYMBOL(dibusb_power_ctrl); ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Patch for PCTV200e driver solving NULL pointer dereference
On Sat, 14 Jul 2007, Juan Antonio Garcia wrote: I have tested the patch below (included at the end) and seems to kill the NULL Pointer dereference bug when initializing the PCTV200e driver. does the driver actually work after this patch? I don't see this driver in v4l-dvb, but this doesn't look right to me. If the demod attach fails, it allocates a fake frontend struct and attaches a tuner anyway? How's it supposed to do anything without the demod? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [Em28xx] MPL-licensed V4L kernel modules (em2880)
On Tue, 10 Jul 2007, Markus Rechberger wrote: Stop that MPL discussion, I can put that code offline too and update it with some probably nonfunctional code for several devices but it won't help anyone in the end - so I won't do it. I don't want my work to be stolen by linuxtv people in the end. It's It's funny you should say this, since 99% of the code you are distributing came from linuxtv in the first place! ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] af9005/mt2060 module unload failure
On Thu, 14 Jun 2007, Luca Olivetti wrote: En/na Michael Krufky ha escrit: Why dont you just use dvb_frontend_detach? I retract that comment... The dvb-usb framework does this itself inside dvb-usb-dvb.c , inside dvb_usb_adapter_frontend_exit ... You should not have to do the symbol_put inside af9005-fe.c If you remove that code, does it fix the issue? Well, I'm doing the attach myself to attach the tuner to the frontend the first time it is opened, so if I remove the code there will be at least one reference to the mt2060 (or qt1010, depending on the model) so it cannot be unloaded. The tuner gets attached once when you call dvb_attach() from af9005_fe_init. It will get detached once when dvb_frontend_detach() is called. Everything balanced. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] af9005/mt2060 module unload failure
On Thu, 14 Jun 2007, Michael Krufky wrote: Luca Olivetti wrote: En/na Trent Piepho ha escrit: On Thu, 14 Jun 2007, Luca Olivetti wrote: Well, I'm doing the attach myself to attach the tuner to the frontend the first time it is opened, so if I remove the code there will be at least one reference to the mt2060 (or qt1010, depending on the model) so it cannot be unloaded. The tuner gets attached once when you call dvb_attach() from af9005_fe_init. It will get detached once when dvb_frontend_detach() is called. Everything balanced. but dvb_frontent_detach doesnt' know anynthing about the tuner (since it's in the frontend private data), so if I don't do the put_symbol myself in af9005_fe_release (as I do the dvb_attach myself in af9005_fe_init) there will be a dangling reference count, yes? You are incorrect -- dvb_frontend_detach has access to the entire struct dvb_frontend *fe , and dvb-core will call fe-ops.tuner_ops.release function itself and dvb_frontend_detach will handle the module detachment. Exactly, the dvb_frontend struct contains the tuner. In fact, the pointer returned by the tuner attach functions is just the dvb_frontend pointer you passed in. The tuner attach functions don't return a new tuner object (there is no dvb_tuner object), they add the tuner functions into the frontend. One could have a frontend with no tuner. In af9005_fe_set_frontend(), you do this: ret = state-tuner-ops.tuner_ops.set_params(state-tuner, fep); What you should do is: ret = fe-ops.tuner_ops.set_params(state-tuner, fep); I don't think you need the state-tuner field really. Just replace all the state-tuner-ops... with fe-ops And change (state-tuner != NULL) to (fe-ops.tuner_ops.release != NULL), or add a one bit flag state-tuner_is_attached and use that. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] af9005/mt2060 module unload failure
On Fri, 15 Jun 2007, Luca Olivetti wrote: In af9005_fe_set_frontend(), you do this: ret = state-tuner-ops.tuner_ops.set_params(state-tuner, fep); What you should do is: ret = fe-ops.tuner_ops.set_params(state-tuner, fep); I don't think you need the state-tuner field really. Just replace all the state-tuner-ops... with fe-ops And change (state-tuner != NULL) to (fe-ops.tuner_ops.release != NULL), or add a one bit flag state-tuner_is_attached and use that. Ok, that could be an idea, but it wouldn't explain why my symbol_put_addr messes up the reference count, while the same exact thing done in dvb_frontend_detach wouldn't. Bye It does explain it -- dvb_frontend_detach is running _and_ your code that calls symbol_put_addr is also running. With both of them occurring, this explains the module ref count being screwed up. dvb_frontend_detach calls fe-ops.release, which is af9005_release, which, before returning, does the symbol_put_addr, at the same time that dvb_frontend_detach would do it if it had a fe-ops.tuner_ops.release, But dvb_frontend_detach _does_ have fe-ops.tuner_ops.release(). so, frankly, though at the time it cost me a lot of time to untangle the indirections, I don't see the difference. I.e: with fe-ops.tuner_ops.release not null the sequence is: --in dvb_frontend_detach symbol_put_addr(fe-ops.tuner_ops.release); symbol_put_addr(ptr) (where ptr is a copy of fe) while in my code the sequence is --in af9005_release symbol_put_addr(fe-demodulator_priv-tuner_ops.release); --in dvb_frontend_detach symbol_put_addr(ptr) Nope, your code is doing it like this: dvb_frontend_detach(fe) fe-ops.tuner_ops.release() - mt2060_release() symbol_put_addr(fe-ops.tuner_ops.release == mt2060_release) fe-ops.release() - af9005_fe_release() symbol_put_addr(fe-demodulator_priv-tuner_ops.release == mt2060_release) symbol_put_addr(fe-ops.release == af9005_fe_release) ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC | PATCHES] dibusb-mb / dvb-pll: TESTERS NEEDED!
On Tue, 12 Jun 2007, Michael Krufky wrote: I have finalized the 'removal of static dependencies on the dvb-pll module' changesets, but had to change some things inside the dvb-pll framework in the process. See my dvb-pll tree for the topmost changesets: http://linuxtv.org/hg/~mkrufky/dvb-pll Looks good. I'd use a enum for the tuner id, but that's not a big deal. There is one thing that should be changed: +unsigned const int pll_count = ARRAY_SIZE(pll_list); This should at least be made static, otherwise there really will be a global variable in memory with pll_count in it. Some other source file could use it, so gcc can't delete it. I'd probably make it a macro, or just change: + BUG_ON(pll_desc_id 1 || pll_desc_id pll_count); to + BUG_ON(pll_desc_id 1 || pll_desc_id ARRAY_SIZE(pll_list)); Also, is there a reason for DVB_PLL_UNDEFINED? It doesn't seem like there any way to make use of it. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Wed, 6 Jun 2007, Oliver Endriss wrote:
e9hack wrote:
Trent Piepho wrote:
Does the stv0297 require that no other i2c traffic, to a different device,
appear between the write and the read? Something like:
S stv_addr_W A reg_addr A P
S tuner_addr_W A tuner_data1 A tuner_data2 A P
S stv_addr_R A reg_data NA P
Will the i2c message to the tuner between the two parts of the stv
register
reading sequence be a problem?
The tuner may be a problem, because the stv0297 is the gate for the tuner
i2c-bus.
Correct. Since the I2C gate closes after the following stop condition,
we have a problem, if another I2C transfer happens between gate open and
PLL access:
(1) S stv_addr_W A ...open_gate... P
(2) S eeprom_addr_W A reg_addr A Sr eeprom_addr_R A reg_data NA P
(3) S pll_addr_W A ...pll_data... P
will not work because the I2C gate closes after (2)!
This could be fixed if there was an I2C_M_STOP flag. Have the stv0297 or
another demod that has an i2c gate register a new bridge i2c adapter.
The master_xfer function for this bridge i2c adapter just puts a message to
turn on the i2c gate in front of the transaction and then hands it off the
the real i2c adapter. Since it's a single atomic transaction, you don't need
to worry about another device sneaking in at (2) and closing the gate. If
the device is behind the i2c gate, like the tuner, it's attached to the
bridge i2c adapter, and if it's not, like the eeprom, it's attached to the
real i2c adapter.
It would look something like this:
struct stv0299_state {
i2c_adapter *i2c_adap;
u8 i2c_addr;
...;
}
static int stv0299_master_xfer(struct i2c_adapter *adap,
struct i2c_msg msg[], int num)
{
static char buf[] = { 0x05, 0xb5 };
struct stv0299_state *st = i2c_get_adapdata(adap);
struct i2c_msg gate_msg = { .addr = st-i2c_addr, .flags = I2C_M_STOP,
.buf = buf, .len = sizeof(buf) };
struct i2c_msg *msg_out;
int ret;
msg_out = kmalloc((num + 1) * sizeof(struct i2c_msg), GPF_ATOMIC);
memcpy(msg_out, gate_msg, sizeof(struct i2c_msg));
memcpy(msg_out+1, msg, num * sizeof(struct i2c_msg));
ret = i2c_transfer(st-i2c_adap, msg_out, num+1);
kfree(msg_out);
return ret;
}
The code for i2c_transfer() that I posted in the patch for I2C_M_STOP will
automatically split this into two transactions around the I2C_M_STOP flag,
but both will occur before the i2c adapter's mutex is released so no other
message can sneak in.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [v4l-dvb-maintainer] drivers/media/dvb/b2c2/flexcop-dma.c uses PCI DMA API
On Fri, 8 Jun 2007, Mauro Carvalho Chehab wrote:
Hi Trent,
Here is a patch that does just option B. I have a couple other
patches too.
Tracking the flexcop, I've arrived on a similar patch to yours, but this
approach will duplicate some debug macros. This is somewhat ugly. Since
we need this fix for a late -rc, I think that the better for now is to
use an optional code on Makefile that will add flexcop-dma to
b2c2-flexcop only if flexcop pci support is selected. The end result is
very simple, and will solve the issue.
That is a simple way to solve the issue. My patch was just the simplest
one that made flexcop-dma work inside the flexcop-pci module, which is more
complex, but a better way overall I think. I had another patch that
removed the duplicated macros. The patch series is here:
http://linuxtv.org/hg/~tap/flexcop
Maybe it would be ok for 2.6.23? I'll post the two new patches inline so
they're easier to look at.
-
flexcop: remove unnecessary exports
From: Trent Piepho [EMAIL PROTECTED]
flexcop-dma.c used to be part of b2c2-flexcop.ko, and all its exported
functions were only used by b2c2-flexcop-pci.ko. Now it's part of
b2c2-flexcop-pci, so none of its functions need to be exported anymore.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
+++ b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
@@ -43,14 +43,12 @@ int flexcop_dma_allocate(struct pci_dev
}
return -ENOMEM;
}
-EXPORT_SYMBOL(flexcop_dma_allocate);
void flexcop_dma_free(struct flexcop_dma *dma)
{
pci_free_consistent(dma-pdev, dma-size*2,dma-cpu_addr0,
dma-dma_addr0);
memset(dma,0,sizeof(struct flexcop_dma));
}
-EXPORT_SYMBOL(flexcop_dma_free);
int flexcop_dma_config(struct flexcop_device *fc,
struct flexcop_dma *dma,
@@ -78,7 +76,6 @@ int flexcop_dma_config(struct flexcop_de
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_config);
/* start the DMA transfers, but not the DMA IRQs */
int flexcop_dma_xfer_control(struct flexcop_device *fc,
@@ -119,7 +116,6 @@ int flexcop_dma_xfer_control(struct flex
deb_reg(reg: %03x: %x\n,r0xc,v0xc.raw);
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_xfer_control);
static int flexcop_dma_remap(struct flexcop_device *fc,
flexcop_dma_index_t dma_idx,
@@ -148,7 +144,6 @@ int flexcop_dma_control_size_irq(struct
fc-write_ibi_reg(fc,ctrl_208,v);
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_control_size_irq);
int flexcop_dma_control_timer_irq(struct flexcop_device *fc,
flexcop_dma_index_t no,
@@ -165,7 +160,6 @@ int flexcop_dma_control_timer_irq(struct
fc-write_ibi_reg(fc,ctrl_208,v);
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_control_timer_irq);
/* 1 cycles = 1.97 msec */
int flexcop_dma_config_timer(struct flexcop_device *fc,
@@ -182,7 +176,6 @@ int flexcop_dma_config_timer(struct flex
fc-write_ibi_reg(fc,r,v);
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_config_timer);
#if 0
@@ -205,7 +198,6 @@ int flexcop_dma_control_packet_irq(struc
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_control_packet_irq);
int flexcop_dma_config_packet_count(struct flexcop_device *fc,
flexcop_dma_index_t dma_idx,
@@ -220,6 +212,5 @@ int flexcop_dma_config_packet_count(stru
fc-write_ibi_reg(fc,r,v);
return 0;
}
-EXPORT_SYMBOL(flexcop_dma_config_packet_count);
#endif /* 0 */
flexcop: clean up debug printing functions
From: Trent Piepho [EMAIL PROTECTED]
Common debug macro definitions from flexcop-pci.c and flexcop-dma.c are moved
into a new header named flexcop-pci.h. This header has the flexcop-pci
version of the code that is in flexcop.h.
The debug macro in both flexcop-pci.h and flexcop.h is changed so that it adds
a message level (KERN_DEBUG) to the messages as well as the driver prefix. In
effect this:
printk(i2c success\n)
is changed to this:
printk(KERN_DEBUG b2c2-flexcop: i2c success\n)
The flexcop.h file was checking __FLEXCOP_H__ but defining __FLEXCOP_H___,
with an extra underscore.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
+++ b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
@@ -5,22 +5,7 @@
*
* see flexcop.c for copyright information.
*/
-#define FC_LOG_PREFIX flexcop-pci
-#include flexcop-common.h
-
-#ifdef CONFIG_DVB_B2C2_FLEXCOP_DEBUG
-#define dprintk(level,args...) \
- do { if ((b2c2_flexcop_pci_debug level)) printk(args); } while (0)
-#define DEBSTATUS
-#else
-#define dprintk(level,args...)
-#define DEBSTATUS (debugging is not enabled)
-#endif
Re: [linux-dvb] [v4l-dvb-maintainer] drivers/media/dvb/b2c2/flexcop-dma.c uses PCI DMA API
On Thu, 7 Jun 2007, Mauro Carvalho Chehab wrote:
Mauro,
It appears that your change has caused the following build warning:
WARNING: b2c2_flexcop_debug
[/home/mk/v4l-dvb-master/v4l/b2c2-flexcop-pci.ko] undefined!
Weird, this error didn't appeared on my tests here.
Ok, I'll work on fixing this.
I have another alternative working only on Kconfig stuff, but this seems
to be the cleaner one.
You probably had CONFIG_DVB_B2C2_FLEXCOP_DEBUG off, in which case the
debugging stuff isn't used.
The problem is that when flexcop-dma.c was part of b2c2-flexcop.ko, it used a
non-exported global called b2c2_flexcop_debug.
In flexcop-pci.c, there is a static global called debug, which is slightly
different. They are both a set of bit flags but the flags are different.
Since the functions in flexcop-dma are only used by flexcop-pci, it makes much
more sense to make them part of the pci module instead of the common module.
It will effectively reduce the size of the flexcop-usb driver, since the
pci-only dma functions won't be loaded.
I see three ways to fix the debug symbol:
A) Export b2c2_flexcop_debug in flexcop.c, so that flexcop-dma.c can use it.
The debug messages flexcop-dma writes will be controlled the same way they
were before.
But, this means some debug messages from b2c2-flexcop-pci.ko will be
controlled by the debug parameter of b2c2-flexcop-pci.ko (those from
flexcop-pci.c), and some (those from flexcop-dma.c) will be controlled by
the debug parameter of b2c2-flexcop.ko. IMHO, that's messed up.
B) Change flexcop-dma.c to use the debug parameter of flexcop-pci.c. This
means that parameter will need to change from static global to non-exported
non-static global.
The debug messages from flexcop-dma will now be controlled by the
b2c2-flexcop-pci.ko debug parameter, since it's part of that module.
C) Do away with the separate debug parameter in flexcop-pci, and just export
b2c2_flexcop_debug. Both flexcop-pci and flexcop-usb debugging messages
will be controlled by this parameter. This makes the parameter and the
code the simplest, but it's more limited. Maybe someone just wants
messages from the pci or usb module? It also makes sense to me that
messags printing by module X should be controlled by a parameter to module
X.
Here is a patch that does just option B. I have a couple other
patches too.
--
flexcop: Have flexcop-dma use the flexcop-pci debug parameter
From: Trent Piepho [EMAIL PROTECTED]
Another patch moved flexcop-dma.c from the flexcop common module
(b2c2-flexcop.ko) to the flexcop pci module (b2c2-flexcop-pci.ko), since it's
PCI specific.
Debug printing was controlled by b2c2-flexcop.ko's debug parameter, but now
that it's in b2c2-flexcop-pci.ko, it makes sense for debug printing to be
controlled by b2c2-flexcop-pci.ko's debug parameter.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
--- a/linux/drivers/media/dvb/b2c2/flexcop-dma.c
+++ b/linux/drivers/media/dvb/b2c2/flexcop-dma.c
@@ -5,7 +5,22 @@
*
* see flexcop.c for copyright information.
*/
-#include flexcop.h
+#define FC_LOG_PREFIX flexcop-pci
+#include flexcop-common.h
+
+#ifdef CONFIG_DVB_B2C2_FLEXCOP_DEBUG
+#define dprintk(level,args...) \
+ do { if ((b2c2_flexcop_pci_debug level)) printk(args); } while (0)
+#define DEBSTATUS
+#else
+#define dprintk(level,args...)
+#define DEBSTATUS (debugging is not enabled)
+#endif
+
+#define deb_info(args...) dprintk(0x01,args)
+#define deb_reg(args...) dprintk(0x02,args)
+
+extern int b2c2_flexcop_pci_debug;
int flexcop_dma_allocate(struct pci_dev *pdev, struct flexcop_dma *dma, u32
size)
{
@@ -88,8 +103,8 @@ int flexcop_dma_xfer_control(struct flex
v0x0 = fc-read_ibi_reg(fc,r0x0);
v0xc = fc-read_ibi_reg(fc,r0xc);
- deb_rdump(reg: %03x: %x\n,r0x0,v0x0.raw);
- deb_rdump(reg: %03x: %x\n,r0xc,v0xc.raw);
+ deb_reg(reg: %03x: %x\n,r0x0,v0x0.raw);
+ deb_reg(reg: %03x: %x\n,r0xc,v0xc.raw);
if (index FC_DMA_SUBADDR_0)
v0x0.dma_0x0.dma_0start = onoff;
@@ -100,8 +115,8 @@ int flexcop_dma_xfer_control(struct flex
fc-write_ibi_reg(fc,r0x0,v0x0);
fc-write_ibi_reg(fc,r0xc,v0xc);
- deb_rdump(reg: %03x: %x\n,r0x0,v0x0.raw);
- deb_rdump(reg: %03x: %x\n,r0xc,v0xc.raw);
+ deb_reg(reg: %03x: %x\n,r0x0,v0x0.raw);
+ deb_reg(reg: %03x: %x\n,r0xc,v0xc.raw);
return 0;
}
EXPORT_SYMBOL(flexcop_dma_xfer_control);
@@ -178,7 +193,7 @@ int flexcop_dma_control_packet_irq(struc
{
flexcop_ibi_value v = fc-read_ibi_reg(fc,ctrl_208);
- deb_rdump(reg: %03x: %x\n,ctrl_208,v.raw);
+ deb_reg(reg: %03x: %x\n,ctrl_208,v.raw);
if (no FC_DMA_1)
v.ctrl_208.DMA1_Size_IRQ_Enable_sig = onoff;
@@ -186,7 +201,7
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sat, 2 Jun 2007, Johannes Stezenbach wrote: On Fri, Jun 01, 2007, Oliver Endriss wrote: Any news about this? Imho Trent's patch to add I2C_M_STOP makes sense. According to the stv0299 datasheet, the stv0299 requires this STOP condition, too. This chip seems to be more tolerant though. The current driver does not send STOP before READ, and it works. I re-read the i2c spec (conveniently available from http://i2c-bus.org/ ), and although it doesn't use very clear words I think it says that any device _must_ support repeated start conditions (e.g. section 9 FORMATS WITH 7-BIT ADDRESSES). There's also some more explanation: http://i2c-bus.org/RepeatedStartCondition/ Now, it could well be that the stv0297 i2c interface is broken (broken because it cannot safely be used on a bus with multiple masters), but it may also be quite possible that the stv0297 datasheet is just inaccurate. IMHO both possibilities are just as likely, however I trust adq has actually tested that repeat start doesn't work. http://linuxtv.org/hg/v4l-dvb/rev/c204a1d063aa Then I2C_M_STOP still makes sense, but the patch should document that it's used only a workaround for broken hardware. Well, I tried but no one on the i2c list liked the I2C_M_STOP idea. http://lists.lm-sensors.org/pipermail/i2c/2007-May/001362.html The answer seems to be that one should have your i2c driver use it's own mutex to insure that an i2c transaction with a stop is atomic. That won't work if you try to use both the stv0297 driver and i2cdump from userspace at the same time, so the answer there is just to not do that. If you want to dump the registers, you need to put a copy of i2cdump in the kernel for each driver that you want a register dump from. Then the driver can create a sysfs file with a register dump. That way the in-kernel driver specific i2cdump can use driver's mutex to insure atomic bus access. I'm still unclear on exactly what the stv0297 requires. The datasheet says one can't use a repeated start, but must have a stop between a read and a write. That's simple enough, but has anyone actually verified that the datasheet is really correct? I know many datasheets provide some _examples_ of i2c transactions, but it's by no means an exahstive list. Just because something isn't listed doesn't mean it won't work too. Does the stv0297 require that no other i2c traffic, to a different device, appear between the write and the read? Something like: S stv_addr_W A reg_addr A P S tuner_addr_W A tuner_data1 A tuner_data2 A P S stv_addr_R A reg_data NA P Will the i2c message to the tuner between the two parts of the stv register reading sequence be a problem? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] [RFC] remove static dependencies on dvb-pll
On Sat, 2 Jun 2007, Michael Krufky wrote:
This is _not_ the final version of the patch. There is still one caller
of dvb_pll_configure (dvb-usb-i2c), and that must be removed before I
can remove the dvb_pll_configure export, and store the pointer to the
dvb_pll_desc inside the priv structure, instead of storing the id.
So, let's get rid of that last dvb_pll_configure user!
Here's a patch that does it.
# HG changeset patch
# User Trent Piepho [EMAIL PROTECTED]
# Date 1180812646 25200
# Node ID e92f277e9c25e3d18fa77710217efbeb2bbaee9a
# Parent 98e80288b44b34a8bf46a049338c02fcee328829
dvb-pll digitv dvb-usb: Eliminate last user of dvb_pll_configure
From: Trent Piepho [EMAIL PROTECTED]
The last user of dvb_pll_configure was the dvb-usb function
dvb_usb_tuner_calc_regs(), which was nothing more than a wrapper around
dvb_pll_configure(). It's just a copy of the functionality provided by
the tuner_ops calc_regs method, and can be deleted.
There were two users of dvb_usb_tuner_calc_regs().
One was dvb_usb_tuner_set_params_i2c(), which is converted to use
fe-ops.tuner_ops.calc_regs().
The other was the digitv driver. This driver can use one of two demods,
mt352 or nxt6000. For the mt352, the driver would set
tuner_ops.calc_regs to dvb_usb_tuner_calc_regs(). We can just attach
dvb_pll and use the tuner_ops.calc_regs() provided by that module.
For the nxt600, the driver would set tuner_ops.set_params to
digitv_nxt6000_tuner_set_params. That function would in turn use
dvb_usb_tuner_calc_regs(). We convert it to use tuner_ops.calc_regs()
instead, and use dvb_pll_attach.
The digitv_tuner_attach() needs to know which frontend was attached by
digitv_frontend_attach(), since the nxt6000 needs tuner_ops.set_params()
to be overridden with digitv_nxt6000_tuner_set_params(). So to do this a
digitv_state that says which frontend was used is added to the
dvb_usb_device private state field.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff -r 98e80288b44b -r e92f277e9c25 linux/drivers/media/dvb/dvb-usb/digitv.c
--- a/linux/drivers/media/dvb/dvb-usb/digitv.c Fri Jun 01 20:27:57 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/digitv.c Sat Jun 02 12:30:46 2007 -0700
@@ -118,7 +118,8 @@ static int digitv_nxt6000_tuner_set_para
{
struct dvb_usb_adapter *adap = fe-dvb-priv;
u8 b[5];
- dvb_usb_tuner_calc_regs(fe,fep,b, 5);
+
+ fe-ops.tuner_ops.calc_regs(fe, fep, b, sizeof(b));
if (fe-ops.i2c_gate_ctrl)
fe-ops.i2c_gate_ctrl(fe, 1);
return digitv_ctrl_msg(adap-dev, USB_WRITE_TUNER, 0, b[1], 4, NULL,
0);
@@ -130,21 +131,29 @@ static struct nxt6000_config digitv_nxt6
static int digitv_frontend_attach(struct dvb_usb_adapter *adap)
{
+ struct digitv_state *st = adap-dev-priv;
+
if ((adap-fe = dvb_attach(mt352_attach, digitv_mt352_config,
adap-dev-i2c_adap)) != NULL) {
- adap-fe-ops.tuner_ops.calc_regs = dvb_usb_tuner_calc_regs;
+ st-is_nxt6000 = 0;
return 0;
}
if ((adap-fe = dvb_attach(nxt6000_attach, digitv_nxt6000_config,
adap-dev-i2c_adap)) != NULL) {
+ st-is_nxt6000 = 1;
+ return 0;
+ }
+ return -EIO;
+}
+
+static int digitv_tuner_attach(struct dvb_usb_adapter *adap)
+{
+ struct digitv_state *st = adap-dev-priv;
+
+ if (!dvb_attach(dvb_pll_attach, adap-fe, 0x60, NULL, dvb_pll_tded4))
+ return -ENODEV;
+
+ if (st-is_nxt6000)
adap-fe-ops.tuner_ops.set_params =
digitv_nxt6000_tuner_set_params;
- return 0;
- }
- return -EIO;
-}
-
-static int digitv_tuner_attach(struct dvb_usb_adapter *adap)
-{
- adap-pll_addr = 0x60;
- adap-pll_desc = dvb_pll_tded4;
+
return 0;
}
@@ -273,6 +282,8 @@ static struct dvb_usb_device_properties
.usb_ctrl = CYPRESS_FX2,
.firmware = dvb-usb-digitv-02.fw,
+ .size_of_priv = sizeof(struct digitv_state),
+
.num_adapters = 1,
.adapter = {
{
diff -r 98e80288b44b -r e92f277e9c25 linux/drivers/media/dvb/dvb-usb/digitv.h
--- a/linux/drivers/media/dvb/dvb-usb/digitv.h Fri Jun 01 20:27:57 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/digitv.h Sat Jun 02 12:30:46 2007 -0700
@@ -3,6 +3,10 @@
#define DVB_USB_LOG_PREFIX digitv
#include dvb-usb.h
+
+struct digitv_state {
+int is_nxt6000;
+};
extern int dvb_usb_digitv_debug;
#define deb_rc(args...) dprintk(dvb_usb_digitv_debug,0x01,args)
diff -r 98e80288b44b -r e92f277e9c25
linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
--- a/linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c Fri Jun 01 20:27:57
2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c Sat Jun 02 12:30:46
2007 -0700
@@ -78,26 +78,6 @@ int dvb_usb_tuner_init_i2c(struct dvb_fr
}
EXPORT_SYMBOL(dvb_usb_tuner_init_i2c);
-int dvb_usb_tuner_calc_regs(struct dvb_frontend *fe, struct
dvb_frontend_parameters *fep, u8 *b, int buf_len
Re: [linux-dvb] [RFC] remove static dependencies on dvb-pll
On Fri, 1 Jun 2007, Michael Krufky wrote:
I haven't tested this yet, but it should work just fine...
I will test it when I get home.
This patch removes all static dependencies on the dvb-pll module, without
_any_
harmful side effects.
Any comments?
I think the handling inside dvb-pll might be better a little differently.
Keep the pll_desc inside dvb_pll_priv as a pointer, instead of making it the
pll id number. Look up the pointer from the id once in dvb_pll_attach(), so
it doesn't have to be done for each time a pll function is called.
Instead of making the pll ID an int and using #defines, I'd make the id an
enum. You don't have to manually assign the id numbers that way and it's
clear what supposed to go there.
Instead of using a big switch statement to turn the pll id into a description
pointer, I'd use an array:
dvb-pll.h:
enum dvb_pll_id = {
DVB_PLL_THOMSON_DTT7579,
...
DVB_PLL_LAST
};
dvb-pll.c:
static struct dvb_pll_desc* pll_list[] = {
[DVB_PLL_THOMSON_DTT7579] = dvb_pll_thomson_dtt7579,
... // order doesn't actually have to match the enum
};
struct dvb_frontend *dvb_pll_attach(..., enum dvb_pll_id id)
{
if (id = DVB_PLL_LAST) { some error? BUG()? };
priv-pll_desc = pll_list[id];
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Re: menuconfig not working as expected?
On Wed, 23 May 2007, Mauro Carvalho Chehab wrote: Hi Trent, does this mean v4l-dvb is no longer compatibel with the 2.6.20-kernel ? For the moment, yes. The v4l-dvb source tracks the latest kernel. To make the C code work with older kernels too, we have all kinds of #if/#endif blocks and magic stuff in file called compat.h that takes care of the differences. In this case, the problem is that the Kconfig files are not backward compatible. All the things we do to C code won't work for the Kconfig language. Hmm... Are you meaning handling language changes on Kconfig? Yes, current procedures don't work fine. Language changes would be one example. In this case it's not a language change, there is a new variable HAS_IOMEM that drivers depend on that doesn't exist in the old kernels. So in this case I could hack make_kconfig to assume HAS_IOMEM is true if (it doesn't exist kernel 2.6.22) I'm not sure exactly how to handle this. Maybe we could run the Kconfig files through cpp before using them, so we could use #if/#endif style macros to make them work on old kernels? The same gentree.pl script that cleans the C code would work on the Kconfig files too. This would work, although it seems a hack. As you mentioned, it would make life harder also for make kernellinks. Maybe a better solution would be writing a diff file to be applied at v4l/kconfig if kernel version 2.6.20. How would you keep this patch up to date as the kconfig files change? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Re: menuconfig not working as expected?
On Wed, 23 May 2007, Martin Dauskardt wrote: Date: Tue, 22 May 2007 21:01:32 -0700 (PDT) From: Trent Piepho [EMAIL PROTECTED] Subject: Re: [linux-dvb] Re: menuconfig not working as expected? I tried v4l-dvb-015313b16eab which already includes your patch. But there is still only Enable drivers not supported by this kernel and Audio devices for multimedia ... It is probably leftover files from a previous build. Run make distclean after changes in the build system. There is no previously build. I tried it with a fresh hg. I also checked v4l-dvb-644ef6908cb6 from your repository with the same result. My kernel is a 2.6.20.1 Just to be sure: The changeset 0b52eec65285 build: Update make_kconfig to support depends on in menus is the patch that should fix it? There is no other patch (outside the hg) I have to use? That should be everything. What kernel are you building against? What does grep IOMEM .config return when run in your kernel source directory? I suspect it's the Kconfig files themselves that aren't backward compatible with your kernel. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Wed, 23 May 2007, Manu Abraham wrote: Johannes Stezenbach wrote: On Sun, May 20, 2007, e9hack wrote: With the attached patch, it works for the stv0297 functions. It doesn't solve the problem, why I've wrote the initial patch. I need a dump from the registers of the stv0297. I've attach a second patch. stv0297_attach() inserts a wrapper between i2ctransfer() and the transfer function of the saa7146. The add/del functions for the wrapper are a little bit dirty. I didn't find a clean way for the add/del function. Hm, I was trying to tell you that the problem is in i2cdump, not in saa7146 or stv0297. i2cdump is simply limited to simple SMBUS-like transfers, but I think it wouldn't be difficult to extend it or write a new utility which uses the I2C_RDWR ioctl to perform the transfer as required by stv0297. I have been looking at the STV0297D/E datasheets specifically to check this issue (and i don't see any differences than how it is potentially' differently from other devices): HTH The STV0297D/E datasheet defines the transaction thus .. I2C Read: START SLAVE ADDRESS R/W ACK (STV0297) BASE ADDRESS ACK (STV0297) STOP -- this is different START SLAVE ADDRESS R/W ACK (STV0297) DATA BYTE 1 ACK (Host) DATA BYTE n ACK (Host) STOP The emulated smbus commands that i2cdump uses don't have a stop between writing the base address and reading the data bytes. Check Documentation/i2c/smbus-protocol: SMBus Read Byte Data S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P What the stv0297 wants is: S Addr Wr [A] Comm [A] P S Addr Rd [A] [Data] NA P ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Re: Re: menuconfig not working as expected?
On Wed, 23 May 2007, Martin Dauskardt wrote: That should be everything. What kernel are you building against? What does grep IOMEM .config return when run in your kernel source directory? [EMAIL PROTECTED]:/usr/local/src/linux-2.6.20.1# grep IOMEM .config when I enter this, I get no result That's what I figured would be the problem. I suspect it's the Kconfig files themselves that aren't backward compatible with your kernel. does this mean v4l-dvb is no longer compatibel with the 2.6.20-kernel ? For the moment, yes. The v4l-dvb source tracks the latest kernel. To make the C code work with older kernels too, we have all kinds of #if/#endif blocks and magic stuff in file called compat.h that takes care of the differences. In this case, the problem is that the Kconfig files are not backward compatible. All the things we do to C code won't work for the Kconfig language. I'm not sure exactly how to handle this. Maybe we could run the Kconfig files through cpp before using them, so we could use #if/#endif style macros to make them work on old kernels? The same gentree.pl script that cleans the C code would work on the Kconfig files too. I'm not sure if the Kconfig files have cpp clean syntax, and this could complicate the make kernellinks ability. Note that having non-backward compatible kconfig files also complicates kernellinks. I think in this case, I could put a special case hack in make_kconfig that detects kernel 2.6.22 and does some stuff to make the combined Kconfig backward compatible. That won't help kernellinks though. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: menuconfig not working as expected?
On Tue, 22 May 2007, Martin Dauskardt wrote: Date: Mon, 21 May 2007 11:34:46 -0700 (PDT) From: Trent Piepho [EMAIL PROTECTED] Subject: Re: [linux-dvb] menuconfig not working as expected? One of the backported kernel patches added a new kconfig construct (depends on in a menu) that the build system can't handle. I've already made a patch to fix it that should show up soon. I tried v4l-dvb-015313b16eab which already includes your patch. But there is still only Enable drivers not supported by this kernel and Audio devices for multimedia ... It is probably leftover files from a previous build. Run make distclean after changes in the build system. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] menuconfig not working as expected?
On Mon, 21 May 2007, Stone wrote: Hi, I am using 2.6.21.1 with current HG drivers and when I type make menuconfig in the v4l-dvb directory, I dont get any dvb driver options to select anymore. The only things I see are Enable drivers not supported by this kernel and Audio devices for multimedia. Why are none of the dvb driver options being displayed? Best Regards. One of the backported kernel patches added a new kconfig construct (depends on in a menu) that the build system can't handle. I've already made a patch to fix it that should show up soon. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sun, 20 May 2007, e9hack wrote: Trent Piepho wrote: This would work for stv0297, wouldn't it? With the attached patch, it works for the stv0297 functions. It doesn't solve the problem, why I've wrote the initial patch. I need a dump from the registers of the stv0297. I've attach a second patch. stv0297_attach() inserts a wrapper between i2ctransfer() and the transfer function of the saa7146. The add/del functions for the wrapper are a little bit dirty. I didn't find a clean way for the add/del function. It think your first patch is the way to do it. Most I2C devices use a transaction that looks like: (S=start, P=stop, A=ack) S 0x38 A 0x01 A S 0x39 A 0x42 NA P That would be the transaction that reads the value 0x42 from the register 0x01. But stv0297 is different, it needs an extra stop: S 0x38 A 0x01 A P S 0x39 A 0x42 NA P It seems like the proper solution is to have the I2C master (saa7146) send the i2c_msg[] that it's given. The stv0297 driver should send the correct i2c transaction (the second one), not send the wrong transaction (the first one) and expect the I2C master to special-case hack it into the right one. W.r.t. i2c_dump, the problem is that it's sending the wrong transaction to read an stv0297 register. So the proper solution is to fix i2c_dump to send the correct transaction. Isn't i2c_dump maintained by the same group that does the I2C core? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sun, 20 May 2007, Manu Abraham wrote:
Don't you think that the STV0297 (the obvious case that i looked at was
b2c2 flexcop) B2C2 cablestar.
In this case looking at flexcop-i2c.c flexcop_i2c_read4(foobar)
if ((ret = flexcop_i2c_operation(fc, r100)) != 0) {
/* The cablestar needs a different kind of i2c_transfer (does not
* support Repeat Start);
* wait for the ACK failure,
* and do a subsequent read with the Bit 30 enabled
*/
..
Now, to me it looks a rather bit strange: the reason being the transfer
here just needs a stop bit in between which exactly is a very normal
transaction with START/STOP bits, just that the whole transaction is
looped for 4 bytes.
This mode is exactly a BYTE mode which is a loop for 4 bytes and not a
PAGE mode transfer, what we normally have under Linux.
So what i think would be better, probably would be like this:
* pass a flag to master_xfer to define the mode of operation say a flag
PAGE_MODE or BYTE_MODE [1] Page 9
now master_xfer looks for the FOO_MODE flag and decides what transfer to
be done.
[1] http://www.tranzistoare.ro/datasheets/150/501070_DS.pdf
The page mode vs byte mode from that eeprom datasheet is just something
internal to the way the eeprom's write latches work. It has nothing to do
with the I2C protocol. The I2C transaction for a multi-byte write and page
mode write is exactly the same. In mutli-byte mode, the write is limited
to 4 bytes and can start at any address. In page mode the write can be up
to 8 bytes, but must start at an 8-byte aligned address.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Fri, 18 May 2007, Johannes Stezenbach wrote: On Fri, May 18, 2007 at 04:48:13PM +0200, e9hack wrote: Johannes Stezenbach wrote: According to linux/Documentation/i2c/i2c-protocol.txt the correct way to get a STOP condition between two I2C messages is send them in seperate I2C transactions. I don't find this description in i2c-protocol. It's not written explicitly, but it says you need to use a Simple send transaction and/or a Simple receive transaction instead of a Combined transaction if you want a STOP bit in between. That's how i2c-core is designed. IMHO, it isn't possible to split a read request into a single write and a single read request outside of the core device. The device must be locked during both transfers. If the device isn't locked, it is possible that another transfer will change the slave offset before the content is read. This may occur with the current implementation. If locking is necessary the drivers would need to handle this explicitely (I think it isn't unless ou start messing mith /dev/i2c concurrently). Or you could propose a change to i2c-core to add a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which then would have to be implemented by all i2c bus drivers. It seems like this is the only way to send multiple stops in a single atomic transaction. All drivers wouldn't have to implement it, just the ones where someone actually wants this ability. Few drivers actually implement all of the existing i2c features. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] make the registers of the stv0297 visible for other applications (e.g. i2cdump)
On Sat, 19 May 2007, e9hack wrote:
Trent Piepho wrote:
On Fri, 18 May 2007, Johannes Stezenbach wrote:
Or you could propose a change to i2c-core to add
a I2C_M_STOP flag (analogous to I2C_M_NOSTART), which
then would have to be implemented by all i2c bus drivers.
It seems like this is the only way to send multiple stops in a single
atomic transaction. All drivers wouldn't have to implement it, just the
ones where someone actually wants this ability. Few drivers actually
implement all of the existing i2c features.
It is a big difference between the I2C_M_STOP and the I2C_M_NOSTART flag.
I2C_M_NOSTART is a nice feature, which a
master may implement. If I look through the different implementations, it
isn't defined exactly, what it means.
I2C_M_STOP is a must have for the master, if a slave is connected to the bus
like the stv0297.
It doesn't seem any different than I2C_M_TEN, I2C_M_NO_RD_ACK, etc. in that a
slave that needs one of these features won't work with a master (i2c_adapter
in Linux I2C terms) that doesn't implement them. There are plenty of i2c
adapters that don't even support messages longer than two bytes or
transactions with more than one or two parts.
It isn't necessary, that I2C_M_STOP is implemented by the master itself. It
is possible to implement it in i2ctransfer.
If the flag is set, each entry of the message array is send as a single
request to the underlaying transfer function of
That's a good point, i2c_tranfer() is basically:
mutex_lock(i2c_adapter-mutex);
i2c_adapter-master_xfer(...);
mutex_unlock(i2c_adapter-mutex);
The problem with stv0297 is that one wants multiple calls to master_xfer()
inside the mutex protected region. It would be easy to have this code break a
series of i2c messages into multiple calls to master_xfer() with a I2C_M_STOP
flag. Then all i2c_adapters could support I2C_M_STOP without needing to be
changed. One could also support the flag inside an i2c_adapter driver, but
there doesn't seem to be much point.
I've written a patch that implements I2C_M_STOP. It would be used like this:
char buf1[2] = {0x0b,0x3c}, buf2[1];
struct i2c_msg msgs[2] = {
{ .addr = 0x61, .buf = buf1, .len = 2, .flags = I2C_M_STOP },
{ .addr = 0x61, .buf = buf2, .len = 1, .flags = I2C_M_RD } };
i2c_transfer(adap, msgs, 2);
_Without_ the I2C_M_STOP flag, one would see a transfer like this:
i2c-adapter i2c-0: emitting start condition
i2c-adapter i2c-0: i2c_outb: 0xc2 A
i2c-adapter i2c-0: i2c_outb: 0x0b A
i2c-adapter i2c-0: i2c_outb: 0x3c A
i2c-adapter i2c-0: wrote 2 bytes
i2c-adapter i2c-0: emitting repeated start condition
i2c-adapter i2c-0: i2c_outb: 0xc3 A
i2c-adapter i2c-0: i2c_inb: 0x74 NA
i2c-adapter i2c-0: read 1 byte
i2c-adapter i2c-0: emitting stop condition
_With_ the I2C_M_STOP flag, one sees this:
i2c-adapter i2c-0: emitting start condition
i2c-adapter i2c-0: i2c_outb: 0xc2 A
i2c-adapter i2c-0: i2c_outb: 0x0b A
i2c-adapter i2c-0: i2c_outb: 0x3c A
i2c-adapter i2c-0: wrote 2 bytes
i2c-adapter i2c-0: emitting stop condition
i2c-adapter i2c-0: emitting start condition
i2c-adapter i2c-0: i2c_outb: 0xc3 A
i2c-adapter i2c-0: i2c_inb: 0x74 NA
i2c-adapter i2c-0: read 1 byte
i2c-adapter i2c-0: emitting stop condition
This would work for stv0297, wouldn't it?
diff -r 56b4c3e8f350 drivers/i2c/i2c-core.c
--- a/drivers/i2c/i2c-core.cSat May 19 05:00:32 2007 +
+++ b/drivers/i2c/i2c-core.cSat May 19 17:35:19 2007 -0700
@@ -862,6 +862,7 @@ int i2c_transfer(struct i2c_adapter * ad
int ret;
if (adap-algo-master_xfer) {
+ int n, total = 0;
#ifdef DEBUG
for (ret = 0; ret num; ret++) {
dev_dbg(adap-dev, master_xfer[%d] %c, addr=0x%02x,
@@ -872,10 +873,28 @@ int i2c_transfer(struct i2c_adapter * ad
#endif
mutex_lock_nested(adap-bus_lock, adap-level);
- ret = adap-algo-master_xfer(adap,msgs,num);
+ for (n=1; n=num; n++) {
+ /* xfer the message(s) if we want a stop or if
+ it's the last message. */
+ if (n == num || (msgs[n-1].flags I2C_M_STOP)) {
+ ret = adap-algo-master_xfer(adap,msgs,n);
+
+ total += ret;
+ if (ret n) {
+ /* Return error code, if any */
+ if (ret 0)
+ total = ret;
+ break;
+ }
+
+ /* Process any remaining messages */
+ msgs += n;
+ num -= n;
+ n = 0;
+ }
+ }
mutex_unlock(adap-bus_lock
[linux-dvb] Re: [RFC/PATCHES] xc3028 hybrid tuner, em28xx/em2880-dvb, saa7134, cx88
On Mon, 14 May 2007, Markus Rechberger wrote: Hi all, I exported the patches of my v4l-dvb-experimental repository against the current v4l-dvb repository on linuxtv.org. The single patchfiles are available on mcentral.de http://mcentral.de/~mrec/patches/v4l-dvb/ [93 patches] It's really hard for anyone to make sense of a patch bomb like this. There's just too many changes, and none of the patches even have comments longer than one line. The organization of the patches is really hard to follow too. For example, patch 19 adds a NULL pointer check to tuner-core (why is this necessary?) and then also adds two register names names to the dvb zl10353 driver. Those changes have nothing to do with each other. It's patch 20 that actually adds the code to zl10353 that uses the new registers, and it even changes the names used in patch 19. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [patch] TT C-1200 USB wrong frequency
On Mon, 7 May 2007, Thomas Kaiser wrote: Trent Piepho wrote: I looked at the code again, and I mis-read the budget-ci DVB-C tuner, it should have been: budget-ci DVB-T 195 1/8 MHz budget-ci DVB-C 160 MHz (wrong!) ttusb-budgetDVB-T 195 1/8 MHz ttusb-budgetDVB-C 236 1/8 MHz (wrong?) In other words, DVB-C was 160 MHz when it should have been near 200 MHz. Anyway, this http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=e7c424bbf9aa;style=gitweb change is wrong anyway and should be reverted. You're right, reverting this change will make it go from 160 MHz to 200 MHz. It still looks to me like the ttusb-budget driver has the bug in the DVB-C td1316 tuner code, as it switches at 236.13 Mhz where as all the other td1316 code uses 195 ~ 200 MHZ as a switch point. Yes, the bug is still there in the ttusb-budget tda1316 tuner code. My patch (it wasn't really a patch :-( ) was applied to the wrong file. One thing I don't really understand. Why do we have to add the IF frequency to determine the frequency for the band switch (it's a long time since I repaired televisions)? No reason, it shouldn't make any difference. if(x 159) is mathmatically the same as: if((x+36) (159+36)) It's just an arbitrary choice if you should define the bands before or after the IF offset is taken into account. The bug in ttusb-budget looks like it came from someone cutpasting code without taking this into account. When I look in the docs of the tuner, it is written: Low band 49 to 159 MHz Mid band 162 to 444 MHz High band 448 to 862 MHz This is the Channel center frequency including tuning margin. Are the docs available somewhere? I couldn't find them on google. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] wrong frontend assignment when 1 frontend missing on 2 adapter setup
On Wed, 9 May 2007, Lucian Muresan wrote: blues dvb # ls -al /dev/dvb/* /dev/dvb/adapter0: total 0 drwxr-xr-x 2 root root 100 May 9 2007 . drwxr-xr-x 4 root root 80 May 9 2007 .. crw-rw 1 root video 212, 4 May 9 2007 demux0 crw-rw 1 root video 212, 5 May 9 2007 dvr0 crw-rw 1 root video 212, 7 May 9 2007 net0 /dev/dvb/adapter1: total 0 drwxr-xr-x 2 root root 120 May 9 2007 . drwxr-xr-x 4 root root 80 May 9 2007 .. crw-rw 1 root video 212, 68 May 9 2007 demux0 crw-rw 1 root video 212, 69 May 9 2007 dvr0 crw-rw 1 root video 212, 67 May 9 2007 frontend0 crw-rw 1 root video 212, 71 May 9 2007 net0 Nevertheless, I wanted to point out that it seems that the frontend which was found, namely the one from the HVR-1300 was hooked under the DVB-S adapter (maybe by udev?), and thus none of the 2 cards where So the frontend that didn't work because of missing lnbp21 support was the DVB-S one? And the the DVB-S adapter is adapter1, and the HVR-1300 is adapter0? Or is it different? What I'm asking is, is adapter0 or adapter1 the device that needs lnbp21? Keep in mind that which card ends up as adapter0 or 1 is not necessarily the always going to be the same. It's not clear to me that there really is a DVB problem. It looks like maybe adapter0 is the one that needs he missing driver, and so is missing its fontend, and adapter1 is fine. actually usable (like I said, kaffeine refused to show them as detected). Which could be a kaffeine problem. It might see that adapter0/frontend0 doesn't exist, and then assume it has found all adapters. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On Wed, 2 May 2007, Manu Abraham wrote: I've been aware of the problem with dst not fully using the dvb customization systems(*) for a long time. It came up when dvb_attach() et al were first being integrated, well before any rejected patches or strongly worded emails or whatever from certain people that I'm aware of. Well, your understanding of the device is quite limited and hence your comments and patches. Manu, have you actually looked at the patch? It seems like you are just rejecting everything that has anything to do with dst out of hand. Can you point to any line of code there, and say what it breaks or what it will make impossible? These features are not the characteristics of a DVB Frontend. Here there is a DVB frontend like the normal ones which is hidden behind another pseudo bridge (So you don't have *any* access to the frontend at large) Again, did you actually look at the patch? I never so much as used the word frontend to describe the dst. I didn't change the operation of the dst in any way. I didn't move it to a new place in the framework. The bt8xx driver talks to the dst module via the dvb_frontend object, my patch has nothing to do with this. It is a simple patch for simple programming issues and nothing to do with these larger issues you bring up. I would think that it would be *extremely* rude for a person to send in patches for a device that which you don't understand at all, when it is for limiting the capability of the said device Is the problem that there is a bug in my patch? Or is your problem that I was rude in submitting any patch at all that had anything to do with your code? Do you feel that this part of the Linux kernel is owned by you, and that no one else should be permitted to have anything to do with it? (*) There are two customization/dependency control systems in DVB. One is dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely separate systems, but overlap in their design a great deal. Here we have the attach method attaching different objects, but basically it can be handled for the frontend devices only (and that too that share a very common trait, in this case, frontends are coupled using the i2c bus) and not for other devices. Situation changes when you use another interface such as SPI, where the interface is not well defined. This is not correct. The dvb_attach() system has no assumption that it will be used for a front-end device. There are already users which are not front-ends, such as tuners or lnb supply control chips, and yes, dst, which will all know very well is not a frontend. It also has nothing do with the i2c. The attached device could be connected in any way. I plan to add dvb_attach() support for the cx88 secondary i2c bus driver (aka vp3054), and that isn't even a different chip. This design means the actual hard link between different drivers is limited to each driver's single attach function (**). By breaking this one link, we can control which drivers must be loaded or linked to only those necessary or wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of controlling these links. dvb_attach will have to go away for the DST. It doesn't work for the mentioned reasons that it is just pushing the device to a corner as a DVB frontend whereas it is not a DVB Frontend at all. The dst is already using dvb_attach()! I'm not changing that at all. being the author and maintainer of dst/dst_ca and maintainer of dvb-bt8xx, i NACK this change Can one become a maintainer just be declaring ones self to be so? Or is there an expectation that a maintainer will in fact, maintain. That is to say, address concerns in a timely fashion, review patches and work in good faith to resolve problems with said patches. What i would like to do is like this: Have the current state frozen as it is, So as maintainer you are declaring that no changes of any kind are permitted? That is to say, the code should become frozen, un-fixed and un-updated, in other words, _unmaintained_. How can you have it both ways, that you are the maintainer and that it should be unmaintained? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Request xc3028_release symbol when CONFIG_DVB_CORE_ATTACH is defined
On Mon, 7 May 2007, System Administrator wrote: my previous suggestion, dvb_frontend_detach would still try to call symbol_put_addr on xc3028_release even though there was no previous symbol_request call for that symbol. That would cause the Used by reference counter for xc3028_tuner to become a negative value meaning that the module could not be unloaded. The kernel reference counting is done at the module level, not the symbol level. Normally what happens is that when dvb_attach() is used to, it does a symbol_get() on the attach_XXX() function. At release time, the symbol_put() is done on at the release_XXX() function. Since both functions should be in the same module, it has the desired effect. If you're seeing the counter wrap around, dvb_attach() was probably not used in the first place, or the is an extra symbol_put() in there some place. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [patch] TT C-1200 USB wrong frequency
On Wed, 2 May 2007, Thomas Kaiser wrote: Trent Piepho wrote: driver tuner post-IF-offset low-mid band switch point budget-ci DVB-T 195 1/8 MHz (to two decimal places) budget-ci DVB-C 200 MHz (this is the likely correct value) ttusb-budgetDVB-T 195 1/8 MHz (to two decimal places) ttusb-budgetDVB-C 236 1/8 MHz (this is clearly wrong) I looked at the code again, and I mis-read the budget-ci DVB-C tuner, it should have been: budget-ci DVB-T 195 1/8 MHz budget-ci DVB-C 160 MHz (wrong!) ttusb-budgetDVB-T 195 1/8 MHz ttusb-budgetDVB-C 236 1/8 MHz (wrong?) In other words, DVB-C was 160 MHz when it should have been near 200 MHz. Anyway, this http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=e7c424bbf9aa;style=gitweb change is wrong anyway and should be reverted. You're right, reverting this change will make it go from 160 MHz to 200 MHz. It still looks to me like the ttusb-budget driver has the bug in the DVB-C td1316 tuner code, as it switches at 236.13 Mhz where as all the other td1316 code uses 195 ~ 200 MHZ as a switch point. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Handle failures to create devices
I've tested this and can confirm it works. dvb_class will be set too late without the change to subsys_initcall. On Tue, 1 May 2007, Simon Arlott wrote: dvb-core is not started early enough when device drivers that use dvb are compiled in so device_register_device fails (silently) since dvb_class is ^dvb_register_device NULL, this runs dvb_init using subsys_initcall instead of module_init. dvb_register_device will now check the return value of class_device_create. All the printks had missing level prefixes so I've fixed these too. Probably better to make this a separate patch, since it's not related. - printk (%s: could get find free device id...\n, __FUNCTION__); + printk(KERN_ERR %s: could get find free device id...\n, __FUNCTION__); couldn't find free device id If it's ok with you, I'll import your patch as two seperate patches with the spelling errors fixed? + dprintk(KERN_DEBUG DVB: register adapter%d/%s%d @ minor: %i (0x%02x)\n, adap-num, dnames[type], id, nums2minor(adap-num, type, id), nums2minor(adap-num, type, id)); The dvb-core dvbdev_debug parameter does nothing but turn on this one single dprintk. I'm tempted to just delete it. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] Request xc3028_release symbol when CONFIG_DVB_CORE_ATTACH is defined
On Mon, 7 May 2007, System Administrator wrote: On Mon, 2007-05-07 at 06:20 +1000, System Administrator wrote: I think that the bug is that xc3028_attach is returning 0 to indicate success whereas dvb_attach() is treating 0 as failure? Hello again, I have verified that this is indeed what is happening. xc3028_tuner should be returning a pointer on success, not 0. Here's a patch to fix that. You're right, dvb_attach() expects the function will return a pointer, so NULL == failure. dvb_attach() does a symbol_put() on failure, but not on success, since it needs to keep a reference to the module it attached to. It's important that symbol_get() (via symbol_request) is called _before_ the attach function is called, and that symbol_put() is called _after_ the release function. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Thu, 3 May 2007, Mauro Carvalho Chehab wrote:
Em Qua, 2007-05-02 ??s 04:10 -0700, Trent Piepho escreveu:
I promise, this time it's right!
http://linuxtv.org/hg/~tap/dst-new
Confirmed. Now the patch is properly working. My tests were done with a
board with DST. Those are the results:
1) when DST is unselected, on a board with DST, it will print the errors
indicating that the Kconfig items were not selected:
DVB: registering new adapter (bttv0).
DVB: Unable to find symbol dst_attach()
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
The only issue is the wrong printk msg, stating that a frontend driver
were not found. As this issue also happens with the current driver, due
the usage of dvb_attach() macro, I don't see any regressions.
It would be nice, however, to have a patch making dvb_attach more
generic, by e.g. having a variant that allows passing another message.
Only this message is from dvb_attach():
DVB: Unable to find symbol dst_attach()
Is it saying that it cannot load the module that dst_attach() is in (it
doesn't know what module that is, modprobe knows that). If you enabled dst
support and deleted the module, it would be the same.
If you turn off dvb_attach() and also disable dst, you should instead get
this message:
dst_attach: driver disabled by Kconfig
Maybe that would look nicer with a DVB: prefix? That would easier if it
wasn't necessary to update the printk in each boilerplate stub function. What
if one macro created these stubs
frontend_init: Could not find a Twinhan DST.
dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem
fbfb/f800
These two messages are printed by the dvb-bt8xx driver, not by dvb_attach().
It would be trivial to change of course, but I'm not sure what would be
pedantically correct for both dst and non-dst based hardware.
There's an argument against the prototype changes on dst_attach and
dst_ca_attach since they aren't frontend.
The reason I changed that, is the dst_attach() already did return a
dvb_frontend pointer, it was just inside an enclosing structure. i.e. what
existed before:
{
struct dst_state *state;
state = dst_attach(...);
card-fe = state-frontend;
} /* state goes out of scope */
The frontend is inside the state struct and the state pointer isn't saved
anywhere. dvb-bt8xx just saves a frontend pointer from inside the dst state
and tosses the state pointer away. So I changed that to:
card-fe = dst_attach(...);
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: Em Ter, 2007-05-01 ??s 16:16 -0700, Trent Piepho escreveu: On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new With the changes, the dst unselection worked. Those are the logs with dst unselected: DVB: registering new adapter (bttv0). DVB: Unable to find symbol dst_attach() frontend_init: Could not find a Twinhan DST. dvb-bt8xx: A frontend driver was not found for device 109e/0878 subsystem fbfb/f800 This is the dvb_attach() not found message. You should see this same message if you leave dst selected and then just delete the dst modules before loading dvb-bt8xx. If you turn dvb_attach off, you should see a different dst support was disabled message (and no crash!). However, when dst is selected, I got those errors: When I made this patch I was basing it off a patch I made around 9 months ago. I thought since that one was ok, this would be ok too, and in my hurry to get it done I've clearly put too little effort into checking it, and I'm sorry to have wasted your time. I promise, this time it's right! http://linuxtv.org/hg/~tap/dst-new ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem with TT C1500
On Wed, 2 May 2007, Robert wrote: I managed to track this down to two things. Firstly if I used the NVIDIA binary drivers, I had this problem, but if I used the nv driver I didn't. For me using the nv driver wasn't really an option (MythTV menus were horribly slow) I had this same problem (and so did others) with a pcHDTV HD-3000 ATSC card receiving QAM-256. With the nvidia binary driver, graphics activity would kill reception, while the nv driver didn't have this problem. 8-VSB reception, which doesn't need as high a SNR, is ok with the nvidia driver. I could run azap and watch the lock and SNR readings. If nothing was happening, they would be ok. But as soon as I moved a window around or started mplayer or scrolled an xterm, the SNR would drop and lock would be lost. I've seen reports that changing to a different power supply would fix the issue. Something about the nvidia graphics chip creating noise in the power supply rails, and a better power supply having better filtering. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [patch] TT C-1200 USB wrong frequency
On Tue, 1 May 2007, Petri Helin wrote:
Thomas Kaiser wrote:
Suur Karu wrote:
Thomas Kaiser wrote:
If your device is using the philips tda1316 tuner, i think there is a
problem in setting the correct Band. 162 MHz and above should be band
2 (Mid-Band). But in dvbc_philips_tdm1316l_tuner_set_params band 1 is
set for frequencies below 200 MHz:
// determine charge pump
tuner_frequency = params-frequency;
if (tuner_frequency 8700) {return -EINVAL;}
else if (tuner_frequency 13000) {cp = 3; band = 1;}
else if (tuner_frequency 16000) {cp = 5; band = 1;}
else if (tuner_frequency 2) {cp = 6; band = 1;} ==
Just to let you all know, in case you didn't see an earlier post about
tuning problems with TechnoTrend's C1500 card, the above change broke
tuning on those cards with frequencies under 160MHz.
That doesn't seem possible, that it would break tuning for under 160Mhz.
This change only affects the band for frequencies between 160 Mhz and 200
Mhz, nothing outside this of this range should be affected in any way.
What frequency does it break exactly?
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] dvb-core: Handle failures to create devices
On Tue, 1 May 2007, Simon Arlott wrote: dvb-core is not started early enough when device drivers that use dvb are compiled in so device_register_device fails (silently) since dvb_class is NULL, this runs dvb_init using subsys_initclass instead of module_init. dvb_register_device will now check the return value of class_device_create. Good catch. + printk(%s: failed to create device dvb%d.%s%d (%ld)\n, __FUNCTION__, + adap-num, dnames[type], id, PTR_ERR(clsdev)); + return PTR_ERR(clsdev); printk(KERN_ERR ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Simon Arlott wrote: On 30/04/07 22:17, Markus Rechberger wrote: From my side I do not see any problem with that patch, if someone else has a problem with it please state out the reason. I have no problem with the patch since it has nothing to do with my DVB card but you're only encouraging Uwe to be abusive since it seems to help get him what he wants: I've been aware of the problem with dst not fully using the dvb customization systems(*) for a long time. It came up when dvb_attach() et al were first being integrated, well before any rejected patches or strongly worded emails or whatever from certain people that I'm aware of. I saw some discussion about dst by Markus, Mauro, and Andrew Morton, and since I already know about the issues here, I felt I should post a patch for them any other reasonable developers who might spend time on this. If there is an abusive person, I'm not going to let it affect my behavior. You lose if you let them influence your decisions one way, or influence them another way. (*) There are two customization/dependency control systems in DVB. One is dvb_attach(), the other is DVB_FE_CUSTOMISE. They are not two entirely separate systems, but overlap in their design a great deal. The significant part, common to both, is the overall design of the driver framework. DVB uses what I would describe as an object oriented system. A driver for a certain type of hardware exports a single attach function, which returns an object for one instance of that hardware. All control of that hardware is done via methods defined in this object. There is typical hierarchy, where an 'adapter' object will contain a 'frontend' object which will contain a 'tuner' object. Of course hardware designers are not constrained by the software frameworks we create, so sometimes it's more complex (e.g., dst). This design means the actual hard link between different drivers is limited to each driver's single attach function (**). By breaking this one link, we can control which drivers must be loaded or linked to only those necessary or wanted. dvb_attach() and DVB_FE_CUSTOMISE are two different ways of controlling these links. dvb_attach() is based on symbol_request() A. It's only useful with modules B. It doesn't prevent drivers from being compiled C. It allows one to build support for hardware, yet not actually load that support until it is needed. This allows supporting a wide array of possible hardware without a large amount of wasted resources, useful for distribution kernels for example. DVB_FE_CUSTOMISE is based on Kconfig and static inline stub functions A. It works with drivers compiled into the kernel, not using modules. B. It prevents drivers from even being compiled in the first place. C. Disabled drivers are truly disabled, it is not possible to have support for hardware and yet not load it. This is useful for the smallest simplest kernel, for set top boxes and the like. It's entirely possible to use both at once: compile some drivers into your kernel, leave others as modules, not compile modules for hardware you don't have, only load the modules for the hardware you are using at the moment, and still support hardware you might connect later. (**) The dvb-pll module still exports more symbols than just dvb_pll_attach(), that is why the customization systems don't fully work with it yet. It also exports dvb_pll_configure(), an obsolete interface which only a couple remaining users that have yet been converted. And it exports PLL definition structs, which isn't a difficult problem and I know several ways to fix it, we just haven't decided or actually done it yet. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: DST/BT878 module customization (.. was: Critical points about ...)
On Tue, 1 May 2007, Mauro Carvalho Chehab wrote: With this configuration, dvb-bt8xx hangs during initialization, generating an OOPS, if you have a board with DST (modprobe dvb-bt8xx never returns). Stupid typo in the first patch, a != should have been ==. Fixed: http://linuxtv.org/hg/~tap/dst-new ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216me integration (fwd)
On Mon, 30 Apr 2007, e9hack wrote:
I've some question to this patch:
Trent Piepho wrote:
Include the patch this time
diff --git a/linux/drivers/media/dvb/frontends/dvb-pll.c
b/linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c
@@ -38,6 +38,12 @@
0x50 = AGC Take over point = 103 dBuV */
static u8 tua603x_agc103[] = { 2, 0x80|0x40|0x18|0x06|0x01, 0x00|0x50 };
+/* 0x04 = 166.67 kHz divider
+
+ 0x80 = AGC Time constant 50ms Iagc = 9 uA
+ 0x20 = AGC Take over point = 112 dBuV */
+static u8 tua603x_agc112[] = { 2, 0x80|0x40|0x18|0x04|0x01, 0x80|0x20 };
Why is the AGC time constant set permanently to 50ms (short time)? Usually,
the AGC time constant of the tuner is set to
the short time during tuning only. After the pll lock + some time (ca.
100ms), the AGC time constant should be switched
back to 2s (long time). If the time constant isn't changed during tuning,
they should be set to the long time.
Is this so that the AGC circuit can quickly adjust to the input level of
the new channel, but then have less AGC created noise added later?
Anyway, the 50ms AGC time constant is what is recommended in the fmd1216me
datasheet. It explicitly says in DVB-T mode, ATC == 1. And this is what
the existing users of the fmd1216me have been using (those that set AGC).
Maybe for this tuner, the smaller time constant is better? Adding support
for changing AGC settings after tuning is an entirely new patch.
.setbw = fmd1216me_bw,
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
In sleep mode, the AGC shouldn't be set into high impedance mode. A
better solution is to disable the AGC. 0x60 should be 0x70. In sleep
mode, P0 and P1 must be set to 1. This means 0x54 should be 0x54|0x03.
Why is the value of the band switch byte 0x54? Bits 5,6 and 7 aren't
used.
This isn't exactly sleep mode. See the earlier thread in this list with
the other Hartmut. When the DVB driver closes, the frontend (not just
PLL!) is put into analog mode so that the v4l driver will work.
Port P4 appears to control the tda9887 analog demod chip. This is why bit
port bit 0x10 is set. It's also why 0x03 sleep mode isn't used; the PLL's
port must remain on.
Setting the AGC to high-Z is what the datasheet recommends for analog mode.
I guess there is some other AGC source (I think the tda9887 has an agc
output, maybe that is it?). Again, this is also an existing intentional
effect of code in saa7134 which this patch replaces.
Why is port bit 0x40 set? I don't know. All the existing code does this.
The fmd1216me datasheet doesn't say what that bit does. The TUA6034
datasheet indicates the bit is unused. Yet several different examples in
the fmd1216me datasheet explicitly set port bit 0x40. It's either A) has
an important yet undocumented function, or B) has no affect what-so-ever.
Either way, seems safest to just leave it.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [patch] TT C-1200 USB wrong frequency
On Wed, 2 May 2007, Petri Helin wrote:
If your device is using the philips tda1316 tuner, i think there is a
problem in setting the correct Band. 162 MHz and above should be band
2 (Mid-Band). But in dvbc_philips_tdm1316l_tuner_set_params band 1 is
set for frequencies below 200 MHz:
// determine charge pump
tuner_frequency = params-frequency;
if (tuner_frequency 8700) {return -EINVAL;}
else if (tuner_frequency 13000) {cp = 3; band = 1;}
else if (tuner_frequency 16000) {cp = 5; band = 1;}
else if (tuner_frequency 2) {cp = 6; band = 1;} ==
Just to let you all know, in case you didn't see an earlier post about
tuning problems with TechnoTrend's C1500 card, the above change broke
tuning on those cards with frequencies under 160MHz.
That doesn't seem possible, that it would break tuning for under 160Mhz.
This change only affects the band for frequencies between 160 Mhz and 200
Mhz, nothing outside this of this range should be affected in any way.
What frequency does it break exactly?
The problem seams to be that the fix was applied in the wrong file -
budget-ci.c instead of dvb-ttusb-budget.c as supposed to.
dvbc_philips_tdm1316l_tuner_set_params in budget-ci.c uses an offset of
36125000 for frequency before assigning the charge pump and band (what's
the need for this offset??) and therefore the failing frequencies (for
example 138MHz and 146MHz) are actually interpreted as something between
160MHz and 200MHz when the band is set.
This offset is the IF frequency. Search this list for if frequency and
you should find plenty of information.
These tuning functions are old code, and should be converted into users of
dvb-pll. I'll put it on my dvb-pll todo list, right after fmd1216me is
committed.
In budget-ci.c, philips_tdm1316l_tuner_set_params() uses 159 Mhz
*pre-IF-offset* as the low-mid band switch point. While
dvbc_philips_tdm1316l_tuner_set_params() uses 200 MHz *post-IF-offset* as
the band switch point.
In dvb-ttusb-budget.c, philips_tdm1316l_tuner_set_params() uses 159 MHz
pre-IF-offset. And dvbc_philips_tdm1316l_tuner_set_params() uses 200 MHz
pre-IF-offset.
This 4x duplication of the same code with random bugs in some copies is
exactly why this should be converted to dvb-pll!
I think it is highly likely that the band switch point post-IF-offset is
the same for both the DVB-T and the DVB-C tuners.
driver tuner post-IF-offset low-mid band switch point
budget-ci DVB-T 195 1/8 MHz (to two decimal places)
budget-ci DVB-C 200 MHz (this is the likely correct value)
ttusb-budgetDVB-T 195 1/8 MHz (to two decimal places)
ttusb-budgetDVB-C 236 1/8 MHz (this is clearly wrong)
My guess is the correct value is 200 MHz, not 195 1/8th. It would only
make a difference for a channel between 159 MHz and 163.87 MHz. Does
anyone have the datasheet to check?
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: Critical points about kernel 2.6.21 and pseudo-authorities
On Mon, 30 Apr 2007, Linus Torvalds wrote: Anyway, I'll get out of the discussion. There's clearly some personality issues in the DVB area, and I don't know quite _why_ that is, but Uwe, you're definitely not helping. There isn't a problem here, just a lot of noise coming from one source. I have no problem with Mauro and think he does a good job and is an extremely reasonable person. He is just getting Uwe's thesaurus thrown at him because he's the closest target. Sure there are disagreements sometimes, but this is always the case. I can think of plenty of lists far more full of flames and personality conflicts than linux-dvb. The issue with dst is just a minor missing feature to fully support the dvb helper module customization system. So nobody needs to worry about this anymore, the last two patches in this repository will fix it correctly. http://linuxtv.org/hg/~tap/dst-new?cmd=summary;style=gitweb Making dvb-pll work fully with this same system is a little more complex. It's on the virtual todo list, but not at the top. I'll finish with this completely unrelated quote. Especially important is the warning to avoid conversations with the demon. We may ask what is relevant but anything beyond that is dangerous. He is a liar. The demon is a liar. He will lie to confuse us. But he will also mix lies with the truth to attack us. The attack is psychological, Damien, and powerful. So don't listen to him. Remember that - do not listen. - from The Exorcist ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Small patch into opera1.c to make FPGA firmware load visible
On Thu, 26 Apr 2007, CIJOML wrote: Hi, I thinks this patch should clean many problems with firmware upload when device doesn't swith to warm state: - info(start downloading fpga firmware); + printk(FPGA firmware download starts...\n); info() is a macro that just expands to printk(), so this patch doesn't change much of anything at all. I think what you might be seeing is that the info() call gives the firmware downloading message INFO priority. The message might not appear in some log files that only contain more important messages. Your patch isn't making the firmware load, it's just letting you see the message where you are looking. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] fmd1216me integration
Here's my latest patch for fmd1216me integration into dvb-pll. It's little changed from when I posted it three weeks ago, except for cxusb which is now part of the patch. I'm going to try to get it into mainline soon for the 2.6.22 window, so if there are comments now is the time. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] fmd1216me integration (fwd)
Include the patch this time
-- Forwarded message --
Date: Thu, 26 Apr 2007 12:02:59 -0700 (PDT)
From: Trent Piepho [EMAIL PROTECTED]
To: Linux DVB linux-dvb@linuxtv.org
Cc: Hartmut Hackmann [EMAIL PROTECTED]
Subject: fmd1216me integration
Here's my latest patch for fmd1216me integration into dvb-pll. It's little
changed from when I posted it three weeks ago, except for cxusb which is
now part of the patch.
I'm going to try to get it into mainline soon for the 2.6.22 window, so if
there are comments now is the time.
-
Integrate all users of the fmd1216 tuner with dvb-pll
From: Trent Piepho [EMAIL PROTECTED]
Enhance the dvb-pll definition of the fmd1216 tuner by adding an init sequence
and a sleep sequence.
The init sequence sets the AGC control register to 0xa0, selecting the fast
time constant and 112 dBuV take-over point. This the recommended value for
DVB-T operation.
The sleep sequence sets bit P4 (which is believed to turn the analog
demodulator on), turns off the tuning voltage, and sets the AGC control
register to 0x60 (external AGC voltage, the recommended value for analog
operation).
The existing dvb-pll users in the cx88 driver, listed below, will gain these
init and sleep sequences.
CX88_BOARD_HAUPPAUGE_HVR1100Hauppauge WinTV-HVR1100 DVB-T/Hybrid
CX88_BOARD_HAUPPAUGE_HVR1100LP Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profi
CX88_BOARD_WINFAST_DTV2000H WinFast DTV2000 H
CX88_BOARD_HAUPPAUGE_HVR3000Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DV
CX88_BOARD_HAUPPAUGE_HVR1300Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encod
This non-dvb-pll user in the cx88 driver should only gain the sleep sequence,
as it already had an equivalent init sequence. The non-dvb-pll code for this
user is removed.
X88_BOARD_DNTV_LIVE_DVB_T_PRO digitalnow DNTV Live! DVB-T Pro
In these saa7134 driver, these non-dvb-pll users are converted to use dvb-pll:
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
The saa7134 functions philips_fmd1216_tuner_init(),
philips_fmd1216_tuner_sleep(), and philips_fmd1216_tuner_set_params() are
deleted and the dvb-pll versions are used.
This should result in equivalent sleep, init, and tuning sequences being sent
to the tuner.
For the cxusb driver, only one board is effected:
USB_PID_MEDION_MD95700 Medion MD95700
This board used dvb_usb_tuner_init_i2c() and dvb_usb_tuner_set_params_i2c()
for init and tuning, respectively. These functions are effectively the same
as the dvb-pll versions. They call a tuner pass control function defined at
the dvb-usb level, but this does not matter, as this card does not have a
tuner pass control function (only the dib3000mb does). This board will gain
the sleep sequence, while init and tuning should be unchanged.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/dvb-usb/cxusb.c
b/linux/drivers/media/dvb/dvb-usb/cxusb.c
--- a/linux/drivers/media/dvb/dvb-usb/cxusb.c
+++ b/linux/drivers/media/dvb/dvb-usb/cxusb.c
@@ -354,14 +354,8 @@ static struct mt352_config cxusb_mt352_c
/* Callbacks for DVB USB */
static int cxusb_fmd1216me_tuner_attach(struct dvb_usb_adapter *adap)
{
- u8 bpll[4] = { 0x0b, 0xdc, 0x9c, 0xa0 };
- adap-pll_addr = 0x61;
- memcpy(adap-pll_init, bpll, 4);
- adap-pll_desc = dvb_pll_fmd1216me;
-
- adap-fe-ops.tuner_ops.init = dvb_usb_tuner_init_i2c;
- adap-fe-ops.tuner_ops.set_params = dvb_usb_tuner_set_params_i2c;
-
+ dvb_attach(dvb_pll_attach, adap-fe, 0x61, adap-dev-i2c_adap,
+ dvb_pll_fmd1216me);
return 0;
}
diff --git a/linux/drivers/media/dvb/frontends/dvb-pll.c
b/linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c
@@ -38,6 +38,12 @@
0x50 = AGC Take over point = 103 dBuV */
static u8 tua603x_agc103[] = { 2, 0x80|0x40|0x18|0x06|0x01, 0x00|0x50 };
+/* 0x04 = 166.67 kHz divider
+
+ 0x80 = AGC Time constant 50ms Iagc = 9 uA
+ 0x20 = AGC Take over point = 112 dBuV */
+static u8 tua603x_agc112[] = { 2, 0x80|0x40|0x18|0x04|0x01, 0x80|0x20 };
+
struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name = Thomson dtt7579,
.min = 17700,
@@ -282,6 +288,8 @@ struct dvb_pll_desc dvb_pll_fmd1216me =
.max = 85800,
.iffreq= 36125000,
.setbw = fmd1216me_bw,
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
.count = 7,
.entries = {
{ 14387, 17, 0xbc, 0x41 },
diff --git a/linux/drivers/media/video/cx88/cx88-dvb.c
b/linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c
@@ -224,64 +224,6 @@ static int dntv_live_dvbt_pro_demod_init
return 0;
}
-static int
Re: [linux-dvb] [PATCH] Opera S1- DVB-USB
On Mon, 16 Apr 2007, Mauro Carvalho Chehab wrote:
On Mon, 16 Apr 2007, Marco Gittler wrote:
so i this first enough to put it in and have some more testern for this
device ?
For me, it seems ok now. I'll apply it later at master tree, to allow more
people to test it. This will bring us about 3 weeks for testing and decide
if this is ready for 2.6.22 or not.
This will also give opportunity to other guys to send their comments,
patches and sugestions to improve your driver.
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/Kconfig
--- a/linux/drivers/media/dvb/dvb-usb/Kconfig Sat Apr 14 16:19:13 2007 -0300
+++ b/linux/drivers/media/dvb/dvb-usb/Kconfig Mon Apr 16 12:06:05 2007 +0200
@@ -110,6 +110,7 @@ config DVB_USB_CXUSB
Medion MD95700 hybrid USB2.0 device.
DViCO FusionHDTV (Bluebird) USB2.0 devices
+
Random blank line inserted.
diff -r b5be3479f070 linux/drivers/media/dvb/dvb-usb/opera1.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/dvb-usb/opera1.c Mon Apr 16 13:16:17 2007 +0200
[...]
+#include opera1.h
+#include linux/module.h
+#include linux/init.h
+#include linux/firmware.h
+#include dvb-usb.h
+#include dvb-pll.h
+#include stv0299.h
Includes should be first linux/*.h includes (with not ), then
include compat.h, then sub-system includes (e.g., dvb-usb.h), then your
includes. The linux/* then compat.h order is important, the rest not as
much.
+ int ret = 0, t = 0;
+ u8 r[10];
+ u8 u8buf[len];
[...]
+ memset(r, 0, sizeof(*r));
You don't need to initialize ret or t. It would easier to initialize r (I
don't think you need to anyway, but if you do) with u8 r[10] = {0}; Instead
of adding an extra call to memset(). Also the memset is wrong, it should
be memset(r, 0, sizeof(r)); as sizeof(*r) is 1, not 10.
Linux coding style is for one blank line after variables are declared and
before statements start.
The variable sized u8buf[len] array is a C99 feature. Are we allowed to
use this in the kernel? I'm not sure if this is allowed or not.
+ t = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
+ OPERA_TUNER_REQ, USB_DIR_IN | USB_TYPE_VENDOR,
+ 0x01, 0x0, r, 10, 2000);
You never use t anywhere. You should probably check if usb_con...() failed
and return an error or print something.
static int opera1_usb_i2c_msgxfer(struct dvb_usb_device *dev, u16 addr,
[...]
+ request = (addr 0xff00) 8;
+ if (!request)
+ request = 0xb1;
+ value = (addr 0xff);
+ if (flag OPERA_READ_MSG) {
+ value |= 0x01;
+static int opera1_i2c_xfer(struct i2c_adapter *adap, struct i2c_msg msg[],
[...]
+ if ((tmp = opera1_usb_i2c_msgxfer(d,
+ msg[i].addr,
The Linux I2C subsystem uses 7-bit addresses, while your code is using
8-bit addresses. You should either change opera1_usb_i2c_msgxfer() so it
uses 7-bit addreses, or change opera1_i2c_xfer() so it passes
msg[i].addr1 to opera1_usb_i2c_msgxfer(). This problem keeps comming
up again and again, you can check the list archives to find more
explainations.
opera1_i2c_xfer() would be better if you had this at the first line of
code:
if (!d)
return -ENODEV;
And the got rid of the extra if(d){ ... } part. Note that if d is NULL,
you will crash on the line that does mutex_lock_interruptible(d-i2c_mutex),
which is run _before_ you check if d is null. So the current if(d){ } is
pointless, you will crash before you get there.
+static struct stv0299_config opera1_stv0299_config = {
+ .demod_address = 0xd0,
[...]
+static int opera1_tuner_attach(struct dvb_usb_adapter *adap)
+{
+ adap-pll_addr = 0xc0;
The addresses are wrong, it should be 0x68 and 0x60. It works because your
i2c code is also wrong, and the mistakes cancel each other out.
+static int opera1_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
+{
+ u8 buf_start[2] = { 0xff, 0x03 };
+ u8 buf_stop[2] = { 0xff, 0x00 };
Declare constant arrays like this as static const.
+static int opera1_rc_query(struct dvb_usb_device *dev, u32 * event, int *state)
[...]
+ memset(rcbuffer, 0, 32);
This memset isn't necessary, you're just going to over-write it with the i2c
command.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Re: [Patch] USBVision - Fix NT1005 Bridge detection
On Sat, 14 Apr 2007, Mauro Carvalho Chehab wrote:
I've did such change on:
http://linuxtv.org/hg/~mchehab/usbvision
It also honors CodingStyle max line size.
I've also removed some duplicated stuff (ID Vendor/Product) and changed
some flags to use bitmap. As result, It saved about 1K of kernelspace
area.
There's a bug in this patch, the bitfields must be unsigned if you want to
have the range 0..1 and not -1..0.
Anyway, the structure can be made even smaller, -1700 bytes overall change
by my count (*). See linked patch.
01/01: usbvision: store the device database more efficiently
http://linuxtv.org/hg/~tap/usbvision?cmd=changeset;node=7957ba367757
usbvision-cards.c | 431 --
usbvision-core.c |8 -
usbvision-video.c | 37 +++-
usbvision.h | 31 ++-
4 files changed, 207 insertions(+), 300 deletions(-)
(*) counted like this:
objdump -h usbvision.ko |
awk '/bss|text|data/!/init/{print x=strtonum(0x$3),\t,s+=x,$2;}'
___
linux-dvb mailing list
[EMAIL PROTECTED]
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technisat Airstar USB supported no longer
On Sat, 14 Apr 2007, P. van Gaans wrote: Now that I've seen my Afatech locking I'm sure my Linux distro, kaffeine and drivers are all fine. However my Technisat Airstar USB (that has been supported since quite a while) simply won't lock on anything and read no channel or whatever frequency. It's detected, yes, and it stops there. And yes, it works just fine on Bill's OS, the antenna is fine as well and the -/+167 trick doesn't help. I'm willing to help any developer to make it supported again. I already updated the wiki. Get the latest drivers from the linuxtv.org Hg repository if you haven't already. If they don't work and it used to work under linux, try updating to an older version and see if you can find where it broke. If you know it worked in kernel 2.6.x, you can look at the release date for the _previous_ kernel and update v4l-dvb hg to around a week after that date. For example, if it worked on 2.6.18, then check 2.6.17's release date, Jun 18th, and get a revision from around a week after that, say revision 4262. That's about what will have been in 2.6.18. There is no revision that exactly matches a given kernel but, that will be reasonably close. ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVICO Dual Digital 2 - Chris Pascoe's Test branch
On Fri, 13 Apr 2007, Luke Rosenthal wrote: For SBS @ 536625000 Hz, before 53650 Hz after 53667 Hz Station is tuning properly on published frequency, so not going to muck around with it For Nine @ 191625000 Hz, before 19150 Hz after 19167 Hz Ok, have some interesting info to report on this one: 191625000 gets lock, intermittently, and is unwatchable, signal around 37f7 191791667 won't lock, this is an old offset Chris suggested I think 19167 locks, both frontends, gets good signal, will verify pic quality tonight. signal 67ac. snr c2c2. 191791667 would be for before my patch, when rounding was wrong. That frequency will tune one step too high, so it makes sense that it doesn't work. I doesn't make any sense that 191625000 and 19167 would have different effects. They both tune to the exact same value. I think you are just seeing that tuning is for some reason unreliable. It's like flipping one coin and getting heads and another coin and getting tails and saying the first coins is always heads and second is always tails. Use a robust testing method. Tune to 191625000 and measure the average snr over 30 seconds, then tune to 19167 and do the same, then 191625000 again and so on until you've done each one at least 10 times. Then see if there truly is a difference. For Ten @ 21950 Hz, before 21950 Hz after same frequency Ok, still can't tune this frequency but I know the card is capable of doing it, as it worked prior to compiling last week from HG. Need some other offsets to try. I don't think it has anything to do with the frequency or offsets. Double checked it, yep, correct frequencies. Have been using the same freq for this station all along. Got any other ideas/offsets to try? Would it be possible to patch the driver to somehow log debug info to syslog or something? Set debug to 1 for dvb-pll modprobe dvb-pll debug=1 or add to /etc/modprobe.conf options dvb-pll debug=1 or after the module is loaded echo 1 /sys/module/dvb_pll/parameters/debug ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVICO Dual Digital 2 - Chris Pascoe's Test branch
On Thu, 12 Apr 2007, Luke Rosenthal wrote: now tunes but at the expense of another station. As well, another channel I previously needed an offset to tune actually tunes now. Peculiar, but given that you are talking about fixes for rounding, it makes sense. I have a patch in that would bein the curent master for dvb-pll rounding. There was a small change to the thomson dtt7579 tuner data, which is what I think your device uses. I don't think this change would make any difference. What frequency exactly is it that works now but didn't before? I can see if dvb-pll is programming a different value than it did before. SBS is the frequency which never used to work, but does now - 536625000. I didn't think my patch would have any effect for this tuner, but in this case it did. I'm glad it it was an improvement. The tuner can only tune in steps of 1/6 MHz, so it can't get the exact correct frequency. For SBS @ 536625000 Hz, before 53650 Hz after 53667 Hz For Nine @ 191625000 Hz, before 19150 Hz after 19167 Hz For Ten @ 21950 Hz, before 21950 Hz after same frequency For the two channels that now work better, the tuner used to be tuning to a frequency 125 kHz too low, after my patch it's tuning to a frequency 41 1/6th kHz too high. The one channel that doesn't work should be tuning the same frequency as it did before the patch. I wonder if that frequency or something else is wrong? I don't suppose the information on http://www.dba.org.au/ is any different that what you've been trying? Actually, adapter1 seems to get better signal readings across all channels. Eg on 7 digital (never had a problem with it) adapter0 sees signal 57fc, adapter1 sees signal 66dc. Is this normal? I've seen other reports from people with multiple cards that one card gets better reception than the other. ___ linux-dvb mailing list [EMAIL PROTECTED] http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] DVICO Dual Digital 2 - Chris Pascoe's Test branch
On Thu, 12 Apr 2007, Luke Rosenthal wrote: I was following this problem some time ago too, but could not get my Dual Digital to tune SBS no matter what offsets I used. At the time I put it down to poor reception but out of curiosity last week I did a hg clone on the master branch, compiled, make rmmod, make insmod. To my surprise SBS now tunes but at the expense of another station. As well, another channel I previously needed an offset to tune actually tunes now. Peculiar, but given that you are talking about fixes for rounding, it makes sense. I have a patch in that would bein the curent master for dvb-pll rounding. There was a small change to the thomson dtt7579 tuner data, which is what I think your device uses. I don't think this change would make any difference. What frequency exactly is it that works now but didn't before? I can see if dvb-pll is programming a different value than it did before. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
On Fri, 6 Apr 2007, Patrick Boettcher wrote:
On Thu, 5 Apr 2007, Trent Piepho wrote:
On Thu, 5 Apr 2007, Patrick Boettcher wrote:
On Thu, 5 Apr 2007, Borgi2008 wrote:
Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Sepp?l?:
Actually, looking at the code I cannot figure out why there has to be
a
spinlock in the first place.
The lock is only taken in the interrupt handler which already runs in
atomic context so there is no use in making the handler protected by a
spinlock. Am I missing something here?
I think the spinlock is unnecessary and should be removed entirely.
Even on SMP systems? ISRs are only atomic on one CPU.
I thought ISRs were normally atomic even on SMP systems. When an interrupt
occurs, that interrupt is disabled until the ISR returns. Except in fast
handlers (which flexcop is not) all interrupts aren't disabled, and so an
ISR can be interrupted by a _different_ ISR, and a different ISR could be
running at the same time on another CPU. But an ISR doesn't have to worry
about two copies of itself running at the same time.
At least, that's how I think it works.
I don't see how a spin lock that is only used from the ISR could be useful,
assuming the ISR is only called via an interrupt. There is no reason you
couldn't call the isr function from some system call handler, but that
would be an unusual thing to do.
Normally an ISR does need a spinlock, to access data shared by the
non-interrupt part of the driver. I wonder if there is a bug in flexcop in
that nothing else uses irq_lock?
You can only take a spinlock at IRQ-level and not at normal kernel level.
Sure you can. There is a ton of code that does this. It would be pretty
much impossible to create SMP safe ISRs if there was no locking mechanism
that worked across interrupt-level to kernel-level.
Look in Documentation/cli-sti-removal.txt:
irq_handler (...)
{
unsigned long flags;
spin_lock_irqsave(driver_lock, flags);
driver_data.finish = 1;
driver_data.new_work = 0;
spin_unlock_irqrestore(driver_lock, flags);
}
ioctl_func (...)
{
...
spin_lock_irq(driver_lock);
...
driver_data.finish = 0;
driver_data.new_work = 2;
...
spin_unlock_irq(driver_lock);
...
}
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [BUG] flexcop lockdep
On Thu, 5 Apr 2007, Patrick Boettcher wrote: On Thu, 5 Apr 2007, Borgi2008 wrote: Am Mittwoch, den 04.04.2007, 23:29 +0300 schrieb Antti Sepp?l?: Actually, looking at the code I cannot figure out why there has to be a spinlock in the first place. The lock is only taken in the interrupt handler which already runs in atomic context so there is no use in making the handler protected by a spinlock. Am I missing something here? I think the spinlock is unnecessary and should be removed entirely. Even on SMP systems? ISRs are only atomic on one CPU. I thought ISRs were normally atomic even on SMP systems. When an interrupt occurs, that interrupt is disabled until the ISR returns. Except in fast handlers (which flexcop is not) all interrupts aren't disabled, and so an ISR can be interrupted by a _different_ ISR, and a different ISR could be running at the same time on another CPU. But an ISR doesn't have to worry about two copies of itself running at the same time. At least, that's how I think it works. I don't see how a spin lock that is only used from the ISR could be useful, assuming the ISR is only called via an interrupt. There is no reason you couldn't call the isr function from some system call handler, but that would be an unusual thing to do. Normally an ISR does need a spinlock, to access data shared by the non-interrupt part of the driver. I wonder if there is a bug in flexcop in that nothing else uses irq_lock? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] pull fmd1216me into dvb-pll
Here is my patch to put the code for the fmd1216me tuner into dvb-pll. I
addresses the cx88 and saa7134 drivers. I didn't fix the cxusb driver
since there's still some stuff I'm not sure about there.
All the effected boards (see patch description) should work as least as
well as they did before. Some should improve, either in analog mode or
digital mode or both, as they will gain sleep and init sequences they
missed out on before. One board in cx88 was sending an init sequence on
every tune, which shouldn't be necessary, and probably counter productive
since the init sequence would tune to some bogus frequency before tuning to
the correct one.
dvb/frontends/dvb-pll.c | 10 ++-
video/cx88/cx88-dvb.c | 63 ---
video/saa7134/saa7134-dvb.c | 140 +---
3 files changed, 16 insertions(+), 197 deletions(-)
-
Integrate (almost) all users of the fmd1216 tuner with dvb-pll
From: Trent Piepho [EMAIL PROTECTED]
Enhance the dvb-pll definition of the fmd1216 tuner by adding an init sequence
and a sleep sequence.
The init sequence sets the AGC control register to 0xa0, selecting the fast
time constant and 112 dBuV take-over point. This the recommended value for
DVB-T operation.
The sleep sequence sets bit P4 (which is believed to turn the analog
demodulator on), turns off the tuning voltage, and sets the AGC control
register to 0x60 (external AGC voltage, the recommended value for analog
operation).
The existing dvb-pll users in the cx88 driver, listed below, will gain these
init and sleep sequences.
CX88_BOARD_HAUPPAUGE_HVR1100Hauppauge WinTV-HVR1100 DVB-T/Hybrid
CX88_BOARD_HAUPPAUGE_HVR1100LP Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profi
CX88_BOARD_WINFAST_DTV2000H WinFast DTV2000 H
CX88_BOARD_HAUPPAUGE_HVR3000Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DV
CX88_BOARD_HAUPPAUGE_HVR1300Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encod
This non-dvb-pll user in the cx88 driver should only gain the sleep sequence,
as it already had an equivalent init sequence. The non-dvb-pll code for this
user is removed.
X88_BOARD_DNTV_LIVE_DVB_T_PRO digitalnow DNTV Live! DVB-T Pro
In these saa7134 driver, these non-dvb-pll users are converted to use dvb-pll:
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
The saa7134 functions philips_fmd1216_tuner_init(),
philips_fmd1216_tuner_sleep(), and philips_fmd1216_tuner_set_params() are
deleted and the dvb-pll versions are used.
This should result in equivalent sleep, init, and tuning sequences being sent
to the tuner.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
diff --git a/linux/drivers/media/dvb/frontends/dvb-pll.c
b/linux/drivers/media/dvb/frontends/dvb-pll.c
--- a/linux/drivers/media/dvb/frontends/dvb-pll.c
+++ b/linux/drivers/media/dvb/frontends/dvb-pll.c
@@ -38,6 +38,12 @@
0x50 = AGC Take over point = 103 dBuV */
static u8 tua603x_agc103[] = { 2, 0x80|0x40|0x18|0x06|0x01, 0x00|0x50 };
+/* 0x04 = 166.67 kHz divider
+
+ 0x80 = AGC Time constant 50ms Iagc = 9 uA
+ 0x20 = AGC Take over point = 112 dBuV */
+static u8 tua603x_agc112[] = { 2, 0x80|0x40|0x18|0x04|0x01, 0x80|0x20 };
+
struct dvb_pll_desc dvb_pll_thomson_dtt7579 = {
.name = Thomson dtt7579,
.min = 17700,
@@ -282,6 +288,8 @@ struct dvb_pll_desc dvb_pll_fmd1216me =
.max = 85800,
.iffreq= 36125000,
.setbw = fmd1216me_bw,
+ .initdata = tua603x_agc112,
+ .sleepdata = (u8[]){ 4, 0x9c, 0x60, 0x85, 0x54 },
.count = 7,
.entries = {
{ 14387, 17, 0xbc, 0x41 },
diff --git a/linux/drivers/media/video/cx88/cx88-dvb.c
b/linux/drivers/media/video/cx88/cx88-dvb.c
--- a/linux/drivers/media/video/cx88/cx88-dvb.c
+++ b/linux/drivers/media/video/cx88/cx88-dvb.c
@@ -224,64 +224,6 @@ static int dntv_live_dvbt_pro_demod_init
return 0;
}
-static int philips_fmd1216_pll_init(struct dvb_frontend *fe)
-{
- struct cx8802_dev *dev= fe-dvb-priv;
-
- /* this message is to set up ATC and ALC */
- static u8 fmd1216_init[] = { 0x0b, 0xdc, 0x9c, 0xa0 };
- struct i2c_msg msg =
- { .addr = dev-core-pll_addr, .flags = 0,
- .buf = fmd1216_init, .len = sizeof(fmd1216_init) };
- int err;
-
- if (fe-ops.i2c_gate_ctrl)
- fe-ops.i2c_gate_ctrl(fe, 1);
- if ((err = i2c_transfer(dev-core-i2c_adap, msg, 1)) != 1) {
- if (err 0)
- return err;
- else
- return -EREMOTEIO;
- }
-
- return 0;
-}
-
-static int dntv_live_dvbt_pro_tuner_set_params(struct dvb_frontend* fe,
- struct dvb_frontend_parameters*
params)
-{
- struct cx8802_dev *dev= fe-dvb-priv;
- u8 buf[4];
- struct i2c_msg msg =
- { .addr = dev-core-pll_addr, .flags
[linux-dvb] Re: [v4l-dvb-maintainer] Patch kworld dvb-t 210 diff file
On Sat, 31 Mar 2007, john owen-jones wrote:
I apologise for doing this incorrectly but i haven't a clue how to upload
the diff file
After you make your changes, run 'make commit'. This will give you a
pre-made log message to fill in and also fix certain things (e.g. add new
cards to the correct CARDLIST file).
After that, you can use 'hg export tip' to produce a patch to send to the
list. The premade log message you filled in will have the correct
signed-off-by line.
+ .radio_addr= ADDR_UNSET,
+ .mpeg = SAA7134_MPEG_DVB,
+ .gpiomask = 1 21,
+ .inputs = {{
+ .name = name_tv,
+ .vmux = 1,
+ .amux = TV,
+ .tv = 1,
+ },{
Please follow the existing indentation style.
-
+// my addition
+#define SAA7134_BOARD_KWORLD_DVBT_210 113
+// added the dvbt 210 as card 113
Don't add comments like those. There have been some 51,000 patches applied
to the kernel since 2.6.12. Imagine what it would look like if there were
51,000 // my addition lines in there.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] kaffeine: Invalid section length or timeout
On Wed, 28 Mar 2007, Torgeir Veimo wrote: I'm trying to tune to BBC at 505833 khz (the official frequency), but for some reason, i'm receiving at 506000 instead. I'm wondering if this is what might be causing the errors, since there might be a discrepancy between what frequency kaffeine locks on and the transponder frequency data? Sounds like it could be that the driver is using the wrong IF frequency. Do you know if your device is one with a mt2060 tuner or an env57h1xd5 tuner? Are you using v4l-dvb from Hg, and if so, what version (hg head)? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problems after buil the source code from http://linuxtv.org/hg/v4l-dvb.
On Sun, 18 Mar 2007, Francisco Demeter wrote: how to patch the source code, now the IR control is working, but my webcam stops to work. I try to rebuild the webcam driver gspcav, but i get still the same error by load them: [EMAIL PROTECTED]:/usr/src/gspca-source/modules/gspca# dmesg | grep gspca gspca: disagrees about version of symbol video_devdata gspca: Unknown symbol video_devdata The gspca driver is getting built against the media drivers in your kernel source, but the media drivers you are using are the newer ones from the v4l-dvb Hg you installed. What you might be able to do, is to use make kernel-links from v4l-dvb to copy v4l-dvb into your kernel source. This will modify the kernel source you have installed, so you probably should back it up first! Now you can try to rebuild gspca against this new source. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Fri, 16 Mar 2007, Hartmut Hackmann wrote: Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? I only have the datasheet. Things look like P4 needs to be one to make the tda9887 accessible. The problem is that according to the TUA datasheet, this I wish I had a fmd1216 tuner, this would be easy to test. Try turning P4 off and see if the tda9887 stop responding to i2c reads. When P4 is turned back on, is the power-on-reset bit set in the tda9887? If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. ACK. changing the dvb tuning code will not affect this. The only important issue is to set the tuner to analog mode when dvb goes to sleep. Otherwise the first analog tuning attempt will fail because the tda9887 will not listen. dvb-pll will need to be extended to do this. Right now, it can only send a two-byte sequence for the sleep command. In order to set both the AGC byte and the port control byte, a 4-byte message is necessary. The TUA603x datasheet doesn't say you can send CB-AB-CB-BB, but it doesn't say you can't, and I've tested it and it works. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Steven Toth wrote: My plan was to come up with a patch that converted all the users of fmd1216 at once. FMD1216ME was recently replaced by the FMD1216MEX. Not sure if this impacts on your plans. I don't have the datasheet off hand but I'm told FM tuning has changed slightly. That shouldn't make a difference. If the tuner is different enough that it needs a different configuration, then it will just need to be added as a new tuner type. Shouldn't make any difference to existing users of the fmd1216me. Of course I'm sure the card makers will switch tuners without changing their model numbers! Leading to the problem of how do you tell which tuner the card has? Maybe they'll be so kind as to stick the tuner on a different i2c address as well as put something in the eeprom. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Wed, 14 Mar 2007, Hartmut Hackmann wrote: How does that happen? I figured P4 just changed the SAW filters, but it enables/disables the tda9887 too? I have no idea why and how this is done, i just observed that... I wonder if this is a problem for the v4l tuner module. If one doesn't start and then stop the dvb frontend before using analog, how does the tda9887 get turned on? It is a BIG problem. The tuner initialization code turns the tda9886 on, but now things depend on the module initialization order whether the tda is found or not. I haven't used my board in analog mode after the tda9887 merge but things look like it doesn't work any more :-( Unfortunately i know about at least one board that needs the opposite load order. In the datasheet for the Philips TUV1236D tuner, it describes how the TDA9885 is turned on and off by one of the GPIO pins of the NXT2004 demodulator. The same pin also powers off and on the digital IF section, whatever that is exactly (obviously the NXT2004 isn't powering itself down with its own GPIO pin). I imagine this is a big problem for v4l, needing to talk to the ATSC demodulator to turn the analog demodulator on. Anyway, the FMD1216ME datasheet doesn't say anything about turning the TDA9887 on or off. Still, it stands to reason that Philips would have added the ability to do this for the same reason they added it to the TUV1236D. Do you have a datasheet or design guide that explains about needing to turn the tda9887 on? Is it one of the TUA6034 ports that controls it? If analog doesn't work the fmd1216, then I don't think a dvb-pll integration patch should be obligated to fix it. But, I don't want to break anything that does work now. I wonder how the other users of the fmd1216, in the cx88 and cxusb driver, work in analog mode? Maybe they don't? My plan was to come up with a patch that converted all the users of fmd1216 at once. Ok, less work for me. If you want, I can make a simple patch that fixes the bug in fmd1216me_sleep quickly to apply first. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] [RFC] Change dvb-pll handling of IF frequency
The basic frequency calculation done in dvb-pll is to take the desired frequency, add the IF frequency, and then divide by the reference frequency. When dvb-pll does the division, it just rounds the result down. It would make more sense to round to the nearest integer, which is done by adding 1/2 the divisor (the reference frequency) before dividing. Some PLL definitions already do this, by adding one half the reference frequency to the IF frequency. The effect is the same, except one looking at the code doesn't know if they are seeing the IF frequency, or the IF frequency plus 1/2 the reference frequency. Of course some PLL defintions do it one way and some do it the other and there is no record of which is which. I think it makes a lot more sense put just the IF frequency in the PLL definition, and take care of rounding properly in the dvb-pll code. So I have attached a patch which does this. In order to do this, I had to guess which PLLs had stepsize/2 added to the offset and which didn't. The second patch moves the IF frequency out of the per-band data. There is no reason for the IF to change from one band to another, and in all of the PLLs defined the IF is constant across bands. As far as which PLLs had offsets with stepsize/2 added and which didn't, I've made a list of all the IF frequencies defined in dvb-pll: dvb_pll_thomson_dtt7610 44 dvb_pll_microtune_4042 44 dvb_pll_thomson_dtt761x 44 dvb_pll_lg_tdvs_h06xf 44 dvb_pll_tdhu2 44 dvb_pll_tuv1236d44 dvb_pll_samsung_tbmv44 dvb_pll_tua6010xs 36 1/8 dvb_pll_thomson_dtt7579 36 1/6 dvb_pll_tded4 36 1/6 dvb_pll_tua6034 36 1/6 dvb_pll_unknown_1 36 1/6 dvb_pll_thomson_dtt759x 36 1/6 dvb_pll_lg_z201 36 1/6 dvb_pll_philips_td1316 36 1/6 (rounded to nearest kHz) dvb_pll_tda665x 36 1/6 (rounded to nearest kHz) + step/2 dvb_pll_fmd1216me 36 1/8 (rounded to two decimals) + step/2 dvb_pll_thomson_fe6600 36 1/8 (rounded to two decimals) + step/2 dvb_pll_env57h1xd5 36 1/8 + step dvb_pll_philips_sd1878_tda8261 499 Anyway, from this list I think it's clear that the PLLs with a pre-adjusted offset are dvb_pll_tda665x, dvb_pll_fmd1216me, dvb_pll_thomson_fe6600, and dvb_pll_env57h1xd5. dvb_pll_philips_sd1878_tda8261 is an odd one, as it's the only satellite PLL with zero-IF output in the list. It uses an offset of 499 with a stepsize of 500 kHz so that it rounds _up_. I've left this PLL rounding up, assuming there is a reason it was this way. Also, dvb_pll_env57h1xd5 is not 36 1/8 + step/2, but 36 1/8 + step. I think this is a bug. If you go back to patch 1740 which created the dvb-pll definition, you'll see it was taken from the dibusb driver. The original code for this pll was: u32 freq_khz = fep-frequency / 1000; u32 tfreq = ((freq_khz + 36125)*6 + 500) / 1000; If you multiple that out and reduce it, you get: tfreq = (fep-frequency + 36125000 + 17/2) / 17; But the dvb-pll definition is using 36125000 + 17.# Added/removed/changed files: # linux/drivers/media/dvb/frontends/dvb-pll.c | 148 ++-- # 1 files changed, 75 insertions(+), 73 deletions(-) # # For better log display, please keep a blank line after subject, after from, # and before signed-off-by. # First line should be the subject, without Subject: # dvb-pll: Adjust rounding to be consistent # Now, patch author (just the main one), on a From: field # Please change below if the committer is not the patch author. # From: Trent Piepho [EMAIL PROTECTED] # Then a detailed description: Some PLLs had one half the step size added to the offset, so that the divisor would be rounded to the nearest integer. Some didn't and so would always be rounded down. This makes dvb-pll round to the nearest when calculating the divisor, without the offset needing to be fudged. PLLs that had a fudged offset have the offset changed to be just the IF frequency. The satellite PLL dvb_pll_philips_sd1878_tda8261 was rounding up for some reason, and I've kept it that way. In addition, frequencies that were rounded to the nearest kHz are extended to full Hz resolution. One sixth MHz step sizes that were listed as 166,666 Hz are changed to 166,667 Hz, which is slightly closer. PLLs that were already rounding: dvb_pll_tda665x, offset was 36 1/6 (to nearest kHz) + step/2 dvb_pll_fmd1216me, offset was 36 1/8 (to two digits) + step/2 dvb_pll_thomson_fe6600, offset was 36 1/8 (to two digits) + step/2 dvb_pll_env57h1xd5, offset was 36 1/8 + step Note that the last PLL, dvb_pll_env57h1xd5, appears to have had a bug in the offset. Rather than adding stepsize/2, it was adding a full stepsize. The PLL definition originally came from the dibusb driver, which used 36 1/8 + step/2. The change to 36 1/8 + step was probably a mistake
Re: [linux-dvb] fmd1216 integration
On Tue, 13 Mar 2007, Hartmut Hackmann wrote:
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
Jep
I've made patches to do this, I'll send them to the list later.
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
I will have a look
My fmd1216 patch will have the tuner init function send {0xdd, 0xa0} to the
tuner. That will set the agc value (byte AB) to 0xa0, the same thing.
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
AFIK the v4l tuner driver can't do this since init is called only one at
module initialization. Maybe the sequence is overdone but the intention is:
Yeah, V4L should do it, but doesn't. I think there is a special case hack
for some tuners where on every tune, they take the 4-byte command, send it
once, then modify the last two bytes to set AGC, and then send it again.
- set up RF AGC
- set the PLL to a valid frequency. I was told that this is important.
If you just send two bytes, then it's not necessary to change the frequency
from what it was at before.
Anyway, I don't think the frequency is valid either:
divisor = 0x0bdc, ratio bits = 1,1 = 62.5 kHz, so freq = 189.75 MHz
But, BB = 0x54, which is analog mode HIGH band. 189.75 MHz would be in the
LOW band. (remember to subtract the IF frequency to compare to the
bandswitch points used in the code)
- turn on the tda9887. This is invisible on the I2C bus in DVB mode.
How does that happen? I figured P4 just changed the SAW filters, but it
enables/disables the tda9887 too?
I am not aware that the tuner actually has a sleep mode. I used the sleep
call be cause it simply was there.
If you set the low bit of CB, it disables the tuning voltage. That's
probably the closest thing to sleep mode there is.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
Hm, the sequence is incomplete.. Do you have more information about the
PLL chip?
The documentation for the Infineon TUA6034 should be easy to find if you
don't have it. It's pretty clear that you don't need to send the divisor
bytes each time. You can just send CB+BB or in this case CB+AB. And I've
verified that indeed you can set the AGC values with just two bytes.
Are you aware that there is also the td1316?
One tuner at a time
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] fmd1216 integration
I've been looking into integrating fmd1216 tuner support fully into dvb-pll and removing the various code used in some drivers. I've mostly figured out what the effect will be on the various users of fmd1216 tuners, but there is something I'm not sure of. In dvb-pll, the frequency offset, which is the IF frequency the tuner will output at, is set to 36.21 MHz. It looks like this code was written about two years ago by Patrick as part of the reverse engineered cxusb driver. In saa7134-dvb, there is some totally different code from programming fmd1216 tuners, and it uses an IF frequency of 36.13 MHz. So, why the difference? The fmd1216 datasheet says the DVB-T IF frequency is 36.13 MHz. But the IF frequency is something also determined by the demodulator. There are several different demods using a fmd1216. The cx22702 is used by a number of cards, the product brief says it uses an IF of 36.17 MHz or 44.1 MHz. There is a card using an mt352, which is using 36.16667 MHz in this case (no code to re-program the IF frequency registers). There are also two cards using the tda10046 demod, which according to the driver is using a 36.13 MHz IF. It seems like 36.13 MHz (probably 36 1/8 rounded to two digits) or 36.16667 (clearly 36 1/6) are the correct values. So where did 36.21 MHz come from? It is supposed to be 36.13 plus 1/2 of the 1/6 MHz step size? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Doubt about cohexistence of FILTER and PES_FILTER on the same pid
On Sun, 11 Mar 2007, [iso-8859-1] M?ns Rullg?rd wrote: Nico Sabbi [EMAIL PROTECTED] writes: What would happen if I set a pes filter on pid N (e.g. pmt_pid) and at the same time a section filter on the same pid? Would I get data from both or only from the section filter? The pdf doesn't mention this possible use case (or at least I didn't find it). Whatever happens, doing that wouldn't make any sense. A PID carries either PES data or sections, never both. In the dvb api, a PES_FILTER is also used to get the raw TS stream for a pid. There is anothing about a PES_FILTER that requires the PID to have PES data on it. If you setup two filters for the same PID, I think the software filter code will handle it ok. For a device with hardware filters, it probably depends on how the hardware works. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] fmd1216 integration
On Mon, 12 Mar 2007, Hartmut Hackmann wrote:
On Sunday 11 March 2007 09:40, Trent Piepho wrote:
In dvb-pll, the frequency offset, which is the IF frequency the tuner will
output at, is set to 36.21 MHz. It looks like this code was written
about two years ago by Patrick as part of the reverse engineered cxusb
driver.
In saa7134-dvb, there is some totally different code from programming
fmd1216 tuners, and it uses an IF frequency of 36.13 MHz.
So, why the difference?
After looking at dvb-pll some more, I'm pretty sure the difference between
the saa7134 and the dvb-pll IF frequency is that the dvb-pll version has
1/2 the step size added in, so the result will be rounded correctly.
I think that should be done is adjust the IF values in in the dvb-pll
config structs to NOT include step-size/2 for rounding. Just use the IF
frequency. This is how most of the PLL definitions are already. The code
which calculates the divisor should be changed to round to the nearest
integer, rather than round down.
I wrote the code in saa7134-dvb. The FMD1216 has an integrated SAW filter
for DVB-T, the data sheet says 36.13MHz. This is strange because the
data sheet also recommends a tuning step size of 167 kHz (4 MHz / 24),
so it should be 36.167MHz
Maybe the person who picked the SAW filter and the person who recommended
the step size should have talked to each other...
When i started writing it, there was no dvb-pll module. And the reason
why i didn't move to dvb-pll yet is that this module has no means to
control the RF AGC. Philips recommends different setting for analog and
DVB-T.
dvb-pll can do this now. These are the notes I've made about converting
fmd1216 to use dvb-pll wrt the saa7134 driver.
saa7134 driver
tda10046 demod, driver supports IF 36.13 Mhz (used here) or 36.17 MHz
SAA7134_BOARD_MD7134Medion 7134
SAA7134_BOARD_ASUS_EUROPA2_HYBRID Asus Europa2 OEM
tuner_ops.init = philips_fmd1216_tuner_init
tuner_ops.sleep = philips_fmd1216_tuner_sleep
tuner_ops.set_params = philips_fmd1216_tuner_set_params
philips_fmd1216_tuner_init() just sends { 0x0b, 0xdc, 0x9c, 0xa0 } to the
tuner. It could be replaced with the dvb-pll version, which will have
the same effect.
philips_fmd1216_tuner_set_params() does not use dvb_pll_configure(), but is
totally different code. I've looked through it, and it will end up sending
almost the same data to the tuner. The only difference is that dvb-pll
uses a IF frequency of 36.21 MHz while the code in saa7134 uses 36.13
MHz. In this case, I think dvb-pll is wrong. It looks like the 26.213 MHz
value was written by Patrick Boettcher in 2005 when he wrote the cxusb
driver. Actually, what I think now is that the dvb-pll value is offset by
stepsize/2 for rounding, since dvb-pll rounds down while saa7143 rounds to
nearest. I should make a patch to fix rounding in dvb-pll.
philips_fmd1216_tuner_sleep() is buggy! The _first_ time it is called
after _module loading_ it will send {0x0b, 0xdc, 0x9c, 0x60} and then
{0x0b, 0xdc, 0x86, 0x54} to the tuner. The first sequence sets AGC to
analog mode (IMHO, the v4l tuner driver should do this for tuner init,
but it doesn't). The second sequence just tunes to some random frequency
for no apparent reason. Neither actually turns the tuner off!
After the first time it is called, philips_fmd1216_tuner_sleep() will just
send {0x0b, 0xdc, 0x86, 0x54} twice! The array the sequence is in
shouldn't be static, or there should just be two static arrays for each
sequence. IMHO, using static locals that are not const is almost always
wrong in the kernel.
I think this could be replaced with the dvb-pll sleep function, if a
sleep sequence was added to dvb_pll_fmd1216me. We should send {0x9d,
0x60}, which will turn the tuner off and set the AGC back to the analog
recommended value.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] v4l-dvb: add $DESTDIR support
On Fri, 9 Mar 2007, Ludwig Nussel wrote: This doesn't seem correct. Shouldn't it be: print OUT \t/sbin/depmod -a \$(KERNELRELEASE) \$(if \$(DESTDIR),-b \$(DESTDIR))\n\n; One needs to run depmod when the modules get installed to their final location. $DESTDIR is incomplete so it doesn't make sense to run depmod here already. When compiling an RPM package DESTDIR may not be the final location, but that is not the only reason one might want to use DESTDIR. One could repair a mounted root fs after booting from a rescue CD or be trying to create a bootable MythTV image. Also consider what would happen if someone tried to rebuild the rpm as root or another user who would write to /. The modules would be installed in the rpm buildroot, but depmod would be run on their system modules. If the kernel v4l-dvb is being built against isn't the one that is being run, then they'll get a new directory in /lib/modules when they build the rpm. Well, obviously noone cared about such exotic use cased yet. Anyways here a patch that adds your change as well, please apply. Patch applied. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [PATCH] v4l-dvb: add $DESTDIR support
On Thu, 8 Mar 2007, Ludwig Nussel wrote:
Trent Piepho wrote:
Following patch adds $DESTDIR support so one can install the kernel
modules into a directory other than / as non-root user. That's
useful when building an rpm or compiling for a different machine.
-print OUT \t/sbin/depmod -a \${KERNELRELEASE}\n\n;
+print OUT \tif [ -w / ]; then /sbin/depmod -a \${KERNELRELEASE};
fi\n\n;
This doesn't seem correct. Shouldn't it be:
print OUT \t/sbin/depmod -a \$(KERNELRELEASE) \$(if \$(DESTDIR),-b
\$(DESTDIR))\n\n;
One needs to run depmod when the modules get installed to their final
location.
$DESTDIR is incomplete so it doesn't make sense to run depmod here already.
When compiling an RPM package DESTDIR may not be the final location, but
that is not the only reason one might want to use DESTDIR. One could
repair a mounted root fs after booting from a rescue CD or be trying to
create a bootable MythTV image.
If I can write to /, then the modules go to DESTDIR but depmod is run on /.
That doesn't seem consistent. And if I can't write to / (say it's read
only) but can write to the module install directory, then depmod isn't run,
even if I plan to boot a system with those modules.
Also, the kernel's modules_install target will run depmod on with -b
$(INSTALL_MOD_PATH) if the modules are being installed to a directory other
than the root. I think it makes sense to be consistent with the kernel's
behavior.
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
