This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git.
Pull mirroring updated .
- Aug 31, 2011
-
-
Thierry Reding authored
Video data is useless in radio mode, so the corresponding interface can be safely disabled. This should reduce the amount of isochronous traffic noticeably. Signed-off-by:
Thierry Reding <thierry.reding@avionic-design.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Thierry Reding authored
The register ACTIVE_VIDEO_IF register should be named ACTIVE_IF since it controls more than just the video interface. Signed-off-by:
-
Thierry Reding authored
This brings the IRQ callback implementation more in line with how other drivers do it. Signed-off-by:
-
Thierry Reding authored
Signed-off-by:
-
Thierry Reding authored
In radio mode, the correct input is rinput. The pseudo index 5 is used but cannot be used to index the vinput array because that only has 3 elements. Signed-off-by:
-
Thierry Reding authored
This commit fixes a number of coding style issues as well as some issues reported by checkpatch and sparse. Signed-off-by:
-
Mauro Carvalho Chehab authored
In radio mode, no frequency offset should be used. Instead of taking Thierry's patch that creates a separate function to calculate the digital offset, it seemed better to just keep everything at the same place. Reported-by:
-
Thierry Reding authored
When loading the firmware, complete each chunk by sending an I2C flush command to the frontend. Some devices like the tm6000 seem to require this to properly flush the I2C buffers. The current code in tm6000 executes the flush command once after each I2C transfer, which slows down the firmware loading especially when loading large BASE type images. Signed-off-by:
-
- Aug 29, 2011
-
-
Sakari Ailus authored
The ccdc block in the omap3isp produces events whenever it starts receiving a new frame. A private HS_VS event was used for this previously. Now, the generic V4L2_EVENT_FRAME_SYNC event is being used for the purpose. This patch also provides the frame sequence number to user space. Signed-off-by:
Sakari Ailus <sakari.ailus@iki.fi> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Sakari Ailus authored
Define a frame sync event to tell user space when the reception of a frame starts. Signed-off-by:
-
- Aug 27, 2011
-
-
Jose Alberto Reguero authored
Signed-off-by:
Jose Alberto Reguero <jareguero@telefonica.net> Reviewed-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
istvan_v@mailbox.hu authored
This patch reduces the number of available choices for the notch filter type control so that the standard-specific filter types cannot be selected. It is now limited to being either 0 (4xFsc, the default) or 1 (square pixel optimized). The patch also removes the initialization of this control from cx88_reset(), since that is already done by init_controls(), which is called by cx8800_initdev(). Signed-off-by:
Istvan Varga <istvan_v@mailbox.hu> Signed-off-by:
-
Joe Perches authored
Use the more current logging styles with pr_fmt. Remove now unnecessary private include. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
-
Joe Perches authored
Deduplicate printk formats to save ~20KB text. $ size drivers/media/common/tuners/tda18271*o.* text data bss dec hex filename 10747 56 1920 12723 31b3 drivers/media/common/tuners/tda18271-common.o.new 18889 56 3112 22057 5629 drivers/media/common/tuners/tda18271-common.o.old 20561 204 4264 25029 61c5 drivers/media/common/tuners/tda18271-fe.o.new 31093 204 6000 37297 91b1 drivers/media/common/tuners/tda18271-fe.o.old 3681 6760 440 10881 2a81 drivers/media/common/tuners/tda18271-maps.o.new 5631 6760 680 13071 330f drivers/media/common/tuners/tda18271-maps.o.old Signed-off-by:
-
Antti Palosaari authored
Style issue. Signed-off-by:
-
Antti Palosaari authored
Thanks to Thomas Gutzler for reporting this. Signed-off-by:
-
Antti Palosaari authored
Signed-off-by:
-
Julia Lawall authored
Convert array index from the loop bound to the loop index. A simplified version of the semantic patch that fixes this problem is as // <smpl> @@ expression e1,e2,ar; @@ for(e1 = 0; e1 < e2; e1++) { <... ar[ - e2 + e1 ] ...> } // </smpl> Signed-off-by:Julia Lawall <julia@diku.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Julian Scheel authored
[media] Add support for new revision of KNC 1 DVB-C cards. Using tda10024 instead of tda10023, which is compatible to tda10023 driver Signed-off-by:
Julian Scheel <julian@jusst.de> Signed-off-by:
-
Benjamin Larsson authored
Signed-off-by:
Benjamin Larsson <benjamin@southpole.se> Signed-off-by:
-
Malcolm Priestley authored
Driver for Kworld UB499-2T (id 1b80:e409) The device driver has been named it913x, so that support for other family members can be added later. TODOs Firmware support for other it913x devices. Remote control support, there are two known types. Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> [mchehab@redhat.com: Fix a merge conflict] Signed-off-by:
-
Malcolm Priestley authored
Firmware information for Kworld UB499-2T T09 based on IT913x series. This device uses file dvb-usb-it9137-01.fw. Signed-off-by:
-
Malcolm Priestley authored
Fronted and Tuner Driver for ITE IT913x Series with inital support for IT9137 integrated demodulator and tuner device. The driver is loosely based on AF9035 series. However, support is not intended for this device specificity. The IT9137 tuner has been tested on UHF bands, but VHF has only been simulated. Possible TODO the tuner sections may be separated from the main driver. All future devices should use the it913x_fe_script_loader for other tuner devices. Signed-off-by:
-
Doron Cohen authored
Siano modules already had sms_dbg flag which is a module parameter which sets the debug mode so module prints messages to dmesg for debugging. The variable was static therefore apply only to the file which defines the module. In modules as smsmdtv.ko that contain a few files, the debug flag applied only for functions in that main file. flag was changed to be non-static and therefore can be accessed by all module files (although it is still not exported out of the module). Signed-off-by:
Doron Cohen <doronc@siano-ms.com> Signed-off-by:
-
Jarod Wilson authored
Add note about recent updates coming from Microsoft's publicly available specs on Windows Media Center remotes and receivers/transmitters. Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Jarod Wilson authored
Rather than dumping out hex values, lets print the actual calculated frequency and period the hardware has been configured for. After this [ 2643.276215] mceusb 3-1:1.0: tx data: 9f 07 (length=2) [ 2643.276218] mceusb 3-1:1.0: Get carrier mode and freq [ 2643.277206] mceusb 3-1:1.0: rx data: 9f 06 01 42 (length=4) [ 2643.277209] mceusb 3-1:1.0: Got carrier of 37037 Hz (period 27us) Matches up perfectly with the table in Microsoft's docs. Of course, I've noticed on one of my devices that the MS-recommended default value of 1 for carrier pre-scaler and 66 for carrier period was butchered, and instead of converting 66 to hex (0x42 like above), they put in 0x66, so the hardware reports a default carrier of 24390Hz. Fortunately, I guess, this particular device is rx-only, but I wouldn't put it past other hw to screw up here too. Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
According to the specs, you can read the number of tx ports, number of rx sensors, which tx ports have cables plugged into them, and which rx sensors are active. In practice, most of my devices do seem to report sane values for tx ports and rx sensors (but not all -- one without any tx ports reports having them), and most report the active sensor correctly, but only one of eight reports cabled tx ports correctly. So for the most part, this is just for informational purposes. Signed-off-by:
-
Jarod Wilson authored
Supposedly, there are essentially three different classes of devices that are compatible with Microsoft's specs. First are the "legacy" devices, which are built using Microsoft-provided hardware specs and firmware. Second are "emulator" devices, which are built using custom hardware and firmware, written to emulate Microsoft's firmware. Third are "port" devices, which have their own device driver and firmware, which provides compatible data to higher levels of the stack. >From what I can tell, things like nuvoton-cir and fintek-cir are essentially "port" devices -- their raw IR buffer format is very similar to that of the mceusb devices. Now, within the mceusb driver, we have three different "generations", which at first, seemed like maybe they mapped to emulator versions. Unfortuantely, every single device I have responds "illegal command" to the query to get firmware emulator version from the hardware, which means they're either all emulator version 1, or they're legacy devices, and our different "generations" aren't at all related here. Though in theory, its possible the gen1 devices are "legacy" devices and the rest are emulator v1. There are some useful features of the v2 interface I was hoping to play with, but alas... Signed-off-by:
-
Jarod Wilson authored
According to MS docs, the device firmware may halt after receiving an unknown instruction, but that it should be possible to tell the firmware to continue running by simply sending a device resume command. So lets do that. Signed-off-by:
-
Jarod Wilson authored
Its not uncommon for folks to force these bits enabled, because people do want to wake their htpc kit via their remote. Lets just set the bits for 'em. Signed-off-by:
-
Jarod Wilson authored
Sometimes the init routine is blasting commands out to the hardware faster than it can reply. Throw a brief delay in there to give the hardware a chance to reply before we send the next command. Signed-off-by:
-
Jarod Wilson authored
I was recently pointed to the document titled Windows-Media-Center-RC-IR-Collection-Green-Button-Specification-03-08-2011-V2.pdf which as of this writing, is publicly available from download.microsoft.com. It covers a LOT of the gaps in the mceusb driver, which to this point, was written almost entirely by reverse-engineering. First up, I'm updating the defines for all the MCE commands and responses to match their names in the spec. More to come... Signed-off-by:
-
- Aug 07, 2011
-
-
Jose Alberto Reguero authored
tda827x is currently taking the demod IF frequency into account while seeking for the proper tuner range. This is wrong, as the demod IF frequency has nothing to do with the tuner PLL. Signed-off-by:
-
Luiz Ramos authored
Hello, When migrating from Slackware 13.1 to 13.37 (kernel 2.6.33.x to 2.6.37.6), there was some sort of regression with the external webcam installed at the notebook (0x45:6128, SN9C325+OM6802). In the version 2.6.37.6, the images got *very* dark, making the webcam almost unusable, unless if used with direct sunlight. Tracing back what happened, I concluded that changeset 0e4d413a caused some sort of odd effects - including this - to this specific model. Signed-off-by:
Luiz Carlos Ramos <lramos.prof@yahoo.com.br> Acked-by:
Jean-François Moine <moinejf@free.fr> Signed-off-by:
-
- Aug 06, 2011
-
-
Jarod Wilson authored
There are folks with flaky imon hardware out there that doesn't always respond to requests to write to their displays for some reason, which can flood logs quickly when something like lcdproc is trying to constantly update the display, so lets rate-limit all that error spew. Signed-off-by:
-
Ming Lei authored
If the bus has been reset on resume, set the alternate setting to 0. This should be the default value, but some devices crash or otherwise misbehave if they don't receive a SET_INTERFACE request before any other video control request. Microdia's 0c45:6437 camera has been found to require this change or it will stop sending video data after resume. uvc_video.c] Signed-off-by:
Ming Lei <ming.lei@canonical.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
This device is not using the proper demod IF. Instead of using the IF macro, it is specifying a IF frequency. This doesn't work, as xc3028 needs to load an specific SCODE for the tuner. In this case, there's no IF table for 5 MHz. Cc: stable@kernel.org Signed-off-by: -
Sakari Ailus authored
Move documentation of structures used in DQEVENT from SUBSCRIBE_EVENT to DQEVENT. Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Andy Shevchenko authored
Potentially the adp1653_init_controls could return an error. In our case the error was ignored, meanwhile it means incorrect initialization of V4L2 controls. Additionally we have to free control handler structures in case of apd1653_init_controls or media_entity_init failure. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Cc: Sakari Ailus <sakari.ailus@iki.fi> Signed-off-by:
-
