- 19 5月, 2010 1 次提交
-
-
由 Hans Verkuil 提交于
Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 27 2月, 2010 4 次提交
-
-
由 Mike Isely 提交于
We know that the 300msec settling time after starting the digitizer is only really needed when the digitizer is a SAA7115. So if we're not using a SAA7115, skip the delay. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
After implementing a 300msec wait between digitizer start and encoder start, it has been determined that we don't need to wait quite as long before configuring the encoder. This reduces the wait period from 100msec back to 50msec. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Martin Dauskardt <martin.dauskardt@gmx.de> has determined that the encoder has a much better chance of starting cleanly if we deliberately hold off starting it util the video digitizer has had a chance to run for at least 300msec first. These changes implement an enforced 300msec wait in the state machine that orchestrates streaming start / stop. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Andy Walls 提交于
This change attempts to fix the ivtv tinny audio problem by keeping digitizer to encoder audio clocks running, while disabling the video clocks as needed to avoid unpredictable PCI bus hangs. To accomplish this, for the cx25840 module enabling of audio streaming had to be separated from enabling video streaming, requiring an additional v4l2_subdev_audio_op and calls to this new op in the pvrusb2 and ivtv drivers. The cx231xx and cx23885 driver use the cx25840 module for affecting only video on s_stream calls, so those drivers needed no change. The CX23418 hardware does not exhibit either the tinny audio problem nor the PCI bus hang, so the cx18 driver did not need corresponding changes. CX2341[56] based cards that are not using the CX2584x family of chips do not seem to be affected by the tinny audio problem, and this change should not affect how they are configured. It will delay their first capture by starting by another 300 msec though. Many thanks go to Argus <pthorn-ivtvd@styx2002.no-ip.org> and Martin Dauskardt <martin.dauskardt@gmx.de> whose persistent testing and investigation of this problem will hopefully fix this problem once and for all for many ivtv users. Reported-by: NMartin Dauskardt <martin.dauskardt@gmx.de> Reported-by: NArgus <pthorn-ivtvd@styx2002.no-ip.org> Signed-off-by: NAndy Walls <awalls@radix.net> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 06 12月, 2009 8 次提交
-
-
由 Gary Francis 提交于
These are additional fixes to enable proper pvrusb2 support of 16KB sized FX2 firmware. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
This pvrusb2 change is in support of an existing feature used to help identify and locate newer vendor supplied firmware. This change makes the feature work for the newer larger firmware size. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
New FX2 firmware from Hauppauge is no longer 8KB in size - it's 16KB. This is true for HVR-1950 and HVR-1900 devices. Without this change, new pvrusb2 users with that hardware are unable to use the driver (because the CD shipped with the hardware only has the 16KB firmware). Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
After detecting failure due to module initialization error, get out. Don't report jammed hardware. Problem due to a missing break statement. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
The driver also contains a piece of configuration data that produces a one line description of the specific hardware being driver (e.g. "Hauppauge 24xxx", "OnAir", etc). This change generates an informational message to the kernel log reporting the hardware type being driven. This is a very useful thing to know when diagnosing problems. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
It used to be that the only real detectable reason for the driver to fail during initialization would be that if the hardware is simply jammed. However with the advent of the sub-device mechanism in V4L it is possible now to detect if a sub-device module fails to load successfully. The pvrusb2 driver does in fact react to this by also (correctly) failing, however the original diagnostic message "hardware is jammed" was still being reported. This misleads the user because in fact it might not actually be a hardware failure. This change adds logic to tell the difference and then report a more appropriate message to the kernel log. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 19 9月, 2009 1 次提交
-
-
由 Hans Verkuil 提交于
Rewrite v4l2_i2c_new_subdev as a simplified version of v4l2_i2c_new_subdev_cfg and remove v4l2_i2c_new_probed_subdev and v4l2_i2c_new_probed_subdev_addr. This simplifies this API substantially. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 23 6月, 2009 3 次提交
-
-
由 Mike Isely 提交于
Change default frequency to be US Broadcast channel 3 - with the transition to d igital the previous value has now become useless. This change is PURELY to help with my testing (I need to set some kind of default so it might as well be some thing usable). Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
The cx25840 module's VBI initialization logic uses the current video standard as part of its internal algorithm. This therefore means that we probably need to make sure that the correct video standard has been set before initializing VBI. (Normally we would not care about VBI, but as described in an earlier changeset, VBI must be initialized correctly on the cx25840 in order for the chip's hardware scaler to operate correctly.) It's kind of messy to force the video standard to be set before initializing VBI (mainly because we can't know what the app really wants that early in the initialization process). So this patch does the next best thing: VBI is re-initialized after any point where the video standard has been set. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
The cx25840 module requires that its VBI initialization entry point be called in order for hardware-scaled video capture to work properly - even if we don't care about VBI. Making this behavior even more subtle is that if the capture resolution is set to 720x480 - which is the default that the pvrusb2 driver sets up - then the cx25840 bypasses the hardware scaler. Therefore this problem does not manifest itself until some other resolution, e.g. 640x480, is tried. MythTV typically defaults to 640x480 or 480x480, which means that things break whenever the driver is used with MythTV. This all has been known for a while (since at least Nov 2006), but recent changes in the pvrusb2 driver (specifically in regards to sub-device support) caused this to break again. VBI initialization must happen *after* the chip's firmware is loaded, not before. With this fix, 24xxx devices work correctly again. A related fix that is part of this changeset is that now we re-initialize VBI any time after we issue a reset to the cx25840 driver. Issuing a chip reset erases the state that the VBI setup previously did. Until the HVR-1950 came along this subtlety went unnoticed, because the pvrusb2 driver previously never issued such a reset. But with the HVR-1950 we have to do that reset in order to correctly transition from digital back to analog mode - and since the HVR-1950 always starts in digital mode (required for the DVB side to initialize correctly) then this device has never had a chance to work correctly in analog mode! Analog capture on the HVR-1950 has been broken this *ENTIRE* time. I had missed it until now because I've usually been testing at the default 720x480 resolution which does not require scaling... What fun. By re-initializing VBI after a cx25840 chip reset, correct behavior is restored. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 17 6月, 2009 2 次提交
-
-
由 Jean Delvare 提交于
The i2c core used to maintain a list of client for each adapter. This is a duplication of what the driver core already does, so this list will be removed as part of a future cleanup. Anyone using this list must stop doing so. For pvrusb2, I propose the following change, which should lead to an equally informative output. The only difference is that i2c clients which are not a v4l2 subdev won't show up, but I guess this case is not supposed to happen anyway. Signed-off-by: NJean Delvare <khali@linux-fr.org> Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
This change defines all possible "IR schemes" related to the pvrusb2 driver, on a per-device basis. That information is then set according to the hardware in use. The idea here is to make possible a more intelligent future decision on which, if any, IR receiver driver might be loaded during initialization. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 18 4月, 2009 1 次提交
-
-
由 David Vrabel 提交于
Wireless USB endpoint state has a sequence number and a current window and not just a single toggle bit. So allow HCDs to provide a endpoint_reset method and call this or clear the software toggles as required (after a clear halt, set configuration etc.). usb_settoggle() and friends are then HCD internal and are moved into core/hcd.h and all device drivers call usb_reset_endpoint() instead. If the device endpoint state has been reset (with a clear halt) but the host endpoint state has not then subsequent data transfers will not complete. The device will only work again after it is reset or disconnected. Signed-off-by: NDavid Vrabel <david.vrabel@csr.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 07 4月, 2009 5 次提交
-
-
由 Hans Verkuil 提交于
The functions v4l2_i2c_new_subdev and v4l2_i2c_new_probed_subdev relied on i2c_get_adapdata to return the v4l2_device. However, this is not always possible on embedded platforms. So modify the API to pass the v4l2_device pointer explicitly. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Hans Verkuil 提交于
s_std didn't belong in the tuner ops. Stricly speaking it should be part of the video ops, but it is used by audio and tuner devices as well, so it is more efficient to make it part of the core ops. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Hans Verkuil 提交于
The init callback was used in several places to load firmware. Make a separate load_fw callback for that. This makes the code a lot more understandable. Signed-off-by: NHans Verkuil <hverkuil@xs4all.nl> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Janne Grunau 提交于
Signed-off-by: NJanne Grunau <j@jannau.net> Acked-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Any time a struct (especially one not defined by this driver) is allocated, we MUST zero its underlying storage. This makes our usage of the struct predictable and robust against future changes where fields might be added that we don't know about. Failing to do this with tuner_setup left the config field uninitialized which then caused trouble with the tuner type used for HVR-1950 devices. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
- 30 3月, 2009 15 次提交
-
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Forgot to include the tda9887 component when moving to v4l2-subdev. I got fooled because its name is "tuner", the same as the tuner module. Silly me. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
This change removes the old i2c module controlling layer from the pvrusb2 driver. This is code that first had appeared in the driver back in December 2005. It's history. Now we use v4l2-subdev. Please note also that with this change, the driver will no longer be usable in kernels older that 2.6.22. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
The v4l2-subdev infrastructure requires that an initialization call must be issued to all attached sub-devices before normal operation can start. This change satisfies that requirement. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
When a pvrusb2 driver instance first initializes, we need to be sure to send out a complete state update for everything to all attached modules. The old i2c layer did this by keeping a separate mask of "stale" bits for each attached module - and setting that mask to all stale when that module attaches. But the new sub-device adaptation I've implemented here no longer has per-module stale bits. So instead there's now a global "force dirty" bit that is set upon instance initialization, before the sub-devices are attached. After the first update, this bit is cleared, allowing for normal update-on-dirty behavior. In this manner, we ensure that all sub-devices have been properly synchronized at initialization. Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
The tuner sub-device isn't going to work very well unless we tell it the correct tuner type to use... Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-
由 Mike Isely 提交于
Signed-off-by: NMike Isely <isely@pobox.com> Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
-