Re: [GIT PULL -tip] fix 33 make headers_check warnings
* Sam Ravnborg s...@ravnborg.org wrote:
On Sun, Jan 18, 2009 at 08:37:41AM +1100, David Woodhouse wrote:
On Sun, 2009-01-18 at 01:47 +0530, Jaswinder Singh Rajput wrote:
--- a/include/linux/dvb/audio.h
+++ b/include/linux/dvb/audio.h
@@ -24,9 +24,8 @@
#ifndef _DVBAUDIO_H_
#define _DVBAUDIO_H_
-#ifdef __KERNEL__
#include linux/types.h
-#else
+#ifndef __KERNEL__
#include stdint.h
#endif
That patch looks wrong, and unnecessary. It was fine before.
Nope - include/linux/dvb/audio.h failed to include linux/types.h
despite the fact that is uses __u32 etc.
But why the _kernel_ should include a userspace header is
much more questionable.
ok, i dropped this one for the time being.
Sam, Andrew, et al, i've got the commit lineup below, to fix the ~200 new
CONFIG_HEADERS_CHECK=y warnings we have in current -git, on x86
allyesconfig.
Note that i have restructured the tree and the commits so that this effort
can be tracked more easily: each commit has a headers_check fix subject
line prefix. So you can go back later and revisit these things - for
example whether a header really needs to be exported to user-space, via:
git log --grep='headers_check fix:' --pretty=format:%h: %s
to get an overview and a historic track record. We can follow this
notation in the future too.
So if there are no objections, i'll send this to Linus tomorrow-ish and
we'll have the worst of the fallout behind us and can embark on a much
more fluid (and per maintainer) headers_check related workflow.
Ingo
-
The latest core/header-fixes git tree can be pulled from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git
core/header-fixes
--
Cyrill Gorcunov (3):
headers_check fix: x86, prctl.h
headers_check fix: x86, sigcontext32.h
headers_check fix: x86, setup.h
Jaswinder Singh Rajput (38):
headers_check fix: include/linux/*, __[us]{8,16,32,64} types
headers_check fix: capability.h: extern's make no sense in userspace
headers_check fix: coda_psdev.h: extern's make no sense in userspace
headers_check fix: in6.h: extern's make no sense in userspace
headers_check fix: nubus.h: extern's make no sense in userspace
headers_check fix: socket.h: extern's make no sense in userspace
headers_check fix: x86, e820.h
headers_check fix: x86, kvm.h
headers_check fix: x86, mce.h
headers_check fix: x86, mtrr.h
headers_check fix: x86, ptrace-abi.h
headers_check fix: x86, sigcontext.h
headers_check fix: x86, swab.h
headers_check fix: can/bcm.h
headers_check fix: dvb/dmx.h
headers_check fix: dvb/frontend.h
headers_check fix: dvb/net.h
headers_check fix: dvb/video.h
headers_check fix: netfilter/xt_conntrack.h
headers_check fix: nfsd/export.h
headers_check fix: nfsd/nfsfh.h
headers_check fix: nfsd/stats.h
headers_check fix: nfsd/syscall.h
headers_check fix: raid/md_p.h
headers_check fix: spi/spidev.h
headers_check fix: tc_act/tc_gact.h
headers_check fix: tc_act/tc_mirred.h
headers_check fix: tc_act/tc_pedit.h
headers_check fix: tc_ematch/tc_em_cmp.h
headers_check fix: tc_ematch/tc_em_meta.h
headers_check fix: tc_ematch/tc_em_nbyte.h
headers_check fix: tc_ematch/tc_em_text.h
headers_check fix: usb/cdc.h
headers_check fix: usb/gadgetfs.h
headers_check fix: mtd/inftl-user.h
headers_check fix: sound/hdsp.h
headers_check fix: video/sisfb.h
headers_check fix: video/uvesafb.h
arch/x86/include/asm/e820.h| 11 ---
arch/x86/include/asm/kvm.h |2 +-
arch/x86/include/asm/mce.h |5 +
arch/x86/include/asm/mtrr.h|1 +
arch/x86/include/asm/prctl.h |4
arch/x86/include/asm/ptrace-abi.h |5 -
arch/x86/include/asm/setup.h |8 +++-
arch/x86/include/asm/sigcontext.h |2 +-
arch/x86/include/asm/sigcontext32.h|2 ++
arch/x86/include/asm/swab.h| 21 +++--
include/linux/aio_abi.h|1 +
include/linux/atalk.h |1 +
include/linux/atmbr2684.h |1 +
include/linux/auto_fs4.h |1 +
include/linux/bfs_fs.h |2 ++
include/linux/blktrace_api.h |2 ++
include/linux/can/bcm.h|2 ++
include/linux/capability.h |8
include/linux/cdrom.h |1 +
include/linux/cgroupstats.h|1 +
include/linux/coda_psdev.h |2 ++
include/linux/dlm_plock.h |2 ++
include/linux/dn.h |2 ++
include/linux/dvb/dmx.h|2 +-
include/linux/dvb/frontend.h |3 +--
include/linux/dvb/net.h|3
Re: [linux-dvb] Where to buy a Dual PCI-e DVB-s2 card in switzerland ?
On Sat, Jan 17, 2009 at 08:10:48PM +0100, BOUWSMA Barry wrote: Hello ;-) (Feckin' Reply-To header makes it difficult to send a personal reply as well as a followup to the desired place... Grrr...) I don't really like the join of the different ml : over the past we have seen lots of this king of question on linux-dvb and I don't know if it's fine on this new one ? (if that's the case then I am for the joining...). (with mutt for example a g reply to all). Seems that it is not yet widely available... Yes you seem to be right. Can I assume you are in the Suisse Romande, and somewhat far from Germany/Basel, or perhaps somewhere like Zürich? You Yes, I am in Suisse Romande. can often save enough and get Mwst back if you shop over the border. Feel free to respond privately if you do not wish to make your location public... The Swiss Post recently changed there tax for presenting Mwst which makes the shipping from outside not as interesting as it was just a month ago here :-( In any case, I would suggest perhaps waiting a few weeks, and then seeing where it can be found in various online shops and price comparison sites... For sure I'll do that, thank you very much for your answer, -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Siano 10237 __le32 to le32
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1232271170 -7200
# Node ID 56b506432a55cebe0f52eb28cc8b55584bc9a429
# Parent 50775d37b85469c33f4023203a6c54394163c4bd
__le32 to le32
From: Uri Shkolnik u...@siano-ms.com
Trent Piepho made a commit review about the usage of __le32, as
a result the code has been modified to use le32 instead.
Priority: normal
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 50775d37b854 -r 56b506432a55 linux/drivers/media/dvb/siano/smscoreapi.c
--- a/linux/drivers/media/dvb/siano/smscoreapi.cThu Jan 15 15:39:15
2009 +0200
+++ b/linux/drivers/media/dvb/siano/smscoreapi.cSun Jan 18 11:32:50
2009 +0200
@@ -481,8 +481,8 @@ static int smscore_load_firmware_family2
u8 *payload = firmware-Payload;
int rc = 0;
- firmware-StartAddress = __le32_to_cpu(firmware-StartAddress);
- firmware-Length = __le32_to_cpu(firmware-Length);
+ firmware-StartAddress = le32_to_cpu(firmware-StartAddress);
+ firmware-Length = le32_to_cpu(firmware-Length);
mem_address = firmware-StartAddress;
diff -r 50775d37b854 -r 56b506432a55 linux/drivers/media/dvb/siano/smsendian.c
--- a/linux/drivers/media/dvb/siano/smsendian.c Thu Jan 15 15:39:15 2009 +0200
+++ b/linux/drivers/media/dvb/siano/smsendian.c Sun Jan 18 11:32:50 2009 +0200
@@ -34,7 +34,7 @@ void smsendian_handle_tx_message(void *b
switch (msg-xMsgHeader.msgType) {
case MSG_SMS_DATA_DOWNLOAD_REQ:
{
- msg-msgData[0] = __le32_to_cpu(msg-msgData[0]);
+ msg-msgData[0] = le32_to_cpu(msg-msgData[0]);
break;
}
@@ -43,7 +43,7 @@ void smsendian_handle_tx_message(void *b
sizeof(struct SmsMsgHdr_ST))/4;
for (i = 0; i msgWords; i++)
- msg-msgData[i] = __le32_to_cpu(msg-msgData[i]);
+ msg-msgData[i] = le32_to_cpu(msg-msgData[i]);
break;
}
@@ -62,7 +62,7 @@ void smsendian_handle_rx_message(void *b
{
struct SmsVersionRes_ST *ver =
(struct SmsVersionRes_ST *) msg;
- ver-ChipModel = __le16_to_cpu(ver-ChipModel);
+ ver-ChipModel = le16_to_cpu(ver-ChipModel);
break;
}
@@ -79,7 +79,7 @@ void smsendian_handle_rx_message(void *b
sizeof(struct SmsMsgHdr_ST))/4;
for (i = 0; i msgWords; i++)
- msg-msgData[i] = __le32_to_cpu(msg-msgData[i]);
+ msg-msgData[i] = le32_to_cpu(msg-msgData[i]);
break;
}
@@ -92,9 +92,9 @@ void smsendian_handle_message_header(voi
#ifdef __BIG_ENDIAN
struct SmsMsgHdr_ST *phdr = (struct SmsMsgHdr_ST *)msg;
- phdr-msgType = __le16_to_cpu(phdr-msgType);
- phdr-msgLength = __le16_to_cpu(phdr-msgLength);
- phdr-msgFlags = __le16_to_cpu(phdr-msgFlags);
+ phdr-msgType = le16_to_cpu(phdr-msgType);
+ phdr-msgLength = le16_to_cpu(phdr-msgLength);
+ phdr-msgFlags = le16_to_cpu(phdr-msgFlags);
#endif /* __BIG_ENDIAN */
}
diff -r 50775d37b854 -r 56b506432a55 linux/drivers/media/dvb/siano/smsusb.c
--- a/linux/drivers/media/dvb/siano/smsusb.cThu Jan 15 15:39:15 2009 +0200
+++ b/linux/drivers/media/dvb/siano/smsusb.cSun Jan 18 11:32:50 2009 +0200
@@ -334,7 +334,7 @@ static int smsusb_init_device(struct usb
case SMS_VEGA:
dev-buffer_size = USB2_BUFFER_SIZE;
dev-response_alignment =
- __le16_to_cpu(dev-udev-ep_in[1]-desc.wMaxPacketSize) -
+ le16_to_cpu(dev-udev-ep_in[1]-desc.wMaxPacketSize) -
sizeof(struct SmsMsgHdr_ST);
params.flags |= SMS_DEVICE_FAMILY2;
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL -tip] fix 33 make headers_check warnings
On Sun, Jan 18, 2009 at 10:13:00AM +0100, Ingo Molnar wrote: * Sam Ravnborg s...@ravnborg.org wrote: On Sun, Jan 18, 2009 at 08:37:41AM +1100, David Woodhouse wrote: On Sun, 2009-01-18 at 01:47 +0530, Jaswinder Singh Rajput wrote: --- a/include/linux/dvb/audio.h +++ b/include/linux/dvb/audio.h @@ -24,9 +24,8 @@ #ifndef _DVBAUDIO_H_ #define _DVBAUDIO_H_ -#ifdef __KERNEL__ #include linux/types.h -#else +#ifndef __KERNEL__ #include stdint.h #endif That patch looks wrong, and unnecessary. It was fine before. Nope - include/linux/dvb/audio.h failed to include linux/types.h despite the fact that is uses __u32 etc. But why the _kernel_ should include a userspace header is much more questionable. ok, i dropped this one for the time being. Sam, Andrew, et al, i've got the commit lineup below, to fix the ~200 new CONFIG_HEADERS_CHECK=y warnings we have in current -git, on x86 allyesconfig. Note that i have restructured the tree and the commits so that this effort can be tracked more easily: each commit has a headers_check fix subject line prefix. So you can go back later and revisit these things - for example whether a header really needs to be exported to user-space, via: git log --grep='headers_check fix:' --pretty=format:%h: %s to get an overview and a historic track record. We can follow this notation in the future too. So if there are no objections, i'll send this to Linus tomorrow-ish and we'll have the worst of the fallout behind us and can embark on a much more fluid (and per maintainer) headers_check related workflow. Thanks for taking care of this Ingo and please push towards Linus. And thanks to all the contributors too - it was great to see this dealt with soo quickly! Sam -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
Hi Trent, On Sat, 17 Jan 2009 11:45:57 -0800 (PST), Trent Piepho wrote: On Fri, 16 Jan 2009, Jean Delvare wrote: On Fri, 16 Jan 2009 05:34:59 -0800 (PST), Trent Piepho wrote: How will this work for drivers like bttv, where the i2c address of the tuner chips isn't know for every supported card? Is this a problem in practice? My understanding was that I2C gates were relatively recent in the history of V4L devices, so I assumed that for devices with an I2C gate we would know where the devices are. Changing hardware without notice is something manufactures still do, which makes probing even for modern hardware still useful in some cases. But I would expect limited probing then (using i2c_new_probed_device()), not wide probing using the .detect() method. But the old hardware that was always probed uses the same i2c clients as the new hardware that has gates and muxes. This isn't necessarily an issue: your I2C chip driver can implement a .detect() method for old hardware, where class is set to I2C_CLASS_TV_ANALOG, while more recent hardware set no class and instantiate the I2C devices explicitly. The new i2c model allows both approaches to cohabit nicely. This is indeed a possible implementation. One could argue though that it's a bit overkill to instantiate a separate i2c_adapter just for a gate. There are also caveats you must pay attention to. Two things in particular that come to my mind: The I2C layer doesn't have a concept for an i2c bus segment, so an i2c_adapter is the next closest thing. One could create an entirely new struct i2c_bus for that, but how would it be different than the currenct i2c_adapter? It seems like just another layer of complexity. I agree with you, using i2c_adapter for bus segments is the plan, as far as multiplexers are concerned. My point was whether it was worth considering a chip behind a gate as a bus segment or not. * Your proposal above, in its simple form, is incompatible with I2C device detection, because devices which are before the gate would be double-detected (once on each segment.) The first point is very easy to handle, the second is a little more complicated. Basically you should add an address check at the beginning of cx88_gate_i2c_xfer() to reject all transfers except to the device you know is behind the gate. I can think of a few more ways to do. The main adapter could get registered with no I2C_CLASS_* (or with something like I2C_CLASS_MUX) so clients that scan won't scan it. Then create virtual adapters for gate closed and gate open. Scan gate closed first and then excluded any addresses found from the gate open adapter. Yeah, that could work in some cases... At the cost of 3 i2c_adapter instances. And it seems specifically tailored for hardware that need scanning. I mean, if you do _not_ scan when gate is closed, then you don't know what addresses must be removed from the gate-opened adapter, so you can't allow for probing on that adapter. But this doesn't seem to work in the general case: you may not be able to actually scan for chips when gate is closed. Some chips may not respond to probing (either because they never do, or because they are themselves behind another gate or multiplexer.) For complex topologies, I am skeptical that your approach will be practical. It might even be pretty confusing due to the fact that the apparent topology will be quite different from the physical one. (If we go that route then it does make sense to start speaking of virtual adapters.) Anyway, there's nothing missing from i2c-core right now to implement this, is there? At which point it is no longer clear why you want to have 2 i2c_adapters. You can have just one which opens (and closes) the gate automatically for the right I2C address and not for the other addresses. The scanning order problem. The adapter is scanned before the gate can be controlled. Works better with i2c-dev too. Suppose I have a new card or a new revision and want to scan for devices behind the gate and see if I can figure out what they are? Well, if you have a new card, you presumably don't know that it has a gate to start with. If you have enough information about the gate, then I expect you to also have enough information about what is behind it. One possible requirement this discussion is bringing up, is the ability to instantiate an i2c_adapter without any probing class set, then do some initialization (e.g. accessing the gate chip, and close the gate) and only then add probing classes (or have a separate function to ask for re-probing of a given adapter.) This would fulfill your needs, wouldn't it? Then we can stick to the physical topology. Sorry for not being clear, I was only trying to address the gate issue here, not the (more complex) multiplexing issue. I am not aware of V4L devices having real I2C muxes? I think some multi-tuner cards have real muxes. But if the system created for
Re: budget.c driver: Kernel oops: BUG: unable to handle kernel paging request at ffffffff
Tony Broad wrote:
I'm using a Hauppauge WinTV-NOVA-T DVB card of PCI id 13c2:1005 with
kernel 2.6.27.9.
I've recently experienced the following fairly consistent kernel oops on
startup in grundig_29504_401_tuner_set_params from budget.c. As you
might expect, following this failure, the card doesn't work.
I'm not a kernel developer, nevertheless I seem to have managed to track
this down to a non-existent initialisation of
budget-dvb_frontend-tuner_priv.
The attached patch fixes the problem for me (and I've managed to tune
the card successfully as a result), but I don't know of anyone else
using the driver so I can't test it on other people.
Please let me know if this works for you or if I've done something
terribly wrong ;-(
Hi,
you are right, and your patch is basically correct.
Anyway, the l64781 frontend driver is a better place to fix the bug:
Initializing the frontend struct at allocation time will prevent this
kind of problem for all card drivers now and forever...
Signed-off-by: Oliver Endriss o.endr...@gmx.de
Btw, this fix should be applied to all kernels = 2.6.26.
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
diff -r 1930f80b6970 linux/drivers/media/dvb/frontends/l64781.c
--- a/linux/drivers/media/dvb/frontends/l64781.c Sun Dec 14 15:38:29 2008 +0100
+++ b/linux/drivers/media/dvb/frontends/l64781.c Sun Jan 18 14:04:39 2009 +0100
@@ -501,7 +501,7 @@ struct dvb_frontend* l64781_attach(const
{ .addr = config-demod_address, .flags = I2C_M_RD, .buf = b1, .len = 1 } };
/* allocate memory for the internal state */
- state = kmalloc(sizeof(struct l64781_state), GFP_KERNEL);
+ state = kzalloc(sizeof(struct l64781_state), GFP_KERNEL);
if (state == NULL) goto error;
/* setup the state */
Re: [linux-dvb] Siano subsystem (DAB/DMB support) library for linux?
On Sun, 18 Jan 2009, Uri Shkolnik wrote: You know, it might help if I actually looked at the files I'm hacking on, instead of blindly assuming they work like `MAKEDEV' and create the node in the current directory :-) Well, I guess that has blown my chances of ever getting a job again ;-) Now the world will see this post and say that something about my claim to having written an operating system in my spare time just doesn't add up... But now that the cat is out of the bag, and you've made the Linux library available to all, I figure it's time to post my hack to the public. Attached as a file is a replacement for the MAKEDEV-like script which can be found in contrib/ in the download from Siano. It tackles the following issues: * eliminates the DOS-type line-endings, which did not agree with my flavour of /bin/sh * attempts to figure out where the Siano library should be looking for its devices -- this is useful for the case where the desired major number 251 is already in use, and one has to specify a module load parameter (I think I've described this as best I could in an earlier message to linux-dvb) * allows the user to specify the major and/or minor numbers given as module parameters * unlinks potentially existing nodes in case of the need to recreate them with different major or minors This is a total hack, and can be rewritten to probably half the number of lines by anyone with a Clue, say, using a for loop and simplifying my logic (note to future employers: look into my eyes, my eyes, not around the eyes, you did not see this, you are suddenly interested in the shiny toys on your desk) So, feel free to improve on this, or to use it in place of that supplied from the Siano ftp site. It was not hardware debugging needed, so it seems. On Or... was it? Not only with major 249 on the newer build, but now, again with 249 on my notebook, I also see success. Could it be that the USB device into which I plugged the TerraTec Piranha caused the problems? Maybe, because into a different USB hub, I have success on the notebook... Now, the interesting thing is that a USB2 DVB-S connected through this same hub delivered streams that were corrupt every few minutes, while the same device connected to a different hub has been delivering flawless streams. Now I need to check whether the USB1 Piranha can deliver the clean streams, or if again, cheap hardware will cause me grief... An update to this, in case it would be of interest... After several attempts to tune potential if weak signals, I once again reached the point where attempts to initialise the device would timeout -- exactly what I had seen originally, but this time after half a dozen successful attempts to use it and at least get to the tuning stage. So now I've moved the device to a different USB hub port, and once again it's working fine. How long will this last? I still haven't tried it in the hub where my other DVB device works flawlessly, but it may come to that... Cool, I'm just CC the ML I get questions (sometimes the exact same questions) from various of people. Lets use the ML to sync all... Well, I hope that by making a fool of myself, I can post this info so that others can benefit from it, and you won't be bothered by these same questions. In summary: I've had success with DAB signals with the following: The default_mode= module loading parameter works set to =2. The firmware I've used is that which I downloaded some time back as part of the DVB-T in-kernel siano support, and looks like... -r-xr-xr-x 1 beer besoffen 40096 May 17 2007 /usr/lib/hotplug/firmware/tdmb_stellar_usb.inp There are firmware files of different size on the Siano ftp server, such as -rw-rw-r-- 1 beer staff 38428 2008-12-31 16:26 tdmb_stellar_usb_12mhz_downld.inp -rw-rw-r-- 1 beer staff 38720 2008-12-31 16:26 tdmb_stellar_usb_12mhz_eeprom_a2.brn I have not yet done anything with these to see if these might be a better choice. If, like me, your `cat /proc/devices` is full, and major 251 is assigned to something else, when you go to load the siano smsmdtv.ko kernel module, you will need to specify an alternate major number (minor can also be specified, should you need) smschar_major=249 (tweak as you need), for example. You can give the major number as 0... smschar_major=0 In this case, the first available major number will be automatically assigned. The script which I attach attempts to find this, assuming `procfs' is available and mounted, and does its best to create the proper devices. Should that fail, you can optionally specify the major (and, should you wish, the minor) as options to the script, which should explain itself in the comments if you read it. Here's hoping this is useful... (followup as appropriate; /dev/null is where this should have gone) barry bouwsma create_char_dev.sh Description: Hacked version of contrib/create_char_dev.sh
[PATCH] V4L/DVB: make card signed
Is this correct?
---8--8
make card signed
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/video/em28xx/em28xx-cards.c
b/drivers/media/video/em28xx/em28xx-cards.c
index ef9bf00..7c7a96c 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -47,7 +47,7 @@ static unsigned int disable_ir;
module_param(disable_ir, int, 0444);
MODULE_PARM_DESC(disable_ir, disable infrared remote support);
-static unsigned int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = UNSET };
+static int card[] = {[0 ... (EM28XX_MAXBOARDS - 1)] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Siano's patches
Uri Shkolnik wrote: Hi Mauro, Hope you had a great weekend :-) I would like to know if you have already reached the conclusion whether to use the Mercurial tree option or the email option we discussed last week. Regarding the patches that have been already submitted to the linux-media@vger.kernel.org ML, any schedule for the merge? Uri, I've already responded to your last email -- You should continue to submit patches to the mailing list. As for your pending patches, I explained in my email that they are in my queue. I am in the midst of reviewing the changes. As you're already aware, your changes break the Hauppauge device's functionality. After merging your changes, I will have to go back and re-implement the Hauppauge-specific changes in the driver, using the new methods in your pending patches. Once I have reviewed merged your changes and after I can restore the proper functionality to the hauppauge devices, then I will post a new mercurial tree for testing against all siano-based devices. Please be patient -- this takes time. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Auto-response for your message to the linux-dvb mailing list
linux-dvb-boun...@linuxtv.org wrote: This ML is deprecated. Please use linux-media@vger.kernel.org instead. For more info about linux-media@vger.kernel.org, please read: http://vger.kernel.org/vger-lists.html#linux-media Since when??? I thought we were going to have separate -user and -devel mailing lists? Now three separate mailing lists are being folded into one?!?!? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa716x: fix pointer cast to 32bit
Pointers may be 64bit long, casting them to u32 is wrong.
For doing math on the address unsigned long is guaranteed to have to correct
size to hold the value of the pointer.
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
linux/drivers/media/dvb/saa716x/saa716x_dma.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: b/linux/drivers/media/dvb/saa716x/saa716x_dma.c
===
--- a/linux/drivers/media/dvb/saa716x/saa716x_dma.c 2009-01-18
19:13:35.126021813 +0100
+++ b/linux/drivers/media/dvb/saa716x/saa716x_dma.c 2009-01-18
19:15:34.074015003 +0100
@@ -34,7 +34,7 @@
return -ENOMEM;
}
- BUG_ON(!(((u32) dmabuf-mem_ptab_phys % SAA716x_PAGE_SIZE) == 0));
+ BUG_ON(!(((unsigned long) dmabuf-mem_ptab_phys % SAA716x_PAGE_SIZE) ==
0));
return 0;
}
@@ -126,9 +126,9 @@
}
/* align memory to page */
- dmabuf-mem_virt = (void *) PAGE_ALIGN (((u32)
dmabuf-mem_virt_noalign));
+ dmabuf-mem_virt = (void *) PAGE_ALIGN (((unsigned long)
dmabuf-mem_virt_noalign));
- BUG_ON(!u32) dmabuf-mem_virt) % SAA716x_PAGE_SIZE) == 0));
+ BUG_ON(!unsigned long) dmabuf-mem_virt) %
SAA716x_PAGE_SIZE) == 0));
} else {
dmabuf-mem_virt = buf;
}
Luca
--
La vita potrebbe non avere alcun significato. Oppure, ancora peggio,
potrebbe averne uno che disapprovo. -- Ashleigh Brilliant
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] saa716x: fix uninitialized splinlocks
Fix uninitialized spinlocks.
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
linux/drivers/media/dvb/dvb-core/dmxdev.c|1 +
linux/drivers/media/dvb/saa716x/saa716x_hybrid.c |1 +
2 files changed, 2 insertions(+)
Index: b/linux/drivers/media/dvb/dvb-core/dmxdev.c
===
--- a/linux/drivers/media/dvb/dvb-core/dmxdev.c 2009-01-18 19:15:52.630015822
+0100
+++ b/linux/drivers/media/dvb/dvb-core/dmxdev.c 2009-01-18 19:16:17.182016807
+0100
@@ -1087,6 +1087,7 @@
for (i = 0; i dmxdev-filternum; i++) {
dmxdev-filter[i].dev = dmxdev;
dmxdev-filter[i].buffer.data = NULL;
+ spin_lock_init(dmxdev-filter[i].buffer.lock);
dvb_dmxdev_filter_state_set(dmxdev-filter[i],
DMXDEV_STATE_FREE);
}
Index: b/linux/drivers/media/dvb/saa716x/saa716x_hybrid.c
===
--- a/linux/drivers/media/dvb/saa716x/saa716x_hybrid.c 2009-01-18
19:15:52.590024681 +0100
+++ b/linux/drivers/media/dvb/saa716x/saa716x_hybrid.c 2009-01-18
19:16:17.182016807 +0100
@@ -49,6 +49,7 @@
goto fail0;
}
+ spin_lock_init(saa716x-gpio_lock);
saa716x-verbose= verbose;
saa716x-int_type = int_type;
saa716x-pdev = pdev;
Luca
--
Regole per la felicit�:
1. Sii soddisfatto di quello che hai.
2. Assicurati di avere tutto.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Siano's patches
--- On Sun, 1/18/09, Michael Krufky mkru...@linuxtv.org wrote: From: Michael Krufky mkru...@linuxtv.org Subject: Re: Siano's patches To: uri...@yahoo.com Cc: Mauro Carvalho mche...@infradead.org, linux-media@vger.kernel.org, linuxtv-comm...@linuxtv.org, linux-dvb linux-...@linuxtv.org Date: Sunday, January 18, 2009, 8:07 PM Uri Shkolnik wrote: Hi Mauro, Hope you had a great weekend :-) I would like to know if you have already reached the conclusion whether to use the Mercurial tree option or the email option we discussed last week. Regarding the patches that have been already submitted to the linux-media@vger.kernel.org ML, any schedule for the merge? Uri, I've already responded to your last email -- You should continue to submit patches to the mailing list. Mauro suggested two options, I asked for the first (the Mercurial tree) which is more convenient for me. As it used by multiple parties here and if there is no objection based on some unknown (to me) reason, I would like to use that option. As for your pending patches, I explained in my email that they are in my queue. I am in the midst of reviewing the changes. As you're already aware, your changes break the Hauppauge device's functionality. After merging your changes, I will have to go back and re-implement the Hauppauge-specific changes in the driver, using the new methods in your pending patches. Some of the patches in the list are pending from early September, 2008. ( I think it's time they will be popped out of the queue :-) Regarding restoring, modifying, enhancing, etc. - Please do it successively, submitting my patches and your after them, so (1) the congruity between the Mercurial DVB tree change-sets and Siano's change-set will be kept, and (2) I, and other reviewers, may review your patches/changes in their own change-sets. Once I have reviewed merged your changes and after I can restore the proper functionality to the hauppauge devices, then I will post a new mercurial tree for testing against all siano-based devices. Please see above Please be patient -- this takes time. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] ERRORS: armv5 armv5-ixp armv5-omap2 i686 m32r mips powerpc64 x86_64 v4l-dvb build
(This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below.) Results of the daily build of v4l-dvb: date:Sun Jan 18 19:00:02 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10241:7981bdd4e25a gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.16.61-armv5: OK linux-2.6.17.14-armv5: OK linux-2.6.18.8-armv5: OK linux-2.6.19.5-armv5: OK linux-2.6.20.21-armv5: OK linux-2.6.21.7-armv5: OK linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29-rc2-armv5: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29-rc2-armv5-ixp: ERRORS linux-2.6.27-armv5-omap2: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29-rc2-armv5-omap2: ERRORS linux-2.6.16.61-i686: OK linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29-rc2-i686: ERRORS linux-2.6.16.61-m32r: OK linux-2.6.17.14-m32r: OK linux-2.6.18.8-m32r: OK linux-2.6.19.5-m32r: OK linux-2.6.20.21-m32r: OK linux-2.6.21.7-m32r: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc2-m32r: ERRORS linux-2.6.16.61-mips: OK linux-2.6.26-mips: WARNINGS linux-2.6.27-mips: WARNINGS linux-2.6.28-mips: WARNINGS linux-2.6.29-rc2-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29-rc2-powerpc64: ERRORS linux-2.6.16.61-x86_64: OK linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29-rc2-x86_64: ERRORS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc2): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
On Sunday 18 January 2009 19:10:16 CityK wrote: Hans Verkuil wrote: On Friday 16 January 2009 04:20:02 CityK wrote: The hack-fix patch applies cleanly against Hans' sources. However, the test results are negative -- the previous workaround (modprobe tuner -r and modprobe tuner) fails to produce the desired result. If you try to run 'modprobe -r tuner' when the saa7134 module build from my sources is loaded, then that should not work since saa7134 increases the use-count of the tuner module preventing it from being unloaded. If you can do this, then that suggests that you are perhaps not using my modified driver at all. Huh? Of course I'm using your modified driver. As a recap: * I tried Hans' modified sources and the test result was negative. I also attempted (in a similar fashion as to the steps required when using Mike's hack/workaround) unloading all the modules and then modprobing them as Mike later explained, the modifications Hans had made are not enough to correct the issue * Mike then asked whether: (a) his hack/workaround still applied cleanly against Hans' source, and stated that, if that was not the case, then he would re-spin the hack patch ... I confirmed that Mike's hack/workaround did indeed apply cleanly against Han's source. (b) I was successful in getting the analogue TV working after applying his hack/workaround patch against Hans' source. However, as I reported, the results of this test were negative ... as Mauro later explained, the hack/workaround that Mike had spun will no longer work given the inherent changes introduced in Hans' code As requested by Mauro, I will provide the dmesg output, both that from the base case and then that given when 12c_scan is employed ... but that will have to occur either later today or sometime during the week ... at present, I have switched back to an older changeset, as I required having a functional second TV this weekend BTW, I've asked Mauro to pull from my tree (www.linuxtv.org/hg/~hverkuil/v4l-dvb) which contains the converted saa7134 and saa6752hs drivers. It's definitely something that needs to be done regardless. Err, while I agree that the changes are something that need to be done (I don't think anyone is in disagreement with that consensus), I don't think that this is a case of regardless.In fact, I stand behind Mike's position: Anyway, if the previous workaround works after Hans' changes, then I think his changes should be merged But as I have demonstrated above, and as Mauro explained, the previous hack/workaround no longer works in the case of with the Hans source code. The if case fails! Consequently, the else case should be don't merge. Why? Because we have now gone from: * circa pre-2.6.25, Mauro's changes that broke the boards analog TV support, but which could somewhat be corrected by Mike's hack/workaround * to present, where merging Hans' code eliminates the usability of Mike's hack/workaround ... in essence, analog TV function has now been completely killed with these boards. I've taken a look at Mike's workaround and that will indeed no longer work. I suspect that the core problem is related to the SAA7134_BOARD_KWORLD_ATSC110 case in saa7134_board_init2 in saa7134-cards.c. There the 'tuner is enabled', whatever that means. I'm beginning to suspect that this code should perhaps be executed before the tuner module is loaded. Does anyone know more about what is going on here? If my analysis is correct, then this should be executed earlier. Reading older mails in this thread suggests that this is indeed the case. I've made a new tree http://linuxtv.org/hg/~hverkuil/v4l-dvb-kworld/ that calls 'enables the tuner' before loading the module. See if that works. Anyway, I get the feeling that saa7134_board_init2 contains different types of initializations: some open a gate or mux to a tuner and so should be called before loading and setting the tuner, and others should be called after loading the tuner, but before setting up the tuner. Now, if it is a case that a resolution to the problem is imminently forthcoming, then I don't think that the merge would be much of a problem. However, given the breadth of the conversation so far (and I really do appreciate the depth of Trent's and Jean's discussion/consideration on the matter), it is entirely unclear to me that such a resolution will be found in short order (although, I don't discount the possibility of it either). It should definitely go in, if only to ensure deterministic behavior. Please test my v4l-dvb-kworld tree. I suspect that this might fix the bug. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] DVB: negative internal-sub_range won't get noticed
internal-sub_range is unsigned, a negative won't get noticed.
Signed-off-by: Roel Kluin roel.kl...@gmail.com
---
diff --git a/drivers/media/dvb/frontends/stb0899_algo.c
b/drivers/media/dvb/frontends/stb0899_algo.c
index 83dc7e1..2ea32da 100644
--- a/drivers/media/dvb/frontends/stb0899_algo.c
+++ b/drivers/media/dvb/frontends/stb0899_algo.c
@@ -464,13 +464,14 @@ static void next_sub_range(struct stb0899_state *state)
if (internal-sub_dir 0) {
old_sub_range = internal-sub_range;
- internal-sub_range = MIN((internal-srch_range / 2) -
+ if (internal-tuner_offst + internal-sub_range / 2 =
+ internal-srch_range / 2)
+ internal-sub_range = 0;
+ else
+ internal-sub_range = MIN((internal-srch_range / 2) -
(internal-tuner_offst +
internal-sub_range / 2),
internal-sub_range);
- if (internal-sub_range 0)
- internal-sub_range = 0;
-
internal-tuner_offst += (old_sub_range + internal-sub_range)
/ 2;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KWorld ATSC 115 all static
Hans Verkuil wrote: On Sunday 18 January 2009 22:20:30 CityK wrote: The output of dmesg is interesting (two times tuner simple initiating): Shouldn't there be a tda9887 as well? It's what the card config says, but I'm not sure whether that is correct. Would you like to see the results of after enabling 12c_scan to see what is going on, or is this the behaviour you expected? It seems to be OK, although I find it a bit peculiar that the tuner type is set twice. Or does that have to do with it being a hybrid tuner, perhaps? The Philips TUV1236D NIM does indeed use a tda9887 (I know, because I was the one who discovered this some four years ago (pats self on head)). But the module is not loading. I can make it load, just as Hermann demonstrated to Mike in one of the recent messages for this thread. In regards to the tuner type being set twice, that is precisely my point -- its peculiar and not symptomatic of normal behaviour. That is why I asked whether you expected it to do this Some Other Miscellanea: 1) Before this gets merged, can I ask you to also make one small change to tuner-simple; specifically, swap the contents of lines 301 and 304. This will change the driver's default behaviour in regards to the selection of which RF input to use for digital cable and digital over-the-air. Currently, the driver is set to use digital OTA on the top RF input and digital cable on the lower RF input spigot. However, IMO, a more logical/convenient configuration is to have the digital cable input be handled by the top RF input spigot, as this is the same one that the analog cable is also drawn from by default. Mike had made this change, on my request, previously, but it appears that it got reverted after the tuner re-factoring. Note: users have reported different default configurations in the past (e.g. http://www.mythtv.org/wiki/Kworld_ATSC_110), but I actually doubt that there has been any manufacturing difference with the TUV1236D. Rather, I suspect that the user experiences being reported are just reflecting a combination of the different states of how our driver behaved in the past and differences in driver version that they may have been using (i.e. that version provided by/within their distro or by our Hg). After all, this configuration setting has gone from being handled by saa7134-dvb.c to dvb-pll.c to tuner-simple.c, with changes in the behaviour implemented along the way. I'm not going to merge this, it's just a quick hack for this card. This is something for Mike or Hermann to fix. Fair enough -- I will pester them a la Bart Simpson spy camera style (see: http://peanutbutterandpickles.blogspot.com/2008/06/wheres-my-spy-camera-wheres-my-spy.html and for actual dialogue: http://www.snpp.com/episodes/7G10.html) :P It is a trivial change which I can vouch that works (after successfully testing your new KWorld changeset, I immediately applied this change and rebuilt ... with, of course, successful results). Someone with a better knowledge of this driver and these tuners should review the saa7134_board_init2() function and move the opening of tuner gate/muxes to a separate function. 2) This is likely related to the discussion about the gate -- after closing the analog TV app, the audio from the last channel being viewed can still be heard if one turns up the volume on their system. This leakage has always been present. But given that we are addressing this issue now, it strikes me that the gate is being kept open on the audio line after application closing/release occurs. I just did some testing in regards to point number 2 ... at first I was thinking that maybe it was because tda9887 is not loading automatically that, absent of fine control, the audio leakage was occurring. But after loading tda9887 and then removing the module, the leakage continues. Naturally, the other suspect is saa7134. And, as it turns out, if one modprobe -r saa7134-dvb (which obviously uses sa7134), then the audio leakage immediately comes to an end, and checking lsmod, saa7134 is no longer found. So at least I know the source of the bug now ... now its just a case of getting it to release properly. Comments from anyone on this? 3) there is an issue about having two of these cards in the same system --- IIRC, only one card will get /dev/video Mauro touched upon this very briefly in one of the earlier messages; recall: Mauro wrote: This generated lots of issues in the past, like machines with two boards doesn't work anymore. With two boards, and a tuner module, the first board probes tuner after opening the demod gateway. However, the second board will try to probe tuner before opening the i2c gateway. So, tuner is not found. Now, I can't test for this myself, but I do know of several users on AVSforums who have two such cards and can test if that issue is now resolved do you suspect that the
Re: Analog TV on Leadtek PxDVR 3200 H
Martin Edlman wrote: Hello, I have a problem with module cx23885, it doesn't create the /dev/video0 device. The module doesn't support analogue yet. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL -tip] fix 33 make headers_check warnings
On Mon, 2009-01-19 at 11:24 +1100, Stephen Rothwell wrote:
On Sun, 18 Jan 2009 01:47:21 +0530 Jaswinder Singh Rajput
jaswin...@kernel.org wrote:
diff --git a/include/linux/nfsd/stats.h b/include/linux/nfsd/stats.h
index 7678cfb..0b53cfe 100644
--- a/include/linux/nfsd/stats.h
+++ b/include/linux/nfsd/stats.h
@@ -29,9 +29,11 @@ struct nfsd_stats {
unsigned intra_size;/* size of ra cache */
unsigned intra_depth[11]; /* number of times ra entry was found
that deep
* in the cache (10percentiles). [10] =
not found */
+#ifdef __KERNEL__
#ifdef CONFIG_NFSD_V4
unsigned intnfs4_opcount[LAST_NFS4_OP + 1]; /* count of individual
nfsv4 operations */
#endif
+#endif /* __KERNEL__ */
};
The only variable in the kernel of type struct nfsd_stats is only
exported to user mode via procfs, so this whole structure could probably
go inside __KERNEL__. Then looking harder, I wonder if this header
should be exported to user mode at all.
I was in doubt may be this will be used by some userspace utilities.
Once I got confirmation that it is not required in userspace, I will
remove it :-)
--
JSR
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Mon, 19 Jan 2009 05:25:15 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote:
On Sat, 17 Jan 2009 19:09:51 +0100
Carsten Meier c...@trexity.de wrote:
Am Fri, 16 Jan 2009 02:47:50 -0200
schrieb Mauro Carvalho Chehab mche...@infradead.org:
For usb devices, usb_make_path() provide a canonical name for
the device. For PCI ones, we have pci_name() for the same
function. in the case of pci devices, I suspect that all use
pci_name(). We just need to use usb_make_path() at the usb
ones.
I looked at the sources for what string gets generated for
bus_info by usb_make_path(). If it gets used by pvrusb2, my
problems are solved, because it is constant across
standby-wake-up-cycles. The pvrusb2's implementation currently
delivers usb 7-2 address 6 here. address 6 corresponds to
devnum which gets constantly increased, which results in always
changing strings here. Sorry for my unneccessary complaints.
Mike, Thierry, Jean-Francois, Laurent and others:
IMO, we should patch all usb drivers to use usb_make_path(). It
will be more transparent to userspace, if all drivers provide the
bus_info using the same notation. Comments?
I did this thing to dsbr100.c usb radio driver:
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34
2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.c Mon Jan
19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
+ struct dsbr100_device *radio = video_drvdata(file);
+
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio,
sizeof(v-card));
- sprintf(v-bus_info, USB);
+ usb_make_path(radio-usbdev, v-bus_info,
sizeof(v-bus_info));
+ printk(KERN_INFO %s\n, v-bus_info);
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER;
return 0;
And get such dmesg messages for different usb ports:
usb-:00:1d.2-2
usb-:00:1d.0-1
Looks okay to my eyes or may be i missed something. Anyway it's more
useful than just simple USB string.
Do you get the same string if you unplug and then replug the same
device to the same port? If not, I have the same problems than before,
otherwise I'll be happy with it.
Regards,
Carsten
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2
Am Mon, 19 Jan 2009 06:11:33 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Mon, Jan 19, 2009 at 6:09 AM, Alexey Klimov
klimov.li...@gmail.com wrote:
On Mon, 2009-01-19 at 03:55 +0100, Carsten Meier wrote:
Am Mon, 19 Jan 2009 05:25:15 +0300
schrieb Alexey Klimov klimov.li...@gmail.com:
On Sun, 2009-01-18 at 23:36 -0200, Mauro Carvalho Chehab wrote:
On Sat, 17 Jan 2009 19:09:51 +0100
Carsten Meier c...@trexity.de wrote:
Am Fri, 16 Jan 2009 02:47:50 -0200
schrieb Mauro Carvalho Chehab mche...@infradead.org:
For usb devices, usb_make_path() provide a canonical name
for the device. For PCI ones, we have pci_name() for the
same function. in the case of pci devices, I suspect that
all use pci_name(). We just need to use usb_make_path() at
the usb ones.
I looked at the sources for what string gets generated for
bus_info by usb_make_path(). If it gets used by pvrusb2, my
problems are solved, because it is constant across
standby-wake-up-cycles. The pvrusb2's implementation
currently delivers usb 7-2 address 6 here. address 6
corresponds to devnum which gets constantly increased, which
results in always changing strings here. Sorry for my
unneccessary complaints.
Mike, Thierry, Jean-Francois, Laurent and others:
IMO, we should patch all usb drivers to use usb_make_path(). It
will be more transparent to userspace, if all drivers provide
the bus_info using the same notation. Comments?
I did this thing to dsbr100.c usb radio driver:
diff -r de513684aca2 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Jan 18 23:06:34
2009 -0200 +++ b/linux/drivers/media/radio/dsbr100.cMon
Jan 19 05:18:36 2009 +0300 @@ -393,9 +393,12 @@
static int vidioc_querycap(struct file *file, void *priv,
struct v4l2_capability *v)
{
+ struct dsbr100_device *radio = video_drvdata(file);
+
strlcpy(v-driver, dsbr100, sizeof(v-driver));
strlcpy(v-card, D-Link R-100 USB FM Radio,
sizeof(v-card));
- sprintf(v-bus_info, USB);
+ usb_make_path(radio-usbdev, v-bus_info,
sizeof(v-bus_info));
+ printk(KERN_INFO %s\n, v-bus_info);
v-version = RADIO_VERSION;
v-capabilities = V4L2_CAP_TUNER;
return 0;
And get such dmesg messages for different usb ports:
usb-:00:1d.2-2
usb-:00:1d.0-1
Looks okay to my eyes or may be i missed something. Anyway it's
more useful than just simple USB string.
Do you get the same string if you unplug and then replug the same
device to the same port? If not, I have the same problems than
before, otherwise I'll be happy with it.
To be sure that i did that you want me to: i plug device in, run
application that use it, close application, unplug device, and then
plug device in (and i didn't reload the kernel module during this),
run app again..
Yes, i have the same string in this case. btw, kernel 2.6.29-rc2.
Oh, i forget to tell you that it was the same usb port and the same
usb device. :)
Yes, that's what I meant. :) Userspace-land would be very happy if
usb_make_path() is used by all usb-device-drivers.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Regression since 2.6.25 kernel: Crash of userspace program leaves DVB device unusable
Hi, I wrote to linux-dvb (2009-01-03 12:00 pm): I've been coming up against a problem that seems to be with the DVB drivers that occurs when a program using them, usually VDR in my case, terminates uncleanly (segfault, general protection fault). Linux 2.6.25 doesn't have this problem, but 2.6.26, 2.6.27, and 2.6.28 do, though 2.6.28 manifests slightly differently to the others. I'll focus on what 2.6.28 does. I have a DViCO FusionHDTV DVB-T Plus, running on an amd64 Debian Testing (mostly) dual-core machine. After VDR crashes it attemps to restart itself. This was fine on 2.6.25, but on later kernels the crash seems to leave the device in some unusable state, where no program can subsequently use it - the device files (/dev/dvb) no longer exist. (In 2.6.2[67], the files existed, but accessing /dev/dvb/adapter0/dvr0 resulted in No such device.) I had figured out that in order to get the device working again it is necessary to rmmod cx88_dvb cx8802; modprobe cx88_dvb. This worked in 2.6.2[67] without trouble, but in 2.6.28, it's as if the cx88_dvb module gets lost somehow. It doesn't appear in lsmod, however: phi:~# modprobe cx88_dvb FATAL: Error inserting cx88_dvb (/lib/modules/2.6.28/kernel/drivers/media/video/cx88/cx88-dvb.ko): No such device phi:~# rmmod cx88_dvb cx8802 ERROR: Module cx88_dvb does not exist in /proc/modules phi:~# modprobe cx88_dvb Note that probing it works only *after* cx8802 was unloaded. As before, now the device is accessible. So it seems something is wrong in the cx8802 module. Something is not being cleaned up after a userspace program crashes while using it, leaving the DVB system in a broken state. I'd very much like this to not be the case, since on my system a VDR crash is somewhat inevitable, and the automatic restart *was* very handy, back in 2.6.25. Deafening silence. Does nobody have a clue? Or care? I just noticed I posted to the linux-dvb list which has been deprecated, so I'm quoting it here in its entirety in case relevent people missed it. Is there anything else I can do? Peace, Brendon signature.asc Description: This is a digitally signed message part.
Re: KWorld ATSC 115 all static
On Monday 19 January 2009 08:53:19 Hans Verkuil wrote: On Monday 19 January 2009 00:36:35 CityK wrote: Hans Verkuil wrote: On Sunday 18 January 2009 22:20:30 CityK wrote: The output of dmesg is interesting (two times tuner simple initiating): Shouldn't there be a tda9887 as well? It's what the card config says, but I'm not sure whether that is correct. Would you like to see the results of after enabling 12c_scan to see what is going on, or is this the behaviour you expected? It seems to be OK, although I find it a bit peculiar that the tuner type is set twice. Or does that have to do with it being a hybrid tuner, perhaps? The Philips TUV1236D NIM does indeed use a tda9887 (I know, because I was the one who discovered this some four years ago (pats self on head)). But the module is not loading. I can make it load, just as Hermann demonstrated to Mike in one of the recent messages for this thread. I have no idea why the tda9887 isn't loading. It loads fine for my empress card. Does someone know if there is something special about this? And how do you manage to make analog TV work if the tda9887 isn't found? That's rather peculiar. To clarify: you should see this in the dmesg output if there is a tda9887: ... saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff ff ff ff ff tuner 1-0043: chip found @ 0x86 (saa7133[0]) tda9887 1-0043: creating new instance tda9887 1-0043: tda988[5/6/7] found ^^^ All bytes are equal. It is not a TEA5767 tuner 1-0060: chip found @ 0xc0 (saa7133[0]) tuner-simple 1-0060: creating new instance tuner-simple 1-0060: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) input: BeholdTV as /class/input/input2 ir-kbd-i2c: BeholdTV detected at i2c-1/1-002d/ir0 [saa7133[0]] saa6752hs 1-0020: chip found @ 0x40 (saa7133[0]) saa7133[0]: registered device video0 [v4l2] saa7133[0]: registered device vbi0 saa7133[0]: registered device radio0 saa7133[0]: registered device video1 [mpeg] Regards, Hans In regards to the tuner type being set twice, that is precisely my point -- its peculiar and not symptomatic of normal behaviour. That is why I asked whether you expected it to do this I think it is OK. The second setup is probably done by dvb_attach() in saa7134-dvb.c, line 1191. Can you verify that with a debug message? Note that Mauro merged my saa7134 changes, so these are now in the master repository. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
