aboutsummaryrefslogtreecommitdiff
path: root/Documentation/video4linux/bttv/Insmod-options
AgeCommit message (Collapse)Author
2007-02-17Various typo fixes.Robert P. J. Day
Correct mis-spellings of "algorithm", "appear", "consistent" and (shame, shame) "kernel". Signed-off-by: Robert P. J. Day <rpjday@mindspring.com> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-09-26V4L/DVB (4609): Improved i2c performance on software bitbang algoritmMauro Carvalho Chehab
Software I2C were using a very conservative value of udelay=16, meaning about 20Kbps. According with Philips I2C datasheet, the i2c should answer well for times at the order of 4.7 us. So, using udelay=5 should work for all devices. After this patch, the speed should be close to 66,67 Kbps, with the current kernel software bitbang, with 30/60 duty cycle. Anyway, added a new parameter (i2c_udelay) that would allow using conservative values, if eventually a hardware doesn't support the datasheet values. Thanks to Jean Delvare <khali@linux-fr.org> for pointing this improvement. Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>
2005-08-04[PATCH] v4l: oopsfix for BTTV on badly behaved PCI chipsetsMauro Carvalho Chehab
no_overlay bttv parameter implemented to fix OOPS on some PCI chipsets (like some VIA) with these behaviors: 1) If pci_quicks does identify the chip as having troubles to handle PCI2PCI transfers, no_overlay defaults to 1. The user may force it to 0, to reenable (not recommended). 2) For newer chipsets not blacklisted, no_overlay=1 is provided as a workaround until PCI chipset included on /drivers/pci/quirks.c Thanks to Bodo Eggert <7eggert@gmx.de> Signed-off-by: Michael Krufky <mkrufky@m1k.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@brturbo.com.br> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-04-16Linux-2.6.12-rc2Linus Torvalds
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!