- 20 May, 2011 40 commits
-
-
Stefan Ringel authored
vitual input enums Signed-off-by:
Stefan Ringel <stefan.ringel@arcor.de> Signed-off-by:
Mauro Carvalho Chehab <mchehab@redhat.com>
-
Stefan Ringel authored
change to virtual inputs Signed-off-by:
-
Stefan Ringel authored
add tm6010 audio mode setup Signed-off-by:
-
Stefan Ringel authored
add radio capabilities Signed-off-by:
-
Huzaifa Sidhpurwala authored
Make sure pdev is not dereferenced when it is null Signed-off-by:
Huzaifa Sidhpurwala <huzaifas@redhat.com> Signed-off-by:
-
Andreas Oberritter authored
Signed-off-by:
Andreas Oberritter <obi@linuxtv.org> Signed-off-by:
-
Andreas Oberritter authored
- Holds the parameters detected by the demod. - Updated on every call to get_frontend, either through ioctl or when a frontend event occurs. - Reset to input parameters after every call to set_frontend, tune or search/track. Signed-off-by:
-
Andreas Oberritter authored
Signed-off-by:
-
Andreas Oberritter authored
Signed-off-by:
-
Andreas Oberritter authored
- Preparation to distinguish input parameters from output parameters. Signed-off-by:
-
Andreas Oberritter authored
- Drivers should be able to override properties returned to the user. - The default values get prefilled from the cache. Signed-off-by:
-
Andreas Oberritter authored
- Use const pointers and remove assignments. - delivery_system already gets assigned by DTV_DELIVERY_SYSTEM and dtv_property_cache_sync. Signed-off-by:
-
Steve Kerrison authored
This is supported in DVB-T2 mode, so added to the T/T2 frontend. Signed-off-by:
Steve Kerrison <steve@stevekerrison.com> Acked-by:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Steve Kerrison authored
A few new capabilities added to frontend.h for DVB-T2. Added these to the documentation plus some notes explaining that they are used by the T2 delivery system. Signed-off-by:
-
Andreas Oberritter authored
drivers/media/common/tuners/mxl5005s.c: In function ‘mxl5005s_set_params’: drivers/media/common/tuners/mxl5005s.c:4016: warning: enumeration value ‘BANDWIDTH_5_MHZ’ not handled in switch drivers/media/common/tuners/mxl5005s.c:4016: warning: enumeration value ‘BANDWIDTH_10_MHZ’ not handled in switch drivers/media/common/tuners/mxl5005s.c:4016: warning: enumeration value ‘BANDWIDTH_1_712_MHZ’ not handled in switch Signed-off-by:
-
Andreas Oberritter authored
drivers/media/dvb/frontends/drxd_hard.c: In function ‘DRX_Start’: drivers/media/dvb/frontends/drxd_hard.c:2327: warning: enumeration value ‘BANDWIDTH_5_MHZ’ not handled in switch drivers/media/dvb/frontends/drxd_hard.c:2327: warning: enumeration value ‘BANDWIDTH_10_MHZ’ not handled in switch drivers/media/dvb/frontends/drxd_hard.c:2327: warning: enumeration value ‘BANDWIDTH_1_712_MHZ’ not handled in switch [mchehab@redhat.com: removed the status = status assignment after the switch] Signed-off-by:
-
Andreas Oberritter authored
[steve@stevekerrison.com: Remove private definitions from cxd2820r that existed before API was defined] Signed-off-by:
-
Julia Lawall authored
ictx->touch is intialied in imon_init_intf1, to the result of calling the function that contains this code. Thus, in this code, input_free_device should be called on touch itself. A simplified version of the semantic match that finds this problem is: (http://coccinelle.lip6.fr/) // <smpl> @r exists@ local idexpression struct input_dev * x; expression ra,rr; position p1,p2; @@ x = input_allocate_device@p1(...) ... when != x = rr when != input_free_device(x,...) when != if (...) { ... input_free_device(x,...) ...} if(...) { ... when != x = ra when forall when != input_free_device(x,...) \(return <+...x...+>; \| return@p2...; \) } @script:python@ p1 << r.p1; p2 << r.p2; @@ cocci.print_main("input_allocate_device",p1) cocci.print_secs("input_free_device",p2) // </smpl> Signed-off-by:
Julia Lawall <julia@diku.dk> Signed-off-by:
Jarod Wilson <jarod@redhat.com> Signed-off-by:
-
Devin Heitmueller authored
Enable the IR support for the Hauppauge HVR-1150 and HVR-1120. Thanks to Fernando Laudares Camargos for testing the patch. Signed-off-by:
Devin Heitmueller <dheitmueller@kernellabs.com> Cc: Fernando Laudares Camargos <fernando.laudares.camargos@gmail.com> Signed-off-by:
-
Jarod Wilson authored
This is a new rc-core device driver for the IR transceivers made by RedRat Ltd. (http://redrat.co.uk/). It started out life as an out-of-lirc-tree lirc driver, maintained in its own repo on sourceforge, by Stephen Cox. He started porting it to what was then ir-core, and I finally picked it up about two week ago and did a fairly large overhaul on it, and its now into a state where I'm fairly comfortable submitting it here for review and inclusion in the kernel. I'm claiming authorship of this driver, since while it started out as Stephen's work, its definitely a derivative work now, at 876 lines added and 1698 lines removed since grabbing it from sourceforge. Stephen's name is retained as secondary author though, and credited in the headers. Those interested in seeing how the changes evolved can (at least for now) look at this branch in my git tree: http://git.kernel.org/?p=linux/kernel/git/jarod/linux-2.6-ir.git;a=shortlog;h=refs/heads/redrat3 That won't be around forever though, and I'm doing this as a single commit to go into mainline. Anyway... I've successfully tested in-kernel decode of rc5, rc6 and nec remotes, as well as lirc userspace decode of rc5 and rc6. There are still some quirks here to sort out with rc5 lirc userspace decode, but I'm working with the RedRat folks themselves to figure out what's going on there (rc5 lirc decode works, but you only get an event on key release -- in-kernel rc5 decode behaves perfectly fine). Note that lirc decode of rc6 is working perfectly. Transmit is also working, tested by pointing the redrat3 at an mceusb transceiver, which happily picked up the transmitted signals and properly decoded them. There's no default remote for this hardware, so its somewhat arbitrarily set to use the Hauppauge RC5 keymap by default. Easily changed out by way of ir-keytable and irrelevant if you're using lircd for decode. CC: Chris Dodge <chris@redrat.co.uk> CC: Andrew Vincer <Andrew.Vincer@redrat.co.uk> CC: Stephen Cox <scox_nz@yahoo.com> Signed-off-by:
-
Jarod Wilson authored
When device_add is called in rc_register_device, the rc sysfs nodes show up, and there's a window in which ir-keytable can be launched via udev and trigger a show_protocols call, which runs without various rc_dev fields filled in yet. Add some locking around registration and store/show_protocols to prevent that from happening. The problem manifests thusly: [64692.957872] BUG: unable to handle kernel NULL pointer dereference at 0000000000000090 [64692.957878] IP: [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957890] PGD 19cfc7067 PUD 19cfc6067 PMD 0 [64692.957894] Oops: 0000 [#1] SMP [64692.957897] last sysfs file: /sys/devices/pci0000:00/0000:00:03.1/usb3/3-1/3-1:1.0/rc/rc2/protocols [64692.957902] CPU 3 [64692.957903] Modules linked in: redrat3(+) ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_hauppauge ir_nec _decoder rc_core ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_mi di_event snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_seq snd_pcm snd_seq_device snd_timer snd_page_alloc snd_util_mem pcsp kr tg3 snd_hwdep emu10k1_gp snd amd64_edac_mod gameport edac_core soundcore edac_mce_amd k8temp shpchp i2c_piix4 lm63 e100 mii uinput ipv6 raid0 rai d1 ata_generic firewire_ohci pata_acpi firewire_core crc_itu_t sata_svw pata_serverworks floppy radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: redrat3] [64692.957949] [64692.957952] Pid: 12265, comm: ir-keytable Tainted: G M W 2.6.39-rc6+ #2 empty empty/TYAN Thunder K8HM S3892 [64692.957957] RIP: 0010:[<ffffffffa036a4c1>] [<ffffffffa036a4c1>] show_protocols+0x47/0xf1 [rc_core] [64692.957962] RSP: 0018:ffff880194509e38 EFLAGS: 00010202 [64692.957964] RAX: 0000000000000000 RBX: ffffffffa036d1e0 RCX: ffffffffa036a47a [64692.957966] RDX: ffff88019a84d000 RSI: ffffffffa036d1e0 RDI: ffff88019cf2f3f0 [64692.957969] RBP: ffff880194509e68 R08: 0000000000000002 R09: 0000000000000000 [64692.957971] R10: 0000000000000002 R11: 0000000000001617 R12: ffff88019a84d000 [64692.957973] R13: 0000000000001000 R14: ffff8801944d2e38 R15: ffff88019ce5f190 [64692.957976] FS: 00007f0a30c9a720(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000 [64692.957979] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [64692.957981] CR2: 0000000000000090 CR3: 000000019a8e0000 CR4: 00000000000006e0 [64692.957983] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [64692.957986] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [64692.957989] Process ir-keytable (pid: 12265, threadinfo ffff880194508000, task ffff88019a9fc720) [64692.957991] Stack: [64692.957992] 0000000000000002 ffffffffa036d1e0 ffff880194509f58 0000000000001000 [64692.957997] ffff8801944d2e38 ffff88019ce5f190 ffff880194509e98 ffffffff8131484b [64692.958001] ffffffff8118e923 ffffffff810e9b2f ffff880194509e98 ffff8801944d2e18 [64692.958005] Call Trace: [64692.958014] [<ffffffff8131484b>] dev_attr_show+0x27/0x4e [64692.958014] [<ffffffff8118e923>] ? sysfs_read_file+0x94/0x172 [64692.958014] [<ffffffff810e9b2f>] ? __get_free_pages+0x16/0x52 [64692.958014] [<ffffffff8118e94c>] sysfs_read_file+0xbd/0x172 [64692.958014] [<ffffffff8113205e>] vfs_read+0xac/0xf3 [64692.958014] [<ffffffff8113347b>] ? fget_light+0x3a/0xa1 [64692.958014] [<ffffffff811320f2>] sys_read+0x4d/0x74 [64692.958014] [<ffffffff814c19c2>] system_call_fastpath+0x16/0x1b Its a bit difficult to reproduce, but I'm fairly confident this has fixed the problem. Signed-off-by:
-
Jarod Wilson authored
Signed-off-by:
-
Jarod Wilson authored
Reported-by:
Douglas Clowes <dclowes1@optusnet.com.au> Signed-off-by:
-
Jarod Wilson authored
Continuing with IR transmit after resuming from suspend seems fairly useless, given that the only place we can actually end up suspending is after IR has been send and we're simply mdelay'ing. Lets simplify the resume path by just waiting on tx to complete in the suspend path, then we know we can't be transmitting on resume, and reinitialization of the hardware registers becomes more straight-forward. CC: Juan Jesús García de Soria <skandalfo@gmail.com> Signed-off-by:
-
Jarod Wilson authored
There was some rather odd spacing in a few of the ite8709-specific functions that made it hard to read those sections of code. This is just a simple reformatting. CC: Juan Jesús García de Soria <skandalfo@gmail.com> Signed-off-by:
-
Jarod Wilson authored
Just recently acquired an Asus Eee Box PC with an onboard IR receiver driven by ite-cir (ITE8713 sub-variant). Works out of the box with the ite-cir driver in 2.6.39, but stops working after a suspend/resume cycle. Its fixed by simply reinitializing registers after resume, similar to what's done in the nuvoton-cir driver. I've not tested with any other ITE variant, but code inspection suggests this should be safe on all variants. Reported-by:
Stephan Raue <sraue@openelec.tv> CC: Juan Jesús García de Soria <skandalfo@gmail.com> Signed-off-by:
-
Jarod Wilson authored
- Eliminate a possible circular locking lockdep warning - Make sure we don't try to unregister a vfd on a device w/a vga screen - Always free imon context after devices are removed (display_close can just error out w/no context) Signed-off-by:
-
Jarod Wilson authored
- Set a default timeout (matching mceusb.c) and use ir_raw_event_store_with_filter, which leads to better behavior when using lirc userspace decoding with this hardware - Fill in rx_resolution with the value we're using here (50us) - Wire up input phys and device parent pointer - Use device_init_wakeup() instead of device_set_wakeup_*() Signed-off-by:
-
Hans de Goede authored
The M420 format is used by the Microsoft LifeCam Studio HD. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> [laurent.pinchart@ideasonboard.com: split into v4l/uvcvideo patches] Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Hans de Goede authored
M420 is a hybrid YUV 4:2:0 packet/planar format. Two Y lines are followed by an interleaved U/V line. Signed-off-by:
-
Bob Liu authored
Add support to uvc driver for NOMMU arch including add function uvc_queue_get_unmapped_area() and make some changes in uvc_queue_mmap(). So that uvc camera can be used on nommu arch like blackfin. Signed-off-by:
Bob Liu <lliubbo@gmail.com> Signed-off-by:
-
Bob Liu authored
This reverts commit c29fcff3. Signed-off-by:
-
Teresa Gámez authored
This camera driver supports only rising edge, which is the default setting of the device. The function mt9m111_setup_pixfmt() overwrites this setting. So the driver actually uses falling edge. This patch corrects that. Signed-off-by:
Teresa Gámez <t.gamez@phytec.de> [g.liakhovetski@gmx.de: removed superfluous register write] Signed-off-by:
Guennadi Liakhovetski <g.liakhovetski@gmx.de> Tested-by:
-
Teresa Gámez authored
The setup of the pixel clock is done wrong in the mt9v022 driver. The 'Invert Pixel Clock' bit has to be set to 1 for falling edge and not for rising. This is not clearly described in the data sheet. Tested on pcm037 and pcm027/pcm990. Signed-off-by:
-
Guennadi Liakhovetski authored
soc_mbus_get_fmtdesc() returning NULL means only, that no standard mediabus code -> fourcc conversion is known, this shouldn't be treated as an error by drivers. Signed-off-by:
-
Guennadi Liakhovetski authored
Add new look-up entries for all mediabus codes, for which respective fourcc codes exist. Signed-off-by:
-
Guennadi Liakhovetski authored
12-bit formats, similar to YUV 4:2:0 occupy 3 bytes for each two pixels and cannot be described by any of the existing SOC_MBUS_PACKING_* macros. This patch adds a new one SOC_MBUS_PACKING_1_5X8 to describe such formats and extends soc_mbus_samples_per_pixel() to support it. Signed-off-by:
-
Guennadi Liakhovetski authored
Since V4L2_MBUS_FMT_* codes have become large and sparse, they cannot be used as array indices anymore. Signed-off-by:
-
Guennadi Liakhovetski authored
Recently mediabus pixel format codes have become a part of the user- space API, at which time their values also have been changed from contiguous numbers, running from 0 to sparse numbers with values around 0x1000, 0x2000, 0x3000... This made them unsuitable for the use as array indices. This patch switches soc-camera internal format look-ups to not depend on values of those macros. Signed-off-by:
-
Kassey Li authored
Signed-off-by:
Kassey Lee <ygli@marvell.com> Signed-off-by:
Qing Xu <qingx@marvell.com> Signed-off-by:
-
