On Wednesday 03 October 2012 20:57:07 Hans Petter Selasky wrote: > On Tuesday 02 October 2012 21:52:11 Hans Petter Selasky wrote: > > On Saturday 08 September 2012 19:08:22 Jose Alberto Reguero wrote: > > > This patch add the toggle bit to the tt3650_rc_query function of the > > > ttusb2 driver. > > > > > > Signed-off-by: Jose Alberto Reguero <jareguero@xxxxxxxxxxxxxx> > > > > > > Jose Alberto > > > > Hi, > > > > This patch looks OK. > > Hi, > > > Regarding the TTUSB2 support, I see an issue where the IR polling > > interference with the CAM access. If a IR poll request happens exactly > > between a write/read CAM request, then that CAM request will fail. How > > can this issue be solved without disabling the IR support entirely? > > I checked the code and see that "dvb_usb_generic_rw()" will synchronize the > requests, so this can't be the root cause. Currently I suspect the not > brand new AMD based EHCI controller I'm using to connect my TTUSB adapter > to be at fault. This is FreeBSD, not Linux. What I see when I dump all the > transactions is that I have quite frequent timeouts on some of the I2C/CAM > and IR commands going on the BULK endpoints. For example grepp'ed log > extract looks like this: > > 0000 55 3B 42 02 00 A0 01 DF 00 00 00 00 00 FB F5 81 |U;B.............| > 0000 AA 3C 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.<B... | > 0000 55 3C 42 02 00 01 01 DF 00 00 00 00 00 FB F5 81 |U<B.............| > 0000 AA 3D 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.=B... | > 18:46:16.972329 usbus1.3 DONE-BULK- > EP=00000081,SPD=HIGH,NFR=0,SLEN=0,IVAL=0,ERR=TIMEOUT > 0000 AA 3E 31 04 11 01 01 1A -- -- -- -- -- -- -- -- |.>1..... | > 0000 55 3E 31 04 10 01 01 DF 00 00 00 00 00 FB F5 81 |U>1.............| > 0000 AA 3D 42 02 00 01 -- -- -- -- -- -- -- -- -- -- |.=B... | > 0000 55 3D 42 02 00 01 01 DF 00 00 00 00 00 FB F5 81 |U=B.............| > 0000 AA 40 41 01 01 -- -- -- -- -- -- -- -- -- -- -- |.@A.. | > > I'm now trying some EHCI quirks, and will see what results I get later this > week. > > I can also say that VDR receives a ring buffer overflow at exactly the same > time the USB BULK endpoint timeout happens .... > > If this sounds familar to anyone, please let me know. > > Thank you, > > --HPS More info if anyone cares to look at it: vdr: [680141312] ERROR: can't write to CI adapter on device 0: Device not configured vdr: [680142848] ERROR: 7 ring buffer overflows (1316 bytes dropped) vdr: [680141312] CAM 1: module present vdr: [680141312] CAM 1: module ready vdr: [680141312] CAM 1: Conax Conditional Access, 01, 0B00, 0001 vdr: [680141312] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted vdr: [680141312] ERROR: can't write to CI adapter on device 0: Device not configured vdr: [680142848] ERROR: 11 ring buffer overflows (2068 bytes dropped) vdr: [680141312] CAM 1: module present vdr: [680141312] CAM 1: module ready vdr: [680141312] CAM 1: Conax Conditional Access, 01, 0B00, 0001 vdr: [680141312] CAM 1: doesn't reply to QUERY - only a single channel can be decrypted Happens regularly, interrupts the stream and is very annoying :-) --HPS -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
