summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2011-07-28[media] xc4000: xc_tune_channel() cleanupIstvan Varga1-10/+9
Minor coding changes related to the xc_tune_channel() function. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: implemented analog TV and radioIstvan Varga1-19/+100
The following patch implements support for analog TV and FM radio. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: added audio_std module parameterIstvan Varga1-0/+23
The 'audio_std' module parameter makes it possible to fine tune some audio related aspects of the driver, like setting the exact audio standard (NICAM, A2, etc.) to be used for some video standards. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: setting registersIstvan Varga1-12/+55
This patch implements setting the registers in xc4000_set_params() and xc4000_set_analog_params(). A new register is defined which enables filtering of the composite video output (this is needed to avoid bad picture quality with some boards). Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: debug message improvementsIstvan Varga1-23/+45
The following patch makes a few minor changes to the printing of debug messages, and reporting the tuner status. The 'debug' module parameter can now be set from 0 to 2 to control the verbosity of debug messages. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: firmware initializationIstvan Varga1-20/+16
This patch fixes/cleans up the loading of the firmware file when the driver is loaded and initialized. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: implemented power managementIstvan Varga1-5/+34
The following patch implements the xc4000_sleep() function. The 'no_powerdown' module parameter is now interpreted differently: - 0 uses a device-specific default - 1 disables power management like before - 2 enables power management Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: added card_typeIstvan Varga2-2/+20
This patch adds support for selecting a card type in struct xc4000_config, to allow for implementing some card specific code in the driver. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: check_firmware() cleanupIstvan Varga1-10/+5
This patch makes the following fixes in check_firmware(): - there is only one BASE and INIT1 firmware for XC4000 - loading SCODE is needed also for FM radio Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: simplified load_scodeIstvan Varga1-18/+8
Removed unused code from load_scode() (all SCODE firmwares are assumed to have the HAS_IF bit set). Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: simplified seek_firmware()Istvan Varga1-46/+25
This patch simplifies the code in seek_firmware(). Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: added firmware_name parameterIstvan Varga1-5/+12
The firmware_name module parameter makes it possible to set the firmware file name. It defaults to "xc4000.fw" if not specified. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: fixed frequency errorIstvan Varga1-2/+3
The xc_get_frequency_error() function reported the frequency error incorrectly. The data read from the hardware is a signed integer, in 15625 Hz units. The attached patch fixes the bug. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: added mutexIstvan Varga1-30/+50
This patch adds a mutex to xc4000_priv, to protect the driver from being accessed by multiple processes at the same time. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: added support for 7 MHz DVB-TIstvan Varga1-2/+15
The following patch implements support for DVB-T with 7 MHz bandwidth. Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: updated standards tableIstvan Varga1-32/+35
This patch makes the following changes to the standards table: - added 'u16 int_freq' to struct XC_TV_STANDARD (needed for analog TV and radio, 0 for DVB-T) - added new standard for SECAM-D/K video with PAL-D/K audio - the 'int_freq' values are now specified in the table - changed VideoMode for NTSC and PAL-B/G standards Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: code cleanupIstvan Varga2-115/+45
This is the first of a set of patches that update the original xc4000 sources to my modified version. It removes some unused code, and makes a few minor formatting changes. [mchehab@redhat.com: re-add XC_TUNE_ANALOG/XC_TUNE_DIGITAL constants, to avoid compilation breakage] Signed-off-by: Istvan Varga <istvan_v@mailbox.hu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: Fix a few bad whitespaces on itMauro Carvalho Chehab1-8/+8
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: remove notes from bringup of PCTV 340eDevin Heitmueller1-62/+1
Remove some inline comments I had written from when I was computing the proper dib7000p configuration to work with the xc4000. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: cleanup dmesg loggingDevin Heitmueller1-25/+6
Remove some printk() calls added during driver development, and demote some other messages to debug only (to reduce dmesg chatter). Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: rename firmware image filenameDevin Heitmueller1-1/+3
Give the xc4000 firmware filename a filename that makes more sense for public release. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: turn off debug logging by defaultDevin Heitmueller1-1/+1
Don't dump debug into to dmesg by default (something I had enabled during bringup of the xc4000 driver). Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: make PCTV 340e work!Devin Heitmueller1-8/+9
Fixup the PLL and AGC configs so that the 340e works (correcting errors I made when I did the original config blindly). Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: get rid of hard-coded 8MHz firmware configDevin Heitmueller1-40/+51
Remove a hack I had put in to force the firmware to be 8MHz, now setting the firmware properly based on the target standard. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: fixup PLL config for PCTV 340eDevin Heitmueller1-1/+41
Based on a reference trace under Windows, reverse engineer the PLL config. Note that the xtal is not yet setup, and the timf cannot be determined yet because my reference trace doesn't actually achieve a signal lock. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: handle dib0700 broken i2c stretchingDevin Heitmueller1-5/+29
It was confirmed by DibCom that i2c stretching is broken in the i2c master on the dib7700. So we need to put a hack into the xc4000 driver to not complain in certain very specific cases where we know i2c stretching occurs. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: setup dib7000p AGC config for PCTV 340eDevin Heitmueller1-5/+66
Setup a proper AGC config for the 340e, based on the Windows USB trace Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: use if_khz provided in xc4000_configDevin Heitmueller1-5/+5
Remove hard-coded references to 5400, using the value passed in when the xc4000 is attached. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: continued cleanup of the firmware loading routineDevin Heitmueller1-136/+44
Properly setup the standard firmware loading and scode loading, as well as getting rid of a ton of dead code. Note that I am getting a single i2c error when the standard firmware sets the video standard, but everything else seems to be loading properly now. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: add code to do standard and scode firmware loadingDevin Heitmueller1-9/+332
Add code to handle firmware blobs for the standard and scode. Note there appears to be some issue with loading the DTV8 standard firmware, probably related to direct/indirect mode. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: remove xc5000 firmware loading routineDevin Heitmueller1-2/+0
Since we use the xc3028 version of the firmware file parsing routine (which includes support for scodes and separate blobs), we can drop the xc5000 version of the code. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: remove XREG_BUSY code only supported in xc5000Devin Heitmueller1-26/+0
The xc4000 driver is based on the original xc5000 driver, and while the xc5000 supports the XREG_BUSY register, the xc4000 does not. So remove the code in question. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: properly set type for init1 firmwareDevin Heitmueller1-1/+1
We need to set the firmware type properly in order to locate the init1 firmware. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: cut over to using xc5000 version for loading i2c sequencesDevin Heitmueller1-90/+5
The xc3028 version does i2c splitting in a different manner than xc4000 and xc5000, so reuse the xc5000 version of the routine (the key here being that xc4000 expects the first *two* bytes to be the same for splitting transactions. Doing it the xc3028 way was resulting in i2c errors partially through the firmware load. With this change, it would appear that the entire base firmware is being loaded successfully (product id now properly shows 0x0FA0). Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] xc4000: pull in firmware management code from xc3028Devin Heitmueller1-31/+393
Switch over to using the firmware management routines from the tuner-xc2028, since that has support for scodes, etc. This code still requires signficant cleanup, and at this point the base firmware does not load properly (i2c write errors about 300 bytes in). Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib7000p: setup dev.parent for i2c master built into 7000pDevin Heitmueller1-0/+5
We need to set the dev.parent member on the dib7000p on its i2c master, or else calls to request_firmware() will hit an oops in 2.6.31. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: add a sleep before attempting to detect dib7000pDevin Heitmueller1-0/+2
Add a sleep since in some cases the dib7000p wasn't online when being probed. The optimal timing has not yet been determined. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: successfully connect to xc4000 over i2c for PCTV 340eDevin Heitmueller1-8/+15
Use the correct i2c bus to communicate with the tuner, and properly setup the reset GPIO and i2c address. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: properly setup GPIOs for PCTV 340eDevin Heitmueller1-1/+63
Provide a frontend setup routine for the PCTV 340e which takes into account the specific GPIO setup of the board. Note that this patch does *not* take into account the xc4000 reset pin, which is attached to the dib7000. Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: add USB id for PCTV 340eSEDevin Heitmueller2-2/+8
Add the board profile for the PCTV 340eSE, since that's what I have here for development. [mchehab@redhat.com: rebased on the top of the current tree] Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dib0700: add initial code for PCTV 340e by Davide FerriDavide Ferri8-0/+1242
This is initial code written by Davide Ferri for the PCTV 340e, including a new xc4000 driver. I am checking in all the code unmodified, and making no assertions about its quality (other than confirming it compiles). [mchehab@redhat.com: rebased on the top of the current tree] Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Davide Ferri <davidef1986@gmail.com> Cc: Patrick Boettcher <pboettcher@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] mt9v011: Fixed gain calculationJohannes Obermaier1-11/+52
The implementation of the gain calculation for this sensor is incorrect. It is only working for the first 127 values. The reason is, that the gain cannot be set directly by writing a value into the gain registers of the sensor. The gain register work this way (see datasheet page 24): bits 0 to 6 are called "initial gain". These are linear. But bits 7 and 8 ("analog multiplicative factors") and bits 9 and 10 ("digital multiplicative factors") work completely different: Each of these bits increase the gain by the factor 2. So if the bits 7-10 are 0011, 0110, 1100 or 0101 for example, the gain from bits 0-6 is multiplied by 4. The order of the bits 7-10 is not important for the resulting gain. (But there are some recommended values for low noise) The current driver doesn't do this correctly: If the current gain is 000 0111 1111 (127) and the gain is increased by 1, you would expect the image to become brighter. But the image is completly dark, because the new gain is 000 1000 0000 (128). This means: Initial gain of 0, multiplied by 2. The result is 0. This patch adds a new function which does the gain calculation and also fixes the same bug for red_balance and blue_balance. Additionally, the driver follows the recommendation from the datasheet, which says, that the gain should always be above 0x0020. Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] mt9v011: Added exposure for mt9v011Johannes Obermaier1-1/+21
There are problems when you use this camera/sensor in a very bright room or outside. The image is completely white, because it is overexposed. The driver uses a default value which is not suitable for all environments. This patch makes it possible to adjust the exposure time by youself. I found out by logging the i2c-data, that the windows driver for this sensor is doing this, too. I tested the camera on a sunny day and after adjusting the exposure time, I was able to see a very good image. Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] mt9v011: Fixed incorrect value for the first valid columnJohannes Obermaier1-1/+1
According to the datasheet (page 8), the first optical clear pixel-column is not at position 14. The correct/recommended value is 20. Without this patch there is a dark line on the left side of the image. Tested-by: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Johannes Obermaier <johannes.obermaier@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] rc-core: fix winbond-cir issuesDavid Härdeman1-16/+6
The conversion of winbond-cir to use rc-core seems to have missed a a few bits and pieces which were in my local tree. Kudos to Juan Jesús García de Soria Lucena <skandalfo@gmail.com> for noticing. [mchehab@redhat.com: fix two UTF-8 violations] Signed-off-by: David Härdeman <david@hardeman.nu> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] rc/redrat3: dereferencing null pointerDan Carpenter1-1/+1
In the original code, if the allocation failed we dereference "rr3" when it was NULL. Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] rc: double unlock in rc_register_device()Dan Carpenter1-1/+2
If change_protocol() fails and we goto out_raw, then it calls unlock twice. I noticed that the other time we called change_protocol() we held the &dev->lock, so I changed it to hold it here too. Reviewed-by: Jarod Wilson <jarod@redhat.com> Acked-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] DVB: dvb_frontend: fix dtv_property_dump for DTV_DVBT2_PLP_IDAndreas Oberritter1-1/+2
- Add missing entry to array "dtv_cmds". - Set array size to DTV_MAX_COMMAND + 1 to avoid future off-by-ones. Reported-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] V4L/videobuf2-memops: use pr_debug for debug messagesUwe Kleine-König1-3/+3
Otherwise they clutter the dmesg buffer even on a production kernel. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2011-07-28[media] dvb-usb.h function rc5_scanManoel Pinheiro1-1/+1
The function "rc5_scan" in "dvb_usb.h" is returning invalid value. The value should be returned "u16" but is returning "u8". See example below in "drivers/media/dvb/dvb-usb/opera1.c": send_key = (send_key & 0xffff) | 0x0100; for (i = 0; i < ARRAY_SIZE(rc_map_opera1_table); i++) { if (rc5_scan(&rc_map_opera1_table[i]) == (send_key & 0xffff)) { *state = REMOTE_KEY_PRESSED; *event = rc_map_opera1_table[i].keycode; opst->last_key_pressed = rc_map_opera1_table[i].keycode; break; } opst->last_key_pressed = 0; } Signed-off-by: Manoel Pinheiro <pinusdtv@hotmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>