Re: [PULL] nGene driver - http://endr...@linuxtv.org/hg/~endriss/ngene
Hi, Mauro Carvalho Chehab wrote: There's just one thing missing: to update the get firmware script to get the firmware files from somewhere, or to add some documentation about how to retrieve it. When you have some time, please prepare something. Mauro, Please pull from http://endr...@linuxtv.org/hg/~endriss/ngene for the following 2 changesets: 01/02: get_dvb_firmware: Add function to retrieve nGene firmwares http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=647f7b65d45d 02/02: get_dvb_firmware: Fix typo, sort list of components http://endr...@linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=a48317c6c872 get_dvb_firmware | 23 +-- 1 file changed, 21 insertions(+), 2 deletions(-) Thanks, Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls: On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP So there is something wrong with the list manipulations or, if needed, locking around the the list manipulations of the list that was introduced in the patch you identified as the problem. That is what is causing the Ooops on close(). It will take a some more scrutiny to see what exactly is wrong. Schedule update: I'll be looking at this tonight (Thursday evening). After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Comments? Regards, Andy Hi Andy, thanks for this excellent analysis :) kaffeine-1.0pre3, xawtv-4.0pre (-discontinued), vdr-1.6.0, mythtv-0.22: None of them uses neither DMX_ADD_PID nor DMX_REMOVE_PID in conjunction with DMX_OUT_TSDEMUX_TAP. So reverting the kernel patch does not do harm to anybody. Furthermore: If it is technically possible to send and receive, demux and multiplex, play and record complete contents of a transponder (i. e. multiple TS streams) by using dvbstream or mumudvb (- 8192 command line parameter), then I myself do not see the necessity to extend the capabilities of one physical device dvr0 or demux0 into a multiplicity of devices dvr0 or demux0. The what and especially the why will remain Andreas Oberritters' secret. However: The hanging process that alevt-dvb produces if an external application switches to a channel belonging to a different DVB-S transponder still remains the second problem which is not touched by this discussion - just as a reminder for everybody! The one who wants to use teletext under Linux is in a very bad position: 1. There seems to be a plugin for vdr that I never tried because I do not like vdr at all. 2. alevt-dvb is officially not maintained. The last contribution by its original author happened in 2007 with the implementation of v4l2. 3. mtt by Gerd Knorr (Hoffmann) is part of a discontinued suite called xawtv-4.0 pre. xawtv-4.0 pre was never officially released or finished. Especially the main program xawtv is simply
I don't get GIT
Hi Linux Media, As an end user I am most interested in updating specific drivers for my system. Most distros, that I know of, only bump kernel versions by releasing a new version of the distro. As development move to the GIT repository, how do I as an end user pull the drivers and compile for my current running kernel? I am not too interested in compiling the whole kernel just to get the fixes of the drivers. NOTE: The sole reason this server exists is to provide TV and media distribution in the home. When I read through Mauro's announcement of the GIT repository it seemed to indicate that this feature wasn't available. Although I could have read that incorrectly. Thanks in advance for the answers! Brandon -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Chicken Furthermore: If it is technically possible to send and receive, demux and multiplex, play and record complete contents of a transponder (i. e. multiple TS streams) by using dvbstream or mumudvb (- 8192 command line parameter), then I myself do not see the necessity to extend the capabilities of one physical device dvr0 or demux0 into a multiplicity of devices dvr0 or demux0. The what and especially the why will remain Andreas Oberritters' secret. I can only say my 2 words regarding Andreas' patch: At least one big DVB application is using it - enigma (originally inside tuxbox project, later enhanced by Dream Multimedia for theirs well-known linux based set-top-boxes Dreambox). Those boxes are selling worlwide, so userbase is wide enough (note: I'm not in any way connected with Dream Multimedia, so it is only my personal feeling and/or investigation). Of course using full TS and remuxing only in user land is not possible way for embedded application. And if you count that there can be more then one TS input, things are getting even worst. And as Andy wrote: But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Well, it is also possible way. But it expands dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so. We definitelly need such feature. I, personally, like DMX_OUT_TSDEMUX_TAP approach. Rgds /Honza -- 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: I don't get GIT
Hello Brandon, On 02/05/2010 09:48 AM, Brandon Jenkins wrote: Hi Linux Media, As an end user I am most interested in updating specific drivers for my system. Most distros, that I know of, only bump kernel versions by releasing a new version of the distro. As development move to the GIT repository, how do I as an end user pull the drivers and compile for my current running kernel? I am not too interested in compiling the whole kernel just to get the fixes of the drivers. NOTE: The sole reason this server exists is to provide TV and media distribution in the home. We still have mercurial tree available which became the backport tree. Basically, almost daily this tree is synced with git tree and backported some drivers to work with old kernels. When I read through Mauro's announcement of the GIT repository it seemed to indicate that this feature wasn't available. Although I could have read that incorrectly. You can download the hg tree following the linuxtv wiki page: http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#Using_Mercurial Cheers, Douglas -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Andreas Oberritter wrote: Hello Andy, Andy Walls wrote: After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. Well, the patch were already added on an upstream kernel, so just reverting it will cause regressions. If it is just aletv-dvb that broke, it seems better to fix it than to cause even more troubles by reverting two new ioctls. The reason for this is not that fixing the patch is impossible. Why? Where exactly the breakage happened? INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. why exactly do you think this is wrong? I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Would this involve running mknod for every recording you start? Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. Andreas arguments makes sense to me. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. I'm sure, other projects are going to adopt this interface sooner or later. It is still quite new after all. It seems too late for me to revert it. So, we need to figure out a way to workaround it or to fix the applications that got broken by this change. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hello Andy, Andy Walls wrote: After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. why exactly do you think this is wrong? I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Would this involve running mknod for every recording you start? Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. I'm sure, other projects are going to adopt this interface sooner or later. It is still quite new after all. Regards, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy
Hi,
On 02/04/2010 09:22 AM, Németh Márton wrote:
Hi,
This is a proof-of-concept patch to try to decode the JPEG with PixArt markers.
Please check whether it is working at your side. My experience is that the
number of frames with glitch are reduced.
Hi,
Good job! I never noticed the ff ff ff xx markers where spaced a certain numbers
of bytes apart. Based on that I've written a different filtering function, which
at least for me completely removes all glitches!!
See:
http://linuxtv.org/hg/~hgoede/libv4l/rev/1fa67e17b77c
Thanks !!!
Regards,
Hans
Regards,
Márton Németh
---
From: Márton Némethnm...@freemail.hu
Before trying to decode the image data filter the PixArt markers out.
Signed-off-by: Márton Némethnm...@freemail.hu
---
diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.h
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hTue Feb 02
11:34:06 2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hThu Feb 04
09:13:24 2010 +0100
@@ -91,8 +91,11 @@
/* Private variables */
const unsigned char *stream_begin, *stream_end;
unsigned int stream_length;
+ unsigned char *stream_begin_filtered, *stream_end_filtered;
+ unsigned int stream_length_filtered;
const unsigned char *stream;/* Pointer to the current stream */
+ unsigned char *stream_filtered;
unsigned int reservoir, nbits_in_reservoir;
struct component component_infos[COMPONENTS];
diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Tue Feb 02 11:34:06 2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Thu Feb 04 09:13:24 2010 +0100
@@ -312,19 +312,18 @@
/* Special Pixart versions of the *_nbits functions, these remove the special
ff ff ff xx sequences pixart cams insert from the bitstream */
-#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \
+#define
pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted) \
do { \
while (nbits_in_reservoirnbits_wanted) \
{ \
unsigned char c; \
- if (stream= priv-stream_end) { \
+ if (stream= stream_end) { \
snprintf(priv-error_string, sizeof(priv-error_string), \
fill_nbits error: need %u more bits\n, \
nbits_wanted - nbits_in_reservoir); \
longjmp(priv-jump_state, -EIO); \
} \
c = *stream++; \
- reservoir= 8; \
if (c == 0xff) { \
switch (stream[0]) { \
case 0x00: \
@@ -332,7 +331,7 @@
break; \
case 0xd9: /* EOF marker */ \
stream++; \
- if (stream != priv-stream_end) { \
+ if (stream != stream_end) { \
snprintf(priv-error_string, sizeof(priv-error_string), \
Pixart JPEG error: premature EOF\n); \
longjmp(priv-jump_state, -EIO); \
@@ -340,14 +339,22 @@
break; \
case 0xff: \
if (stream[1] == 0xff) { \
- if (stream[2] 7) { \
+ if (stream[2] == 0) { \
+ stream += 3; \
+ c = *stream++; \
+ break; \
+ } else if (stream[2] == 1) { \
+ stream += 3; \
+ c = *stream++; \
+ break; \
+ } else if (stream[2] == 2) { \
stream += 3; \
c = *stream++; \
break; \
} else if (stream[2] == 0xff) { \
- /* four 0xff in a row: the first belongs to the image data
*/ \
+ /* four 0xff in a row: the first belongs to the image */ \
break; \
- }\
+ } \
} \
/* Error fall through */ \
default: \
@@ -358,15 +365,16 @@
longjmp(priv-jump_state, -EIO); \
} \
} \
+ reservoir= 8; \
reservoir |= c; \
nbits_in_reservoir+=8; \
} \
} while(0);
/* Signed version */
-#define
pixart_get_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \
+#define
pixart_get_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result)
\
do { \
- pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \
+
pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,(nbits_wanted));
\
result = ((reservoir)(nbits_in_reservoir-(nbits_wanted))); \
nbits_in_reservoir -= (nbits_wanted); \
reservoir= ((1Unbits_in_reservoir)-1); \
@@ -374,9 +382,9 @@
result += (0xUL(nbits_wanted))+1; \
} while(0);
-#define
pixart_look_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \
+#define
pixart_look_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result)
\
do { \
- pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \
+
[PATCH 3/4] V4L/DVB: gspca - sn9c20x: correct onstack wait_queue_head declaration
Use DECLARE_WAIT_QUEUE_HEAD_ONSTACK to make lockdep happy
Signed-off-by: Yong Zhang yong.zha...@gmail.com
Cc: Brian Johnson brij...@gmail.com
Cc: Jean-Francois Moine moin...@free.fr
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: linux-media@vger.kernel.org
---
drivers/media/video/gspca/sn9c20x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/gspca/sn9c20x.c
b/drivers/media/video/gspca/sn9c20x.c
index 0ca1c06..8f75fbc 100644
--- a/drivers/media/video/gspca/sn9c20x.c
+++ b/drivers/media/video/gspca/sn9c20x.c
@@ -1426,7 +1426,7 @@ static int input_kthread(void *data)
struct gspca_dev *gspca_dev = (struct gspca_dev *)data;
struct sd *sd = (struct sd *) gspca_dev;
- DECLARE_WAIT_QUEUE_HEAD(wait);
+ DECLARE_WAIT_QUEUE_HEAD_ONSTACK(wait);
set_freezable();
for (;;) {
if (kthread_should_stop())
--
1.6.3.3
--
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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Hello Andy, Andy Walls wrote: After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. Well, the patch were already added on an upstream kernel, so just reverting it will cause regressions. If it is just aletv-dvb that broke, it seems better to fix it than to cause even more troubles by reverting two new ioctls. The reason for this is not that fixing the patch is impossible. Why? Where exactly the breakage happened? Mauro, alevt-dvb is the only application that is broken by that kernel patch in question. mtt works, but it is part of a suite of programs, it's not teletext only. So the architexture behind is much more complicated than alevt-dvb itself ever was. Conclusion: fix the application alevt-dvb is the shortest way to solve the problem. CS INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. why exactly do you think this is wrong? I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Would this involve running mknod for every recording you start? Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. Andreas arguments makes sense to me. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. I'm sure, other projects are going to adopt this interface sooner or later. It is still quite new after all. It seems too late for me to revert it. So, we need to figure out a way to workaround it or to fix the applications that got broken by this change. -- 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] adv7180 builds since kernel 2.6.26
VIDEO_ADV7180 is listed twice in v4l/versions.txt: once in [2.6.31] and once in [2.6.26]. As I have tested that it builds fine in 2.6.26, drop the former entry. Signed-off-by: Jean Delvare kh...@linux-fr.org --- v4l/versions.txt |1 - 1 file changed, 1 deletion(-) --- v4l-dvb.orig/v4l/versions.txt 2010-01-25 21:25:50.0 +0100 +++ v4l-dvb/v4l/versions.txt2010-02-05 15:13:47.0 +0100 @@ -18,7 +18,6 @@ VIDEO_DM355_CCDC # Start version for those drivers - probably compile with older versions VIDEO_CX25821 VIDEO_CX25821_ALSA -VIDEO_ADV7180 RADIO_TEF6862 # follow_pfn needed by VIDEOBUF_DMA_CONTIG and drivers that use it VIDEOBUF_DMA_CONTIG -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Mauro Carvalho Chehab wrote: Pekka Sarnila wrote: So dvb is both as a place and a name misleading. It happens that almost all tv products (analog or digital) come with some IR support. But you can find also some products that are just IR. That's why we're moving it to be outside the V4L and the DVB directory. For now, it is at /drivers/media/IR (since it helps us to move the code, while there are still some dependencies at ir-common). But the better is to move it later to /drivers/IR or /drivers/input/IR. I was referring to the dvb-usb-remote. I think it's right place should not be under dvb but under usb/remotes. If you have an usb remote device that has nothing to do with audio-video, it would be strange to have its driver under dvb. Dvb is a protocol name and should be used us such in linux kernel as well. Otherwise it is misleading. Well I was talking about HID remotes that don't give ir codes but key codes. What to do with them? What happens if you use it to receive keycodes from a different IR using the same protocol? Nothing. It responds only to those codes that are at the moment loaded into its internal table. Maybe it can still be valid to keep allowing keycode translation. Yes, provided that it can translate also keyboard keycodes to some other keycodes. Well, as HID, you may loose the capability of using a different IR than the one shipped with the af9015. It may make sense to just disable HID and use USB Vendor Class. Yes, that is the question. Both ways have good arguments for. The thing is that remote controller trough HID layer does not provide IR keycode but standard keyboard key code. And HID layer does not know that it is a remote controller but sees it as an ordinary usb keyboard. The question is that how can it tell the upper layer that it really is a remote controller so that the event would end up to generic ir-core. For HID remote controllers, the only way I see is to have an USB ID list of devices that are known to be remote controllers and register them via ir_input_register, instead of input_register_device. Well, the current kernel architecture for input devices is so, that a higher layer generic driver registers a handler with the input layer telling by the way of capabilities what kind deices it is willing to handle. Lower layer devices drivers register with the input layer telling it what kind of capabilities they have. Based on that the input layer finds a match and relays events accordingly. Although arguments against this mechanism can be found, one of its good sides is that it completely separates generic device layer from device driver layer. E.g. the coder of mouse layer does not need to know anything about various mouse device drivers and vv. This is very good for the highly distributed way linux is being developed. IMHO ir remote controller receivers should be no exception to that. So rather than use separate ir_input_register, a generic remote controller layer (not only IR code based) should register a handler with the input layer with suitable capabilities, and all remote controller device drivers should register with the input layer telling by capabilities that they are remote controllers. They would send events in standard way to the input layer. Input layer would do the rest as normally. Also in naming, due consideration should be given to the fact that IR can be used for other type of communication as well. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 11:28 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Hello Andy, Andy Walls wrote: After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. Well, the patch were already added on an upstream kernel, so just reverting it will cause regressions. If it is just aletv-dvb that broke, it seems better to fix it than to cause even more troubles by reverting two new ioctls. The reason for this is not that fixing the patch is impossible. Why? Where exactly the breakage happened? Mauro, I think the dissassembler extracts done by Andy do answer this question already. Just go back to the first messages of that thread and you will know where the breakage begins. For an experienced programmer / coder it should not be too different to draw the adequate conclusions what needs to be done. While everybody is behaving rather passive defending the kernel status quo, stressing the fact that this discussion is nearly one week old now: The core questions are: 1. What is the minimum adequate requirement for alevt-dvb to conform to the latest DVB demux design and do its work again without noise and causing kernel oopses? 2. What is the minimum adequate requirement for alevt-dvb to stop causing hanging processes when the transponder is changed? In its current state the application does not seem to understand the effects of a PMT change (-program management table). 3. Who can write / offer patches for alevt's DVB design? Still hoping for qualified help CS INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. why exactly do you think this is wrong? I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Would this involve running mknod for every recording you start? Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. Andreas arguments makes sense to me. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. I'm sure, other projects are going to adopt this interface sooner or later. It is still quite new after all. It seems too late for me to revert it. So, we need to figure out a way to workaround it or to fix the applications that got broken by this change. -- 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: dvb-usb-remote woes [was: HID: ignore afatech 9016]
Most of the question here are already answered or no more actual, but for clarity: Jiri Slaby wrote: The remote is visible to the system as a usb interrupt end point. Interrupt endpoint tells the system the polling interval (by endpoint report). From the USB specs on the interval: The USB System Software will use this information during configuration to determine a period that can be sustained. The period provided by the system may be shorter than that desired by the device up to the shortest period defined by the USB (125 µs microframe or 1 ms frame). The client software and device can depend only on the fact that the host will ensure that the time duration between two transaction attempts with the endpoint will be no longer than the desired period. As I understand it, in plain English it means that the polling interval must not be longer than what the endpoint report says (in case of full-speed endpoint 1 to 255 ms). This device in question, assuming it gives the interval in full-speed mode even it really is high-speed device, gives 16ms interval period. However af9015.c/dvb-usb-remote.c accesses it as if it was a bulk endpoint and with 150ms interval. I did not look further on if this is the only reason or the reason for it not to work. But at least it is in clear contradiction of the USB-specs. To what statement is it in contradiction? The statement above is for interrupt transfers. The answer was that there is no contradiction since the 150 ms was for the bulk endpoint (0/81). When writing this I thought af9015.c used the HID endpoint (1/83), which is interrupt endpoint, as an bulk endpoint. I suspect, to make it work, much of the code from hid-driver should be copied to the device driver. Which code? I see no code being copied. I meant that to make af9015.c to use HID endpoint past HID layer would require copying big parts from the HID layer to af9015.c. Again it was due to the above misunderstanding on my part. However I think that would be exactly the wrong way to go. I think the whole idea of making for every device a separated driver ignoring the common code already in the kernel is bad architecture. Common code does not work well here. Don't you see weird key repetitions and similar? No, it worked ok for me. Patrick, Johannes, why was not dvb-usb-remote implemented rather as a part of the HID layer? Because it's for device specific drivers that uses vendor class endpoint instead of the HID class endpoint. Also it is wrong idea that you could/should detect the type of remote controller based on the tv-stick. E.g with Haupauge TV-NOVA nearly any remote works ok (e.g my panasonic tv remote). Every generic ir-receiver sends also the manufacturer and model codes. Remote ir-to-code translates should be based on that (there is a kind of generic layer for that in linux kernel) and not on the tv-stick model at all (as in the af9015 driver). Sorry, I don't understand this paragraph. Could you rephrase? This has been, it seems, the one of the very goals of IR input coding: to make remotes other than the ones provided with tv-stick to work with that same stick. BTW I now recall how I got Afateck remote work as should. The driver loads ir-to-code translate table to the stick. I changed the codes to what made more sense. Why you didn't push this upstream? Well the driver was at the time not part of the standard kernel (downloaded form Matti Palosaaris site). And I put there directly the keycodes that worked with command line mplayer. No standard solution. One problem here is that current HID layer is very sparse in the information it passes on, really only a code. It should also convey the precice id of the device so upper layer would be better able to deal with events. One of my hobbies is flight simulator flying. I use X-plane (excellent program). There is also a linux version. But the linux joystick driver is far from adequate for it (also some joysticks, yokes and pedals or some of their controls didn't work at all). So I use a special kernel for which I rewrote big parts of the HID-driver and input-driver and wrote completely new joystick driver. Now it works quite decently. One problem is the kernel-user joystick driver interface, but it can not be changed since that's what X-plane (and others use). One thing I got to change for that was that HID does less model specific processing and passes more event info to higher layer without breaking the old HID-devices (same with the input layer), so that the joystick layer could do more intelligent processing. I fixed also some bugs and one design omission in the HID driver (e.g. some force feedback joysticks uses that HID-specification, in standard kernel there is some ad-hoc code for that purpose). Can't be HID bus with a specific driver used instead now? Well it could, but this way it is much less work and more generic. I use many different joysticks, yokes and pedals. And with some
Re: Any saa711x users out there?
I also have a device that has the SAA7113 chip in it. Kworld 315U. I suggested a patch to add a an s_power function to the code but it looks like the patch didn't work. I have to do some cleanup to it and resubmit it. Franklin Meng --- On Thu, 2/4/10, Devin Heitmueller dheitmuel...@kernellabs.com wrote: From: Devin Heitmueller dheitmuel...@kernellabs.com Subject: Re: Any saa711x users out there? To: Andy Walls awa...@radix.net Cc: Linux Media Mailing List linux-media@vger.kernel.org Date: Thursday, February 4, 2010, 8:34 PM Hey Andy, On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls awa...@radix.net wrote: Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. It's possible. One thing I did as a test though was I did a capture of the i2c traffic under Windows (using the same reference video source), and then compared the register programming (via some scripts I whipped up). There were some other registers that were different, but the only one that made *any* visible difference in the output was the AA flag. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. To give you a better idea of what I'm talking about, look at this image: http://imagebin.org/83458 The above image was taken with the generator via the s-video input (ruling out the possibility that it's any sort of product of intermodulation). For the sake of comparison, here's the exact same signal source against an a similar em28xx design but with the tvp5150. http://imagebin.org/83459 Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Believe it or not, I'm actually having trouble with the generator right now with anything but NTSC. I'm going back and forth with Promax on repair options. So I cannot do any PAL or SECAM testing right now. On a separate note, I really should look at extending the v4l2 capture-example to a version that let's me do a direct capture of the YUYV frame and convert the output into a zero-loss RGB format. It's too easy to be mislead by things the applications are doing like deinterlacing, rescaling, blending, and compression of the screenshot when saving to a file. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy
On 02/05/2010 02:42 PM, Hans de Goede wrote: Good job! I never noticed the ff ff ff xx markers where spaced a certain numbers You can find this info here http://www.kaiser-linux.li/index.php?title=PAC7311 go down the page to 2006-11-12 Thomas -- 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
[GIT PATCHES FOR 2.6.34] Support for vpfe-capture on DM365
Mauro, Please pull from the following:- The following changes since commit 84b74782ace1ae091c1b0e14ae2ee9bb720532ba: Douglas Schilling Landgraf (1): V4L/DVB: Fix logic for Leadtek winfast tv usbii deluxe are available in the git repository at: git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream Murali Karicheri (6): DaVinci - Adding platform board changes for vpfe capture on DM365 V4L - vpfe capture - header files for ISIF driver V4L - vpfe capture - source for ISIF driver on DM365 V4L - vpfe capture - vpss driver enhancements for DM365 V4L - vpfe_capture - bug fixes and enhancements V4L - vpfe capture - build environment for isif driver arch/arm/mach-davinci/board-dm365-evm.c| 71 ++ arch/arm/mach-davinci/dm365.c | 102 ++- arch/arm/mach-davinci/include/mach/dm365.h |2 + drivers/media/video/Kconfig| 14 +- drivers/media/video/davinci/Makefile |1 + drivers/media/video/davinci/isif.c | 1513 drivers/media/video/davinci/isif_regs.h| 269 + drivers/media/video/davinci/vpfe_capture.c | 118 ++- drivers/media/video/davinci/vpss.c | 289 +- include/media/davinci/isif.h | 531 ++ include/media/davinci/vpfe_capture.h | 11 +- include/media/davinci/vpss.h | 41 +- 12 files changed, 2853 insertions(+), 109 deletions(-) create mode 100644 drivers/media/video/davinci/isif.c create mode 100644 drivers/media/video/davinci/isif_regs.h create mode 100644 include/media/davinci/isif.h -- Murali Karicheri mkarich...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
test - please ignore
-- Murali Karicheri mkarich...@gmail.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
On Fri, 2010-02-05 at 13:19 +0100, HoP wrote: Hi Chicken Furthermore: If it is technically possible to send and receive, demux and multiplex, play and record complete contents of a transponder (i. e. multiple TS streams) by using dvbstream or mumudvb (- 8192 command line parameter), then I myself do not see the necessity to extend the capabilities of one physical device dvr0 or demux0 into a multiplicity of devices dvr0 or demux0. The what and especially the why will remain Andreas Oberritters' secret. I can only say my 2 words regarding Andreas' patch: At least one big DVB application is using it - enigma (originally inside tuxbox project, later enhanced by Dream Multimedia for theirs well-known linux based set-top-boxes Dreambox). Those boxes are selling worlwide, so userbase is wide enough (note: I'm not in any way connected with Dream Multimedia, so it is only my personal feeling and/or investigation). Of course using full TS and remuxing only in user land is not possible way for embedded application. And if you count that there can be more then one TS input, things are getting even worst. Well then, it appears reverting the patch is not an option. Time to slog through the code and fix it, I guess. And as Andy wrote: But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Well, it is also possible way. But it expands dvrX from usuall dvr0 to something like dvr0 ... dvr31 or so. We definitelly need such feature. I thought about this more and was thinking the device nodes presented to userspace might look something like this: /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/dvr0.0 (symlink to dvr0 or the other way around) /dev/dvb/adapter0/dvr0.1 /dev/dvb/adapter0/dvr0.2 ... /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/net0 So that dvr0.n was still associated with the demux0 filter settings, but that the demux filter outputs could be steered to one of a number of different dvr0.n devices. That keeps dvr0.n devices as providing a TS multiplex of exactly the PIDs one wants, allows multiple TS multiplexes to be recorded from the originating demux0, and also allows the dvr0.n outputs to be controlled by the originating demux0. It would require the current DMX_SET_PES_FILTER_PARAMS ioctl()'s to be modified, so that the output setting could include a subaddress (the n in dvr0.n), but with a default of 0 for backward compatability. I, personally, like DMX_OUT_TSDEMUX_TAP approach. From what I gather, originally: a. the demux0 device would provide a single PID stream (not a TS but a section?) with DMX_OUT_TAP b. the dvr0 device would provide a full TS multiplex of all the PIDs specified with DMX_OUT_TS_TAP c. a dvr node always delivered a TS and an open demux instance always delivered a non-TS stream So the problems were, I think: a. No way to capture more than one TS from an originating demux. So userspace could not re-multiplex PIDs together easily(?). b. No way to capture more than one TS multiplex from an originating demux. No way for userspace to easily capture separate TV programs from a single multiplex, into separate TS multiplexes each containing only the related PID for each spearate TV program (i.e. audio and video PIDs) Problem a. was solved by the DMX_OUT_TSDEMUX_TAP change. That was a very simple patch and appear fairly straight forward. It changes the type of output one can get from an open demux0 instance from just section to also include a single PID TS. IMO, that change looks like a conveient shortcut to avoid dealing with how to implement multiple dvr nodes per originating demux. But that's OK, if your userspace app just needs one PID per TS: mplayer playing audio and video from one TV program (?) Problem b. was solved by the DMX_ADD_PID, DMX_REMOVE_PID patch. This allows an open demux instance to now not only send a TS, but also send multiple PIDs in that TS, essentially creating an output of the kind one would see at a dvr0 node. So my thinking at this point is why dance around the issue? The requirement appears to be to set up multiple dvr type feeds for userspace from a single originating demux. I would want to take the time to audit the code and fix the problems with the DMX_ADD_PID, DMX_REMOVE_PID patch, if it were not used by any popular userspace apps and if there were something that made
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Andreas, On Fri, 2010-02-05 at 14:19 +0100, Andreas Oberritter wrote: Hello Andy, Andy Walls wrote: After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. why exactly do you think this is wrong? Originally the dvr0 device provided a single TS multiplex of PIDs while the open instances of demux0 each provided a single stream. The end objective appears to be able to have multiple different TS multiplexes from a single hardware (or software) demux. IMO, the logical answer from a userspace perspective is to have multiple dvr device nodes (eg dvr0.n) corresponding to a single originating demux0 device node. With each one of those dvr0.n devices configurable essentially as before from the demux0 node, but being able to steer the output of a filter to a dvr node other than dvr0 (e.g. dvr0.2). The patches that added DMX_OUT_TSDEMUX_TAP and then DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple dvr nodes associated with a single demux node. The end result is that demux0, essentially a device node intended for control AFAICT, has now been transformed to be multiple anonymous dvr device nodes. In my opinion, that was the wrong end result. I guess that is based on my notion that the original Nokia/Convergence API separated control from datastream, and these changes together do just the opposite. I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. My perception was that the demux0 node was for control of the TS output (and perhaps debug for isolating stream). The dvr0 node was for presenting a TS to userspace. There is btw. no other way for multiple readers to receive TS packets without implementing a second demux layer in a userspace daemon, which must then be used by all readers. This would needlessly create quite some overhead on high bandwidth services. I agree. The DVB subsystem need a way to present multiple TS multiplexs to userspace from a single, orginating demultiplexer. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. Yes it does, except for write() functionality, which is only available for dvr0 and not demux0. It also collapses control of one demultiplexer and all the data streams available from it down to one device node. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Would this involve running mknod for every recording you start? I would think that dvb_dmxdev_init() would register a number of DVB_DEVICE_DVR device nodes for demux0 named something like dvr0.0 (or dvr0), dvr0.1, dvr0.2, dvr0.3, etc. udev rules would handle device node creation. A module parameter could allow the user to set the number of dvr0.n nodes to a non-default number. Just an idea. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. A demux device (and dvr respectively) represents a transport stream input. Hardware with multiple transport stream inputs (read: embedded set top boxes) already has multiple demux and dvr devices. Yes, that was a bad idea. I agree with you: one demux device node per input TS and demultiplexer device. One could still have multiple dvr0.m nodes representing different filter configurations from a demux0 node. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. The need for such an interface was already pointed out and discussed back in 2006: http://www.linuxtv.org/pipermail/linux-dvb/2006-April/009269.html As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. Thanks for the comments. Regards, Andy I'm sure, other projects are going to adopt this interface sooner or later.
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Feb 5 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14158:68752268de57 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-rc5-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: OK linux-2.6.27.44-i686: OK linux-2.6.28.10-i686: OK linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-rc5-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: OK linux-2.6.27.44-x86_64: OK linux-2.6.28.10-x86_64: OK linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Andy Walls wrote: Originally the dvr0 device provided a single TS multiplex of PIDs while the open instances of demux0 each provided a single stream. The end objective appears to be able to have multiple different TS multiplexes from a single hardware (or software) demux. Right. IMO, the logical answer from a userspace perspective is to have multiple dvr device nodes (eg dvr0.n) corresponding to a single originating demux0 device node. With each one of those dvr0.n devices configurable essentially as before from the demux0 node, but being able to steer the output of a filter to a dvr node other than dvr0 (e.g. dvr0.2). This sounds like a matter of taste to me. But anyway, your proposal would have one of two possible side effects: You could either choose to allocate those device nodes statically, which would create an artificial limit of filter groups on hardware, where filters are shared between multiple inputs. Or you could create the device nodes dynamically, which would involve waiting for udev to create the new node between setting up the filter(s) and being able to read data. Another reason for the addition of the two new ioctls was, that changing the DMX_SET_PES_FILTER control was not an option, to keep old software running on new kernels and vice versa. The patches that added DMX_OUT_TSDEMUX_TAP and then DMX_ADD_PID/DMX_REMOVE_PID, seemed to be avoiding implementing multiple dvr nodes associated with a single demux node. The end result is that demux0, essentially a device node intended for control AFAICT, has now been transformed to be multiple anonymous dvr device nodes. In my opinion, that was the wrong end result. I guess that is based on my notion that the original Nokia/Convergence API separated control from datastream, and these changes together do just the opposite. That's wrong. The demuxN devices have always been used to control filters and to read section and PES (i.e. TS payload) data streams. The addition of DMX_OUT_TSDEMUX_TAP was just an extension to read a third type of data from it (TS header + payload). I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. How so? It's all about reading demultiplexed packets, which is exactly what a demux is good for. My perception was that the demux0 node was for control of the TS output (and perhaps debug for isolating stream). Being able to read section and PES data is very important for DVB applications. This is definitely not a debugging feature. Processing raw TS streams for other purposes than recording to disk is rarely seen on DVB devices. It's something that mainly comes from the PC world, which is dominated by cheap peripherials which have no or very limited capabilities for filtering and stream processing. The dvr0 node was for presenting a TS to userspace. Right. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. Actually it makes dvrN obsolete, but it must of course be kept for backwards compatibility. Yes it does, except for write() functionality, which is only available for dvr0 and not demux0. Right. It also collapses control of one demultiplexer and all the data streams available from it down to one device node. That has already been the case for sections and PES since the first days of the API. The only recent change is to allow multiple PIDs per file descriptor (which only makes sense for TS, not for sections and PES, where the PID value itself is not carried inside the payload). As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. Regards, Andreas -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi, Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Andy Walls wrote: As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. So, removing those two ioctls is not an option anymore. Cheers, Mauro during the still ongoing v4l to v4l2 conversion, all major apps did ship with their own headers. Since we keep backward compat, that previously unknown to me alevt-dvb-t, agreed it is a nice to have, should compile against the older headers instead latest kernel headers, until someone maintains it again and takes advantage of later improvements. Untested, but usually we see just such. Cheers, Hermann -- 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 PATCHES FOR 2.6.34] Support for vpfe-capture on DM365
Muralidharan Karicheri wrote:
Mauro,
Please pull from the following:-
The following changes since commit 84b74782ace1ae091c1b0e14ae2ee9bb720532ba:
Douglas Schilling Landgraf (1):
V4L/DVB: Fix logic for Leadtek winfast tv usbii deluxe
are available in the git repository at:
git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream
Murali Karicheri (6):
DaVinci - Adding platform board changes for vpfe capture on DM365
V4L - vpfe capture - header files for ISIF driver
V4L - vpfe capture - source for ISIF driver on DM365
Hmm...
+static int isif_get_params(void __user *params)
+{
+ /* only raw module parameters can be set through the IOCTL */
+ if (isif_cfg.if_type != VPFE_RAW_BAYER)
+ return -EINVAL;
+
+ if (copy_to_user(params,
+ isif_cfg.bayer.config_params,
+ sizeof(isif_cfg.bayer.config_params))) {
+/* Parameter operations */
+static int isif_set_params(void __user *params)
+{
+ struct isif_config_params_raw *isif_raw_params;
+ int ret = -EINVAL;
+
+ /* only raw module parameters can be set through the IOCTL */
+ if (isif_cfg.if_type != VPFE_RAW_BAYER)
+ return ret;
+
+ isif_raw_params = kzalloc(sizeof(*isif_raw_params), GFP_KERNEL);
+ if (NULL == isif_raw_params)
+ return -ENOMEM;
+
+ ret = copy_from_user(isif_raw_params,
It seems that you're defining some undocumented new userspace API here.
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] gotoX program?
Hi, Please try rotor-control or xdipo: http://www.vdr-settings.com/download/ 2010/2/5 Scott Doty sc...@ponzo.net: Hi, I'm looking for the gotoX program mentioned in this message: http://www.linuxtv.org/pipermail/linux-dvb/2007-May/017748.html It is supposed to be here: http://www.verbraak.org/wiki/index.php/Goto_X_program ...but alas, that wiki would appear to be broken. :( Also, I don't see it in dvb-apps... Any info greatly appreciated. Thanks! :) -Scott ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Andy Walls wrote: As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. You cannot expect people reacting immediately if something is wrong. There are and do exist enormous delays between publishing a new kernel and the decision to use it after appropriate system or distro update. So your expectation level is simply wrong. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. Yes. Trivial! From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. It's truly amazing how the filter system of your perception works, isn't it? :) It's not just an old, orphaned application with a non-official patch on it. That's nonsense! a. As I stated already, there do exist several patched versions of alevt-dvb. For instance the one that Herman Pitton tested here in public causes a closed demux device error on my machine. That means that it does not run because xine-ui is already using the demux device. And this phenomenon has got nothing to do with the kernel headers! I've tried all possibilities (old kernel headers and actual ones) so I know better than Hermann Pitton does! And my version (and obviously the ones of Thomas Voegtle and Emil Meier whom I helped with my tip to revert that patch) cause a kernel crash with the actual kernel. b. As I also stated already the other teletext application called mtt does officially not exist except for Novell / OpenSuSe distros (at least as far as I have seen and found out). And this one is, as I also stated, not affected by the kernel patch. It's part of a discontinued program suite called xawtv-4.0 pre with a very complex infrastructure behind. Please do not ask me why this one runs without noise - I do not know. So AFAICS alevt-dvb is the ONLY teletext application for Linux which is available in almost all Gnu/Linux distros. Other applications with similar features weren't affected. From where do you know that the features are similar? This is a 100 % phantasy product of your mind that has got nothing to do with existing reality, man! Just one example: alevt-dvb has got an excellent html export filter which makes it possible to export teletext pages as graphical html files. I do not know any other teletext application offering that. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. Who says that a new API or an overworked API must be ready for 2.6.33? When do you think the correct starting point must be set? When the merge window for 2.6.34 opens or when? Absurd argument! Not valid at all! So, removing those two ioctls is not an option anymore. Yes. Conclusion??? None! So if everybody wants to close down this discussion with that output then you must admit (if you want it or not) that you de facto bury teletext usage in the mud for the majority of Gnu/Linux DVB users. So the output is more than badly disappointing. Bye bye Teletext. Nothing for future kernels, huh? Regards CS P. S.: If you continue like that you make people run away. Instead you better should try to win people, shouldn't you? Just see how many volunteers are here to help and then reflect why that manpower is missing, Mauro! Your gesture being expressed above does a lot, but it is definitely NOT motivating to change that precarious situation. -- 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 3/12] tm6000: clean the identifer string
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index e697ce3..1167b01 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -480,7 +480,7 @@ static int tm6000_usb_probe(struct usb_interface *interface,
/* Check to see next free device and mark as used */
nr=find_first_zero_bit(tm6000_devused,TM6000_MAXBOARDS);
if (nr = TM6000_MAXBOARDS) {
- printk (tm6000: Supports only %i em28xx
boards.\n,TM6000_MAXBOARDS);
+ printk (tm6000: Supports only %i tm60xx
boards.\n,TM6000_MAXBOARDS);
usb_put_dev(usbdev);
return -ENOMEM;
}
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/12] tm6000: update init table and sequence for tm6010
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-core.c | 179 --
1 files changed, 128 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 7ec13d5..a2e2af5 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+
+ /* additional from Terratec Cinergy Hybrid XE */
+ { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+ { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+ { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+ { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+ { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
@@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+ u8 buf[40];
if (dev-dev_type == TM6010) {
tab = tm6010_init_tab;
@@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
}
}
- msleep(5); /* Just to be conservative */
-
- /* Check board version - maybe 10Moons specific */
- board=tm6000_get_reg16 (dev, 0x40, 0, 0);
- if (board =0) {
- printk (KERN_INFO Board version = 0x%04x\n,board);
- } else {
- printk (KERN_ERR Error %i while retrieving board
version\n,board);
- }
-
+ /* hack */
if (dev-dev_type == TM6010) {
- /* Turn xceive 3028 on */
- tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
0x01);
- msleep(11);
- }
-
- /* Reset GPIO1 and GPIO4. */
- for (i=0; i 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x00);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x01);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
0);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
1);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
- return rc;
- }
-
- if (!i) {
- rc=tm6000_get_reg16(dev, 0x40,0,0);
- if (rc=0) {
- printk (board=%d\n, rc);
+
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_4, 0);
+ msleep(15);
+
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_1, 0);
+
+ msleep(50);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_1, 1);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ buf[0] = 0x12;
+ buf[1] = 0x34;
+ tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x, buf, 2);
+
+ msleep(15);
+ buf[0] = 0x00;
+ buf[1] = 0x01;
+ tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x, buf,
39);
+
+ msleep(15);
+ buf[0] = 0x00;
+ buf[1] = 0x00;
+ tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2);
+
[PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev
From: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-cards.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index 7f594a2..e697ce3 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -422,6 +422,7 @@ static int tm6000_init_dev(struct tm6000_core *dev) } #endif } + return 0; err2: v4l2_device_unregister(dev-v4l2_dev); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index c4db903..7f594a2 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -44,6 +44,10 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
-
+ [TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+ .name = Terratec Cinergy Hybrid XE,
+ .tuner_type = TUNER_XC2028, /* has a XC3028 */
+ .tuner_addr = 0xc2 1,
+ .demod_addr = 0x1e 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6010_GPIO_2,
+ }
};
/* table of devices that work with this driver */
@@ -221,6 +239,7 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER
},
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
+ { USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
@@ -311,6 +330,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
switch(dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
ctl.fname = xc3028L-v36.fw;
break;
default:
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-i2c.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 4da10f5..3e43ad7 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -86,6 +86,11 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
msgs[i].len == 1 ? 0 : msgs[i].buf[1],
msgs[i + 1].buf, msgs[i + 1].len);
i++;
+
+ if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+ tm6000_set_reg(dev, 0x32, 0,0);
+ tm6000_set_reg(dev, 0x33, 0,0);
+ }
if (i2c_debug = 2)
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
@@ -99,6 +104,12 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
REQ_16_SET_GET_I2C_WR1_RDN,
addr | msgs[i].buf[0] 8, 0,
msgs[i].buf + 1, msgs[i].len - 1);
+
+
+ if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+ tm6000_set_reg(dev, 0x32, 0,0);
+ tm6000_set_reg(dev, 0x33, 0,0);
+ }
}
if (i2c_debug = 2)
printk(\n);
@@ -198,7 +209,7 @@ static struct i2c_algorithm tm6000_algo = {
static struct i2c_adapter tm6000_adap_template = {
.owner = THIS_MODULE,
- .class = I2C_CLASS_TV_ANALOG,
+ .class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL,
.name = tm6000,
.id = I2C_HW_B_TM6000,
.algo = tm6000_algo,
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 8/12] tm6000: add tuner parameter
From: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-cards.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index 4592397..f22f8ad 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -312,7 +312,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev) memset(tun_setup, 0, sizeof(tun_setup)); tun_setup.type = dev-tuner_type; tun_setup.addr = dev-tuner_addr; - tun_setup.mode_mask = T_ANALOG_TV | T_RADIO; + tun_setup.mode_mask = T_ANALOG_TV | T_RADIO | T_DIGITAL_TV; tun_setup.tuner_callback = tm6000_tuner_callback; v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_type_addr, tun_setup); @@ -324,10 +324,12 @@ static void tm6000_config_tuner (struct tm6000_core *dev) memset(xc2028_cfg, 0, sizeof(xc2028_cfg)); memset (ctl,0,sizeof(ctl)); - ctl.mts = 1; - ctl.read_not_reliable = 1; + ctl.input1 = 1; + ctl.read_not_reliable = 0; ctl.msleep = 10; - + ctl.demod = XC3028_FE_ZARLINK456; + ctl.vhfbw7 = 1; + ctl.uhfbw8 = 1; xc2028_cfg.tuner = TUNER_XC2028; xc2028_cfg.priv = ctl; -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/media/common/tuners/tuner-xc2028.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..fcf19cc 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ if ((strcmp (priv-ctrl.fname, xc3028L-v36.fw) == 0)
+ (priv-ctrl.demod == XC3028_FE_ZARLINK456)
+ ((type DTV78) || (type DTV8)))
+ demod = priv-ctrl.demod;
+ else
+ demod = priv-ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] tm6000: bugfix usb DVB transfer
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-dvb.c | 125 ++-
1 files changed, 79 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index fdbee30..055a58f 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -17,7 +17,9 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include linux/kernel.h
#include linux/usb.h
+#include compat.h
#include tm6000.h
#include tm6000-regs.h
@@ -30,13 +32,58 @@
#include tuner-xc2028.h
+static void inline print_err_status (struct tm6000_core *dev,
+int packet, int status)
+{
+ char *errmsg = Unknown;
+
+ switch(status) {
+ case -ENOENT:
+ errmsg = unlinked synchronuously;
+ break;
+ case -ECONNRESET:
+ errmsg = unlinked asynchronuously;
+ break;
+ case -ENOSR:
+ errmsg = Buffer error (overrun);
+ break;
+ case -EPIPE:
+ errmsg = Stalled (device not responding);
+ break;
+ case -EOVERFLOW:
+ errmsg = Babble (bad cable?);
+ break;
+ case -EPROTO:
+ errmsg = Bit-stuff error (bad cable?);
+ break;
+ case -EILSEQ:
+ errmsg = CRC/Timeout (could be anything);
+ break;
+ case -ETIME:
+ errmsg = Device does not respond;
+ break;
+ }
+ if (packet0) {
+ dprintk(dev, 1, URB status %d [%s].\n,
+ status, errmsg);
+ } else {
+ dprintk(dev, 1, URB packet %d, status %d [%s].\n,
+ packet, status, errmsg);
+ }
+}
+
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,19)
+static void tm6000_urb_received(struct urb *urb, struct pt_regs *ptregs)
+#else
static void tm6000_urb_received(struct urb *urb)
+#endif
{
int ret;
struct tm6000_core* dev = urb-context;
- if(urb-status != 0){
- printk(KERN_ERR tm6000: status != 0\n);
+ if(urb-status != 0) {
+ print_err_status (dev,0,urb-status);
}
else if(urb-actual_length0){
dvb_dmx_swfilter(dev-dvb-demux, urb-transfer_buffer,
@@ -56,49 +103,37 @@ static void tm6000_urb_received(struct urb *urb)
int tm6000_start_stream(struct tm6000_core *dev)
{
int ret;
- unsigned int pipe, maxPaketSize;
+ unsigned int pipe, size;
struct tm6000_dvb *dvb = dev-dvb;
printk(KERN_INFO tm6000: got start stream request %s\n,__FUNCTION__);
tm6000_init_digital_mode(dev);
-/*
- ret = tm6000_set_led_status(tm6000_dev, 0x1);
- if(ret 0) {
- return -1;
- }
-*/
-
dvb-bulk_urb = usb_alloc_urb(0, GFP_KERNEL);
if(dvb-bulk_urb == NULL) {
printk(KERN_ERR tm6000: couldn't allocate urb\n);
return -ENOMEM;
}
- maxPaketSize = dev-bulk_in-desc.wMaxPacketSize;
+ pipe = usb_rcvbulkpipe(dev-udev, dev-bulk_in-desc.bEndpointAddress
+
USB_ENDPOINT_NUMBER_MASK);
+
+ size = usb_maxpacket(dev-udev, pipe, usb_pipeout(pipe));
+ size = size * 15; /* 512 x 8 or 12 or 15 */
- dvb-bulk_urb-transfer_buffer = kzalloc(maxPaketSize, GFP_KERNEL);
+ dvb-bulk_urb-transfer_buffer = kzalloc(size, GFP_KERNEL);
if(dvb-bulk_urb-transfer_buffer == NULL) {
usb_free_urb(dvb-bulk_urb);
printk(KERN_ERR tm6000: couldn't allocate transfer buffer!\n);
return -ENOMEM;
}
- pipe = usb_rcvbulkpipe(dev-udev, dev-bulk_in-desc.bEndpointAddress
-
USB_ENDPOINT_NUMBER_MASK);
-
usb_fill_bulk_urb(dvb-bulk_urb, dev-udev, pipe,
dvb-bulk_urb-transfer_buffer,
-maxPaketSize,
+size,
tm6000_urb_received, dev);
- ret = usb_set_interface(dev-udev, 0, 1);
- if(ret 0) {
- printk(KERN_ERR tm6000: error %i in %s during set
interface\n, ret, __FUNCTION__);
- return ret;
- }
-
ret = usb_clear_halt(dev-udev, pipe);
if(ret 0) {
printk(KERN_ERR tm6000: error %i in %s during pipe
reset\n,ret,__FUNCTION__);
@@ -108,14 +143,13 @@ int tm6000_start_stream(struct tm6000_core *dev)
printk(KERN_ERR tm6000: pipe resetted\n);
}
-// mutex_lock(tm6000_driver.open_close_mutex);
+/* mutex_lock(tm6000_driver.open_close_mutex); */
ret =
[PATCH 7/12] tm6000: add tuner callback for dvb frontend
From: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
drivers/staging/tm6000/tm6000-dvb.c |3 ++-
drivers/staging/tm6000/tm6000.h |3 +++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 5cf5d58..4592397 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -245,7 +245,7 @@ struct usb_device_id tm6000_id_table [] = {
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
-static int tm6000_tuner_callback(void *ptr, int component, int command, int
arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
{
int rc=0;
struct tm6000_core *dev = ptr;
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index e900d6d..fdbee30 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -235,7 +235,8 @@ int tm6000_dvb_register(struct tm6000_core *dev)
.i2c_adap = dev-i2c_adap,
.i2c_addr = dev-tuner_addr,
};
-
+
+ dvb-frontend-callback = tm6000_tuner_callback;
ret = dvb_register_frontend(dvb-adapter, dvb-frontend);
if (ret 0) {
printk(KERN_ERR
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 877cbf6..d713c48 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -202,6 +202,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/12] tm6000: remove unused function
From: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h index d713c48..e88836d 100644 --- a/drivers/staging/tm6000/tm6000.h +++ b/drivers/staging/tm6000/tm6000.h @@ -212,7 +212,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req, int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index); int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index); int tm6000_init (struct tm6000_core *dev); -int tm6000_init_after_firmware (struct tm6000_core *dev); int tm6000_init_analog_mode (struct tm6000_core *dev); int tm6000_init_digital_mode (struct tm6000_core *dev); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/12] tm6000: add Terratec Cinergy Hybrid XE
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 22 +-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index c4db903..7f594a2 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -44,6 +44,10 @@
#define TM6000_BOARD_FREECOM_AND_SIMILAR 7
#define TM6000_BOARD_ADSTECH_MINI_DUAL_TV 8
#define TM6010_BOARD_HAUPPAUGE_900H9
+#define TM6010_BOARD_BEHOLD_WANDER 10
+#define TM6010_BOARD_BEHOLD_VOYAGER11
+#define TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE12
+
#define TM6000_MAXBOARDS16
static unsigned int card[] = {[0 ... (TM6000_MAXBOARDS - 1)] = UNSET };
@@ -208,7 +212,21 @@ struct tm6000_board tm6000_boards[] = {
},
.gpio_addr_tun_reset = TM6000_GPIO_2,
},
-
+ [TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE] = {
+ .name = Terratec Cinergy Hybrid XE,
+ .tuner_type = TUNER_XC2028, /* has a XC3028 */
+ .tuner_addr = 0xc2 1,
+ .demod_addr = 0x1e 1,
+ .type = TM6010,
+ .caps = {
+ .has_tuner= 1,
+ .has_dvb = 1,
+ .has_zl10353 = 1,
+ .has_eeprom = 1,
+ .has_remote = 1,
+ },
+ .gpio_addr_tun_reset = TM6010_GPIO_2,
+ }
};
/* table of devices that work with this driver */
@@ -221,6 +239,7 @@ struct usb_device_id tm6000_id_table [] = {
{ USB_DEVICE(0x2040, 0x6600), .driver_info =
TM6010_BOARD_HAUPPAUGE_900H },
{ USB_DEVICE(0x6000, 0xdec0), .driver_info = TM6010_BOARD_BEHOLD_WANDER
},
{ USB_DEVICE(0x6000, 0xdec1), .driver_info =
TM6010_BOARD_BEHOLD_VOYAGER },
+ { USB_DEVICE(0x0ccd, 0x0086), .driver_info =
TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE },
{ },
};
@@ -311,6 +330,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev)
switch(dev-model) {
case TM6010_BOARD_HAUPPAUGE_900H:
+ case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
ctl.fname = xc3028L-v36.fw;
break;
default:
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/12] tm6000: avoid unregister the driver after success at tm6000_init_dev
From: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-cards.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index 7f594a2..e697ce3 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -422,6 +422,7 @@ static int tm6000_init_dev(struct tm6000_core *dev) } #endif } + return 0; err2: v4l2_device_unregister(dev-v4l2_dev); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/12] tm6000: clean the identifer string
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index e697ce3..1167b01 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -480,7 +480,7 @@ static int tm6000_usb_probe(struct usb_interface *interface,
/* Check to see next free device and mark as used */
nr=find_first_zero_bit(tm6000_devused,TM6000_MAXBOARDS);
if (nr = TM6000_MAXBOARDS) {
- printk (tm6000: Supports only %i em28xx
boards.\n,TM6000_MAXBOARDS);
+ printk (tm6000: Supports only %i tm60xx
boards.\n,TM6000_MAXBOARDS);
usb_put_dev(usbdev);
return -ENOMEM;
}
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/12] tm6000: update init table and sequence for tm6010
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-core.c | 179 --
1 files changed, 128 insertions(+), 51 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 7ec13d5..a2e2af5 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -414,7 +414,15 @@ struct reg_init tm6010_init_tab[] = {
{ REQ_07_SET_GET_AVREG, 0x3f, 0x00 },
{ REQ_05_SET_GET_USBREG, 0x18, 0x00 },
-
+
+ /* additional from Terratec Cinergy Hybrid XE */
+ { REQ_07_SET_GET_AVREG, 0xdc, 0xaa },
+ { REQ_07_SET_GET_AVREG, 0xdd, 0x30 },
+ { REQ_07_SET_GET_AVREG, 0xde, 0x20 },
+ { REQ_07_SET_GET_AVREG, 0xdf, 0xd0 },
+ { REQ_04_EN_DISABLE_MCU_INT, 0x02, 0x00 },
+ { REQ_07_SET_GET_AVREG, 0xd8, 0x2f },
+
/* set remote wakeup key:any key wakeup */
{ REQ_07_SET_GET_AVREG, 0xe5, 0xfe },
{ REQ_07_SET_GET_AVREG, 0xda, 0xff },
@@ -424,6 +432,7 @@ int tm6000_init (struct tm6000_core *dev)
{
int board, rc=0, i, size;
struct reg_init *tab;
+ u8 buf[40];
if (dev-dev_type == TM6010) {
tab = tm6010_init_tab;
@@ -444,61 +453,129 @@ int tm6000_init (struct tm6000_core *dev)
}
}
- msleep(5); /* Just to be conservative */
-
- /* Check board version - maybe 10Moons specific */
- board=tm6000_get_reg16 (dev, 0x40, 0, 0);
- if (board =0) {
- printk (KERN_INFO Board version = 0x%04x\n,board);
- } else {
- printk (KERN_ERR Error %i while retrieving board
version\n,board);
- }
-
+ /* hack */
if (dev-dev_type == TM6010) {
- /* Turn xceive 3028 on */
- tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6010_GPIO_3,
0x01);
- msleep(11);
- }
-
- /* Reset GPIO1 and GPIO4. */
- for (i=0; i 2; i++) {
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x00);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10); /* Just to be conservative */
- rc = tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
- dev-tuner_reset_gpio, 0x01);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO1 reset\n,rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
0);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
- return rc;
- }
-
- msleep(10);
- rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_4,
1);
- if (rc0) {
- printk (KERN_ERR Error %i doing GPIO4 reset\n,rc);
- return rc;
- }
-
- if (!i) {
- rc=tm6000_get_reg16(dev, 0x40,0,0);
- if (rc=0) {
- printk (board=%d\n, rc);
+
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_4, 0);
+ msleep(15);
+
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_1, 0);
+
+ msleep(50);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ TM6010_GPIO_1, 1);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x0e, 0x0010, 0x4400, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ buf[0] = 0x12;
+ buf[1] = 0x34;
+ tm6000_read_write_usb (dev, 0x40, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0xf432, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0x0032, 0x, buf, 2);
+
+ msleep(15);
+ buf[0] = 0x00;
+ buf[1] = 0x01;
+ tm6000_read_write_usb (dev, 0x40, 0x10, 0xf332, 0x, buf, 2);
+
+ msleep(15);
+ tm6000_read_write_usb (dev, 0xc0, 0x10, 0x00c0, 0x, buf,
39);
+
+ msleep(15);
+ buf[0] = 0x00;
+ buf[1] = 0x00;
+
[PATCH 8/12] tm6000: add tuner parameter
From: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000-cards.c | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/staging/tm6000/tm6000-cards.c b/drivers/staging/tm6000/tm6000-cards.c index 4592397..f22f8ad 100644 --- a/drivers/staging/tm6000/tm6000-cards.c +++ b/drivers/staging/tm6000/tm6000-cards.c @@ -312,7 +312,7 @@ static void tm6000_config_tuner (struct tm6000_core *dev) memset(tun_setup, 0, sizeof(tun_setup)); tun_setup.type = dev-tuner_type; tun_setup.addr = dev-tuner_addr; - tun_setup.mode_mask = T_ANALOG_TV | T_RADIO; + tun_setup.mode_mask = T_ANALOG_TV | T_RADIO | T_DIGITAL_TV; tun_setup.tuner_callback = tm6000_tuner_callback; v4l2_device_call_all(dev-v4l2_dev, 0, tuner, s_type_addr, tun_setup); @@ -324,10 +324,12 @@ static void tm6000_config_tuner (struct tm6000_core *dev) memset(xc2028_cfg, 0, sizeof(xc2028_cfg)); memset (ctl,0,sizeof(ctl)); - ctl.mts = 1; - ctl.read_not_reliable = 1; + ctl.input1 = 1; + ctl.read_not_reliable = 0; ctl.msleep = 10; - + ctl.demod = XC3028_FE_ZARLINK456; + ctl.vhfbw7 = 1; + ctl.uhfbw8 = 1; xc2028_cfg.tuner = TUNER_XC2028; xc2028_cfg.priv = ctl; -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/12] tm6000: add tuner callback for dvb frontend
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c |2 +-
drivers/staging/tm6000/tm6000-dvb.c |3 ++-
drivers/staging/tm6000/tm6000.h |3 +++
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 5cf5d58..4592397 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -245,7 +245,7 @@ struct usb_device_id tm6000_id_table [] = {
/* Tuner callback to provide the proper gpio changes needed for xc2028 */
-static int tm6000_tuner_callback(void *ptr, int component, int command, int
arg)
+int tm6000_tuner_callback(void *ptr, int component, int command, int arg)
{
int rc=0;
struct tm6000_core *dev = ptr;
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index e900d6d..fdbee30 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -235,7 +235,8 @@ int tm6000_dvb_register(struct tm6000_core *dev)
.i2c_adap = dev-i2c_adap,
.i2c_addr = dev-tuner_addr,
};
-
+
+ dvb-frontend-callback = tm6000_tuner_callback;
ret = dvb_register_frontend(dvb-adapter, dvb-frontend);
if (ret 0) {
printk(KERN_ERR
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 877cbf6..d713c48 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -202,6 +202,9 @@ struct tm6000_fh {
V4L2_STD_PAL_M|V4L2_STD_PAL_60|V4L2_STD_NTSC_M| \
V4L2_STD_NTSC_M_JP|V4L2_STD_SECAM
+/* In tm6000-cards.c */
+
+int tm6000_tuner_callback (void *ptr, int component, int command, int arg);
/* In tm6000-core.c */
int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req,
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 9/12] tm6000: remove unused function
From: Stefan Ringel stefan.rin...@arcor.de Signed-off-by: Stefan Ringel stefan.rin...@arcor.de --- drivers/staging/tm6000/tm6000.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h index d713c48..e88836d 100644 --- a/drivers/staging/tm6000/tm6000.h +++ b/drivers/staging/tm6000/tm6000.h @@ -212,7 +212,6 @@ int tm6000_read_write_usb (struct tm6000_core *dev, u8 reqtype, u8 req, int tm6000_get_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index); int tm6000_set_reg (struct tm6000_core *dev, u8 req, u16 value, u16 index); int tm6000_init (struct tm6000_core *dev); -int tm6000_init_after_firmware (struct tm6000_core *dev); int tm6000_init_analog_mode (struct tm6000_core *dev); int tm6000_init_digital_mode (struct tm6000_core *dev); -- 1.6.4.2 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/12] tm6000: adding special usb request to quiting tuner transfer
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-i2c.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-i2c.c
b/drivers/staging/tm6000/tm6000-i2c.c
index 4da10f5..3e43ad7 100644
--- a/drivers/staging/tm6000/tm6000-i2c.c
+++ b/drivers/staging/tm6000/tm6000-i2c.c
@@ -86,6 +86,11 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
msgs[i].len == 1 ? 0 : msgs[i].buf[1],
msgs[i + 1].buf, msgs[i + 1].len);
i++;
+
+ if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+ tm6000_set_reg(dev, 0x32, 0,0);
+ tm6000_set_reg(dev, 0x33, 0,0);
+ }
if (i2c_debug = 2)
for (byte = 0; byte msgs[i].len; byte++)
printk( %02x, msgs[i].buf[byte]);
@@ -99,6 +104,12 @@ static int tm6000_i2c_xfer(struct i2c_adapter *i2c_adap,
REQ_16_SET_GET_I2C_WR1_RDN,
addr | msgs[i].buf[0] 8, 0,
msgs[i].buf + 1, msgs[i].len - 1);
+
+
+ if ((dev-dev_type == TM6010) (addr == 0xc2)) {
+ tm6000_set_reg(dev, 0x32, 0,0);
+ tm6000_set_reg(dev, 0x33, 0,0);
+ }
}
if (i2c_debug = 2)
printk(\n);
@@ -198,7 +209,7 @@ static struct i2c_algorithm tm6000_algo = {
static struct i2c_adapter tm6000_adap_template = {
.owner = THIS_MODULE,
- .class = I2C_CLASS_TV_ANALOG,
+ .class = I2C_CLASS_TV_ANALOG | I2C_CLASS_TV_DIGITAL,
.name = tm6000,
.id = I2C_HW_B_TM6000,
.algo = tm6000_algo,
--
1.6.4.2
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/12] tm6000: tuner reset timeing optimation
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-cards.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 1167b01..5cf5d58 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -271,11 +271,14 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
switch (arg) {
case 0:
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
+ dev-tuner_reset_gpio, 0x01);
+ msleep(60);
+ tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x00);
- msleep(130);
+ msleep(75);
tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
dev-tuner_reset_gpio, 0x01);
- msleep(130);
+ msleep(60);
break;
case 1:
tm6000_set_reg (dev, REQ_04_EN_DISABLE_MCU_INT,
@@ -288,10 +291,10 @@ static int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
TM6000_GPIO_CLK, 0);
if (rc0)
return rc;
- msleep(100);
+ msleep(10);
rc=tm6000_set_reg (dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
- msleep(100);
+ msleep(10);
break;
}
}
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] tm6000: bugfix usb DVB transfer
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/tm6000-dvb.c | 125 ++-
1 files changed, 79 insertions(+), 46 deletions(-)
diff --git a/drivers/staging/tm6000/tm6000-dvb.c
b/drivers/staging/tm6000/tm6000-dvb.c
index fdbee30..055a58f 100644
--- a/drivers/staging/tm6000/tm6000-dvb.c
+++ b/drivers/staging/tm6000/tm6000-dvb.c
@@ -17,7 +17,9 @@
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
*/
+#include linux/kernel.h
#include linux/usb.h
+#include compat.h
#include tm6000.h
#include tm6000-regs.h
@@ -30,13 +32,58 @@
#include tuner-xc2028.h
+static void inline print_err_status (struct tm6000_core *dev,
+int packet, int status)
+{
+ char *errmsg = Unknown;
+
+ switch(status) {
+ case -ENOENT:
+ errmsg = unlinked synchronuously;
+ break;
+ case -ECONNRESET:
+ errmsg = unlinked asynchronuously;
+ break;
+ case -ENOSR:
+ errmsg = Buffer error (overrun);
+ break;
+ case -EPIPE:
+ errmsg = Stalled (device not responding);
+ break;
+ case -EOVERFLOW:
+ errmsg = Babble (bad cable?);
+ break;
+ case -EPROTO:
+ errmsg = Bit-stuff error (bad cable?);
+ break;
+ case -EILSEQ:
+ errmsg = CRC/Timeout (could be anything);
+ break;
+ case -ETIME:
+ errmsg = Device does not respond;
+ break;
+ }
+ if (packet0) {
+ dprintk(dev, 1, URB status %d [%s].\n,
+ status, errmsg);
+ } else {
+ dprintk(dev, 1, URB packet %d, status %d [%s].\n,
+ packet, status, errmsg);
+ }
+}
+
+
+#if LINUX_VERSION_CODE KERNEL_VERSION(2,6,19)
+static void tm6000_urb_received(struct urb *urb, struct pt_regs *ptregs)
+#else
static void tm6000_urb_received(struct urb *urb)
+#endif
{
int ret;
struct tm6000_core* dev = urb-context;
- if(urb-status != 0){
- printk(KERN_ERR tm6000: status != 0\n);
+ if(urb-status != 0) {
+ print_err_status (dev,0,urb-status);
}
else if(urb-actual_length0){
dvb_dmx_swfilter(dev-dvb-demux, urb-transfer_buffer,
@@ -56,49 +103,37 @@ static void tm6000_urb_received(struct urb *urb)
int tm6000_start_stream(struct tm6000_core *dev)
{
int ret;
- unsigned int pipe, maxPaketSize;
+ unsigned int pipe, size;
struct tm6000_dvb *dvb = dev-dvb;
printk(KERN_INFO tm6000: got start stream request %s\n,__FUNCTION__);
tm6000_init_digital_mode(dev);
-/*
- ret = tm6000_set_led_status(tm6000_dev, 0x1);
- if(ret 0) {
- return -1;
- }
-*/
-
dvb-bulk_urb = usb_alloc_urb(0, GFP_KERNEL);
if(dvb-bulk_urb == NULL) {
printk(KERN_ERR tm6000: couldn't allocate urb\n);
return -ENOMEM;
}
- maxPaketSize = dev-bulk_in-desc.wMaxPacketSize;
+ pipe = usb_rcvbulkpipe(dev-udev, dev-bulk_in-desc.bEndpointAddress
+
USB_ENDPOINT_NUMBER_MASK);
+
+ size = usb_maxpacket(dev-udev, pipe, usb_pipeout(pipe));
+ size = size * 15; /* 512 x 8 or 12 or 15 */
- dvb-bulk_urb-transfer_buffer = kzalloc(maxPaketSize, GFP_KERNEL);
+ dvb-bulk_urb-transfer_buffer = kzalloc(size, GFP_KERNEL);
if(dvb-bulk_urb-transfer_buffer == NULL) {
usb_free_urb(dvb-bulk_urb);
printk(KERN_ERR tm6000: couldn't allocate transfer buffer!\n);
return -ENOMEM;
}
- pipe = usb_rcvbulkpipe(dev-udev, dev-bulk_in-desc.bEndpointAddress
-
USB_ENDPOINT_NUMBER_MASK);
-
usb_fill_bulk_urb(dvb-bulk_urb, dev-udev, pipe,
dvb-bulk_urb-transfer_buffer,
-maxPaketSize,
+size,
tm6000_urb_received, dev);
- ret = usb_set_interface(dev-udev, 0, 1);
- if(ret 0) {
- printk(KERN_ERR tm6000: error %i in %s during set
interface\n, ret, __FUNCTION__);
- return ret;
- }
-
ret = usb_clear_halt(dev-udev, pipe);
if(ret 0) {
printk(KERN_ERR tm6000: error %i in %s during pipe
reset\n,ret,__FUNCTION__);
@@ -108,14 +143,13 @@ int tm6000_start_stream(struct tm6000_core *dev)
printk(KERN_ERR tm6000: pipe resetted\n);
}
-// mutex_lock(tm6000_driver.open_close_mutex);
+/*
[PATCH 12/12] tm6000: add a different set param values
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/staging/tm6000/hack.c | 160 -
1 files changed, 157 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/tm6000/hack.c b/drivers/staging/tm6000/hack.c
index f181fce..bb4100b 100644
--- a/drivers/staging/tm6000/hack.c
+++ b/drivers/staging/tm6000/hack.c
@@ -37,7 +37,6 @@ static inline int tm6000_snd_control_msg(struct tm6000_core
*dev, __u8 request,
static int pseudo_zl10353_pll(struct tm6000_core *tm6000_dev, struct
dvb_frontend_parameters *p)
{
- int ret;
u8 *data = kzalloc(50*sizeof(u8), GFP_KERNEL);
printk(KERN_ALERT should set frequency %u\n, p-frequency);
@@ -51,7 +50,7 @@ printk(KERN_ALERT and bandwith %u\n, p-u.ofdm.bandwidth);
}
// init ZL10353
- data[0] = 0x0b;
+/* data[0] = 0x0b;
ret = tm6000_snd_control_msg(tm6000_dev, 0x10, 0x501e, 0x00, data, 0x1);
msleep(15);
data[0] = 0x80;
@@ -189,7 +188,162 @@ printk(KERN_ALERT and bandwith %u\n,
p-u.ofdm.bandwidth);
msleep(15);
break;
}
-
+*/
+ switch(p-u.ofdm.bandwidth) {
+ case BANDWIDTH_8_MHZ:
+ data[0] = 0x03;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+ msleep(40);
+ data[0] = 0x44;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+ msleep(40);
+ data[0] = 0x40;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+ msleep(40);
+ data[0] = 0x46;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x521e,0,data,1);
+ msleep(40);
+ data[0] = 0x15;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x531e,0,data,1);
+ msleep(40);
+ data[0] = 0x0f;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x541e,0,data,1);
+ msleep(40);
+ data[0] = 0x80;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+ msleep(40);
+ data[0] = 0x01;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+ msleep(40);
+ data[0] = 0x00;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xea1e,0,data,1);
+ msleep(40);
+ data[0] = 0x8b;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x631e,0,data,1);
+ msleep(40);
+ data[0] = 0x75;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0xcc1e,0,data,1);
+ msleep(40);
+ data[0] = 0xe6; //0x19;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6c1e,0,data,1);
+ msleep(40);
+ data[0] = 0x09; //0xf7;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x6d1e,0,data,1);
+ msleep(40);
+ data[0] = 0x67;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x651e,0,data,1);
+ msleep(40);
+ data[0] = 0xe5;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x661e,0,data,1);
+ msleep(40);
+ data[0] = 0x75;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5c1e,0,data,1);
+ msleep(40);
+ data[0] = 0x17;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5f1e,0,data,1);
+ msleep(40);
+ data[0] = 0x40;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x5e1e,0,data,1);
+ msleep(40);
+ data[0] = 0x01;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x701e,0,data,1);
+ msleep(40);
+ break;
+ case BANDWIDTH_7_MHZ:
+ data[0] = 0x03;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x501e,0,data,1);
+ msleep(40);
+ data[0] = 0x44;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x511e,0,data,1);
+ msleep(40);
+ data[0] = 0x40;
+
tm6000_read_write_usb(tm6000_dev,0x40,0x10,0x551e,0,data,1);
+ msleep(40);
+ data[0] = 0x46;
+
[PATCH 11/12] tm6000: bugfix firmware xc3028L-v36.fw used with Zarlink and DTV78 or DTV8 no shift
From: Stefan Ringel stefan.rin...@arcor.de
Signed-off-by: Stefan Ringel stefan.rin...@arcor.de
---
drivers/media/common/tuners/tuner-xc2028.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/media/common/tuners/tuner-xc2028.c
b/drivers/media/common/tuners/tuner-xc2028.c
index ed50168..fcf19cc 100644
--- a/drivers/media/common/tuners/tuner-xc2028.c
+++ b/drivers/media/common/tuners/tuner-xc2028.c
@@ -1114,7 +1114,12 @@ static int xc2028_set_params(struct dvb_frontend *fe,
/* All S-code tables need a 200kHz shift */
if (priv-ctrl.demod) {
- demod = priv-ctrl.demod + 200;
+ if ((strcmp (priv-ctrl.fname, xc3028L-v36.fw) == 0)
+ (priv-ctrl.demod == XC3028_FE_ZARLINK456)
+ ((type DTV78) || (type DTV8)))
+ demod = priv-ctrl.demod;
+ else
+ demod = priv-ctrl.demod + 200;
/*
* The DTV7 S-code table needs a 700 kHz shift.
* Thanks to Terry Wu terrywu2...@gmail.com for reporting this
--
1.6.4.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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Andy Walls wrote: As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. You cannot expect people reacting immediately if something is wrong. There are and do exist enormous delays between publishing a new kernel and the decision to use it after appropriate system or distro update. So your expectation level is simply wrong. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. Yes. Trivial! From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. It's truly amazing how the filter system of your perception works, isn't it? :) It's not just an old, orphaned application with a non-official patch on it. That's nonsense! a. As I stated already, there do exist several patched versions of alevt-dvb. For instance the one that Herman Pitton tested here in public causes a closed demux device error on my machine. That means that it does not run because xine-ui is already using the demux device. And this phenomenon has got nothing to do with the kernel headers! I've tried all possibilities (old kernel headers and actual ones) so I know better than Hermann Pitton does! And my version (and obviously the ones of Thomas Voegtle and Emil Meier whom I helped with my tip to revert that patch) cause a kernel crash with the actual kernel. b. As I also stated already the other teletext application called mtt does officially not exist except for Novell / OpenSuSe distros (at least as far as I have seen and found out). And this one is, as I also stated, not affected by the kernel patch. It's part of a discontinued program suite called xawtv-4.0 pre with a very complex infrastructure behind. Please do not ask me why this one runs without noise - I do not know. So AFAICS alevt-dvb is the ONLY teletext application for Linux which is available in almost all Gnu/Linux distros. Other applications with similar features weren't affected. From where do you know that the features are similar? This is a 100 % phantasy product of your mind that has got nothing to do with existing reality, man! Just one example: alevt-dvb has got an excellent html export filter which makes it possible to export teletext pages as graphical html files. I do not know any other teletext application offering that. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. Who says that a new API or an overworked API must be ready for 2.6.33? When do you think the correct starting point must be set? When the merge window for 2.6.34 opens or when? Absurd argument! Not valid at all! So, removing those two ioctls is not an option anymore. Yes. Conclusion??? None! So if everybody wants to close down this discussion with that output then you must admit (if you want it or not) that you de facto bury teletext usage in the mud for the majority of Gnu/Linux DVB users. So the output is more than badly disappointing. Bye bye Teletext. Nothing for future kernels, huh? Yes, you say it. It definitely will go away and we do have not any influence on that! Did you not notice the very slow update rate these days? Regards CS P. S.: If you continue like that you make people run away. Instead you better should try to win people, shouldn't you? Just see how many volunteers are here to help and then reflect why that manpower is missing, Mauro! Your gesture being expressed above does a lot, but it is definitely NOT motivating to change that precarious situation. Then maybe better tell what you tried already, instead leaving others behind doing the same in vain again? Mauro always did try to keep backward compat as much as possible and others had to tell him better not to waste his time on it. You hit the wrong guy again and he
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton: Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Andy Walls wrote: As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. You cannot expect people reacting immediately if something is wrong. There are and do exist enormous delays between publishing a new kernel and the decision to use it after appropriate system or distro update. So your expectation level is simply wrong. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. Yes. Trivial! From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. It's truly amazing how the filter system of your perception works, isn't it? :) It's not just an old, orphaned application with a non-official patch on it. That's nonsense! a. As I stated already, there do exist several patched versions of alevt-dvb. For instance the one that Herman Pitton tested here in public causes a closed demux device error on my machine. That means that it does not run because xine-ui is already using the demux device. And this phenomenon has got nothing to do with the kernel headers! I've tried all possibilities (old kernel headers and actual ones) so I know better than Hermann Pitton does! And my version (and obviously the ones of Thomas Voegtle and Emil Meier whom I helped with my tip to revert that patch) cause a kernel crash with the actual kernel. b. As I also stated already the other teletext application called mtt does officially not exist except for Novell / OpenSuSe distros (at least as far as I have seen and found out). And this one is, as I also stated, not affected by the kernel patch. It's part of a discontinued program suite called xawtv-4.0 pre with a very complex infrastructure behind. Please do not ask me why this one runs without noise - I do not know. So AFAICS alevt-dvb is the ONLY teletext application for Linux which is available in almost all Gnu/Linux distros. Other applications with similar features weren't affected. From where do you know that the features are similar? This is a 100 % phantasy product of your mind that has got nothing to do with existing reality, man! Just one example: alevt-dvb has got an excellent html export filter which makes it possible to export teletext pages as graphical html files. I do not know any other teletext application offering that. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. Who says that a new API or an overworked API must be ready for 2.6.33? When do you think the correct starting point must be set? When the merge window for 2.6.34 opens or when? Absurd argument! Not valid at all! So, removing those two ioctls is not an option anymore. Yes. Conclusion??? None! So if everybody wants to close down this discussion with that output then you must admit (if you want it or not) that you de facto bury teletext usage in the mud for the majority of Gnu/Linux DVB users. So the output is more than badly disappointing. Bye bye Teletext. Nothing for future kernels, huh? Yes, you say it. It definitely will go away and we do have not any influence on that! Did you not notice the very slow update rate these days? a. NOTHING will go away. This is empty rant, nothing else it is! In US teletext is dead, yes. In Europe analogue television is close to dead. Yes. But I have found no information source that teletext will disappear in general. At least not in Europe or Germany. So if you keep that up then prove the assertion please. What slow update rate please? What the hell are you talking about, man? Regards CS P. S.: If you continue like that you
Re: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Am Samstag, den 06.02.2010, 00:39 +0100 schrieb Chicken Shack: Am Samstag, den 06.02.2010, 00:12 +0100 schrieb hermann pitton: Am Freitag, den 05.02.2010, 23:32 +0100 schrieb Chicken Shack: Am Freitag, den 05.02.2010, 19:07 -0200 schrieb Mauro Carvalho Chehab: Andreas Oberritter wrote: Andy Walls wrote: As Honza noted, these ioctls are used by enigma2 and, in general, by software running on Dream Multimedia set top boxes. Right, so reverting the patch is not an option. It also makes implementing multiple dvr0.n nodes for a demux0 device node probably a waste of time at this point. I think so, too. But I guess it's always worth discussing alternatives. If this discussion happened before 2.6.32 release, and provided that a different implementation were agreed, things would be easier, as a different solution like your proposal could be decided and used. You cannot expect people reacting immediately if something is wrong. There are and do exist enormous delays between publishing a new kernel and the decision to use it after appropriate system or distro update. So your expectation level is simply wrong. Now, we have already a regression on a stable kernel, and solving it by creating another regression is not something smart to do. Yes. Trivial! From what I understood, the regression appeared on an old, orphan application with a non-official patch applied on it. Other applications with similar features weren't affected. On the other hand, if the patch got reverted, we'll break a maintained application that is used on a great number of devices, and whose features depend on the new ioctls. It's truly amazing how the filter system of your perception works, isn't it? :) It's not just an old, orphaned application with a non-official patch on it. That's nonsense! a. As I stated already, there do exist several patched versions of alevt-dvb. For instance the one that Herman Pitton tested here in public causes a closed demux device error on my machine. That means that it does not run because xine-ui is already using the demux device. And this phenomenon has got nothing to do with the kernel headers! I've tried all possibilities (old kernel headers and actual ones) so I know better than Hermann Pitton does! And my version (and obviously the ones of Thomas Voegtle and Emil Meier whom I helped with my tip to revert that patch) cause a kernel crash with the actual kernel. b. As I also stated already the other teletext application called mtt does officially not exist except for Novell / OpenSuSe distros (at least as far as I have seen and found out). And this one is, as I also stated, not affected by the kernel patch. It's part of a discontinued program suite called xawtv-4.0 pre with a very complex infrastructure behind. Please do not ask me why this one runs without noise - I do not know. So AFAICS alevt-dvb is the ONLY teletext application for Linux which is available in almost all Gnu/Linux distros. Other applications with similar features weren't affected. From where do you know that the features are similar? This is a 100 % phantasy product of your mind that has got nothing to do with existing reality, man! Just one example: alevt-dvb has got an excellent html export filter which makes it possible to export teletext pages as graphical html files. I do not know any other teletext application offering that. We are too late in -rc cycle, so probably there's not enough time for writing, test, validate any new API in time for 2.6.33 and write some compat layer to emulate those two ioctls with a different implementation. Who says that a new API or an overworked API must be ready for 2.6.33? When do you think the correct starting point must be set? When the merge window for 2.6.34 opens or when? Absurd argument! Not valid at all! So, removing those two ioctls is not an option anymore. Yes. Conclusion??? None! So if everybody wants to close down this discussion with that output then you must admit (if you want it or not) that you de facto bury teletext usage in the mud for the majority of Gnu/Linux DVB users. So the output is more than badly disappointing. Bye bye Teletext. Nothing for future kernels, huh? Yes, you say it. It definitely will go away and we do have not any influence on that! Did you not notice the very slow update rate these days? a. NOTHING will go away. This is empty rant, nothing else it is! In US teletext is dead, yes. In Europe analogue television is close to dead. Yes. But I have found no information source that teletext will disappear in general. At least not in Europe or Germany. So if
Re: [GIT PATCHES FOR 2.6.34] Support for vpfe-capture on DM365
Mauro,
On Fri, Feb 5, 2010 at 4:52 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Muralidharan Karicheri wrote:
Mauro,
Please pull from the following:-
The following changes since commit 84b74782ace1ae091c1b0e14ae2ee9bb720532ba:
Douglas Schilling Landgraf (1):
V4L/DVB: Fix logic for Leadtek winfast tv usbii deluxe
are available in the git repository at:
git://linuxtv.org/mkaricheri/vpfe-vpbe-video.git for_upstream
Murali Karicheri (6):
DaVinci - Adding platform board changes for vpfe capture on DM365
V4L - vpfe capture - header files for ISIF driver
V4L - vpfe capture - source for ISIF driver on DM365
Hmm...
+static int isif_get_params(void __user *params)
+{
+ /* only raw module parameters can be set through the IOCTL */
+ if (isif_cfg.if_type != VPFE_RAW_BAYER)
+ return -EINVAL;
+
+ if (copy_to_user(params,
+ isif_cfg.bayer.config_params,
+ sizeof(isif_cfg.bayer.config_params))) {
+/* Parameter operations */
+static int isif_set_params(void __user *params)
+{
+ struct isif_config_params_raw *isif_raw_params;
+ int ret = -EINVAL;
+
+ /* only raw module parameters can be set through the IOCTL */
+ if (isif_cfg.if_type != VPFE_RAW_BAYER)
+ return ret;
+
+ isif_raw_params = kzalloc(sizeof(*isif_raw_params), GFP_KERNEL);
+ if (NULL == isif_raw_params)
+ return -ENOMEM;
+
+ ret = copy_from_user(isif_raw_params,
It seems that you're defining some undocumented new userspace API here.
Yes. This supports an experimental, but necessary API that configures
the ISIF (Image sensor Interface) image tuning parameters from
User Space. These parameters are used when converting Bayer RGB image
to UYVY format when capturing from sensors such as MT9T031.
For SoCs like TI's DMxxx series, the user needs to have full control
over these parameters to get desired image quality.
This had been discussed during the initial version of vpfe-capture
driver discussion and it was decided to keep them as experimental. So
no
documentation is provided at this time. The ioctls are defined in the
vpfe_capture.h header file and the user space structures are under
ccdc.h and isif.h under include/media/davinci and are marked as
experimental. This was also discussed in this mailing list before
and the decision taken at that time was to do it properly as part of
media soc framework. In this framework, isif and other similar SoC
hardware IPs will have a device node to configure these parameters
and therefore will have to be re-worked once media soc framework is
available. Until then vpfe-capture users need to have a way to
configure the ISIF or such hardware IPs.
Regards,
Murali
Cheers,
Mauro
--
Murali Karicheri
mkarich...@gmail.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] cx23885: Enable Message Signaled Interrupts(MSI).
Signed-off-by: Kusanagi Kouichi sl...@ac.auone-net.jp
---
drivers/media/video/cx23885/cx23885-core.c |9 +++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-core.c
b/drivers/media/video/cx23885/cx23885-core.c
index 0dde57e..7101c51 100644
--- a/drivers/media/video/cx23885/cx23885-core.c
+++ b/drivers/media/video/cx23885/cx23885-core.c
@@ -1953,8 +1953,12 @@ static int __devinit cx23885_initdev(struct pci_dev
*pci_dev,
goto fail_irq;
}
- err = request_irq(pci_dev-irq, cx23885_irq,
- IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
+ if (!pci_enable_msi(pci_dev))
+ err = request_irq(pci_dev-irq, cx23885_irq,
+ IRQF_DISABLED, dev-name, dev);
+ else
+ err = request_irq(pci_dev-irq, cx23885_irq,
+ IRQF_SHARED | IRQF_DISABLED, dev-name, dev);
if (err 0) {
printk(KERN_ERR %s: can't get IRQ %d\n,
dev-name, pci_dev-irq);
@@ -2000,6 +2004,7 @@ static void __devexit cx23885_finidev(struct pci_dev
*pci_dev)
/* unregister stuff */
free_irq(pci_dev-irq, dev);
+ pci_disable_msi(pci_dev);
cx23885_dev_unregister(dev);
v4l2_device_unregister(v4l2_dev);
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
