dvb_unregister_frontend hanging on fepriv-dvbdev-users when called from smsdvb_unregister_client
Hi, I am trying to figure out why the smsxxx MiniStick isn't unregistered correctly when I pull out the stick while kaffeine is playing. It gets as far as calling smsdvb_unregister_client dvb_unregister_frontend where it hangs at if (fepriv-dvbdev-users -1) wait_event(fepriv-dvbdev-wait_queue, fepriv-dvbdev-users==-1); When I move dvb_unregister_frontend further down, after dvb_dmxdev_release() and dvb_dmx_release() the deadlock is resolved. Pluging the stick back in and repeating the process results in an Ooops in the kdvb-ad thread however, which appears pretty exactly repeatable: Dec 8 22:31:55 localhost kernel: [24035.987045] BUG: unable to handle kernel paging request at 016a2cef Dec 8 22:31:55 localhost kernel: [24035.987052] IP: [c11d486b] do_raw_spin_lock+0xb/0x104 Dec 8 22:31:55 localhost kernel: [24035.987062] *pde = Dec 8 22:31:55 localhost kernel: [24035.987065] Oops: [#1] SMP DEBUG_PAGEALLOC Dec 8 22:31:55 localhost kernel: [24035.987069] last sysfs file: /sys/devices/platform/coretemp.1/temp1_input Dec 8 22:31:55 localhost kernel: [24035.987074] Modules linked in: smsdvb dvb_core rc_rc5_hauppauge_new ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder smsusb ir_nec_decoder smsmdtv ir_core ppp_deflate ppp_async crc_ccitt ppp_generic slhc fuse i915 drm_kms_helper drm i2c_algo_bit video output nfsd lockd nfs_acl auth_rpcgss exportfs autofs4 coretemp w83627ehf hwmon_vid hwmon tun sunrpc xt_multiport nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xt_tcpudp ipt_LOG xt_limit iptable_filter ip_tables x_tables ipv6 binfmt_misc dm_multipath snd_hda_codec_realtek snd_hda_intel deflate snd_hda_codec zlib_deflate ctr twofish_generic twofish_i586 twofish_common camellia rt2500usb arc4 snd_hwdep serpent ecb snd_seq_dummy snd_seq_oss blowfish cast5 des_generic snd_seq_midi_event xcbc snd_seq rmd160 sha512_generic snd_seq_device rt73usb snd_pcm_oss crc_itu_t crypto_null rt2x00usb snd_mixer_oss rt2x00lib snd_pcm iTCO_wdt iTCO_vendor_support snd_timer mac80211 i2c_i801 option snd intel_aDec 8 22:31:55 localhost kernel: gp i2c_core cfg80211 soundcore agpgart usb_wwan led_class psmouse snd_page_alloc r8169 ppdev mac_hid rfkill usbserial parport_pc mii processor button parport rtc_cmos pcspkr thermal evbug serio_raw piix ata_generic ide_pci_generic pata_acpi sha256_generic cbc aes_i586 aes_generic dm_crypt dm_snapshot dm_zero dm_mirror dm_region_hash dm_log dm_mod ehci_hcd [last unloaded: microcode] Dec 8 22:31:55 localhost kernel: [24035.987199] Dec 8 22:31:55 localhost kernel: [24035.987199] Dec 8 22:31:55 localhost kernel: [24035.987203] Pid: 22798, comm: kdvb-ad-0-fe-0 Not tainted 2.6.36.1v1 #4 945GCM-S/To Be Filled By O.E.M. Dec 8 22:31:55 localhost kernel: [24035.987206] EIP: 0060:[c11d486b] EFLAGS: 00010086 CPU: 1 Dec 8 22:31:55 localhost kernel: [24035.987209] EIP is at do_raw_spin_lock+0xb/0x104 Dec 8 22:31:55 localhost kernel: [24035.987211] EAX: 016a2ceb EBX: 016a2ceb ECX: EDX: Dec 8 22:31:55 localhost kernel: [24035.987214] ESI: 0246 EDI: 016a2ceb EBP: f134be98 ESP: f134be78 Dec 8 22:31:55 localhost kernel: [24035.987216] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Dec 8 22:31:55 localhost kernel: [24035.987219] Process kdvb-ad-0-fe-0 (pid: 22798, ti=f134a000 task=f036c800 task.ti=f134a000) Dec 8 22:31:55 localhost kernel: [24035.987221] Stack: Dec 8 22:31:55 localhost kernel: [24035.987223] f9a92613 c104095d 016a2cfb 016a2ceb 0246 016a2ceb Dec 8 22:31:55 localhost kernel: [24035.987230] 0 f134beb8 c13705f9 0002 f9a92613 016a2cd3 Dec 8 22:31:55 localhost kernel: [24035.987238] 0 f134bedc f9a92613 00c9 0286 f134bf14 f006eb20 Dec 8 22:31:55 localhost kernel: [24035.987246] Call Trace: Dec 8 22:31:55 localhost kernel: [24035.987254] [f9a92613] ? smscore_find_client+0x3c/0x8f [smsmdtv] Dec 8 22:31:55 localhost kernel: [24035.987260] [c104095d] ? lock_timer_base+0x1f/0x3e Dec 8 22:31:55 localhost kernel: [24035.987266] [c13705f9] ? _raw_spin_lock_irqsave+0x36/0x3f Dec 8 22:31:55 localhost kernel: [24035.987271] [f9a92613] ? smscore_find_client+0x3c/0x8f [smsmdtv] Dec 8 22:31:55 localhost kernel: [24035.987276] [f9a92613] ? smscore_find_client+0x3c/0x8f [smsmdtv] Dec 8 22:31:55 localhost kernel: [24035.987281] [f9a9277d] ? smscore_validate_client+0x35/0xab [smsmdtv] Dec 8 22:31:55 localhost kernel: [24035.987285] [f9a9284d] ? smsclient_sendrequest+0x5a/0x75 [smsmdtv] Dec 8 22:31:55 localhost kernel: [24035.987290] [f85de1f7] ? smsdvb_sendrequest_and_wait+0x1f/0x44 [smsdvb] Dec 8 22:31:55 localhost kernel: [24035.987294] [f85de250] ? smsdvb_send_statistics_request+0x34/0x36 [smsdvb] Dec 8 22:31:55 localhost kernel: [24035.987298] [f85de372] ? smsdvb_read_status+0x17/0x2f [smsdvb] Dec 8 22:31:55
[PATCH] keycodes for DSR-0112 remote bundled with Haupauge MiniStick
Hi,
Patch against kernel.org kernel, hope it applies cleanly everywhere.
Add kycodes for DSR-0112 remote that comes together with
Haupauge MiniStick
http://lirc.sourceforge.net/remotes/hauppauge/DSR-0112.jpg
Signed-off-by: Richard Zidlicky r...@linux-m68k.org
--- linux-2.6.36/drivers/media/IR/keymaps/rc-rc5-hauppauge-new.c.rz
2010-11-27 00:43:33.0 +0100
+++ linux-2.6.36/drivers/media/IR/keymaps/rc-rc5-hauppauge-new.c
2010-12-02 00:41:33.0 +0100
@@ -75,6 +75,44 @@
{ 0x1e3b, KEY_SELECT }, /* top right button */
{ 0x1e3c, KEY_ZOOM }, /* full */
{ 0x1e3d, KEY_POWER }, /* system power (green button) */
+
+ /* Keycodes for DSR-0112 remote bundled with Haupauge MiniStick */
+ { 0x1d00, KEY_0 },
+ { 0x1d01, KEY_1 },
+ { 0x1d02, KEY_2 },
+ { 0x1d03, KEY_3 },
+ { 0x1d04, KEY_4 },
+ { 0x1d05, KEY_5 },
+ { 0x1d06, KEY_6 },
+ { 0x1d07, KEY_7 },
+ { 0x1d08, KEY_8 },
+ { 0x1d09, KEY_9 },
+ { 0x1d0a, KEY_TEXT },
+ { 0x1d0d, KEY_MENU },
+ { 0x1d0f, KEY_MUTE },
+ { 0x1d10, KEY_VOLUMEUP },
+ { 0x1d11, KEY_VOLUMEDOWN },
+ { 0x1d12, KEY_CHANNEL },/* Prev.Ch .. ??? */
+ { 0x1d14, KEY_UP },
+ { 0x1d15, KEY_DOWN },
+ { 0x1d16, KEY_LEFT },
+ { 0x1d17, KEY_RIGHT },
+ { 0x1d1c, KEY_TV },
+ { 0x1d1e, KEY_NEXT }, /* | */
+ { 0x1d1f, KEY_EXIT },
+ { 0x1d20, KEY_CHANNELUP },
+ { 0x1d21, KEY_CHANNELDOWN },
+ { 0x1d24, KEY_LAST }, /* | */
+ { 0x1d25, KEY_OK },
+ { 0x1d30, KEY_PAUSE },
+ { 0x1d32, KEY_REWIND },
+ { 0x1d34, KEY_FASTFORWARD },
+ { 0x1d35, KEY_PLAY },
+ { 0x1d36, KEY_STOP },
+ { 0x1d37, KEY_RECORD },
+ { 0x1d3b, KEY_GOTO },
+ { 0x1d3d, KEY_POWER },
+ { 0x1d3f, KEY_HOME },
};
static struct rc_keymap rc5_hauppauge_new_map = {
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
DSR-0112 keymap file for v4l-utils/ir-keytable
Hi, attached the file so people can use the remote with other receivers as well. Richard scancode 0x1d00 = KEY_0 (0x0b) scancode 0x1d01 = KEY_1 (0x02) scancode 0x1d02 = KEY_2 (0x03) scancode 0x1d03 = KEY_3 (0x04) scancode 0x1d04 = KEY_4 (0x05) scancode 0x1d05 = KEY_5 (0x06) scancode 0x1d06 = KEY_6 (0x07) scancode 0x1d07 = KEY_7 (0x08) scancode 0x1d08 = KEY_8 (0x09) scancode 0x1d09 = KEY_9 (0x0a) scancode 0x1d0a = KEY_TEXT (0x184) scancode 0x1d0d = KEY_MENU (0x8b) scancode 0x1d0f = KEY_MUTE (0x71) scancode 0x1d10 = KEY_VOLUMEUP (0x73) scancode 0x1d11 = KEY_VOLUMEDOWN (0x72) scancode 0x1d12 = KEY_CHANNEL (0x16b) scancode 0x1d14 = KEY_UP (0x67) scancode 0x1d15 = KEY_DOWN (0x6c) scancode 0x1d16 = KEY_LEFT (0x69) scancode 0x1d17 = KEY_RIGHT (0x6a) scancode 0x1d1c = KEY_TV (0x179) scancode 0x1d1e = KEY_NEXT (0x197) scancode 0x1d1f = KEY_EXIT (0xae) scancode 0x1d20 = KEY_CHANNELUP (0x192) scancode 0x1d21 = KEY_CHANNELDOWN (0x193) scancode 0x1d24 = KEY_LAST (0x195) scancode 0x1d25 = KEY_OK (0x160) scancode 0x1d30 = KEY_PAUSE (0x77) scancode 0x1d32 = KEY_REWIND (0xa8) scancode 0x1d34 = KEY_FASTFORWARD (0xd0) scancode 0x1d35 = KEY_PLAY (0xcf) scancode 0x1d36 = KEY_STOP (0x80) scancode 0x1d37 = KEY_RECORD (0xa7) scancode 0x1d3b = KEY_GOTO (0x162) scancode 0x1d3c = KEY_EPG (0x16d) scancode 0x1d3d = KEY_POWER (0x74) scancode 0x1d3f = KEY_HOME (0x66) scancode 0x1e00 = KEY_0 (0x0b) scancode 0x1e01 = KEY_1 (0x02) scancode 0x1e02 = KEY_2 (0x03) scancode 0x1e03 = KEY_3 (0x04) scancode 0x1e04 = KEY_4 (0x05) scancode 0x1e05 = KEY_5 (0x06) scancode 0x1e06 = KEY_6 (0x07) scancode 0x1e07 = KEY_7 (0x08) scancode 0x1e08 = KEY_8 (0x09) scancode 0x1e09 = KEY_9 (0x0a) scancode 0x1e0a = KEY_TEXT (0x184) scancode 0x1e0b = KEY_RED (0x18e) scancode 0x1e0c = KEY_RADIO (0x181) scancode 0x1e0d = KEY_MENU (0x8b) scancode 0x1e0e = KEY_SUBTITLE (0x172) scancode 0x1e0f = KEY_MUTE (0x71) scancode 0x1e10 = KEY_VOLUMEUP (0x73) scancode 0x1e11 = KEY_VOLUMEDOWN (0x72) scancode 0x1e12 = KEY_PREVIOUS (0x19c) scancode 0x1e14 = KEY_UP (0x67) scancode 0x1e15 = KEY_DOWN (0x6c) scancode 0x1e16 = KEY_LEFT (0x69) scancode 0x1e17 = KEY_RIGHT (0x6a) scancode 0x1e18 = KEY_VIDEO (0x189) scancode 0x1e19 = KEY_AUDIO (0x188) scancode 0x1e1a = KEY_MHP (0x16f) scancode 0x1e1b = KEY_EPG (0x16d) scancode 0x1e1c = KEY_TV (0x179) scancode 0x1e1e = KEY_NEXTSONG (0xa3) scancode 0x1e1f = KEY_EXIT (0xae) scancode 0x1e20 = KEY_CHANNELUP (0x192) scancode 0x1e21 = KEY_CHANNELDOWN (0x193) scancode 0x1e22 = KEY_CHANNEL (0x16b) scancode 0x1e24 = KEY_PREVIOUSSONG (0xa5) scancode 0x1e25 = KEY_ENTER (0x1c) scancode 0x1e26 = KEY_SLEEP (0x8e) scancode 0x1e29 = KEY_BLUE (0x191) scancode 0x1e2e = KEY_GREEN (0x18f) scancode 0x1e30 = KEY_PAUSE (0x77) scancode 0x1e32 = KEY_REWIND (0xa8) scancode 0x1e34 = KEY_FASTFORWARD (0xd0) scancode 0x1e35 = KEY_PLAY (0xcf) scancode 0x1e36 = KEY_STOP (0x80) scancode 0x1e37 = KEY_RECORD (0xa7) scancode 0x1e38 = KEY_YELLOW (0x190) scancode 0x1e3b = KEY_SELECT (0x161) scancode 0x1e3c = KEY_ZOOM (0x174) scancode 0x1e3d = KEY_POWER (0x74)
Re: New TV713X Remote Control
On Tue, Nov 30, 2010 at 01:53:12PM +0100, Miguel Ángel Fernández wrote: And, what is more. Only when the module is loaded, if I push some buttons of the remote I have this output in dmesg: [ 450.228029] i2c IR (KNC One): unknown key: key=0x03 raw=0x03 down=1 [ 450.288526] i2c IR (KNC One): unknown key: key=0x03 raw=0x03 down=0 [ 451.248534] i2c IR (KNC One): unknown key: key=0x00 raw=0x00 down=1 [ 451.308027] i2c IR (KNC One): unknown key: key=0x00 raw=0x00 down=0 But irw has this output: sudo irw connect: No such file or directory you do not have lircd running. So make lircd run with the correct device and see if you can go through the irrecord process. irw will not work without some keycodes listed in lircd.conf Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: New TV713X Remote Control
On Tue, Nov 30, 2010 at 01:53:12PM +0100, Miguel Ángel Fernández wrote: should have looked closer before answering.. [ 374.444695] input: i2c IR (KNC One) as /devices/virtual/input/input6 [ 374.472666] ir-kbd-i2c: i2c IR (KNC One) detected at i2c-0/0-0030/ir0 [saa7133[0]] in this case try lircd -H devinput -d /dev/input/event6 and lircd.conf.devinput - /etc/lirc/lircd.conf that can be found in recent lirc sources Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV MiniStick IR in 2.6.36 - [PATCH]
On Fri, Nov 26, 2010 at 04:23:49PM -0200, Mauro Carvalho Chehab wrote: Em 15-11-2010 20:57, Richard Zidlicky escreveu: What are the keycodes used on your remote? I don't see why not add them to the Hauppauge keytable. agree, adding them to the table seems like the best option. The codes are very similar like the other haupauge rc but use a different type tag thus the code range is 0x1d00-0x1d40 So I will add them to the table and send a patch. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Thoughts about suspending DVB C PCI device transparently
Hi,
found this old email when searching for suspend issues, seems like a good idea.
Just wondering - how many eg dvb drivers are there with working
suspend/hibernate
(all buses, not just PCI)? Me thinks only a small fraction, the rest will crash
unless blacklisted by pm-utils?
Would it be worth to code a generic approach working around drivers that need
to be
blacklisted? It seems that because of eg firmware loading this might be the
only way
to get dvb drivers behave?
Richard
Once in a time I wrote into Mantis driver Suspend / resume
code. The idea was, that bridge driver (mantis_dvb.c) will
handle the suspend / resume transparently to the application.
With a PCI device this was rather easy to achieve.
With xine, there was just a glitch with video and audio
after resume.
So after suspend, frontend was tuned into the original
frequency, and the DMA transfer state was restored.
Suspend:
1. Turn off possible DMA transfer if active (feeds 0)
2. Remember tuner power on state.
3. Do tuner and fronted power off.
Resume:
1. Restore frontend and tuner power.
2. (feeds 0)? Set frequency for the tuner.
3. (feeds 0)? Restore DMA transfer into previous state.
What do you think about this?
I need some feedback: is it worth coding?
Other needed code is usual suspend / resume stuff.
Is it worth powering off the tuner, if it isn't
used?
For my current usage, powering off the unused tuner
gives more power savings than implementing suspend/resume.
Marko Ristola
--
// suspend to standby, ram or disk.
int mantis_dvb_suspend(struct mantis_pci *mantis, pm_message_t
prevState, pm_message_t mesg)
{
if (mantis-feeds 0)
mantis_dma_stop(mantis);
if (mantis-has_power)
mantis_fe_powerdown(mantis); // power off tuner.
return 0;
}
void mantis_dvb_resume(struct mantis_pci *mantis, pm_message_t prevMesg)
{
// power on frontend and tuner.
mantis_frontend_tuner_init(mantis);
if (mantis-feeds 0 mantis-fe-ops.tuner_ops.init)
(mantis-fe-ops.init)(mantis-fe);
if (mantis-feeds 0) {
(mantis-fe-ops.set_frontend)(mantis-fe, NULL);
mantis_dma_start(mantis);
}
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: sleeping function called from invalid context at...mm/fault.c:1074
Hi, got this pretty confusing BUG, probably triggered by drivers/media/dvb/siano. I had femon kaffeine running in parallel. In kaffeine output stopped so I did quit kaffeine, unplugged the DVB stick and reconnected: Nov 18 15:00:05 localhost kernel: [116557.045363] usb 5-5: USB disconnect, address 17 Nov 18 15:00:05 localhost kernel: [116557.045475] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045479] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045483] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045486] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045489] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045492] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045495] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045498] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045501] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.045504] smsusb_onresponse: line: 71: error, urb status -108 (-ESHUTDOWN), 0 bytes Nov 18 15:00:05 localhost kernel: [116557.060214] sms_ir_exit: Nov 18 15:00:24 localhost kernel: [116575.829453] BUG: sleeping function called from invalid context at /home/rz/rpmbuild/kernels/linux-2.6.36/arch/x8 6/mm/fault.c:1074 Nov 18 15:00:24 localhost kernel: [116575.829457] in_atomic(): 0, irqs_disabled(): 1, pid: 22905, name: femon Nov 18 15:00:24 localhost kernel: [116575.829459] no locks held by femon/22905. Nov 18 15:00:24 localhost kernel: [116575.829461] irq event stamp: 17262 Nov 18 15:00:24 localhost kernel: [116575.829463] hardirqs last enabled at (17261): [c135bd4b] _raw_spin_unlock_irqrestore+0x3f/0x4c Nov 18 15:00:24 localhost kernel: [116575.829472] hardirqs last disabled at (17262): [c135b8dd] _raw_spin_lock_irqsave+0x1a/0x3f Nov 18 15:00:24 localhost kernel: [116575.829476] softirqs last enabled at (17052): [c103ad4a] __do_softirq+0x168/0x170 Nov 18 15:00:24 localhost kernel: [116575.829481] softirqs last disabled at (17047): [c103ad8b] do_softirq+0x39/0x5e Nov 18 15:00:24 localhost kernel: [116575.829486] Pid: 22905, comm: femon Not tainted 2.6.36v1 #2 Nov 18 15:00:24 localhost kernel: [116575.829488] Call Trace: Nov 18 15:00:24 localhost kernel: [116575.829493] [c102d8d4] __might_sleep+0xdb/0xe2 Nov 18 15:00:24 localhost kernel: [116575.829497] [c135ecc8] do_page_fault+0x1c0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829500] [c135eb08] ? do_page_fault+0x0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829504] [c135c85f] error_code+0x5f/0x70 Nov 18 15:00:24 localhost kernel: [116575.829508] [c10500d8] ? srcu_notifier_chain_register+0x14/0x72 Nov 18 15:00:24 localhost kernel: [116575.829511] [c135eb08] ? do_page_fault+0x0/0x304 Nov 18 15:00:24 localhost kernel: [116575.829515] [c105bab5] ? __lock_acquire+0x90/0xc26 Nov 18 15:00:24 localhost kernel: [116575.829518] [c105a125] ? register_lock_class+0x17/0x295 Nov 18 15:00:24 localhost kernel: [116575.829521] [c105ace9] ? mark_lock+0x1e/0x1e3 Nov 18 15:00:24 localhost kernel: [116575.829524] [c105bdac] ? __lock_acquire+0x387/0xc26 Nov 18 15:00:24 localhost kernel: [116575.829527] [c105c6e5] lock_acquire+0x9a/0xbd Nov 18 15:00:24 localhost kernel: [116575.829537] [fa8e15a7] ? smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829540] [c135b8f2] _raw_spin_lock_irqsave+0x2f/0x3f Nov 18 15:00:24 localhost kernel: [116575.829544] [fa8e15a7] ? smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829549] [fa8e15a7] smscore_find_client+0x1d/0x70 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829552] [c105a125] ? register_lock_class+0x17/0x295 Nov 18 15:00:24 localhost kernel: [116575.829557] [fa8e1711] smscore_validate_client+0x35/0xab [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829562] [fa8e17e1] smsclient_sendrequest+0x5a/0x75 [smsmdtv] Nov 18 15:00:24 localhost kernel: [116575.829566] [fa9991f7] smsdvb_sendrequest_and_wait+0x1f/0x44 [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829570] [fa999250] smsdvb_send_statistics_request+0x34/0x36 [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829573] [fa999372] smsdvb_read_status+0x17/0x2f [smsdvb] Nov 18 15:00:24 localhost kernel: [116575.829582] [fa97c453] dvb_frontend_ioctl_legacy+0x610/0xc0d [dvb_core] Nov 18 15:00:24 localhost kernel: [116575.829585] [c105ace9] ? mark_lock+0x1e/0x1e3 Nov 18 15:00:24 localhost kernel:
Re: HVR900H : IR Remote Control
On Sun, Nov 14, 2010 at 08:22:44PM +0100, Massis Sirapian wrote: Thanks Stefan. I've checked the /drivers/media/IR/keymaps of the kernel source directory, but nothing seems to fit my remote, which is a DSR-0012 : http://lirc.sourceforge.net/remotes/hauppauge/DSR-0112.jpg. FYI, this remote is identical to that shipped with (most?) Haupauge Ministicks and the codes reportedly match the rc-dib0700-rc5.c keymap. However I have not figured out how to make the userspace work with the new ir-code yet. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hauppauge WinTV MiniStick IR in 2.6.36 - [PATCH]
Hi, for some users (thats at least one user in Italy and me) the following is required: --- linux-2.6.36/drivers/media/dvb/siano/sms-cards.c.rz 2010-11-15 11:16:56.0 +0100 +++ linux-2.6.36/drivers/media/dvb/siano/sms-cards.c2010-11-15 11:54:25.0 +0100 @@ -17,6 +17,9 @@ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ +//#include media/ir-kbd-i2c.h +//#include media/ir-core.h + #include sms-cards.h #include smsir.h @@ -64,7 +67,7 @@ .type = SMS_NOVA_B0, .fw[DEVICE_MODE_ISDBT_BDA] = sms1xxx-hcw-55xxx-isdbt-02.fw, .fw[DEVICE_MODE_DVBT_BDA] = sms1xxx-hcw-55xxx-dvbt-02.fw, - .rc_codes = RC_MAP_RC5_HAUPPAUGE_NEW, + .rc_codes = RC_MAP_DIB0700_RC5_TABLE, .board_cfg.leds_power = 26, .board_cfg.led0 = 27, .board_cfg.led1 = 28, What is the way to achieve the effect without recompiling the kernel - is there any? Could we combine the keymaps - as I understand it all RC5 maps could be combined into one huge map without any problems except memory usage? Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV MiniStick IR in 2.6.36 - [PATCH]
On Mon, Nov 15, 2010 at 01:55:00PM +0200, Anca Emanuel wrote: On Mon, Nov 15, 2010 at 1:27 PM, Richard Zidlicky r...@linux-m68k.org wrote: Hi, snip What is the way to achieve the effect without recompiling the kernel - is there any? On Ubuntu kernel list Chao Zhang asked the same question. Answer: [quote] You might find following links useful: http://tldp.org/LDP/lkmpg/2.6/html/x181.html http://www.cyberciti.biz/tips/build-linux-kernel-module-against-installed-kernel-source-tree.html [/quote] thanks, personally I have no problem with recompiling the kernel and doing it anyways - I was hoping the new IR framework has something equivalent to a loadkeys. Maybe even loadkeys would work? Not tried yet and it certainly would require some work to define the keymaps and such. In any case for the average user there must be something better than patching the kernel. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV MiniStick IR in 2.6.36 - [PATCH]
On Mon, Nov 15, 2010 at 07:35:06AM -0500, Andy Walls wrote: On Mon, 2010-11-15 at 12:27 +0100, Richard Zidlicky wrote: http://git.linuxtv.org/v4l-utils.git?a=tree;f=utils/keytable;h=e599a8b5288517fc7fe58d96f44f28030b04afbc;hb=HEAD thanks, that should do the trick. In addition I am wondering if the maps of the two remotes that apparently get bundled with the MiniStick should not be merged into one map in the kernel sources so the most common cases are covered? Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Hauppauge WinTV MiniStick IR in 2.6.36 - [PATCH]
On Mon, Nov 15, 2010 at 04:59:24PM -0500, Andy Walls wrote: On Mon, 2010-11-15 at 16:09 +0100, Richard Zidlicky wrote: On Mon, Nov 15, 2010 at 07:35:06AM -0500, Andy Walls wrote: On Mon, 2010-11-15 at 12:27 +0100, Richard Zidlicky wrote: http://git.linuxtv.org/v4l-utils.git?a=tree;f=utils/keytable;h=e599a8b5288517fc7fe58d96f44f28030b04afbc;hb=HEAD thanks, that should do the trick. In addition I am wondering if the maps of the two remotes that apparently get bundled with the MiniStick should not be merged into one map in the kernel sources so the most common cases are covered? I have a certain case where I would like the maps of two bundled remotes both to be loaded - one an RC-5 and one an RC-6 - for a receiver on the HVR-1850 and friends. looks a bit more twisted. In the case of the siano reciever it should be simpler. Apparently it has been bundled with 2 different rc5 type remotes and normal users will have either one of them. So technically it is very easy to provide a table that serves both cases. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb: siano: free spinlock before schedule()
On Tue, Aug 24, 2010 at 09:52:36AM -0300, Mauro Carvalho Chehab wrote:
Em 08-08-2010 13:10, Richard Zidlicky escreveu:
On Wed, Jul 28, 2010 at 12:24:39AM +0200, Jiri Slaby wrote:
sorry for seeing this so late, was flooded with email lately.
There is a better fix (which fixes the potential NULL dereference):
http://lkml.org/lkml/2010/6/7/175
Richard, could you address the comments there and resend?
I am running this patch since many weeks (after fixing the compile error
obviously).
Did not implement your beautification suggestion yet, was doing all kinds
of experiments
with IR and had plenty of unrelated issues.
This patch seems a way better than the previous patch. I've rebased it against
the current tree (and fixed the identation).
thanks for looking at it.
The only missing issue on it is the lack of your Signed-off-by. Richard,
could you
please send it to us?
Signed-off-by: Richard Zidlicky r...@linux-m68k.org
PS: I will be away for a while.
---
drivers/media/dvb/siano/smscoreapi.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
--- patchwork.orig/drivers/media/dvb/siano/smscoreapi.c
+++ patchwork/drivers/media/dvb/siano/smscoreapi.c
@@ -1098,31 +1098,26 @@ EXPORT_SYMBOL_GPL(smscore_onresponse);
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
+ if (!list_empty(coredev-buffers)) {
+ cb = (struct smscore_buffer_t *) coredev-buffers.next;
+ list_del(cb-entry);
+ }
+ spin_unlock_irqrestore(coredev-bufferslock, flags);
+ return cb;
+}
- /* This function must return a valid buffer, since the buffer list is
- * finite, we check that there is an available buffer, if not, we wait
- * until such buffer become available.
- */
-
- prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(coredev-buffers))
- schedule();
-
- finish_wait(coredev-buffer_mng_waitq, wait);
-
- cb = (struct smscore_buffer_t *) coredev-buffers.next;
- list_del(cb-entry);
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
- spin_unlock_irqrestore(coredev-bufferslock, flags);
+ wait_event(coredev-buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] dvb: siano: free spinlock before schedule()
On Wed, Jul 28, 2010 at 12:24:39AM +0200, Jiri Slaby wrote:
sorry for seeing this so late, was flooded with email lately.
There is a better fix (which fixes the potential NULL dereference):
http://lkml.org/lkml/2010/6/7/175
Richard, could you address the comments there and resend?
I am running this patch since many weeks (after fixing the compile error
obviously).
Did not implement your beautification suggestion yet, was doing all kinds of
experiments
with IR and had plenty of unrelated issues.
Richard
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-07
14:32:06.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
-
- /* This function must return a valid buffer, since the buffer list is
-* finite, we check that there is an available buffer, if not, we wait
-* until such buffer become available.
-*/
-
- prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(coredev-buffers))
- schedule();
-
- finish_wait(coredev-buffer_mng_waitq, wait);
-
+ if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
-
+ }
spin_unlock_irqrestore(coredev-bufferslock, flags);
+ return cb;
+}
+
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
+
+ wait_event(coredev-buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
Hi, not much success.. no key events appear in userspace, not sure if the hardware receives anything. Tried both 4 and 9 ports which does not seem to make any difference. lshal does list the IR port, as it did with the siano specific code. Could be my fault, I have cherrypicked patches and applied them on top of Linus 2.6.35. Is there an easy way to get a diff from your version against Linus 2.6.35? I would rather not fetch the whole repo over my mobile connection;) Aug 4 09:04:50 localhost kernel: [ 260.142019] usb 5-5: new high speed USB device using ehci_hcd and address 3 Aug 4 09:04:50 localhost kernel: [ 260.256894] usb 5-5: New USB device found, idVendor=2040, idProduct=5500 Aug 4 09:04:50 localhost kernel: [ 260.256896] usb 5-5: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Aug 4 09:04:50 localhost kernel: [ 260.256899] usb 5-5: Product: WinTV MiniStick Aug 4 09:04:50 localhost kernel: [ 260.256901] usb 5-5: Manufacturer: Hauppauge Computer Works Aug 4 09:04:50 localhost kernel: [ 260.256903] usb 5-5: SerialNumber: f069684c Aug 4 09:04:50 localhost kernel: [ 260.308378] IR NEC protocol handler initialized Aug 4 09:04:50 localhost kernel: [ 260.322270] IR RC5(x) protocol handler initialized Aug 4 09:04:50 localhost kernel: [ 260.332901] IR RC6 protocol handler initialized Aug 4 09:04:50 localhost kernel: [ 260.363497] IR JVC protocol handler initialized Aug 4 09:04:50 localhost kernel: [ 260.407230] IR Sony protocol handler initialized Aug 4 09:04:51 localhost kernel: [ 260.958061] smscore_set_device_mode: firmware download success: sms1xxx-hcw-55xxx-dvbt-02.fw Aug 4 09:04:51 localhost kernel: [ 260.958400] sms_ir_init: Allocating input device Aug 4 09:04:51 localhost kernel: [ 260.958416] sms_ir_init: IR port 0, timeout 100 ms Aug 4 09:04:51 localhost kernel: [ 260.958419] sms_ir_init: Input device (IR) SMS IR (Hauppauge WinTV MiniStick) is set for key events Aug 4 09:04:51 localhost kernel: [ 261.010020] Registered IR keymap rc-rc5-hauppauge-new Aug 4 09:04:51 localhost kernel: [ 261.010571] input: SMS IR (Hauppauge WinTV MiniStick) as /devices/pci:00/:00:1d.7/usb 5/5-5/rc/rc0/input5 Aug 4 09:04:51 localhost kernel: [ 261.010797] rc0: SMS IR (Hauppauge WinTV MiniStick) as /devices/pci:00/:00:1d.7/usb5/ 5-5/rc/rc0 Aug 4 09:04:51 localhost kernel: [ 261.037230] DVB: registering new adapter (Hauppauge WinTV MiniStick) Aug 4 09:04:51 localhost kernel: [ 261.039296] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... Aug 4 09:04:51 localhost kernel: [ 261.044846] usbcore: registered new interface driver smsusb Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
On Tue, Aug 03, 2010 at 10:32:15AM -0300, Mauro Carvalho Chehab wrote: The model number is on a label at the back of the stick (at least, mine have it). ah.. I was wondering whichever magical tool you are using. So here is my number: 55009 LF Rev A1F7 Btw, you don't need to use lirc if all you want is to replace the IR keycodes. You can use, instead, the ir-keycode program, available at http://git.linuxtv.org/v4l-utils.git. There are several keycode tables already mapped there. Of course, lirc offers some extra features. thanks for the tipps.. the userspace configuration seems more confusing than the kernel internals. So far I get keycodes that work nicely in an xterm and for controling firefox but not much else. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] V4L/DVB: smsusb: enable IR port for Hauppauge WinTV MiniStick
On Sun, Aug 01, 2010 at 05:17:18PM -0300, Mauro Carvalho Chehab wrote:
Add the proper gpio port for WinTV MiniStick, with the information provided
by Michael.
Thanks-to: Michael Krufky mkru...@kernellabs.com
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/drivers/media/dvb/siano/sms-cards.c
b/drivers/media/dvb/siano/sms-cards.c
index cff77e2..dcde606 100644
--- a/drivers/media/dvb/siano/sms-cards.c
+++ b/drivers/media/dvb/siano/sms-cards.c
@@ -67,6 +67,7 @@ static struct sms_board sms_boards[] = {
.board_cfg.leds_power = 26,
.board_cfg.led0 = 27,
.board_cfg.led1 = 28,
+ .board_cfg.ir = 9,
are you sure about this?
I am using the value of 4 for the ir port and it definitely works.. confused.
Thanks for looking at it, will test the patches as soon as I can.
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble getting DVB-T working with Portuguese transmissions
On Fri, Jun 18, 2010 at 02:28:38PM +0100, Pedro Côrte-Real wrote: On Thu, Jun 17, 2010 at 9:00 PM, Richard Zidlicky r...@linux-m68k.org wrote: berr is supposed to be the bit error rate. The values displayed here appear to be bogus - then again I am not familiar with this particular driver so maybe just the error reporting is bogus. The w_scan results also look pretty bad. Newest kernel is allways worth a try. I have tried a git snapshot of Linus' 2.6.35 kernel. Is there another non-mainline tree I should try? Would it help to get some kind of dvbsnoop log of this? I've tried doing dvbsnoop -s pidscan and dvbsnoop 0 but didn't get anything that seemed valid. did you test the hardware with the evil OS? Alternatively what is a well supported usb DVB-T tunner? I've also bought an Avermedia Volar HX and a Gigabyte 7200 which seem to have at best some half-assed out-of-tree drivers. I am using idVendor=2040, idProduct=5500 WinTV MiniStick Manufacturer: Hauppauge Computer Works works reasonably well, needs a patch to enable remote. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble getting DVB-T working with Portuguese transmissions
On Thu, Jun 17, 2010 at 10:03:16AM +0100, Pedro Côrte-Real wrote: On Wed, Jun 16, 2010 at 9:57 PM, Richard Zidlicky r...@linux-m68k.org wrote: On Wed, Jun 16, 2010 at 11:43:09AM +0100, Pedro Côrte-Real wrote: status C Y | signal 66% | snr 0% | ber 2097151 | unc 0 | status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 64% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 64% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK the ber is very strange. It should be 0 or very close. What are the ber and the unc? And does the 0% snr make sense? Why the % scale for that? berr is supposed to be the bit error rate. The values displayed here appear to be bogus - then again I am not familiar with this particular driver so maybe just the error reporting is bogus. The w_scan results also look pretty bad. Newest kernel is allways worth a try. Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Trouble getting DVB-T working with Portuguese transmissions
On Wed, Jun 16, 2010 at 11:43:09AM +0100, Pedro Côrte-Real wrote: status C Y | signal 66% | snr 0% | ber 2097151 | unc 0 | status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 64% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 65% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK status SC YL | signal 64% | snr 0% | ber 2097151 | unc 0 | FE_HAS_LOCK the ber is very strange. It should be 0 or very close. Did you try kaffeine or w_scan? Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] support for Hauppauge WinTV MiniStic IR remote
Hi,
I have guessed which gpio line to use and activated the ir-remote receiver.
The keymap seems to work fairly well with the supplied DSR-0112 remote, mostly
tested it with xev as I do not have a working lircd on this computer.
The patch is against 2.6.34.
Richard
Jun 15 16:46:27 localhost kernel: [24399.381936] usb 5-6: New USB device found,
idVendor=2040, idProduct=5500
Jun 15 16:46:27 localhost kernel: [24399.381939] usb 5-6: New USB device
strings: Mfr=1, Product=2, SerialNumber=3
Jun 15 16:46:27 localhost kernel: [24399.381941] usb 5-6: Product: WinTV
MiniStick
Jun 15 16:46:27 localhost kernel: [24399.381943] usb 5-6: Manufacturer:
Hauppauge Computer Works
Jun 15 16:46:27 localhost kernel: [24399.381945] usb 5-6: SerialNumber: f069684c
Jun 15 16:46:27 localhost kernel: [24399.384194] usb 5-6: firmware: requesting
sms1xxx-hcw-55xxx-dvbt-02.fw
Jun 15 16:46:28 localhost kernel: [24400.75] smscore_set_device_mode:
firmware download success: sms1xxx-hcw-55
xxx-dvbt-02.fw
Jun 15 16:46:28 localhost kernel: [24400.000303] DVB: registering new adapter
(Hauppauge WinTV MiniStick)
Jun 15 16:46:28 localhost kernel: [24400.000796] DVB: registering adapter 0
frontend 0 (Siano Mobile Digital MDTV R
eceiver)...
Jun 15 16:46:28 localhost kernel: [24400.001798] sms_ir_init: Allocating input
device
Jun 15 16:46:28 localhost kernel: [24400.001802] sms_ir_init: IR remote
keyboard type is 1
Jun 15 16:46:28 localhost kernel: [24400.001804] sms_ir_init: IR port 0,
timeout 100 ms
Jun 15 16:46:28 localhost kernel: [24400.001807] sms_ir_init: Input device (IR)
SMS IR w/kbd type 1 is set for key
events
Jun 15 16:46:28 localhost kernel: [24400.001887] input: SMS IR w/kbd type 1 as
/devices/pci:00/:00:1d.7/usb
5/5-6/input/input9
--- linux-2.6.34/drivers/media/dvb/siano/smsir.h.rz 2010-06-11
11:24:20.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smsir.h2010-06-11
01:12:54.0 +0200
@@ -30,6 +30,7 @@
enum ir_kb_type {
SMS_IR_KB_DEFAULT_TV,
+ SMS_IR_KB_HCW_DSR0112,
SMS_IR_KB_HCW_SILVER
};
--- linux-2.6.34/drivers/media/dvb/siano/smsir.c.rz 2010-06-11
10:07:32.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smsir.c2010-06-15
18:08:37.0 +0200
@@ -54,6 +54,34 @@
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
}
},
+ [SMS_IR_KB_HCW_DSR0112] = {
+ .ir_protocol = IR_RC5,
+ .rc5_kbd_address = KEYBOARD_ADDRESS_LIGHTING,
+ .keyboard_layout_map = {
+ KEY_0, KEY_1, KEY_2,
+ KEY_3, KEY_4, KEY_5,
+ KEY_6, KEY_7, KEY_8,
+ KEY_9, KEY_TEXT, KEY_RED,
+ KEY_RADIO, KEY_MENU,
+ KEY_SUBTITLE,
+ KEY_MUTE, KEY_VOLUMEUP,
+ KEY_VOLUMEDOWN, KEY_PREVIOUS, 0,
+ KEY_UP, KEY_DOWN, KEY_LEFT,
+ KEY_RIGHT, KEY_VIDEO, KEY_AUDIO,
+ KEY_MHP, KEY_EPG, KEY_TV,
+ 0, KEY_NEXTSONG, KEY_EXIT,
+ KEY_CHANNELUP, KEY_CHANNELDOWN,
+ KEY_CHANNEL, 0,
+ KEY_PREVIOUSSONG, KEY_ENTER,
+ KEY_SLEEP, 0, 0, KEY_BLUE,
+ 0, 0, 0, 0, KEY_GREEN, 0,
+ KEY_PAUSE, 0, KEY_REWIND,
+ 0, KEY_FASTFORWARD, KEY_PLAY,
+ KEY_STOP, KEY_RECORD,
+ KEY_YELLOW, 0, 0, KEY_SELECT,
+ KEY_ZOOM, KEY_POWER, 0, 0
+ }
+ },
[SMS_IR_KB_HCW_SILVER] = {
.ir_protocol = IR_RC5,
.rc5_kbd_address = KEYBOARD_ADDRESS_LIGHTING1,
@@ -120,6 +148,7 @@
sms_log(kernel input keycode (from ir) %d, keycode);
input_report_key(coredev-ir.input_dev, keycode, 1);
+ input_report_key(coredev-ir.input_dev, keycode, 0);
input_sync(coredev-ir.input_dev);
}
@@ -247,6 +276,8 @@
int sms_ir_init(struct smscore_device_t *coredev)
{
struct input_dev *input_dev;
+ int i;
+ u16 *key_map;
sms_log(Allocating input device);
input_dev = input_allocate_device();
@@ -278,7 +309,14 @@
/* Key press events only */
input_dev-evbit[0] = BIT_MASK(EV_KEY);
- input_dev-keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
+
+ key_map =
Re: [PATCH 2.6.34] schedule inside spin_lock_irqsave
On Sun, Jun 06, 2010 at 07:51:56PM +0200, Jiri Slaby wrote:
On 06/06/2010 02:43 PM, Richard Zidlicky wrote:
Hi,
I have done a minimaly invasive patch for the stable 2.6.34 kernel and
stress-tested
it for many hours, definitely seems to improve the behaviour.
I have left out your beautification suggestion for now, want to do more
playing with
other aspects of the driver. There still seem to be issues when the device
is unplugged
while in use and such.
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-04
23:00:35.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t
*coredev)
+
+struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
Sorry, maybe I'm just blind, but where is 'coredev' defined in this
scope? You probably forgot to pass it to get_entry?
How could this be compiled? Is there coredev defined globally?
good catch. I think it failed and despite a different kernel id the old module
was
loaded.
Here is the new version, this time lightly tested
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-07
14:32:06.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(struct smscore_device_t *coredev)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
-
- /* This function must return a valid buffer, since the buffer list is
-* finite, we check that there is an available buffer, if not, we wait
-* until such buffer become available.
-*/
-
- prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(coredev-buffers))
- schedule();
-
- finish_wait(coredev-buffer_mng_waitq, wait);
-
+ if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
-
+ }
spin_unlock_irqrestore(coredev-bufferslock, flags);
+ return cb;
+}
+
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
+
+ wait_event(coredev-buffer_mng_waitq, (cb = get_entry(coredev)));
return cb;
}
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2.6.34] schedule inside spin_lock_irqsave
Hi,
I have done a minimaly invasive patch for the stable 2.6.34 kernel and
stress-tested
it for many hours, definitely seems to improve the behaviour.
I have left out your beautification suggestion for now, want to do more playing
with
other aspects of the driver. There still seem to be issues when the device is
unplugged
while in use and such.
--- linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c.rz2010-06-03
21:58:11.0 +0200
+++ linux-2.6.34/drivers/media/dvb/siano/smscoreapi.c 2010-06-04
23:00:35.0 +0200
@@ -1100,31 +1100,26 @@
*
* @return pointer to descriptor on success, NULL on error.
*/
-struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+
+struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
unsigned long flags;
- DEFINE_WAIT(wait);
-
spin_lock_irqsave(coredev-bufferslock, flags);
-
- /* This function must return a valid buffer, since the buffer list is
-* finite, we check that there is an available buffer, if not, we wait
-* until such buffer become available.
-*/
-
- prepare_to_wait(coredev-buffer_mng_waitq, wait, TASK_INTERRUPTIBLE);
-
- if (list_empty(coredev-buffers))
- schedule();
-
- finish_wait(coredev-buffer_mng_waitq, wait);
-
+ if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
-
+ }
spin_unlock_irqrestore(coredev-bufferslock, flags);
+ return cb;
+}
+
+struct smscore_buffer_t *smscore_getbuffer(struct smscore_device_t *coredev)
+{
+ struct smscore_buffer_t *cb = NULL;
+
+ wait_event(coredev-buffer_mng_waitq, (cb = get_entry()));
return cb;
}
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: schedule inside spin_lock_irqsave?
On Sun, May 30, 2010 at 05:24:38PM +0200, Jiri Slaby wrote:
Hi,
came across following snippet of code
(2.6.34:drivers/media/dvb/siano/smscoreapi.c) and
...
...
...
This should be
wait_event(coredev-buffer_mng_waitq, cb = get_entry());
with get_entry like:
struct smscore_buffer_t *get_entry(void)
{
struct smscore_buffer_t *cb = NULL;
spin_lock_irqsave(coredev-bufferslock, flags);
if (!list_empty(coredev-buffers)) {
cb = (struct smscore_buffer_t *) coredev-buffers.next;
list_del(cb-entry);
}
spin_unlock_irqrestore(coredev-bufferslock, flags);
return cb;
}
...
...
...
Looking at the smscore_buffer_t definition, this is really ugly since it
relies on entry being the first in the structure. It should be
list_first_entry(coredev-buffers, ...) instead, cast-less.
list_del(cb-entry);
}
spin_unlock_irqrestore(coredev-bufferslock, flags);
return cb;
}
thanks for the suggestions, is it on anyones TODO list or should I cook up my
own patch?
Would take a few more days till I can get at it.
BTW does anyone have knowledge how to enable IR receiver code for the smsxxx
devices?
Looks like its just the matter of setting sms_board_gpio_cfg.ir to the right
value
- which value?
Richard
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
remote control for idVendor=2040, idProduct=5500 Siano MDTV
Hi, I am using this stick with a 2.6.33.2 kernel kernel.org) and kaffeine. Works nicely so far but the infrared remote does not work. I am quite happy to apply pacthes or experimental dirvers - are there any? Is there any documentation that woud allow me to write the code? Apr 8 15:05:23 localhost kernel: [ 1204.812906] usb 5-6: Product: WinTV MiniStick Apr 8 15:05:23 localhost kernel: [ 1204.812908] usb 5-6: Manufacturer: Hauppauge Computer Works Apr 8 15:05:23 localhost kernel: [ 1204.812910] usb 5-6: SerialNumber: f069684c Apr 8 15:05:23 localhost kernel: [ 1204.815314] usb 5-6: firmware: requesting sms1xxx-hcw-55xxx-dvbt-02.fw Apr 8 15:05:24 localhost kernel: [ 1205.396048] smscore_set_device_mode: firmware download success: sms1xxx-hcw-55xxx-dvbt-02.fw Apr 8 15:05:24 localhost kernel: [ 1205.396478] DVB: registering new adapter (Hauppauge WinTV MiniStick) Apr 8 15:05:24 localhost kernel: [ 1205.397538] DVB: registering adapter 0 frontend 0 (Siano Mobile Digital MDTV Receiver)... Regards Richard -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
