[PATCH 1/2] tm6000 : Add additional GPIO for UT821 during frmware loading
Signed-off-by: Bee Hock Goh beeh...@gmail.com
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index f795a3e..ced8fce 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -349,6 +349,22 @@ int tm6000_tuner_callback(void *ptr, int
component, int command, int arg)
case 0:
/* newer tuner can faster reset */
switch (dev-model) {
+ case TM5600_BOARD_10MOONS_UT821:
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x01);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ 0x300, 0x01);
+ msleep(10);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x00);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ 0x300, 0x00);
+ msleep(10);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ dev-gpio.tuner_reset, 0x01);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
+ 0x300, 0x01);
+ break;
case TM6010_BOARD_HAUPPAUGE_900H:
case TM6010_BOARD_TERRATEC_CINERGY_HYBRID_XE:
case TM6010_BOARD_TWINHAN_TU501:
--
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/2] tm6000 : Fix filling up of buffer for video frame
Avoid(until there is a better fix) cleaning up of buffer as it will
cause partital green screen when there are frame dropped.
Fix video line couting corruption when cmd is not a video packet.
Signed-off-by: Bee Hock Goh beeh...@gmail.com
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index c53de47..50b12ac 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -133,7 +133,7 @@ static inline void get_next_buf(struct
tm6000_dmaqueue *dma_q,
struct tm6000_buffer **buf)
{
struct tm6000_core *dev = container_of(dma_q, struct tm6000_core, vidq);
- char *outp;
+// char *outp;
if (list_empty(dma_q-active)) {
dprintk(dev, V4L2_DEBUG_QUEUE, No active queue to serve\n);
@@ -148,8 +148,8 @@ static inline void get_next_buf(struct
tm6000_dmaqueue *dma_q,
return;
/* Cleans up buffer - Usefull for testing for frame/URB loss */
- outp = videobuf_to_vmalloc((*buf)-vb);
- memset(outp, 0, (*buf)-vb.size);
+// outp = videobuf_to_vmalloc((*buf)-vb);
+// memset(outp, 0, (*buf)-vb.size);
return;
}
@@ -282,7 +282,8 @@ static int copy_packet(struct urb *urb, u32
header, u8 **ptr, u8 *endp,
start_line=line;
last_field=field;
}
- last_line=line;
+ if (cmd == TM6000_URB_MSG_VIDEO)
+ last_line=line;
pktsize = TM6000_URB_MSG_LEN;
} else {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] V4L2 file handles and event interface, take 2
Sakari Ailus wrote: Hi Mauro, Hans Verkuil has provided the patches to support the V4L2 events on ivtv (thanks, Hans!). Those patches are part of this pull request. The documentation has been improved --- v4l2_fh is now clearly marked as optional interface. Rebased, too. Please pull. The following changes since commit 975b06b6c01ba2da4d26a7ba6ea783d5f670aa7d: Jonathan Corbet (1): V4L/DVB: ov7670: silence some compiler warnings are available in the git repository at: git://gitorious.org/omap3camera/camera-firmware.git v4l-dvb-event git pull git://gitorious.org/omap3camera/camera-firmware.git v4l-dvb-event fatal: Couldn't find remote ref v4l-dvb-event Had you removed this branch? Hans Verkuil (4): v4l: add VSYNC and EOS events for use with ivtv. ivtv: support the new events API. v4l spec: document what odd and even fields are. v4l spec: document new events. Sakari Ailus (6): V4L: File handles V4L: File handles: Add documentation V4L: Events: Add new ioctls for events V4L: Events: Add backend V4L: Events: Support event handling in do_ioctl V4L: Events: Add documentation Documentation/DocBook/media-entities.tmpl | 11 + Documentation/DocBook/v4l/dev-event.xml| 31 ++ Documentation/DocBook/v4l/io.xml |8 +- Documentation/DocBook/v4l/v4l2.xml |3 + Documentation/DocBook/v4l/vidioc-dqevent.xml | 131 + .../DocBook/v4l/vidioc-subscribe-event.xml | 133 + Documentation/video4linux/v4l2-framework.txt | 132 + drivers/media/video/Makefile |3 +- drivers/media/video/ivtv/ivtv-driver.h |7 + drivers/media/video/ivtv/ivtv-fileops.c| 53 +++- drivers/media/video/ivtv/ivtv-ioctl.c | 24 ++- drivers/media/video/ivtv/ivtv-irq.c| 15 +- drivers/media/video/ivtv/ivtv-streams.c|5 + drivers/media/video/v4l2-compat-ioctl32.c |3 + drivers/media/video/v4l2-dev.c |4 + drivers/media/video/v4l2-event.c | 289 drivers/media/video/v4l2-fh.c | 79 ++ drivers/media/video/v4l2-ioctl.c | 53 include/linux/videodev2.h | 35 +++ include/media/v4l2-dev.h |5 + include/media/v4l2-event.h | 67 + include/media/v4l2-fh.h| 65 + include/media/v4l2-ioctl.h |7 + 23 files changed, 1141 insertions(+), 22 deletions(-) create mode 100644 Documentation/DocBook/v4l/dev-event.xml create mode 100644 Documentation/DocBook/v4l/vidioc-dqevent.xml create mode 100644 Documentation/DocBook/v4l/vidioc-subscribe-event.xml create mode 100644 drivers/media/video/v4l2-event.c create mode 100644 drivers/media/video/v4l2-fh.c create mode 100644 include/media/v4l2-event.h create mode 100644 include/media/v4l2-fh.h -- 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: [PATCH 0/2] media, mfd: Add timberdale video-in driver
Samuel Ortiz wrote: Hi Richard, On Fri, Apr 16, 2010 at 06:27:54PM +0200, Richard Röjfors wrote: To follow are two patches. The first one adds the timberdale video-in driver to the media tree. The second one adds it to the timberdale MFD driver. The Kconfig of the media patch selects TIMB_DMA which is introduced in the DMA tree, that's why I cc:d in Dan. Samuel and Mauro hope you can support and solve the potential merge issue between your two trees. Mauro, the mfd part of this patch depends on the video one. Do you mind if I take both through my tree, after getting your Acked-by ? No problem. I'll let you know after I get my ack. -- 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: [PULL] http://linuxtv.org/hg/~endriss/ngene
On Sunday 25 April 2010 15:42:54 Mauro Carvalho Chehab wrote: Oliver Endriss wrote: On Sunday 21 March 2010 21:15:01 Oliver Endriss wrote: Mauro, Please pull from http://linuxtv.org/hg/~endriss/ngene for the following changeset: 01/01: ngene: Workaround for stuck DiSEqC pin http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63 stv090x.c |4 1 file changed, 4 insertions(+) Thanks, Oliver Ping! This patch were already merged on my fixes.git tree: commit 492c3a4e8749e70b2f981d600bc29a1798963ff9 Author: Oliver Endriss o.endr...@gmx.de AuthorDate: Sun Mar 21 11:48:47 2010 -0300 Commit: Mauro Carvalho Chehab mche...@redhat.com CommitDate: Thu Apr 1 12:58:29 2010 -0300 V4L/DVB: ngene: Workaround for stuck DiSEqC pin Send one DiSEqC byte to make sure that the pin is set to low level. It is not on the development tree yet (so, it were not added to the -hg tree). The rationale is that this patch should go first to upstream tree, and then, when merging again from Linus, it will appear at the development tree. However: if we backport from Linus right now, we'll move from a stable revision (2.6.33) to a non-stable random upstream version. I'm avoiding to do it, since, every time we merge back, a full compilation is required for those that are using git. On the other hand, if we simply add the patch at -git, it will appear again when submitting the development tree upstream. So, we basically need some ideas on how to improve the process without those issues . I have a few ideas about it (probably adding some branches at the tree), but I need first to work on my long queue of patches, in order to have some time to work on it. Well, my understanding of a proper software development process is: (1) Patch goes to the master development trees. (2) Patch will (hopefully) get more testing. (3) Patch should go upstream. If we have to wait for patches to be applied upstream, the master development trees are pointless... CU 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: [PATCH 1/2] media: Add timberdale video-in driver
Richard Röjfors wrote:
On 04/25/2010 05:24 PM, Mauro Carvalho Chehab wrote:
Richard Röjfors wrote:
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 videobuffers to handle buffers against user space.
Due to some timing constraint it makes sense to do DMA into an
intermediate buffer and then copy the data to vmalloc:ed buffers.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjforsrichard.rojf...@pelagicore.com
+#define TIMBLOGIW_DMA_BUFFER_SIZE(TIMBLOGIW_BYTES_PER_LINE * 576)
...
+static int __timblogiw_alloc_dma(struct timblogiw_fh *fh, struct
device *dev)
+{
+dma_addr_t addr;
+int err, i, pos;
+int bytes_per_desc = TIMBLOGIW_LINES_PER_DESC *
+timblogiw_bytes_per_line(fh-cur_norm);
+
+fh-dma.cookie = -1;
+fh-dma.dev = dev;
+
+fh-dma.buf = kzalloc(TIMBLOGIW_DMA_BUFFER_SIZE, GFP_KERNEL);
+if (!fh-dma.buf)
+return -ENOMEM;
Why do you need a fixed DMA buffer size? Just allocate the buffer size
dynamically at
buffer_prepare callback.
+videobuf_queue_vmalloc_init(fh-vb_vidq,timblogiw_video_qops,
+NULL,fh-queue_lock, V4L2_BUF_TYPE_VIDEO_CAPTURE,
+V4L2_FIELD_NONE, sizeof(struct videobuf_buffer), fh);
You should be using, instead, videobuf_dma_sg or videobuf_cont,
instead of
using videobuf-vmalloc. This way, you'll avoid double buffering.
1. dma_sg can not be used, the DMA engine requires the memory blocks to
be aligned on a factor of bytes per line, so 4K pages wouldn't work.
2.
I tried using videobuf-dma-contig, but got poor performance. I can not
really explain why, I though it's due to the fact that the contiguous
buffer is allocated coherent - no caching.
I saw both gstreamer and mplayer perform very badly.
The frame grabber requires the DMA transfer for a frame beeing started
while the frame is decoded. When I tested using contigous buffers
gstreamer sometimes was that slow that it sometimes missed to have a
frame queued when a transfer was finished, so I got frame drops. Any
other ideas of the poor performance? otherwise I would like to go for
the double buffered solution.
The better is to fix videobuf-dma_contig to better work on your hardware.
It makes sense to add a flag to allow specifying if it should use coherent
or non-coherent memory for the dma buffer alloc/free calls.
--
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: [PATCH 1/2] media: Add timberdale video-in driver
On 04/25/2010 05:24 PM, Mauro Carvalho Chehab wrote:
Richard Röjfors wrote:
This patch adds the timberdale video-in driver.
The video IP of timberdale delivers the video data via DMA.
The driver uses the DMA api to handle DMA transfers, and make use
of the V4L2 videobuffers to handle buffers against user space.
Due to some timing constraint it makes sense to do DMA into an
intermediate buffer and then copy the data to vmalloc:ed buffers.
If available the driver uses an encoder to get/set the video standard
Signed-off-by: Richard Röjforsrichard.rojf...@pelagicore.com
+#define TIMBLOGIW_DMA_BUFFER_SIZE (TIMBLOGIW_BYTES_PER_LINE * 576)
...
+static int __timblogiw_alloc_dma(struct timblogiw_fh *fh, struct device *dev)
+{
+ dma_addr_t addr;
+ int err, i, pos;
+ int bytes_per_desc = TIMBLOGIW_LINES_PER_DESC *
+ timblogiw_bytes_per_line(fh-cur_norm);
+
+ fh-dma.cookie = -1;
+ fh-dma.dev = dev;
+
+ fh-dma.buf = kzalloc(TIMBLOGIW_DMA_BUFFER_SIZE, GFP_KERNEL);
+ if (!fh-dma.buf)
+ return -ENOMEM;
Why do you need a fixed DMA buffer size? Just allocate the buffer size
dynamically at
buffer_prepare callback.
+ videobuf_queue_vmalloc_init(fh-vb_vidq,timblogiw_video_qops,
+ NULL,fh-queue_lock, V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ V4L2_FIELD_NONE, sizeof(struct videobuf_buffer), fh);
You should be using, instead, videobuf_dma_sg or videobuf_cont, instead of
using videobuf-vmalloc. This way, you'll avoid double buffering.
1. dma_sg can not be used, the DMA engine requires the memory blocks to be aligned on a factor of
bytes per line, so 4K pages wouldn't work.
2.
I tried using videobuf-dma-contig, but got poor performance. I can not really explain why, I though
it's due to the fact that the contiguous buffer is allocated coherent - no caching.
I saw both gstreamer and mplayer perform very badly.
The frame grabber requires the DMA transfer for a frame beeing started while the frame is decoded.
When I tested using contigous buffers gstreamer sometimes was that slow that it sometimes missed to
have a frame queued when a transfer was finished, so I got frame drops. Any other ideas of the poor
performance? otherwise I would like to go for the double buffered solution.
Thanks
--Richard
--
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: av7110 and budget_av are broken!
On Wed, Apr 21, 2010 at 2:44 AM, Oliver Endriss o.endr...@gmx.de wrote: It's merged in Mauro's fixes tree, but I don't think those pending patches have been pushed upstream yet. Mauro, can you verify this? They should be pushed to 2.6.34! What about the HG driver? The v4l-dvb HG repository is broken for 7 weeks... It doesn't make any sense why someone would break a driver and then leave it that way for such a long period of time. Yes, please fix the HG repository. I don't actually know anyone who bothers with the git tree for obvious reasons, but a whole mess of users continue, of course, to use the mercurial tree... -- 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
faulty pac3711
Hi! I'd have an Exibel snakescope TF2808 which dont make any picure on Linux. It worked ok on windows, but I do not have windows installed any longer. I do not think there have happened something to the camera meanwhile, I'd think the camera is OK. The driver seems to be ok too: (part of messages) Apr 25 19:43:16 sigmund-laptop kernel: [ 20.967903] gspca: main v2.6.0 registered Apr 25 19:43:16 sigmund-laptop kernel: [ 21.214190] gspca: probing 093a:2620 Apr 25 19:43:16 sigmund-laptop kernel: [ 21.287398] gspca: probe ok Apr 25 19:43:16 sigmund-laptop kernel: [ 21.287416] gspca: probing 093a:2620 Apr 25 19:43:16 sigmund-laptop kernel: [ 21.287431] gspca: probing 093a:2620 Apr 25 19:43:16 sigmund-laptop kernel: [ 21.287457] usbcore: registered new interface driver pac7311 Apr 25 19:43:16 sigmund-laptop kernel: [ 21.287462] pac7311: registered I'd have tried tvtime and xawtv as viewing application, same result on both; blank screen and various error messages. tvtime comes up with an blue screen no signal,Frames too short from pac7311 and cannot open capture device /dev/video0. xawtv started from an terminal outputs this and hangs: sigm...@sigmund-laptop:~$ xawtv -device /dev/video0 This is xawtv-3.95.dfsg.1, running on Linux/i686 (2.6.31-20-generic) xinerama 0: 1400x1050+0+0 WARNING: No DGA direct video mode for this display. /dev/video0 [v4l2]: no overlay support v4l-conf had some trouble, trying to continue anyway Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*, -efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-m-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-c-*-*-*, -*-*-*-*-*-*-16-*-*-*-*-*-*-*,* to type FontSet Warning: Cannot convert string -*-ledfixed-medium-r-*--39-*-*-*-c-*-*-* to type FontStruct Warning: Missing charsets in String to FontSet conversion Warning: Cannot convert string -*-lucidatypewriter-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -*-courier-bold-r-normal-*-14-*-*-*-m-*-iso8859-*, -gnu-unifont-bold-r-normal--16-*-*-*-c-*-*-*, -efont-biwidth-bold-r-normal--16-*-*-*-*-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-m-*-*-*, -*-*-bold-r-normal-*-16-*-*-*-c-*-*-*, -*-*-*-*-*-*-16-*-*-*-*-*-*-*, * to type FontSet ioctl: VIDIOC_G_STD(std=0xb789b1d000971326 [PAL_B1,PAL_G,PAL_D,PAL_M,PAL_N,NTSC_M,SECAM_B,SECAM_D,SECAM_G,SECAM_K,?ATSC_8_VSB,(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null),(null)]): end of xawtv output syslog also came up with two new lines: Apr 25 20:30:22 sigmund-laptop kernel: [ 2848.327067] gspca: usb_submit_urb [0] err -28 Apr 25 20:30:23 sigmund-laptop kernel: [ 2848.607073] gspca: usb_submit_urb [0] err -28 Tried an Creative Live! cam on the same machine and it works ok. sigm...@sigmund-laptop:~$ uname -a Linux sigmund-laptop 2.6.31-20-generic #58-Ubuntu SMP Fri Mar 12 05:23:09 UTC 2010 i686 GNU/Linux I do not have any idea nor what to do now, nor how the error could be further traced down. Hopefully there's somebody on the list who can help me. Cincerely, Sigmund Skjelnes -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Apr 25 19:00:28 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14592:b438301e588f git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 1fa9d4c07f3ddee1c054a751cd78e53e8b9050b4 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-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc1-armv5-davinci: OK linux-2.6.32.6-armv5-ixp: OK linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc1-armv5-ixp: OK linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc1-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: OK linux-2.6.25.20-i686: OK 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-i686: OK linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-rc1-mips: OK linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: OK linux-2.6.25.20-x86_64: OK 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-x86_64: OK linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 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: [PATCH] tm6000 fix i2c
Hi
It's my error. This code good only for tm6010. Now I rework my patch.
With my best regards, Dmitry.
I am still able to watch tv after applying the patch but the return
code is bad and is causing unnecessary reloading of the same
firmwares.
[ 2482.599040] usb 1-1: firmware: requesting tm6000-xc3028.fw
[ 2482.607229] xc2028 2-0061: Loading 77 firmware images from
tm6000-xc3028.fw, type: xc2028 firmware, ver 2.4
[ 2482.788089] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2503.620069] (0), id 00ff:
[ 2503.620078] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2504.380061] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2504.520063] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2504.536064] xc2028 2-0061: Unable to read tuner registers.
[ 2504.776079] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2525.556048] (0), id 00ff:
[ 2525.556057] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2526.312058] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2526.452061] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2526.468050] xc2028 2-0061: Unable to read tuner registers.
[ 2527.648076] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2548.460067] (0), id 00ff:
[ 2548.460076] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2549.216070] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2549.356064] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2549.372065] xc2028 2-0061: Unable to read tuner registers.
[ 2549.612052] xc2028 2-0061: Loading firmware for type=BASE F8MHZ
(3), id .
[ 2570.609041] (0), id 00ff:
[ 2570.609049] xc2028 2-0061: Loading firmware for type=(0), id
00010007.
[ 2571.397034] xc2028 2-0061: Loading SCODE for type=MONO SCODE
HAS_IF_5320 (60008000), id 000f0007.
[ 2571.537025] xc2028 2-0061: i2c input error: rc = -32 (should be 2)
[ 2571.553024] xc2028 2-0061: Unable to read tuner registers.
[ 2572.553103] Trident TVMaster TM5600/TM6000/TM6010 USB2 board (Load
status: 0) [ 2572.561090] tm6000: open called (dev=video0)
[ 2573.081022] Original value=96
[ 2573.093037] tm6000: VIDIOC_QUERYCAP
[ 2573.149565] tm6000: open called (dev=video0)
On Fri, Apr 23, 2010 at 8:48 AM, Dmitri Belimov d.beli...@gmail.com
wrote:
Hi
Rework I2C for read word from connected devices, now it works well.
Add new functions for read/write blocks.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05 22:56:43
2010 -0400 +++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Fri Apr
23 04:23:03 2010 +1000 @@ -24,6 +24,7 @@
#include linux/kernel.h
#include linux/usb.h
#include linux/i2c.h
+#include linux/delay.h
#include compat.h
#include tm6000.h
@@ -45,11 +46,39 @@
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while
(0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
char addr, __u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT |
USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0,
buf, len);
+ int rc;
+ unsigned int tsleep;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -59,22 +88,30 @@
int rc;
u8 b[2];
- if ((dev-caps.has_zl10353) (dev-demod_addr 1 ==
addr) (reg % 2 == 0)) {
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ if ((dev-caps.has_zl10353) (dev-demod_addr 1 ==
addr)
+ (reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading
Re: [PATCH] tm6000 fix i2c
Hi
It's my error. This code good only for tm6010. Now I rework my patch.
With my best regards, Dmitry.
Am 23.04.2010 02:48, schrieb Dmitri Belimov:
Hi
Rework I2C for read word from connected devices, now it works well.
Add new functions for read/write blocks.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05
22:56:43 2010 -0400 +++
b/linux/drivers/staging/tm6000/tm6000-i2c.c Fri Apr 23
04:23:03 2010 +1000 @@ -24,6 +24,7 @@ #include linux/kernel.h
#include linux/usb.h
#include linux/i2c.h
+#include linux/delay.h
#include compat.h
#include tm6000.h
@@ -45,11 +46,39 @@
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while
(0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN,
TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned
char addr, __u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT |
USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0,
buf, len);
+ int rc;
+ unsigned int tsleep;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -59,22 +88,30 @@
int rc;
u8 b[2];
- if ((dev-caps.has_zl10353) (dev-demod_addr 1 ==
addr) (reg % 2 == 0)) {
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ if ((dev-caps.has_zl10353) (dev-demod_addr 1 ==
addr)
+(reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading from zl10353
*/
reg -= 1;
len += 1;
- rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg
8, 0, b, len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, b, len);
*buf = b[1];
} else {
- rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg
8, 0, buf, len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
}
+ /* release mutex */
return rc;
}
@@ -85,8 +122,106 @@
static int tm6000_i2c_recv_regs16(struct tm6000_core *dev,
unsigned char addr, __u16 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR | USB_RECIP_DEVICE,
- REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+ int rc;
+ unsigned char ureg;
+
+ if (!buf || len != 2)
+ return -1;
+
+ /* capture mutex */
+ ureg = reg 0xFF;
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | (reg 0xFF00), 0, ureg, 1);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ msleep(1400 / 1000);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
+
not all can this request (chip revision 0xf3 and 0xf4 can it)
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_read_sequence(struct tm6000_core *dev,
unsigned char addr,
+ __u16 reg, char *buf, int len)
+{
+ int rc;
+
+ if (!buf || len 1 || len 64)
+ return -1;
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN |
USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
ditto
+ /* release mutex */
+ return rc;
+}
+
+static int tm6000_i2c_write_sequence(struct tm6000_core *dev,
+
Re: [PATCH] tm6000 fix i2c
Hi
Rework last I2C patch.
Set correct limit for I2C packet.
Use different method for the tm5600/tm6000 and tm6010 to read word.
Try this patch.
diff -r 7c0b887911cf linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 05 22:56:43 2010 -0400
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c Mon Apr 26 04:15:56 2010 +1000
@@ -24,6 +24,7 @@
#include linux/kernel.h
#include linux/usb.h
#include linux/i2c.h
+#include linux/delay.h
#include compat.h
#include tm6000.h
@@ -45,11 +46,49 @@
printk(KERN_DEBUG %s at %s: fmt, \
dev-name, __FUNCTION__ , ##args); } while (0)
+static void tm6000_i2c_reset(struct tm6000_core *dev)
+{
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 0);
+ msleep(15);
+ tm6000_set_reg(dev, REQ_03_SET_GET_MCU_PIN, TM6000_GPIO_CLK, 1);
+ msleep(15);
+}
+
static int tm6000_i2c_send_regs(struct tm6000_core *dev, unsigned char addr,
__u8 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf, len);
+ int rc;
+ unsigned int tsleep;
+ unsigned int i2c_packet_limit = 16;
+
+ if (dev-dev_type == TM6010)
+ i2c_packet_limit = 64;
+
+ if (!buf)
+ return -1;
+
+ if (len 1 || len i2c_packet_limit){
+ printk(Incorrect lenght of i2c packet = %d, limit set to %d\n,
+ len, i2c_packet_limit);
+ return -1;
+ }
+
+ /* capture mutex */
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ /* Calculate delay time, 14000us for 64 bytes */
+ tsleep = ((len * 200) + 200 + 1000) / 1000;
+ msleep(tsleep);
+
+ /* release mutex */
+ return rc;
}
/* Generic read - doesn't work fine with 16bit registers */
@@ -58,23 +97,41 @@
{
int rc;
u8 b[2];
+ unsigned int i2c_packet_limit = 16;
- if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr) (reg %
2 == 0)) {
+ if (dev-dev_type == TM6010)
+ i2c_packet_limit = 64;
+
+ if (!buf)
+ return -1;
+
+ if (len 1 || len i2c_packet_limit){
+ printk(Incorrect lenght of i2c packet = %d, limit set to %d\n,
+ len, i2c_packet_limit);
+ return -1;
+ }
+
+ /* capture mutex */
+ if ((dev-caps.has_zl10353) (dev-demod_addr 1 == addr)
+(reg % 2 == 0)) {
/*
* Workaround an I2C bug when reading from zl10353
*/
reg -= 1;
len += 1;
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, b, len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, b, len);
*buf = b[1];
} else {
- rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_16_SET_GET_I2C_WR1_RDN, addr | reg 8, 0, buf,
len);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | reg 8, 0, buf, len);
}
+ /* release mutex */
return rc;
}
@@ -85,8 +142,137 @@
static int tm6000_i2c_recv_regs16(struct tm6000_core *dev, unsigned char addr,
__u16 reg, char *buf, int len)
{
- return tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
USB_RECIP_DEVICE,
- REQ_14_SET_GET_I2C_WR2_RDN, addr, reg, buf, len);
+ int rc;
+ unsigned char ureg;
+
+ if (!buf || len != 2)
+ return -1;
+
+ /* capture mutex */
+ if (dev-dev_type == TM6010){
+ ureg = reg 0xFF;
+ rc = tm6000_read_write_usb(dev, USB_DIR_OUT | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_16_SET_GET_I2C_WR1_RDN,
+ addr | (reg 0xFF00), 0, ureg, 1);
+
+ if (rc 0) {
+ /* release mutex */
+ return rc;
+ }
+
+ msleep(1400 / 1000);
+ rc = tm6000_read_write_usb(dev, USB_DIR_IN | USB_TYPE_VENDOR |
+ USB_RECIP_DEVICE, REQ_35_AFTEK_TUNER_READ,
+ reg, 0, buf, len);
+ }
+ else {
+ rc =
tuner XC5000 race condition??
Hi Sometimes tuner XC5000 crashed on boot. This PC is dual-core. It can be race condition or multi-core depend problem. Add mutex for solve this problem is correct? Crash boot dmesg [ 11.430108] Linux video capture interface: v2.00 [ 11.503411] saa7130/34: v4l2 driver version 0.2.15 loaded [ 11.503554] saa7134 :04:06.0: PCI INT A - GSI 20 (level, low) - IRQ 20 [ 11.503560] saa7133[0]: found at :04:06.0, rev: 209, irq: 20, latency: 64, mmio: 0xfbfff800 [ 11.503566] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7 [card=171,autodetected] [ 11.503582] saa7133[0]: board init: gpio is 20 [ 11.503585] saa7134_ts_init1 start [ 11.503588] saa7134_ts_init_hw start [ 11.503589] saa7134_ts_init_hw stop [ 11.503590] saa7134_ts_init1 stop [ 11.503591] IRQ 20/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 11.645017] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00 00 00 00 01 [ 11.645022] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645027] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645031] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645036] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645040] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645044] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645048] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645052] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645056] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645060] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645064] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645068] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645072] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645077] saa7133[0]: i2c eeprom e0: 72 41 00 00 ff ff ff ff ff ff ff ff ff ff ff ff [ 11.645081] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff ff ff ff ff [ 11.649016] saa7133[0]: i2c scan: found device @ 0x1e [???] [ 11.655017] saa7133[0]: i2c scan: found device @ 0x5a [remote control] [ 11.662017] saa7133[0]: i2c scan: found device @ 0xa0 [eeprom] [ 11.666017] saa7133[0]: i2c scan: found device @ 0xc2 [???] [ 11.696030] tuner 0-0061: chip found @ 0xc2 (saa7133[0]) [ 11.991744] xc5000 0-0061: creating new instance [ 11.994016] xc5000: Successfully identified at address 0x61 [ 11.994018] xc5000: Firmware has not been loaded previously [ 22.441412] input: i2c IR (BeholdTV) as /devices/virtual/irrcv/irrcv0/input5 [ 22.441530] irrcv0: i2c IR (BeholdTV) as /devices/virtual/irrcv/irrcv0 [ 22.441532] ir-kbd-i2c: i2c IR (BeholdTV) detected at i2c-0/0-002d/ir0 [saa7133[0]] [ 22.441869] saa7133[0]: registered device video0 [v4l2] [ 22.441882] saa7133[0]: registered device vbi0 [ 22.441895] saa7133[0]: registered device radio0 [ 22.495864] saa7134 ALSA driver for DMA sound loaded [ 22.495872] IRQ 20/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs [ 22.495886] saa7133[0]/alsa: saa7133[0] at 0xfbfff800 irq 20 registered as card -2 [ 22.634022] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... ^^^ [ 22.634026] saa7134 :04:06.0: firmware: requesting dvb-fe-xc5000-1.6.114.fw [ 22.638556] xc5000 I2C read failed (len=2) [ 22.669356] xc5000: I2C read failed [ 22.669904] xc5000: I2C read failed [ 22.669905] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... ^^^ [ 22.669908] saa7134 :04:06.0: firmware: requesting dvb-fe-xc5000-1.6.114.fw [ 22.669915] [ cut here ] [ 22.669920] WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0xd3/0xeb() [ 22.669921] Hardware name: System Product Name [ 22.669923] sysfs: cannot create duplicate filename '/devices/pci:00/:00:14.4/:04:06.0/firmware/:04:06.0' [ 22.669924] Modules linked in: dvb_core saa7134_alsa ir_kbd_i2c snd_hda_codec_atihdmi ipv6 snd_hda_codec_via snd_hda_intel snd_hda_codec snd_seq_dummy snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss snd_seq_midi xc5000 snd_rawmidi snd_seq_midi_event snd_seq tuner snd_timer saa7134 snd_seq_device ir_common v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core snd ir_core soundcore shpchp tveeprom lirc_mceusb pci_hotplug snd_page_alloc i2c_piix4 fglrx(P) k10temp i2c_core lirc_dev iptable_filter lp ip_tables psmouse parport processor serio_raw x_tables
Re: tuner XC5000 race condition??
On Mon, 2010-04-26 at 10:44 +1000, Dmitri Belimov wrote: Hi Sometimes tuner XC5000 crashed on boot. This PC is dual-core. It can be race condition or multi-core depend problem. Add mutex for solve this problem is correct? Dmitri, This problem may be related to the firmware loading race described here: https://bugzilla.kernel.org/show_bug.cgi?id=15294 I still have not fixed that bug yet. But for your problem, perhaps you can try: echo 120 /sys/class/firmware/timeout as root in the initialization scripts to lengthen the firmware loading timeout to 120 seconds. Maybe that will work around the crash. I'll try and look at what is going on in your crash dumps, if I have time. Regards, Andy -- 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
