From: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
From: Michael Krufky <mkrufky@kernellabs.com> Enable the standby mode optimization to disable the tda18271 slave tuner output / loop thru options when in low power mode Priority: normal Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
From: Jean Delvare <khali@linux-fr.org> There is no point in defining I2C adapter IDs when no code is using them. As this field might go away in the future, stop using it when we don't need to. Signed-off-by: Jean Delvare <khali@linux-fr.org> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
From: Mike Isely <isely@pobox.com> This change does not change any outward behavior; it merely chops down some large if-conditions with embedded assignments into something a little more maintainable for others (I of course never had a problem with this...). Priority: normal Signed-off-by: Mike Isely <isely@pobox.com>
From: Mike Isely <isely@pobox.com> The pvrusb2 driver has a concept of "routing scheme" which defines which physical inputs should be connected based on application's choice of logical input. The correct "routing scheme" depends on the specific device since different devices might wire up their muxes differently - it can't be coded into the sub-device driver and it can't be just a single setting in the pvrusb2 driver since the driver handles multiple different devices. This concept has been in place for a while and works, however there are cases where a specific input for a specific device has no route - previously due to an oversight this was handled badly. With these changes the driver can now specifically recognize cases where there is no defined route for a given input. Priority: normal Signed-off-by: Mike Isely <isely@pobox.com>
From: Mike Isely <isely@pobox.com> 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). Priority: normal Signed-off-by: Mike Isely <isely@pobox.com>
From: Mike Isely <isely@pobox.com> 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. Priority: high Signed-off-by: Mike Isely <isely@pobox.com>
From: Mike Isely <isely@pobox.com> 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. Priority: high Signed-off-by: Mike Isely <isely@pobox.com>
From: Mauro Carvalho Chehab <mchehab@redhat.com> Mostly due to ir-kdb-i2c, but also due to two new drivers, compilation with kernels older than 2.6.29 were broken. This quick and dirty changeset, generated semi-automatically, restaures backport to the subsystem by adding lots of #ifs. It is possible to write a much more small changeset that would restore backport without adding so many ifs, but, due to the lack of time, this will also solve it. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
From: Mauro Carvalho Chehab <mchehab@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>