- 03 8月, 2010 1 次提交
-
-
由 Jarod Wilson 提交于
This adds support for the KWorld PlusTV 340U and KWorld UB345-Q ATSC sticks, which are really the same device. The sticks have an eMPIA em2870 usb bridge chipset, an LG Electronics LGDT3304 ATSC/QAM demodulator and an NXP TDA18271HD tuner -- early versions of the 340U have a a TDA18271HD/C1, later models and the UB435-Q have a C2. The stick has been tested succesfully with both VSB_8 and QAM_256 signals. Its using lgdt3304 support added to the lgdt3305 driver by a prior patch, rather than the current lgdt3304 driver, as its severely lacking in functionality by comparison (see said patch for details). Signed-off-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMichael Krufky <mkrufky@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 5月, 2010 2 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Instead of using the ugly keymap sequences, use the new rc-*.ko keymap files. For now, it is still needed to have one keymap loaded, for the RC code to work. Later patches will remove this depenency. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Replaces most of the occurences of IR keytables on V4L drivers by a macro that evaluates to provide the name of the exported symbol. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 18 5月, 2010 2 次提交
-
-
由 Devin Heitmueller 提交于
Add support for design which has an em2863/tvp5150 and uses the standard empia USB ID. In Sander's case, it was branded as an "Eminent model EM3705" Thanks to Sander Van Ginkel for testing and help debugging the support. [mchehab@redhat.com: move it to a vague card number slot (card=29)] Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Antonio Larrosa 提交于
This patch adapts the changes submitted by Dainius Ridzevicius to the linux-media mailing list on 8/14/09, to the current sources in order to make the Kworld VS-DVB-T 323UR usb device work. I also removed the "not validated" flag since I own the device and validated that it works fine after the patch is applied. Thanks to Devin Heitmueller for his guidance with the code. Signed-off-by: NAntonio Larrosa <larrosa@kde.org> Acked-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 30 3月, 2010 1 次提交
-
-
由 Tejun Heo 提交于
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: NTejun Heo <tj@kernel.org> Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
-
- 27 2月, 2010 5 次提交
-
-
由 Catimimi 提交于
I succeeded in running Cinergy Hybrid T USB XS FR in both modes. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Franklin Meng 提交于
Signed-off-by: NFranklin Meng <fmeng2002@yahoo.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
Adds digital and analogue tv support for Dikom DK300 hybrid usb card. Not working: remote controller To be done: it seems that with the proposed patch the digital demodulator remains activated if the tuner is switched from digital to analogue mode. Workaround is to unplug and replug the device when switching from digital to analogue. If someone can explain how to verify the gpio settings using the usbsnoop, the above issue perhaps can be resolved. Signed-off-by: NAndrea Amorosi <Andrea.Amorosi76@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
As pointed by Magnus Alm <magnus.alm@gmail.com>, commit 99dbd128bb applied a hunk at the wrong place. This patch moves the code to the right place. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Magnus Alm 提交于
fix Video/Sound support "Leadtek winfast tv usbii deluxe". Now, it is working Stereo, IR, Radio, TV, Svideo and Composite. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 16 12月, 2009 3 次提交
-
-
由 Mauro Carvalho Chehab 提交于
This device uses an i2c chip to retrieve the keycode from a RC5 remote. Instead of just getting 6 bits, improve the routine to get 11 bits. This means that the complete RC5 table for Hauppauge Grey IR can be used with this device. Unfortunately, it seems that this IR receiver is not capable of getting the full 14 (or 13 bits) from the RC5 protocol. At lest now, with the new code, it is possible to replace this IR table by another RC5 table. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Laurent Pinchart 提交于
Fix all device drivers to use the video_drvdata function instead of maintaining a local list of minor to private data mappings. Call video_set_drvdata to register the driver private pointer when not already done. Where applicable, the local list of mappings is completely removed when it becomes unused. [mchehab.redhat.com: removed tm6000 changes as tm6000 is not ready yet for submission even on staging] Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Laurent Pinchart 提交于
Fix all device drivers to use the new video_device_node_name function. This also strips kernel log messages from the "/dev/" prefix, has the device node location is a userspace policy decision unknown to the kernel. Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 06 12月, 2009 8 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Modifies the IR table for HVR-950 to use the newer Hauppauge RC5 table, and adds the RC5 address to the functions that get the scancode for this device. It is easy to add support for all other RC5 IR's on em2880 boards, but the scancode table needs to be re-generated. So, keep using the old 7bits tables while we don't have all tables converted. Also, the 7bits tables are still used on other drivers, so this small patch needs to be ported to all drivers. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Adds support to VC211A em2800 card. As this board doesn't have eeprom, and uses a common set of i2c address, it has no way to add any autodetection for it. The patch were tested by me and by Raimundo on his board. Thanks to those tests, several bugs related to em2800 support were corrected. for producing the usbsnoop dump, used to get the gpio's and allowing me to remotelly access his machine and to the needed tests. Thanks-to: Raimundo Eduvirgnes de Oliveira <eduvirgens@yahoo.com.br> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Laurent Pinchart 提交于
Upcoming I2C v4l2_subdev drivers need a way to control the subdevice power state from the core. This use case is already partially covered by the tuner s_standby operation, but no way to explicitly come back from the standby state is available. Rename the tuner s_standby operation to core s_power, and fix tuner drivers accordingly. The tuner core will call s_power(0) instead of s_standby(). No explicit call to s_power(1) is required for tuners as they are supposed to wake up from standby automatically. [mchehab@redhat.com: CodingStyle fix] Signed-off-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Jean Delvare 提交于
Recent fixes to the em28xx and saa7134 drivers have been overzealous. While the ir-kbd-i2c platform data indeed needs to be persistent, the struct i2c_board_info doesn't, as it is only used by i2c_new_device(). So revert a part of the original fixes, to save some memory. Signed-off-by: NJean Delvare <khali@linux-fr.org> Acked-by: NJarod Wilson <jarod@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
The board support has been validated by the user, so get rid of the warning that shows up on board load. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Uroš Vampl 提交于
Make analog audio, dvb and the remote work on a Terratec Cinergy Hybrid XS (em2882). Note by djh: Thanks go out fo Andrej Suligoi for his contribution in providing and testing pretty much the exact same patch as provided by Uros. Between the two of them, they got all the core functionality working for the device. Cc: Andrej Suligoi <suligoi@gmail.com> Signed-off-by: NUroš Vampl <mobile.leecher@gmail.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Seems that the reference design used for the KWorld 2800d switched from the em2860 to em2862, so we need to add the new USB id (and the i2c hash remains so all we need is the default em2862 id. Thanks to Ian Young for reporting the issue and testing the fix. Cc: Ian Young <ian@duffrecords.com> Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 27 11月, 2009 1 次提交
-
-
由 Antti Palosaari 提交于
Set device GPIOs only once. There is no need for .dvb_gpio to select between analog and digital because device is digital only. Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 9月, 2009 4 次提交
-
-
由 Hans Verkuil 提交于
Rewrite v4l2_i2c_new_subdev as a simplified version of v4l2_i2c_new_subdev_cfg and remove v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This simplifies this API substantially. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Antti Palosaari 提交于
Support for Reddo DVB-C USB TV Box device. Remote is not working yet. Thanks to Benjamin Larsson <banan@ludd.ltu.se> Cc: Benjamin Larsson <banan@ludd.ltu.se> Signed-off-by: NAntti Palosaari <crope@iki.fi> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Add support for raw VBI capture for the em28xx bridge, currently only for NTSC. Support for PAL capture to follow shortly (including the removal of numerous hard-coded NTSC-specific sizes for capture buffers, etc). Note that the code currently changes the default current norm from PAL to NTSC (so that zvbi-ntsc-cc works properly). The default norm really should be moved into a board-level parameter. This work was sponsored by EyeMagnet Limited. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Properly document the video input control register, in preparation for the addition of VBI support. Note this patch makes no functional changes. Signed-off-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 15 9月, 2009 1 次提交
-
-
Added Kworld DVD Maker 2 Thanks to C Western <l@c-m-w.me.uk> for reporting this board. Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 13 9月, 2009 2 次提交
-
-
由 Mauro Carvalho Chehab 提交于
There are some extra parenthesis at the clauses, and some switch() tests for boards that don't have i2c ir. Remove those extra code. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Currently, the logic to load ir i2c ancillary module is broken. It is associated to Hauppauge devices with IR flag on their eeprom, no matter if the device uses i2c or em28xx direct IR support. That's wrong. Instead, add a flag to the boards that use i2c IR chips and load the module only for those devices and if ir is not disabled. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 12 9月, 2009 6 次提交
-
-
由 Mauro Carvalho Chehab 提交于
ir-kbd-i2c's ir_probe() function can be called much later (i.e. at ir-kbd-i2c module load), than the lifetime of a struct IR_i2c_init_data allocated off of the stack in cx18_i2c_new_ir() at registration time. Make sure we pass a pointer to a persistent IR_i2c_init_data object at i2c registration time. Thanks to Brian Rogers, Dustin Mitchell, Andy Walls and Jean Delvare to rise this question. Before this patch, if ir-kbd-i2c were probed after em28xx, trash data were used. After the patch, no matter what order, it is properly reported as tested by me: input: i2c IR (i2c IR (EM2840 Hauppaug as /class/input/input10 ir-kbd-i2c: i2c IR (i2c IR (EM2840 Hauppaug detected at i2c-4/4-0030/ir0 [em28xx #0] Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Currently, V4L uses a scancode table whose index is the scancode and the value is the keycode. While this works, it has some drawbacks: 1) It requires that the scancode to be at the range 00-7f; 2) keycodes should be masked on 7 bits in order for it to work; 3) due to the 7 bits approach, sometimes it is not possible to replace the default keyboard to another one with a different encoding rule; 4) it is different than what is done with dvb-usb approach; 5) it requires a typedef for it to work. This is not a recommended Linux CodingStyle. This patch is part of a larger series of IR changes. It basically replaces the IR_KEYTAB_TYPE tables by a structured table: struct ir_scancode { u16 scancode; u32 keycode; }; This is very close to what dvb does. So, a further integration with DVB code will be easy. While we've changed the tables, for now, the IR keycode handling is still based on the old approach. The only notable effect is the redution of about 35% of the ir-common module size: text data bss dec hex filename 6721 29208 4 35933 8c5d old/ir-common.ko 5756 18040 4 23800 5cf8 new/ir-common.ko In thesis, we could be using above u8 for scancode, reducing even more the size of the module, but defining it as u16 is more convenient, since, on dvb, each scancode has up to 16 bits, and we currently have a few troubles with rc5, as their scancodes are defined with more than 8 bits. This patch itself shouldn't be doing any functional changes. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
[mchehab@redhat.com: Fix a few wrong IR keymaps] Signed-off-by: NShine Liu <shinel@foxmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Devin Heitmueller 提交于
Add support for the remote control that comes with the Cinergy Hybrid T USB XS Thanks to Jelle de Jong for providing sample hardware to test with. Cc: Jelle de Jong <jelledejong@powercraft.nl> Signed-off-by: NDevin Heitmueller <dheitmueller@linuxtv.org> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
Fixed eeprom hash table Signed-off-by: NDouglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Zhenyu Wang 提交于
em28xx: Add support for Gadmei UTV330+ Signed-off-by: NZhenyu Wang <zhen78@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 31 8月, 2009 2 次提交
-
-
由 Shine Liu 提交于
We should call em28xx_ir_init(dev) only when disable_ir is true. Signed-off-by: NShine Liu <shinel@foxmail.com> Reviewed-by: NDevin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
[mchehab@redhat.com: fix merge conflict and a few CodingStyle issues] Signed-off-by: NSteve Gotthardt <gotthardt@gmail.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 14 8月, 2009 2 次提交
-
-
由 Mauro Carvalho Chehab 提交于
Register 0x13 seems to be a sort of image control, maybe gamma, white level or black level. Lower values produce better images, while higher values increases the contrast and shifts colors to green. 0xff produces a black image. This register is not Silvercrest-specific, so its code should be moved to a better place. If this register is left alone, a random value can be found at the register, producing weird results. While here, let's remove register 0x0d, as it had no noticed effect at the image. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mauro Carvalho Chehab 提交于
Silvercrest mt9v011 sensor produces a 640x480 image. However, previously, the code were getting only half of the lines and merging two consecutive frames to "produce" a 640x480 image. With the addition of progressive mode, now em28xx is working with a full image. However, when the number of lines is bigger than 240, the beginning of some odd lines are filled with blank. After lots of testing, and physically checking the device for a Xtal, it was noticed experimentally that mt9v011 is using em28xx XCLK as its clock. Due to that, changing XCLK value changes the maximum speed of the stream. At the tests, it were possible to produce up to 32 fps, using a 30 MHz XCLK. However, at that rate, the artifacts happen even at 320x240. Lower values of XCLK produces artifacts only at 640x480. At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is possible to see an invalid sucession of artifacts with this pattern: .xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx .xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (where the dots represent the blanked pixels) So, it seems that a waveform in the format of a ramp is interferring at the image. The cause of this interference is currently unknown. Some possibilities are: - electrical interference (maybe this device is broken?); - some issue at mt9v011 programming; - some bug at em28xx chip. So, for now, let's be conservative and use a value of XCLK that we know for sure that it won't cause artifacts. As I'm waiting for more of such devices with different em28xx chipset revisions, I'll have the opportunity to double check the issue with other pieces of hardware. Later patches can vary XCLK depending on the vertical resolutions, if a proper fix is not discovered. Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-