aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/video/em28xx/em28xx-cards.c
Commit message (Collapse)AuthorAge
* V4L/DVB (12540): v4l: simplify v4l2_i2c_new_subdev and friendsHans Verkuil2009-09-18
| | | | | | | | | | 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: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12951): em28xx: add Reddo DVB-C USB TV BoxAntti Palosaari2009-09-18
| | | | | | | | | 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: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12742): em28xx: add raw VBI support for NTSCDevin Heitmueller2009-09-18
| | | | | | | | | | | | | | | 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: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12740): em28xx: better describe vinctrl registersDevin Heitmueller2009-09-18
| | | | | | | | 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: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12720): em28xx-cards: Add vendor/product id for Kworld DVD Maker 2Douglas Schilling Landgraf2009-09-14
| | | | | | | | Added Kworld DVD Maker 2 Thanks to C Western <l@c-m-w.me.uk> for reporting this board. Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12713): em28xx: Cleanups at ir_i2c handlerMauro Carvalho Chehab2009-09-12
| | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12712): em28xx: properly load ir-kbd-i2c when neededMauro Carvalho Chehab2009-09-12
| | | | | | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12698): em28xx: ir-kbd-i2c init data needs a persistent objectMauro Carvalho Chehab2009-09-12
| | | | | | | | | | | | | | | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12595): common/ir: use a struct for keycode tablesMauro Carvalho Chehab2009-09-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12591): em28xx: Add entry for GADMEI UTV330+ and related IR keymapMauro Carvalho Chehab2009-09-12
| | | | | | [mchehab@redhat.com: Fix a few wrong IR keymaps] Signed-off-by: Shine Liu <shinel@foxmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12444): em28xx: add support for Terratec Cinergy Hybrid T USB XS ↵Devin Heitmueller2009-09-12
| | | | | | | | | | | | remote control 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: Devin Heitmueller <dheitmueller@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12434): em28xx: fix empire auto-detectDouglas Schilling Landgraf2009-09-12
| | | | | | | Fixed eeprom hash table Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12190): em28xx: Add support for Gadmei UTV330+Zhenyu Wang2009-09-12
| | | | | | | em28xx: Add support for Gadmei UTV330+ Signed-off-by: Zhenyu Wang <zhen78@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12495): em28xx: Don't call em28xx_ir_init when disable_ir is trueShine Liu2009-08-31
| | | | | | | | We should call em28xx_ir_init(dev) only when disable_ir is true. Signed-off-by: Shine Liu <shinel@foxmail.com> Reviewed-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12449): adds webcam for Micron device MT9M111 0x143A to em28xxMauro Carvalho Chehab2009-08-31
| | | | | | [mchehab@redhat.com: fix merge conflict and a few CodingStyle issues] Signed-off-by: Steve Gotthardt <gotthardt@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12405): em28xx-cards: move register 0x13 setting to the proper placeMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12411): em28xx: Fix artifacts with Silvercrest webcamMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12410): em28xx: Move the non-board dependent part to be outside ↵Mauro Carvalho Chehab2009-08-13
| | | | | | | | | | | | | em28xx_pre_card_setup() em28xx_pre_card_setup() is meant to contain board-specific initialization. Also, as autodetection sometimes occur only after having i2c bus enabled, this function may need to be called later. Moving those setups to happen outside the function avoids calling it twice without need and without duplicating output lines at dmesg. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12407): em28xx: Adjust Silvercrest xtal frequencyMauro Carvalho Chehab2009-08-13
| | | | | | | | | | We don't know the xtal frequency of Silvercrest, but we need to have some value in order to allow controlling the frame rate frequency. The value is probably still wrong, since the manufacturer announces this device as being capable of 30fps, but the maximum we can get is 13.5 fps. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12406): em28xx: fix: don't do image interlacing on webcamsMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | | | | Due to historical reasons, em28xx driver gets two consecutive frames and fold them into an unique framing, doing interlacing. While this works fine for TV images, this produces two bad effects with webcams: 1) webcam images are progressive. Merging two consecutive images produce interlacing artifacts on the image; 2) since the driver needs to get two frames, it reduces the maximum frame rate by two. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12403): em28xx: properly reports some em2710 chipsMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | As reported by hermann pitton <hermann-pitton@arcor.de>, some devices has a different chip id for em2710 (likely the older ones): em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0) em28xx #0: Identified as EM2710/EM2750/EM2751 webcam grabber (card=22) em28xx #0: em28xx chip ID = 17 Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12402): em28xx: fix: some em2710 chips use a different vendor IDMauro Carvalho Chehab2009-08-13
| | | | | | | | Thanks to hermann pitton <hermann-pitton@arcor.de> for pointing this new variation. Tested-by: hermann pitton <hermann-pitton@arcor.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12344): em28xx: fix support for Plextor ConvertX PX-TV100UMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | This device uses msp34xx and uses 2.048 MHz frequency for I2S communication. Thanks to Angelo Cano <acano@fastmail.fm> for pointing the issues with this device and proposing an approach for fixing the issue. Tested-by: Angelo Cano <acano@fastmail.fm> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12340): mtv9v011: Add a missing chip version to the driverMauro Carvalho Chehab2009-08-13
| | | | | | | | | | | Some mt9v011 webcams report 0x8332 chip version, instead of 0x8243. From the revision history at the mt9v011 datasheet, it seems that the chip version has changed from the first release of the chip. Thanks-to hermann pitton <hermann-pitton@arcor.de> for pointing this to me, on his tests with a Silvercrest webcam. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12263): em28xx: set demod profile for Pinnacle Hybrid Pro 320eDevin Heitmueller2009-07-24
| | | | | | | | | | | | The Pinnacle Hybrid Pro 320e was missing a demod config for the xc3028, which is required for digital tuning to work properly. Add the missing profile. Thanks to Andreas Lunderhage for testing patches and providing a remote debug environment. Cc: Andreas Lunderhage <lunderhage@home.se> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12262): em28xx: Make sure the tuner is initialized if generic empia ↵Devin Heitmueller2009-07-24
| | | | | | | | | | | | | | | | | | | USB id was used In cases where the device has a generic Empia USB ID, the call in the precard setup phase did not set the tuner GPIO. As a result, the tuner may not be taken out of reset before attempting initialization in the analog driver. This problem was not seen before with the EVGA inDtube, since that particular board has the analog GPIO setup to include taking the tuner out of reset. Thanks to Andreas Lunderhage for testing patches and providing a remote debug environment for the Pinnacle 320e. Cc: Andreas Lunderhage <lunderhage@home.se> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12261): em28xx: set GPIO properly for Pinnacle Hybrid Pro analog ↵Devin Heitmueller2009-07-24
| | | | | | | | | | support Set the GPIO properly for the analog side of the Pinnacle Hybrid Pro, or else the emp202 doesn't get detected properly. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12260): em28xx: make support work for the Pinnacle Hybrid Pro ↵Devin Heitmueller2009-07-24
| | | | | | | | | | | | | | (eb1a:2881) Setup the GPIOs properly and enable support for the DVB side of the Pinnacle Hybrid Pro USB stick. Thanks to Andreas Lunderhage for testing patches and providing a remote debug environment. Cc: Andreas Lunderhage <lunderhage@home.se> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12245): em28xx: add support for mt9m001 webcamsMauro Carvalho Chehab2009-07-24
| | | | | | | Thanks to Wally <wally@voosen.eu> for bringing the issue and helping with the tests. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12244): em28xx: adjust vinmode/vinctl based on the stream input formatMauro Carvalho Chehab2009-07-24
| | | | | | | | | Depending on the video input format, vinmode/vinctl needs adjustments. For TV, this is not relevant, since the supported decoders output data at the same format. However, webcam sensors may have different formats, so, this needs to be adjusted based on the device. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12243): em28xx: allow specifying sensor xtal frequencyMauro Carvalho Chehab2009-07-24
| | | | | | | | | | | | | | In order to properly estimate fps, mt9v011 sensor driver needs to know what is the used frequency on the sensor cristal. Adds the proper fields and initialization code for specifying the cristal frequency. Also, based on experimentation, it was noticed that the Silvercrest is outputing data at 7 fps. This means that it should be using a 6.3 MHz cristal. This information needs to be double checked later, by opening the device. Anyway, by using this value for xtal, at least now we have the correct fps report. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12239): em28xx: fix webcam scalingMauro Carvalho Chehab2009-07-24
| | | | | | | | | | | | | | | While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do work with em28xx + webcam. The issue is that the scaling setup depends on the number of visible rows/cols of the input image. With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling is different from a normal TV image (720x480 on NTSC). This were causing a wrong scaling and a previous patch disabled scaling. As each sensor have their different resolution setting, the xres/yres should be adjusted accordingly with the input sensor. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12238): em28xx: call sensor detection code for all webcam entriesMauro Carvalho Chehab2009-07-24
| | | | | | | | | | | | With the previous approach, autodetection were working only for the two generic entries (em275x and em2820 unknown ones). So, if someone would try to force probing an specific device, the code would not properly run the autodetection code. With the new approach, the sensor autodetection will be run not only for the two generic entries, but also do webcam specific ones. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12236): em28xx: stop abusing of board->decoder for sensor informationMauro Carvalho Chehab2009-07-24
| | | | | | | | | | Instead of using em28xx board decoder field for storing sensor information, let's use instead a separate field for it. Also, as sensors are currently autodetected, there's no need of having it at the boards description. So, move it to the main em28xx struct. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12235): em28xx: detects sensors also with the generic em2750/2750 entryMauro Carvalho Chehab2009-07-24
| | | | | | | Webcams in general don't have eeprom. So, the sensor hint code should be called to properly detect what sensor is inside. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12234): em28xx-cards: use is_webcam flag for devices that are known ↵Mauro Carvalho Chehab2009-07-24
| | | | | | | | | to be webcams By having the webcam devices marked as such, it will help the em28xx driver to do the right thing on those devices. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12233): em28xx: rename is_27xx to is_webcamMauro Carvalho Chehab2009-07-24
| | | | | | | Just renames the flag, to use a clearer name. Later patches will use this flag to properly set some drivers behaviors for webcams. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12202): em28xx, fix lock imbalanceJiri Slaby2009-07-05
| | | | | | | | There is one omitted unlock in em28xx_usb_probe. Fix that. Signed-off-by: Jiri Slaby <jirislaby@gmail.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12172): em28xx: Add autodetection code for Silvercrest 1.3 mpixMauro Carvalho Chehab2009-07-05
| | | | Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12156): em28xx: Fix tuning for Terratec Cinergy T XS USB (zl10353 ↵Devin Heitmueller2009-07-05
| | | | | | | | | | | | | | | | | | | | | | | | version) Fix the code so that the zl10353 version of the Terratec Cinergy T XS USB starts working again. This includes fixing what must have been a typo in the GPIO definition for the digital side of the board, and setting of the disable_i2c_gate_ctrl property for the zl10353 config, so that the i2c bus doesn't get wedged the first time something tries to close the gate. Also, add a printk() making clear that the mt352 version still isn't supported. This issue is still being actively debugged, but in the meantime at least the dmesg output will show a very clear error... Thanks to Jelle de Jong for providing sample hardware to test with. Thanks to Simon Kenyon for testing various patches and providing SSH access to his environment so I could debug with access to a valid signal source. Cc: Jelle de Jong <jelledejong@powercraft.nl> Cc: Simon Kenyon <simon@koala.ie> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12138): em28xx: add support for Silvercrest WebcamMauro Carvalho Chehab2009-07-05
| | | | | | | | | | | | | | This webcam uses a em2710 chipset, that identifies itself as em2820, plus a mt9v011 sensor, and a DY-301P lens. It needs a few different initializations than a normal em28xx device. Thanks to Hans de Goede <hdegoede@redhat.com> and Douglas Landgraf <dougsland@redhat.com> for providing the acces for the webcam during this weekend, I could make a patch for it while returning back from FISL/Fudcom LATAM 2009. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12102): em28xx: add Remote control support for EVGA inDtubeDevin Heitmueller2009-06-23
| | | | | | | | Add an IR profile for the EVGA inDtube remote control (which is an NEC type remote) Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12101): em28xx: add support for EVGA inDtubeDevin Heitmueller2009-06-23
| | | | | | | | | | | | | | | Add support for the EVGA inDtube. Both ATSC and analog side validated as fully functional. Thanks to Jake Crimmins from EVGA for providing the correct GPIO info. Thanks to Alan Hagge for doing all the device testing. Thanks to Greg Williamson for providing hardware for testing. Cc: Jake Crimmins <jcrimmins@evga.com> Cc: Alan Hagge <ahagge@gmail.com> Cc: Greg Williamson <cheeseboy16@gmail.com> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (12100): em28xx: make sure the analog GPIOs are set if we used a ↵Devin Heitmueller2009-06-23
| | | | | | | | | | | | | | | | | | card hint In cases where the board had a default USB ID, we would not indentify the board until after the call to em28xx_set_mode(). As a result, for those boards the analog GPIOs were not being set before probing the i2c bus for devices (the probe would occur with the GPIOs being all high). Make a call to em28xx_set_mode() so that the GPIOs are set properly before probing the i2c bus for devices. This problem was detected with the EVGA inDtube, where the tvp5150 is not powered on unless GPIO1 is pulled low. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11977): em28xx: Add Kworld 315 entryFranklin Meng2009-06-16
| | | | | | | | Added an entry for Kworld 315 (for while, dvb only) Signed-off-by: Franklin Meng <fmeng2002@yahoo.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11976): em28xx: set up tda9887_conf in em28xx_card_setup()Franklin Meng2009-06-16
| | | | | | | | Added tda9887_conf set up into em28xx_card_setup() Signed-off-by: Franklin Meng <fmeng2002@yahoo.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11927): em28xx: provide module option to disable USB speed checkDevin Heitmueller2009-06-16
| | | | | | | | | Add an em28xx module option that allows a user to override the USB speed check. Intended for advanced users who understand the consequences of trying to use the device with a 12Mbps bus. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11925): em28xx: Add support for the K-World 2800dDevin Heitmueller2009-06-16
| | | | | | | | | | | | | | | | Make the KWorld 2800d work properly. In this case, that means making the profile more generic so that it works for both the Pointnix Intra-Oral USB camera and the KWorld device. The device provides the audio through a pass-thru cable, so we don't need an actual audio capture profile (neither the K-World device nor the Pointnix have an onboard audio decoder). Thanks to Paul Thomas for providing sample hardware. Cc: Paul Thomas <pthomas8589@gmail.com> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11923): em28xx: Don't let device work unless connected to a high ↵Devin Heitmueller2009-06-16
| | | | | | | | | | | | | | | | speed USB port The em28xx basically just doesn't work at 12 Mbps. The isoc pipe needs nearly 200 Mbps for analog support, so users would see garbage video, and on the DVB/ATSC side scanning is likely to work but if the user tried to tune it would certainly appear to have failed. It's better to fail explicity up front and tell the user to plug into a USB 2.0 port, than to let the driver load and the user have weird problems with tuning and garbage video. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* V4L/DVB (11845): ir-kbd-i2c: Use initialization dataJean Delvare2009-06-16
| | | | | | | | | For specific boards, pass initialization data to ir-kbd-i2c instead of modifying the settings after the device is initialized. This is more efficient and easier to read. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
generated by cgit v1.2.2 (git 2.25.0) at 2024-12-29 20:52:14 -0500