summaryrefslogtreecommitdiffstats
path: root/drivers/media/video/ivtv/ivtv-irq.c
Commit message (Collapse)AuthorAgeFilesLines
* [media] rename most media/video pci drivers to media/pciMauro Carvalho Chehab2012-08-151-1038/+0
| | | | | | | | Rename all PCI drivers with their own directory under drivers/media/video into drivers/media/pci and update the building system. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] ivtv: remove open_id/id from the filehandle codeHans Verkuil2012-01-161-2/+2
| | | | | | | | | Instead of messing around with id's it's much easier to just compare against a filehandle pointer. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Andy Walls <awalls@md.metrocast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] ivtv: Fix corrective action taken upon DMA ERR interrupt to avoid hangMichael2011-03-021-7/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After upgrading the kernel from stock Ubuntu 7.10 to 10.04, with no hardware changes, I started getting the dreaded DMA TIMEOUT errors, followed by inability to encode until the machine was rebooted. I came across a post from Andy in March (http://www.gossamer-threads.com/lists/ivtv/users/40943#40943) where he speculates that perhaps the corrective actions being taken after a DMA ERROR are not sufficient to recover the situation. After some testing I suspect that this is indeed the case, and that in fact the corrective action may be what hangs the card's DMA engine, rather than the original error. Specifically these DMA ERROR IRQs seem to present with two different values in the IVTV_REG_DMASTATUS register: 0x11 and 0x13. The current corrective action is to clear that status register back to 0x01 or 0x03, and then issue the next DMA request. In the case of a 0x13 this seems to result in a minor glitch in the encoded stream due to the failed transfer that was not retried, but otherwise things continue OK. In the case of a 0x11 the card's DMA write engine is never heard from again, and a DMA TIMEOUT follows shortly after. 0x11 is the killer. I suspect that the two cases need to be handled differently. The difference is in bit 1 (0x02), which is set when the error is about to be successfully recovered, and clear when things are about to go bad. Bit 1 of DMASTATUS is described differently in different places either as a positive "write finished", or an inverted "write busy". If we take the first definition, then when an error arises with state 0x11, it means that the write did not complete. It makes sense to start a new transfer, as in the current code. But if we take the second definition, then 0x11 means "an error but the write engine is still busy". Trying to feed it a new transfer in this situation might not be a good idea. As an experiment, I added code to ignore the DMA ERROR IRQ if DMASTATUS is 0x11. I.e., don't start a new transfer, don't clear our flags, etc. The hope was that the card would complete the transfer and issue a ENC DMA COMPLETE, either successfully or with an error condition there. However the card still hung. The only remaining corrective action being taken with a 0x11 status was then the write back to the status register to clear the error, i.e. DMASTATUS = DMASTATUS & ~3. This would have the effect of clearing the error bit 4, while leaving the lower bits indicating DMA write busy. Strangely enough, removing this write to the status register solved the problem! If the DMA ERROR IRQ with DMASTATUS=0x11 is completely ignored, with no corrective action at all, then the card will complete the transfer and issue a new IRQ. If the status register is written to when it has the value 0x11, then the DMA engine hangs. Perhaps it's illegal to write to DMASTATUS while the read or write busy bit is set? At any rate, it appears that the current corrective action is indeed making things worse rather than better. I put together a patch that modifies ivtv_irq_dma_err to do the following: - Don't write back to IVTV_REG_DMASTATUS. - If write-busy is asserted, leave the card alone. Just extend the timeout slightly. - If write-busy is de-asserted, retry the current transfer. This has completely fixed my DMA TIMEOUT woes. DMA ERR events still occur, but now they seem to be correctly handled. 0x11 events no longer hang the card, and 0x13 events no longer result in a glitch in the stream, as the failed transfer is retried. I'm happy. I've inlined the patch below in case it is of interest. As described above, I have a theory about why it works (based on a different interpretation of bit 1 of DMASTATUS), but I can't guarantee that my theory is correct. There may be another explanation, or it may be a fluke. Maybe ignoring that IRQ entirely would be equally effective? Maybe the status register read/writeback sequence is race condition if the card changes it in the mean time? Also as I am using a PVR-150 only, I have not been able to test it on other cards, which may be especially relevant for 350s that support concurrent decoding. Hopefully the patch does not break the DMA READ path. Mike [awalls@md.metrocast.net: Modified patch to add a verbose comment, make minor brace reformats, and clear the error flags in the IVTV_REG_DMASTATUS iff both read and write DMA were not in progress. Mike's conjecture about a race condition with the writeback is correct; it can confuse the DMA engine.] [Comment and analysis from the ML post by Michael <mike@rsy.com>] Signed-off-by: Andy Walls <awalls@md.metrocast.net> Cc: stable@kernel.org Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* ivtv: use kthread_worker instead of workqueueTejun Heo2010-06-291-12/+3
| | | | | | | | | | | | | Upcoming workqueue updates will no longer guarantee fixed workqueue to worker kthread association, so giving RT priority to the irq worker won't work. Use kthread_worker which guarantees specific kthread association instead. This also makes setting the priority cleaner. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Andy Walls <awalls@md.metrocast.net> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: ivtv-devel@ivtvdriver.org Cc: linux-media@vger.kernel.org
* V4L/DVB: ivtv: support the new events APIHans Verkuil2010-05-191-2/+13
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB: ivtv, ivtvfb: Use a define for the output line and field register ↵Andy Walls2010-05-181-3/+5
| | | | | | | | | | address Get rid of the magic number 0x28c0 used in several places in the ivtv and ivtvfb driver and define the register address to a meaningful name. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB: ivtv: Fix ivtv_api_get_data() to avoid unneeded IO during IRQ handlingAndy Walls2010-02-261-4/+5
| | | | | | | | | | ivtv_api_get_data() was performing more PCI MMIO than needed, resulting often in it accounting for more than half the total time spent in ivtv_irq_handler(). Now it only reads at most 7 of the 16 mailbox data words over the PCI bus, and in some instances only 2 or 3 data words as needed. Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB: ivtv: Fix race condition for queued udma transfersIan Armstrong2010-02-261-2/+3
| | | | | | | | | | | | | | | | | | | There are several DMA related interrupts which wake up the dma_waitq. The udma routines use this queue while they wait for their transfer to complete. When woken, the udma routine will check the IVTV_F_I_UDMA_PENDING & IVTV_F_I_UDMA flags to see if the transfer is still queued or has finished. However, a small window exists between the IVTV_F_I_UDMA_PENDING flag being cleared and the IVTV_F_I_UDMA flag being set. Given that the completion of an unrelated DMA transfer may wake up the udma routine, it's possible for this check to fail and the udma routine will start unmapping pages when the transfer has only just started. The result of this is unpredictable. This fix simply delays the clearing of the IVTV_F_I_UDMA_PENDING flag until after IVTV_F_I_UDMA has been set. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Andy Walls <awalls@radix.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11674): ivtv: fix incorrect bit testsHans Verkuil2009-05-091-1/+1
| | | | | | | | Found the coccinelle tool. Thanks-to: Julia Lawall <julia@diku.dk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (10488): ivtv: cleanup naming conventionsHans Verkuil2009-03-301-2/+2
| | | | | | | Use consistent naming for pci_dev, v4l2_device and video_device. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (9166): ivtv - Fix potential race condition in yuv handlerIan Armstrong2008-10-131-3/+6
| | | | | | | | | | | | | Modified yuv register update handling to remove a potential race condition which could occur with the first video frame. Also removed a forced yuv position update, since changing the source video dimensions or interlace settings doesn't affect the frame already being displayed. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (8648): ivtv: improve CC supportHans Verkuil2008-09-031-21/+8
| | | | | | | | | | | | | | - change the work-queue to a single threaded high prio workqueue - use DMA instead of PIO for the sliced VBI data. - remove some incorrect tests - increase the internal VBI capture queue size for sliced VBI packets - ignore duplicate VBI lines With these changes it should finally be possible to get reliable closed captions. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (7963): ivtv: trivial annotationsAl Viro2008-06-051-4/+4
| | | | | Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (7761): ivtv: increase the DMA timeout from 100 to 300 msHans Verkuil2008-04-291-2/+2
| | | | | | | | When there is a lot of DMA traffic this timeout might sometimes be too low. Increase it to be on the safe side. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (7245): ivtv: start timer for each DMA transferHans Verkuil2008-04-241-12/+13
| | | | | | | | The DMA timeout timer was started once for each set of DMA transfers, but it should be started for each single DMA transfer. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6776): ivtv: Some general fixesRichard Knutsson2008-01-251-2/+2
| | | | | | | | | Fix "warning: Using plain integer as NULL pointer". Convert 'x < y ? x : y' to use min() instead. Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6742): ivtv: fix incorrect debug messageHans Verkuil2008-01-251-1/+1
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6717): ivtv: Initial merge of video48 yuv handling into the ↵Ian Armstrong2008-01-251-3/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IVTV_IOC_DMA_FRAME framework Previously, all yuv data written to /dev/video48 had only basic support with no double buffering to avoid display tearing. With this patch, yuv frames written to video48 are now handled by the existing IVTV_IOC_DMA_FRAME framework. As such, the frames are hardware buffered to avoid tearing, and honour scaling mode & field order options. Unlike the proprietary IVTV_IOC_DMA_FRAME ioctl, all parameters are controlled by the V4L2 API. Due to mpeg & yuv output restrictions being different, their V4L2 output controls have been separated. To control the yuv output, the V4L2 calls must be done via video48. If the ivtvfb module is loaded, there will be one side effect to this merge. The yuv output window will be constrained to the visible framebuffer area. In the event that a virtual framebuffer size is being used, the limit to the output size will be the virtual dimensions, but only the portion that falls within the currently visible area of the framebuffer will be shown. Like the IVTV_IOC_DMA_FRAME ioctl, the supplied frames must be padded to 720 pixels wide. However the height must only be padded up the nearest multiple of 32. This would mean an image of 102 lines must be padded to 128. As long as the true source image size is given, the padding will not be visible in the final output. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6716): ivtv: yuv interlace mode changeIan Armstrong2008-01-251-8/+11
| | | | | | | | | | | | | | | | | Interlace mode selection code moved into the frame setup phase, so it's now run before the frame is loaded into a hardware buffer. Given that it can affect how a new frame is displayed, it was a bit stupid running it after the frame was already visible. A few stray interlace related variables which were linked to individual frames have now been moved into the yuv_frame_info struct. This means that all variables linked to a specific frame are in the same place & not scattered. Minor code reformatting in areas touched by the above changes. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6714): ivtv: yuv frame parameter fixIan Armstrong2008-01-251-1/+1
| | | | | | | | | | Inadvertently missed a line when converting code to new hardware buffering method. In some circumstances, this would lead to a frame being displayed using parameters belonging to another frame. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6713): ivtv: ivtv_yuv_prep_frame breakup and yuv hardware buffer ↵Ian Armstrong2008-01-251-15/+16
| | | | | | | | | | | | | | | | changes ivtv_yuv_prep_frame is split in smaller code blocks. Modified yuv buffer handling on the PVR350 itself. We now cycle through all 8 hardware buffers. With this patch in place, driver behaviour should remain unchanged from the existing release. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6712): ivtv: ivtv yuv stream handling changeIan Armstrong2008-01-251-6/+19
| | | | | | | | | | | | | | | | | | | | | | Currently the yuv output stream buffer is divided into blocks whose size depend on the broadcast standard selected during the driver init phase. However, the standard can be changed after the init phase. This effectively breaks the yuv output stream handler, since it relies on the different yuv planes being block aligned. This patch changes the setup, so that the block size is always the same. The decoder dma function has been modified to cope with the fact that the second yuv plane may no longer be block aligned. The start of the yuv frame must still be at the beginning of a block, so the stream write function has also been modified to ensure this is always true. Also, the stream write function will now initiate a yuv dma transfer as soon as a full frame is ready. It will not wait until the current write request has completed, or the stream buffer becomes full. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6313): ivtv: Replace list_for_each+list_entry with list_for_each_entryTrent Piepho2007-10-101-20/+6
| | | | | | | | | | | | | | Also fixed a few cases of cut&paste errors where 'buf' would be set to the first entry in the list prior to be used as the loop iterator. In one case the value of buf was used before it was changed, but the rest were unnecessary. There was one list_for_each+list_entry loop that wasn't changed, since it depending on the loop iterator being left as NULL if the list was empty. Signed-off-by: Trent Piepho <xyzzy@speakeasy.org> CC: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6116): ivtv: VBI cleanups and fixesHans Verkuil2007-10-091-3/+7
| | | | | | | | | | | | | | Besides some VBI cleanups this patch also fixes a subtle problem with the VBI re-insertion stream where the PIO work handler wasn't called quickly enough, resulting in occasional corrupt data. Furthermore the CC output didn't disable CC correctly and at the right time, causing duplicates to be sent. An saa7127 fix for VPS output was also added: the wrong data was sent. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6094): ivtv: more ivtv-driver.h cleanupsHans Verkuil2007-10-091-5/+5
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6093): ivtv: reorganized and cleanup ivtv structHans Verkuil2007-10-091-6/+6
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6091): ivtv: header cleanupHans Verkuil2007-10-091-3/+0
| | | | | | | | | | - add guards - remove unused header includes - move card-specific stuff from ivtv-driver.h to ivtv-cards.h - move YUV-specific stuff from ivtv-driver.h to ivtv-yuv.h Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6050): ivtv: retry/timer improvementsHans Verkuil2007-10-091-0/+4
| | | | | | | | - Give up frame after three retries. - When the last capture/decode ends, make sure to delete the dma_timer. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6049): ivtv: fix VBI reinsertion decodingHans Verkuil2007-10-091-3/+2
| | | | | | | | | | | | | - Invalid VBI packets should result in an empty VBI frame, not in an zero-sized frame that causes the reader to incorrectly return a 0 (EOF) value. - PIO completion should not reset the sg_pending_size field. - The DMA offset detection code should be ignored for PIO transfers: it somehow messes up the data on the card and is not needed anyway for PIO. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6047): ivtv: Fix scatter/gather DMA timeoutsHans Verkuil2007-10-091-93/+141
| | | | | | | | | | | | | | | | | | It turns out that the cx23415/6 DMA engine cannot do scatter/gather DMA reliably. Every so often depending on the phase of the moon and your hardware configuration the cx2341x DMA engine simply chokes on it and you have to reboot to get it working again. This change replaced the scatter/gather DMA by single transfers at a time, where the driver is now responsible for DMA-ing each buffer. UDMA is still done using scatter/gather DMA, that will be fixed soon. Many thanks to Mark Bryars <mark.bryars@etvinteractive.com> for discovering the link between scatter/gather and the DMA timeouts. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6046): ivtv: always steal full frames if out of buffers.Hans Verkuil2007-10-091-1/+4
| | | | | | | | | | | | When there are no more free buffers, then buffers are stolen from the predma queue. Buffers should be stolen from the head of that queue (which is where the most recently added buffers are) and all buffers belonging to a frame should be stolen. Otherwise 'half-frames' would remain in the queue, which leads to ugly playback and complete sync failure for YUV buffers. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (6043): ivtv: fix incorrect round-robin implementationHans Verkuil2007-10-091-2/+4
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5973): ivtv: attach yuv field order to each frameIan Armstrong2007-10-091-8/+14
| | | | | | | | | | | | | | | | | In the current driver, the field order is global. As soon as it's changed it takes immediate effect. This is a problem when the video changes order mid stream. Although it mostly works okay, the video may judder / flicker. This patch attaches the field order to the frame, so that any buffered frames will not be displayed until the correct field. In the event that the field order is changed mid stream, the driver will ensure that the previous frame is displayed for a minimum of 3 fields. These are the two original fields the frame should have occupied, plus the one extra since the new frame still has to wait for the correct field. Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5866): ivtv: fix DMA timeout when capturing VBI + another streamHans Verkuil2007-07-201-2/+5
| | | | | | | | | | | | The VBI DMA is handled in a special way and is marked with a bit. However, that bit was set at the wrong time and could be cleared by mistake if a PCM (or other) DMA request would arrive before the VBI DMA was completed. So on completion of the VBI DMA the driver no longer knew that that DMA transfer was for VBI data. And this in turn caused havoc with the card's DMA engine. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5865): Remove usage of HZ on ivtv driver, replacing by msecs_to_jiffiesMauro Carvalho Chehab2007-07-201-2/+2
| | | | | Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5844): ivtv: add high volume debugging flagHans Verkuil2007-07-181-18/+18
| | | | | | | | Add support for high volume debug messages, allowing them to be turned on selectively. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5675): Move big PIO accesses from the interrupt handler to a ↵Hans Verkuil2007-06-081-67/+137
| | | | | | | | | | | | | workhandler Sliced VBI transfers use PIO instead of DMA. This was done inside the interrupt handler, but since PIO accesses are very slow this meant that a lot of time was spent inside the interrupt handler. All PIO copies are now moved to a workqueue. This should fix various issues with missing time ticks and remote key hits. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5404): Merges VBI & YUV handling into a single work queue.Hans Verkuil2007-04-271-3/+23
| | | | | | Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
* V4L/DVB (5345): ivtv driver for Conexant cx23416/cx23415 MPEG encoder/decoderHans Verkuil2007-04-271-0/+818
It took three core maintainers, over four years of work, eight new i2c modules, eleven new V4L2 ioctls, three new DVB video ioctls, a Sliced VBI API, a new MPEG encoder API, an enhanced DVB video MPEG decoding API, major YUV/OSD contributions from Ian and John, web/wiki/svn/trac support from Axel Thimm, (hardware) support from Hauppauge, support and assistance from the v4l-dvb people and the many, many users of ivtv to finally make it possible to merge this driver into the kernel. Thank you all! Signed-off-by: Kevin Thayer <nufan_wfk@yahoo.com> Signed-off-by: Chris Kennedy <c@groovy.org> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: John P Harvey <john.p.harvey@btinternet.com> Signed-off-by: Ian Armstrong <ian@iarmst.demon.co.uk> Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
OpenPOWER on IntegriCloud