summaryrefslogtreecommitdiff
path: root/drivers/media/usb/em28xx/em28xx-i2c.c
Commit message (Collapse)AuthorAge
* [media] em28xx: use usb_interface for dev_foo() callsMauro Carvalho Chehab2016-12-12
| | | | | | | | The usb_device->dev is not the right device for dev_foo() calls. Instead, it should use usb_interface->dev. Tested-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] em28xx: convert it from pr_foo() to dev_foo()Mauro Carvalho Chehab2016-11-18
| | | | | | | | | | | Instead of using pr_foo(), use dev_foo(), with provides a better output. As this device is a multi-interface one, we'll set the device name to show the chipset and the driver used. While here, get rid of printk continuation messages. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] em28xx: convert the remaining printks to pr_fooMauro Carvalho Chehab2016-10-21
| | | | | | | | | | | | There are still several places with printk's called directly. Convert them to pr_foo() macros, except for the debug printk's, as those are enabled via modprobe vars. While here, realign the pr_foo() arguments to match the recommended CodingStyle. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] em28xx: use pr_foo instead of em28xx-specific printk macrosMauro Carvalho Chehab2016-10-21
| | | | | | | There's no reason to keep using em28xx-specific printk macros here. Just use pr_foo(). Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] constify i2c_algorithm structuresJulia Lawall2016-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These i2c_algorithm structures are only stored in the alg field of an i2c_adapter structure, which is declared as const. This declare the structures as const as well. The semantic patch that makes this change is as follows: (http://coccinelle.lip6.fr/) // <smpl> @r disable optional_qualifier@ identifier i; position p; @@ static struct i2c_algorithm i@p = { ... }; @ok@ identifier r.i; struct i2c_adapter e; position p; @@ e.alg = &i@p; @bad@ position p != {r.p,ok.p}; identifier r.i; @@ i@p @depends on !bad disable optional_qualifier@ identifier r.i; @@ static +const struct i2c_algorithm i = { ... }; // </smpl> Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
* [media] em28xx-i2c: rt_mutex_trylock() returns zero on failureDan Carpenter2016-06-10
| | | | | | | | | | The code is checking for negative returns but it should be checking for zero. Fixes: aab3125c43d8 ('[media] em28xx: add support for registering multiple i2c buses') Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] em28xx: checkpatch cleanup: whitespaces/new lines cleanupsMauro Carvalho Chehab2014-12-04
| | | | | | | | | | | | | | | | | | | This patch is basically produced while testing a tool that Joe Perches sent upstream sometime ago: https://lkml.org/lkml/2014/7/11/794 I used it with those arguments: $ reformat_with_checkpatch.sh drivers/media/usb/em28xx/em28xx*.[ch] It actually produced 24 patches, with is too much, and showed interesting things: gcc produced different codes on most of the patches, even with just linespace changes. The total code data remained the same on all cases I checked though. Anyway, provided that we fold the resulting patches, this tool seems useful. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] add "lgdt330x" device name i2c_devs arrayWilson Michaels2014-11-14
| | | | | | | This patch adds "lgdt330x" device name i2c_devs array used for debugging Signed-off-by: Wilson Michaels <thebitpit@earthlink.net> Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
* [media] media: em28xx - fix i2c_xfer to return -ENODEV when dev is removedShuah Khan2014-07-26
| | | | | | | | | | In em28xx usb disconnect code path, some dvb fe and tuner drivers attempt i2c transfers from their release interfaces. When device is removed, return -ENODEV instead of attempting to transfer data over i2c. Signed-off-by: Shuah Khan <shuah.kh@samsung.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx: remove the i2c_set_adapdata() call in em28xx_i2c_register()Frank Schaefer2014-05-23
| | | | | | | | It is no longer needed since nobody is calling i2c_get_adapdata() anymore. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx-i2c: fix the error code for unknown errorsFrank Schaefer2014-02-04
| | | | | | | | | | | | Commit e63b009d6e "em28xx-i2c: Fix error code for I2C error transfers" changed the code to return -ETIMEDOUT on all unknown errors. But the proper error code for unknown errors is -EIO. So only report -ETIMEDOUT in case of the errors 0x02 and 0x04, which are according to Mauro Carvalho Chehab's tests related to i2c clock stretching and return -EIO for the rest. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx-i2c: fix the i2c error description strings for -ENXIOFrank Schaefer2014-02-04
| | | | | | | | | | Commit d845fb3ae5 "em28xx-i2c: add timeout debug information if i2c_debug enabled" has added wrong error descriptions for -ENXIO. The strings are also missing terminating newline characters, which breaks the output format. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx-i2c: add timeout debug information if i2c_debug enabledMauro Carvalho Chehab2014-01-12
| | | | | | | | | | | | | | | If i2c_debug is enabled, we splicitly want to know when a device fails with timeout. If i2c_debug==2, this is already provided, for each I2C transfer that fails. However, most of the time, we don't need to go that far. We just want to know that I2C transfers fail. So, add such errors for normal (ret == 0x10) I2C aborted timeouts. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx-i2c: cleanup I2C debug messagesMauro Carvalho Chehab2014-01-12
| | | | | | | | | | | | The I2C output messages is too polluted. Clean it a little bit, by: - use the proper core support for memory dumps; - hide most stuff under the i2c_debug umbrella; - add the missing KERN_CONT where needed; - use 2 levels or verbosity. Only the second one will show the I2C transfer data. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx-i2c: Fix error code for I2C error transfersMauro Carvalho Chehab2014-01-12
| | | | | | | | | | | | | | | | | | Follow the error codes for I2C as described at Documentation/i2c/fault-codes. In the case of the I2C status register (0x05), this is mapped into: - ENXIO - when reg 05 returns 0x10 - ETIMEDOUT - when the device is not temporarily not responding (e. g. reg 05 returning something not 0x10 or 0x00) - EIO - for generic I/O errors that don't fit into the above. In the specific case of 0-byte reads, used only during I2C device probing, it keeps returning -ENODEV. TODO: return EBUSY when reg 05 returns 0x20 on em2874 and upper. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx: rename I2C timeout to EM28XX_I2C_XFER_TIMEOUTMauro Carvalho Chehab2014-01-10
| | | | | | | This macro is used by all em28xx devices, and not just em2800. Reviewed-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx: convert i2c wait completion logic to use jiffiesMauro Carvalho Chehab2014-01-10
| | | | | | | | | | | The I2C wait completion/timeout logic currently assumes that msleep(5) will wait exaclty 5 ms. This is not true at all, as it depends on CONFIG_HZ. Convert it to use jiffies, in order to not wait for more time than needed. Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx: fix I2S audio sample rate definitions and info outputFrank Schaefer2014-01-07
| | | | | | | | | | | | | | | | | The audio configuration in chip config register 0x00 and eeprom are always consistent. But currently the audio configuration #defines for the chip config register say 0x20 means 3 sample rates and 0x30 5 sample rates, while the eeprom info output says 0x20 means 1 sample rate and 0x30 3 sample rates. I've checked the datasheet excerpts I have and it seems that the meaning of these bits is different for em2820/40 (1 and 3 sample rates) and em2860+ (3 and 5 smaple rates). I have also checked my Hauppauge WinTV USB 2 (em2840) and the chip/eeprom audio config 0x20 matches the sample rates reproted by the USB device descriptor (32k only). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
* [media] em28xx: fix assignment of the eeprom dataAlban Browaeys2013-09-03
| | | | | | | | | | | | | Set the config structure pointer to the eeprom data pointer (data, here eedata dereferenced) not the pointer to the pointer to the eeprom data (eedata itself). Signed-off-by: Alban Browaeys <prahal@yahoo.com> Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Cc: stable@vger.kernel.org # for v3.10 Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com> Cc: stable@vger.kernel.org
* [media] em28xx: add support for em25xx i2c bus B read/write/check device ↵Frank Schaefer2013-03-28
| | | | | | | | | | | | | | | | | operations The webcam "SpeedLink VAD Laplace" (em2765 + ov2640) uses a special algorithm for i2c communication with the sensor, which is connected to a second i2c bus. We don't know yet how to find out which devices support/use it. It's very likely used by all em25xx and em276x+ bridges. Tests with other em28xx chips (em2820, em2882/em2883) show, that this algorithm always succeeds there although no slave device is connected. The algorithm likely also works for real i2c client devices (OV2640 uses SCCB), because the Windows driver seems to use it for probing Samsung and Kodak sensors. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: fix coding style of multi line commentsFrank Schaefer2013-03-25
| | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: do not break strings across linesFrank Schaefer2013-03-25
| | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: Only change I2C bus inside em28xx-i2cMauro Carvalho Chehab2013-03-22
| | | | | | | | | | There's currently a bug on em28xx-i2c that makes it write the wrong values to register 06, that controlls the I2C bus speed and bus. Fix it to change only the I2C bus flag. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: relax error check in em28xx_i2c_recv_bytes()Frank Schaefer2013-03-18
| | | | | | | | | | | | | | | | | | It turned out that some devices return less bytes then requested via i2c when ALL of the following 3 conditions are met: - i2c bus B is used - there was no attempt to write to the specified slave address before - no device present at the specified slave address With the current code, this triggers an -EIO error and prints a message to the system log. Because it can happen very often during device probing, it is better to ignore this error and bail out silently after the follwing i2c transaction success check with -ENODEV. [mchehab@redhat.com: a small CodingStyle fix] Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add support for registering multiple i2c busesMauro Carvalho Chehab2013-03-18
| | | | | | | | Register both buses 0 and 1 via I2C API. For now, bus 0 is used only by eeprom on all known devices. Later patches will be needed if this changes in the future. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: Prepare to support 2 different I2C busesMauro Carvalho Chehab2013-03-18
| | | | | | | | | | | | Newer em28xx devices have 2 buses. Change the logic to allow using both buses. This patch was generated by this small script: for i in drivers/media/usb/em28xx/*.c; do sed 's,->i2c_adap,->i2c_adap[dev->def_i2c_bus],g;s,->i2c_client,->i2c_client[dev->def_i2c_bus],' done Of course, em28xx.h needed manual edit. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: extract the device configuration dataset from eeproms with ↵Frank Schaefer2013-03-04
| | | | | | | | | | | | | | | | | | 16 bit address width The new eeproms with 16 address width still have the the device config dataset (the content of the old 8 bit eeproms) embedded. Hauppauge also continues to include the tveeprom data structure inside this dataset in their devices. The start address of the dataset depends on the start address of the microcode and a variable additional offset. It should be mentioned that Camera devices seem to use a different dataset type, which is not yet supported. Tested with devices "Hauppauge HVR-930C". I've also checked the USB-log from the "MSI Digivox ATSC" and it works the same way. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: do not store eeprom content permanentlyFrank Schaefer2013-03-04
| | | | | | | | | | | | | | We currently reserve an array of 256 bytes for the eeprom content in the device struct. For eeproms with 16 bit address width it might even be necessary to increase the buffer size further. Having such a big chunk of memory reserved even if the device has no eeprom and keeping it after it has already been processed seems to be a waste of memory. Change the code to allocate + free the eeprom memory dynamically. This also makes it possible to handle different dataset sizes depending on what is stored/found in the eeprom. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add helper function for reading data blocks from i2c clientsFrank Schaefer2013-03-04
| | | | | | | | | | Add a helper function for reading data blocks from i2c devices with 8 or 16 bit address width and 8 bit register width. This allows us to reduce the size of new code added by the following patches. Works only for devices with activated register auto incrementation. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add basic support for eeproms with 16 bit address widthFrank Schaefer2013-03-04
| | | | | | | | | | | | | | | | | | Newer devices (em2874, em2884, em28174, em25xx, em27[6,7,8]x) use eeproms with 16 bit instead of 8 bit address width. The used eeprom type depends on the chip type, which makes sure eeproms can't be damaged. This patch adds basic support for 16 bit eeproms only, which includes - reading the content - calculating the eeprom hash - displaying the content The eeprom content uses a different format, for which support will be added with subsequent patches. Tested with the "Hauppauge HVR-930C" and the "Speedlink VAD Laplace webcam" (with additional experimental patches). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix eeprom data endianessFrank Schaefer2013-03-04
| | | | | | | | | | | The data is stored as little endian in the eeprom. Hence the correct data types should be used and the data should be converted to the machine endianess before using it. The eeprom id (key) also isn't a 32 bit value but 4 separate bytes instead. [mchehab@redhat.com: Fix CodingStyle] Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: do not interpret eeprom content if eeprom key is invalidFrank Schaefer2013-03-04
| | | | | | | | | | If the eeprom key isn't valid, either a different (currently unknown) format is used or the eeprom is corrupted. In both cases it doesn't make sense to interpret the data. Also print an error message. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: also print debug messages at debug level 1Frank Schaefer2013-03-04
| | | | | | | | | | | | | The current code uses only a single debug level and all debug messages are printed for i2c_debug >= 2 only. So debug level 1 is actually the same as level 0, which is odd. Users expect debugging messages to become enabled for anything else than debug level 0. Fix it and simplify the code a bit by printing the debug messages also at debug level 1; Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: replace printk() with the corresponding em28xx macrosFrank Schaefer2013-03-04
| | | | | | | Reduces the number of characters/lines, unifies the code and improves readability. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-i2c: get rid of the dprintk2 macroFrank Schaefer2013-03-04
| | | | | | | | | | There is only a single place where the dprintk2 macro is used, so get rid of it. [mchehab@redhat.com: fix checkpathc.pl complain: ERROR: space prohibited before that close parenthesis ')'] Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add missing IR RC slave address to the list of known i2c devicesFrank Schaefer2013-02-05
| | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: consider the message length limitation of the i2c adapter ↵Frank Schaefer2013-01-05
| | | | | | | | | | | | | | | | when reading the eeprom EEPROMs are currently read in blocks of 16 bytes, but the em2800 is limited to 4 bytes per read. All other chip variants support reading of max. 64 bytes at once (according to the em258x datasheet; also verified with em2710, em2882, and em28174). Since em2800_i2c_recv_bytes() has been fixed to return with -EOPNOTSUPP when more than 4 bytes are requested, EEPROM reading with this chip is broken. It was actually broken before that change, too, it just didn't throw an error because the i2c adapter silently returned trash data (for all reads >1 byte !). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix+improve+unify i2c error handling, debug messages and ↵Frank Schaefer2013-01-05
| | | | | | | | | | | | | | code comments - do not pass USB specific error codes to userspace/i2c-subsystem - unify the returned error codes and make them compliant with the i2c subsystem spec - check number of actually transferred bytes (via USB) everywehere - fix/improve debug messages - improve code comments Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix the i2c adapter functionality flagsFrank Schaefer2013-01-05
| | | | | | | | | | | I2C_FUNC_SMBUS_EMUL includes flag I2C_FUNC_SMBUS_WRITE_BLOCK_DATA which signals that up to 31 data bytes can be written to the ic2 client. But the EM2800 supports only i2c messages with max. 4 data bytes. I2C_FUNC_IC2 should be set if a master_xfer function pointer is provided in struct i2c_algorithm. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix two severe bugs in function em2800_i2c_recv_bytes()Frank Schaefer2013-01-05
| | | | | | | | | | | | | | | Function em2800_i2c_recv_bytes() has 2 severe bugs: 1) It does not wait for the i2c read to complete before reading the received message content from the bridge registers. 2) Reading more than 1 byte doesn't work The former can result in data corruption, the latter always does. The rewritten code also superseds the content of function em2800_i2c_check_for_device(). Tested with device "Terratec Cinergy 200 USB". [mchehab@redhat.com: Fix CodingStyle issues] Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: respect the message size constraints for i2c transfersFrank Schaefer2013-01-05
| | | | | | | | | | | | | | The em2800 can transfer up to 4 bytes per i2c message. All other em25xx/em27xx/28xx chips can transfer at least 64 bytes per message. I2C adapters should never split messages transferred via the I2C subsystem into multiple message transfers, because the result will almost always NOT be the same as when the whole data is transferred to the I2C client in a single message. If the message size exceeds the capabilities of the I2C adapter, -EOPNOTSUPP should be returned. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: clean up the data type mess of the i2c transfer function ↵Frank Schaefer2012-12-22
| | | | | | | parameters Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] rename most media/video usb drivers to media/usbMauro Carvalho Chehab2012-08-15
Rename all USB drivers with their own directory under drivers/media/video into drivers/media/usb and update the building system. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-09-21 12:33:23 +0000