diff mbox

Add toggle to the tt3650_rc_query function of the ttusb2 driver

Message ID 2504977.yNAtCnX8Pk@jar7.dominio (mailing list archive)
State New, archived
Headers show

Commit Message

Jose Alberto Reguero Sept. 8, 2012, 5:08 p.m. UTC 
This patch add the toggle bit to the tt3650_rc_query function of the ttusb2
driver.

Signed-off-by: Jose Alberto Reguero <jareguero@telefonica.net>

Jose Alberto

Comments

Hans Petter Selasky Oct. 2, 2012, 7:52 p.m. UTC | #1 
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@telefonica.net>
> 
> Jose Alberto

Hi,

This patch looks OK.

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?

--HPS
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hans Petter Selasky Oct. 3, 2012, 6:57 p.m. UTC | #2 
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@telefonica.net>
> > 
> > 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Hans Petter Selasky Oct. 3, 2012, 7:08 p.m. UTC | #3 
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@telefonica.net>
> > > 
> > > 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff -upr linux/drivers/media/usb/dvb-usb/ttusb2.c linux.new/drivers/media/usb/dvb-usb/ttusb2.c
--- linux/drivers/media/usb/dvb-usb/ttusb2.c	2012-08-14 05:45:22.000000000 +0200
+++ linux.new/drivers/media/usb/dvb-usb/ttusb2.c	2012-08-23 18:33:33.459191850 +0200
@@ -440,7 +440,7 @@  static int tt3650_rc_query(struct dvb_us
 		/* got a "press" event */
 		st->last_rc_key = (rx[3] << 8) | rx[2];
 		deb_info("%s: cmd=0x%02x sys=0x%02x\n", __func__, rx[2], rx[3]);
-		rc_keydown(d->rc_dev, st->last_rc_key, 0);
+		rc_keydown(d->rc_dev, st->last_rc_key, rx[1]);
 	} else if (st->last_rc_key) {
 		rc_keyup(d->rc_dev);
 		st->last_rc_key = 0;