aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/usb/em28xx
Commit message (Collapse)AuthorAge
* [media] em28xx: fix oops at em28xx_dvb_bus_ctrl()Mauro Carvalho Chehab2013-04-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | em28xx is oopsing with some DVB devices: [10856.061884] general protection fault: 0000 [#1] SMP [10856.067041] Modules linked in: rc_hauppauge em28xx_rc xc5000 drxk em28xx_dvb dvb_core em28xx videobuf2_vmalloc videobuf2_memops videobuf2_core rc_pixelview_new tuner_xc2028 tuner cx8800 cx88xx tveeprom btcx_risc videobuf_dma_sg videobuf_core rc_core v4l2_common videodev ebtable_nat ebtables nf_conntrack_ipv4 nf_defrag_ipv4 xt_CHECKSUM be2iscsi iscsi_boot_sysfs iptable_mangle bnx2i cnic uio cxgb4i cxgb4 tun bridge cxgb3i cxgb3 stp ip6t_REJECT mdio libcxgbi nf_conntrack_ipv6 llc nf_defrag_ipv6 ib_iser rdma_cm ib_addr xt_conntrack iw_cm ib_cm ib_sa nf_conntrack ib_mad ib_core bnep bluetooth iscsi_tcp libiscsi_tcp ip6table_filter libiscsi ip6_tables scsi_transport_iscsi xfs libcrc32c snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq snd_seq_device snd_pcm tg3 snd_page_alloc snd_timer [10856.139176] snd ptp iTCO_wdt soundcore pps_core iTCO_vendor_support lpc_ich mfd_core coretemp nfsd hp_wmi crc32c_intel microcode serio_raw rfkill sparse_keymap nfs_acl lockd sunrpc kvm_intel kvm uinput binfmt_misc firewire_ohci nouveau mxm_wmi i2c_algo_bit drm_kms_helper firewire_core crc_itu_t ttm drm i2c_core wmi [last unloaded: dib0070] [10856.168969] CPU 1 [10856.170799] Pid: 13606, comm: dvbv5-zap Not tainted 3.9.0-rc5+ #26 Hewlett-Packard HP Z400 Workstation/0AE4h [10856.181187] RIP: 0010:[<ffffffffa0459e47>] [<ffffffffa0459e47>] em28xx_write_regs_req+0x37/0x1c0 [em28xx] [10856.191028] RSP: 0018:ffff880118401a58 EFLAGS: 00010282 [10856.196533] RAX: 00020000012d0000 RBX: ffff88010804aec8 RCX: ffff880118401b14 [10856.203852] RDX: 0000000000000048 RSI: 0000000000000000 RDI: ffff88010804aec8 [10856.211174] RBP: ffff880118401ac8 R08: 0000000000000001 R09: 0000000000000000 [10856.218496] R10: 0000000000000000 R11: 0000000000000006 R12: 0000000000000048 [10856.226026] R13: ffff880118401b14 R14: ffff88011752b258 R15: ffff88011752b258 [10856.233352] FS: 00007f26636d2740(0000) GS:ffff88011fc20000(0000) knlGS:0000000000000000 [10856.241626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [10856.247565] CR2: 00007f2663716e20 CR3: 00000000c7eb1000 CR4: 00000000000007e0 [10856.254889] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [10856.262215] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [10856.269542] Process dvbv5-zap (pid: 13606, threadinfo ffff880118400000, task ffff8800cd625d40) [10856.278340] Stack: [10856.280564] ffff88011ffe8de8 0000000000000002 0000000000000000 ffff88011ffe9b00 [10856.288191] ffff880118401b14 00ff88011ffe9b08 ffff880100000048 ffffffff8112a52a [10856.295893] 0000000000000001 ffff88010804aec8 0000000000000048 ffff880118401b14 [10856.303521] Call Trace: [10856.306182] [<ffffffff8112a52a>] ? __alloc_pages_nodemask+0x15a/0x960 [10856.312912] [<ffffffffa045a002>] em28xx_write_regs+0x32/0xa0 [em28xx] [10856.319638] [<ffffffffa045a221>] em28xx_write_reg+0x21/0x30 [em28xx] [10856.326279] [<ffffffffa045a2cc>] em28xx_gpio_set+0x9c/0x100 [em28xx] [10856.332919] [<ffffffffa045a3ac>] em28xx_set_mode+0x7c/0x80 [em28xx] [10856.339472] [<ffffffffa03ef032>] em28xx_dvb_bus_ctrl+0x32/0x40 [em28xx_dvb] This is caused by commit c7a45e5b4f8c2f96cd242ae1b1c06e7fb19a08d0, that added support for two I2C buses. A partial fix was applied at 3de09fbbfaa521e68675bd30cfece252c4856600, but it doesn't cover all cases, as the DVB core fills fe->dvb->priv with adapter->priv. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: save isoc endpoint number for DVB only if endpoint has alt ↵Frank Schaefer2013-04-25
| | | | | | | | | | | | | | settings with xMaxPacketSize != 0 X-Patchwork-Delegate: mchehab@redhat.com In addition to commit 72cc9ba3 "em28xx: ignore isoc DVB USB endpoints with wMaxPacketSize = 0 bytes for all alt settings" we should not save the endpoint number of the isoc DVB endpoint before it has been validated. While the current code works fine, dev->dvb_ep_isoc != 0 could be interpreted as indicator that the device provides DVB support. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add a missing le16_to_cpu conversionFrank Schaefer2013-04-22
| | | | | | | | | commit 61ff5d69 "em28xx: improve em2710/em2820 distinction" missed the le16_to_cpu conversion of the USB vendor ID. 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 <mchehab@redhat.com>
* [media] em28xx: Put remaining .vidioc_g_chip_info instance under ADV_DEBUGMichal Marek2013-04-16
| | | | | | | | | | Commit cd634f1 ("[media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under ADV_DEBUG") missed the initializer of radio_ioctl_ops: drivers/media/usb/em28xx/em28xx-video.c:1830:2: error: unknown field 'vidioc_g_chip_info' specified in initializer drivers/media/usb/em28xx/em28xx-video.c:1830:26: error: 'vidioc_g_chip_info' undeclared here (not in a function) Signed-off-by: Michal Marek <mmarek@suse.cz> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: map remote for 1b80:e425Antti Palosaari2013-04-14
| | | | | | | Map RC_MAP_REDDO to that device. Signed-off-by: Antti Palosaari <crope@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: improve em2710/em2820 distinctionFrank Schaefer2013-04-14
| | | | | | | | | | | | | | Chip id 18 is used by the em2710 and em2820. The current code assumes that if the device is a camera, the chip is an em2710 and an em2820 otherwise. But it turned out that the em2820 is also used in camera devices. "Silvercrest 1.3 MPix" webcams for example are available with both chips. Fortunately both variants are using different generic USD IDs which give us a hint about the used chip. 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 <mchehab@redhat.com>
* [media] em28xx: fix snapshot button supportFrank Schaefer2013-04-14
| | | | | | | | | | The snapshot button support is currently broken, because module em28xx-rc is loaded only if the device has remote control support. Fix it by also loading this module if the device has a snapshot button. 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 <mchehab@redhat.com>
* [media] em28xx: fix kernel oops when watching digital TVHans Verkuil2013-04-14
| | | | | | | | | dvb->adapter.priv should also be set to the i2c bus since that's what em28xx_tuner_callback expects. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Tested-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] v4l2: rename VIDIOC_DBG_G_CHIP_NAME to _CHIP_INFOHans Verkuil2013-04-14
| | | | | | | This ioctl will be extended to return more information than just the name. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] v4l2: put VIDIOC_DBG_G_CHIP_NAME under ADV_DEBUGHans Verkuil2013-04-14
| | | | | | | | | | Only enable this ioctl if the VIDEO_ADV_DEBUG config option is set. This prevents abuse from both userspace and kernelspace (some bridge drivers abuse DBG_G_CHIP_IDENT, lets prevent that from happening again with this ioctl). Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix typo in scale_to_size()Hans Verkuil2013-03-31
| | | | | | | | | | em28xx: fix typo in scale_to_size(). The second hscale should be vscale. This bug caused xawtv to fail because it cannot find a workable image size. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add basic support for OmniVision OV2640 sensorsFrank Schaefer2013-03-29
| | | | | | | | | | | | This sensor is used by the "SpeedLink Vicious And Devine Laplace webcam" and others. It supports resolutions up to 1600x1200 (at 7-8 fps), but for resolutions higher than 640x480, further driver changes will be necessary, such as sensor output resolution switching (including further configuration changes), bridge xclk adjustment and disabling of 16 bit (12 bit) output formats at high resolutions. Image quality should also needs to be improved. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add comment about Samsung and Kodak sensor probing addressesFrank Schaefer2013-03-29
| | | | | | | | | | | The Windows driver also probes at least two further i2c addresses (0x22 >> 1 and 0x66 >> 1). I've got some hints that they are very likely used by Samsung and Kodak sensors, which are known to be used in Empia devices, too. We havn't seen any devices using these sensors yet and don't know how to probe them properly, so leave a comment. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add probing procedure for OmniVision sensorsFrank Schaefer2013-03-29
| | | | | | | | | | | | | OmniVision sensors are used as well in Empiatech based cameras such as the "SpeedLink Vicious And Devine Laplace" webcam (EM2765 + Omnivision OV2640). With this patch applied, OminiVision sensors with 8 bit address and register width are detected (recent models have a 16 bit address width and use different client addresses). The most commonly used sensors (including the ones listed by Empiatech) are detected properly, although there is no support for them yet. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: move the probing of Micron sensors to a separate functionFrank Schaefer2013-03-29
| | | | | | | | Other sensors like the ones from OmniVision need a different probing procedure, so it makes sense have separate functions for each manufacturer/sensor type. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: detect further Micron sensorsFrank Schaefer2013-03-29
| | | | | | | | | | Add further Micron chip IDs to be able to identify all Micron sensors listed by Empiatech. Also probe the two alternate i2c addresses used by Micron sensors with 8 bit address and 16 bit register width. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: move sensor code to a separate source code file em28xx-camera.cFrank Schaefer2013-03-29
| | | | | | | | em28xx-cards.c is very large and the sensor/camera related code is growing, so move this code to a separate source code file em28xx-camera.c. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: rename em28xx_hint_sensor() to em28xx_detect_sensor()Frank Schaefer2013-03-29
| | | | | | | | Now that the board hints and the sensor initialization/configuration have been separated, em28xx_detect_sensor() is the better name for this function. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: separate sensor detection and initialization/configurationFrank Schaefer2013-03-29
| | | | | | | | | | | | Sensor detection and initialization/configuration are currently mixed together. This works as long as all devices with a particular sensor are working with the same board configuration. In the long run, this will be not sufficient, so separate these both steps to make the code more flexible and future proof. This also makes the code more consistent, because the initialization of the MT9V011 sensor subdevice is already separated. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: fix and separate the board hints for sensor devicesFrank Schaefer2013-03-29
| | | | | | | | | | | | | | | | | | The current board hint code is mixed together with the sensor detection and initialization code. It actually selects a board depending on the detected sensor type only, with the result that 3 of the 6 webcam boards are currently dead. Separate it and move it to em28xx_hint_board() which already contains the board hints for analog capturing+TV and DVB devices. This way, we have all board hints at a common place which makes it easier to extend the code and reduces the risk of regressions. It also makes it possible again to use the boards EM2750_BOARD_DLCW_130, EM2820_BOARD_VIDEOLOGY_20K14XUSB and EM2860_BOARD_NETGMBH_CAM (using the module parameter "card"). NOTE: the current board hint logic for webcams is preserved. Not more not less. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: ignore isoc DVB USB endpoints with wMaxPacketSize = 0 bytes ↵Frank Schaefer2013-03-28
| | | | | | | | | | | | | | for all alt settings Some devices without DVB support (such as the "Terratec Grabby" and "Easycap DC-60") provide isochronous DVB USB endpoints with wMaxPacketSize set to 0 bytes for all alt settings. Ignore these endpoints and avoid registering a DVB device node and loading the DVB driver extension. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Tested-by: Timo Teräs <timo.teras@iki.fi> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: write output frame resolution to regs 0x34+0x35 for em25xx ↵Frank Schaefer2013-03-28
| | | | | | | | | | | family bridges The Windows driver writes the output resolution to registers 0x34 (width / 16) and 0x35 (height / 16) always. We don't know yet what these registers are used for. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: make em28xx_set_outfmt() working with EM25xx family bridgesFrank Schaefer2013-03-28
| | | | | | | | | | Streaming doesn't work with the EM2765 if bit 5 of the output format register 0x27 is set. It's actually not clear if really has to be set for the other chips, but for now let's keep it to avoid regressions and add a comment to the code. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add support for em25xx/em276x/em277x/em278x frame data ↵Frank Schaefer2013-03-28
| | | | | | | | | | | | processing The em25xx/em276x/em277x/em278x frame data format is different to the one used by the em2710/em2750/em28xx chips. With the recent cleanups and reorganization of the frame data processing code it can be easily extended to support these devices. Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: add chip id of the em2765Frank Schaefer2013-03-28
| | | | | | | This chip can be found in the SpeedLink VAD Laplace webcam (1ae7:9003 and 1ae7:9004). Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [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: add support for g_chip_nameHans Verkuil2013-03-25
| | | | | | | | | Add support for vidioc_g_chip_name, allowing AC97 to be implemented as a second chip on the bridge with the name "ac97". v4l2-dbg can just match the name with that string in order to detect a ac97-compliant set of registers. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.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] v4l2: add const to argument of write-only s_register ioctlHans Verkuil2013-03-24
| | | | | | | | | This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] v4l2: pass std by value to the write-only s_std ioctlHans Verkuil2013-03-24
| | | | | | | | | | | | | This ioctl is defined as IOW, so pass the argument by value instead of by reference. I could have chosen to add const instead, but this is 1) easier to handle in drivers and 2) consistent with the s_std subdev operation. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] v4l2: add const to argument of write-only s_tuner ioctlHans Verkuil2013-03-24
| | | | | | | | | This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Alexey Klimov <klimov.linux@gmail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] v4l2: add const to argument of write-only s_frequency ioctlHans Verkuil2013-03-24
| | | | | | | This ioctl is defined as IOW, so pass the argument as const. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx: tuner setup is broken after algo_data changeHans Verkuil2013-03-22
| | | | | | | | | | Commit aab3125c43d8fecc7134e5f1e729fabf4dd196da broke em28xx. I traced this eventually to the change in what algo_data points to. This pointer is also passed to em28xx_tuner_callback() through several hidden tuner layers (yuck!) and that callback was not updated. Signed-off-by: Hans Verkuil <hans.verkuil@cisco.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: Add ISDB support for c3tech Digital duoMauro Carvalho Chehab2013-03-19
| | | | | | | | This is an hybrid board. However, for analog, it requires a new driver for saa7136. So, for now, let's just add support for Digital TV. 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: set the timestamp type for video and vbi vb2_queuesFrank Schaefer2013-03-18
| | | | | | | | | | | The em28xx driver obtains the timestamps using function v4l2_get_timestamp(), which produces a montonic timestamp. Fixes the warnings appearing in the system log since commit 6aa69f99 "[media] vb2: Add support for non monotonic timestamps" Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Acked-by: Hans Verkuil <hans.verkuil@cisco.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: Add a separate config dir for secondary busMauro Carvalho Chehab2013-03-18
| | | | | | | | | | | | Prepare to register a separate bus for the second bus. For now, just add a new field. A latter patch will add the bits to make it work. This patch was generated by this script: perl -e 'while (<>) { if (s/EM2874_I2C_SECONDARY_BUS_SELECT.*\n//) { printf "\t\t.def_i2c_bus = 1,\n"; $found = 1; print $_ } else { if ($found) { s/^\s+// }; $found = 0; print $_; } }' \ drivers/media/usb/em28xx/em28xx-cards.c >a && mv a drivers/media/usb/em28xx/em28xx-cards.c 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: enable tveeprom for device Hauppauge HVR-930CFrank Schaefer2013-03-04
| | | | | Signed-off-by: Frank Schäfer <fschaefer.oss@googlemail.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* [media] em28xx-dvb: Don't put device in suspend mode at feed stopMauro Carvalho Chehab2013-03-04
| | | | | | | | | | | | | | | | | | | Putting em28xx in suspend mode when a feed stops is just plain wrong. Every time a new PES filter is changed, the DVB demux code will stop the current feed, and then start a new one. If are there any code that switches off the frontend, via some GPIO setting, this would make the DVB fail. This condition was actually trigged with one device, during DVB scan, as, during scan, it is common that userspace apps to change the filter several times, in order to get all tables. Also, this is not needed at all, since the em28xx code already hooks into ops.ts_bus_ctrl(). This warrants that em28xx can check there if DVB frontend is in usage or not. The code there already puts the device on suspend mode, if the DVB frontend is not used (closed). 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>
generated by cgit v1.2.2 (git 2.25.0) at 2025-04-11 18:21:05 -0400