Hello Manu (and all others) I've played some more with dts_test info and looked closely at the hex values returned by the MCU. (You'll find at the end of the mail the raw values returend by the CAM with various hardware setup.) Here are some patterns found in the MCU values: - byte [5] is always 44 for SCM CAM after reload (i.e. the only case where I can communicate with CAM and de-scramble programs) - byte [5] is always 41 for Aston CAM (which does not work at all: no communication with the CAM) - byte[5] result is 41 or 44 for hotplugged SCM CAM. (Case where CAM communication and descrambling are broken) - taken together (i.e nb = byte[2] << 8 | byte[3]), byte 2 and 3 have interesting statistical properties that suggest they are the result of a measure done by MCU. Probably related to a timing measure. (see below for the statistical results) - For the record, byte[4] is already known and interpreted in the driver (used to check whether the CAM is plugged and/or ready) - last byte is the usual checksum So now, the question is, can we make some use of the info returned by the MCU ? What the deal with byte[5] ? How can we interpret 44 or 41 ? Is this actually related with succesfull com with the CAM ?? Could the byte[2] and [3] info be used to tune the some of the msleep that are present in the dst and dst_ca drivers ? Cheers Statistical result (computed by gnumeric): Mean 5882.48 Standard Error 0 Median 5882 Mode 5892 Standard Deviation 23 Sample Variance 531 Range 162 Minimum 5804 Maximum 5966 Sum 4135380 Count 703 Raw values returned by MCU: No CAM: Apr 2 15:20:20 localhost kernel: 3 ef 17 4 0 44 1 ae Apr 2 15:20:21 localhost kernel: 3 ef 17 1f 0 44 1 93 Apr 2 15:20:22 localhost kernel: 3 ef 17 22 0 44 1 90 Apr 2 15:20:23 localhost kernel: 3 ef 17 39 0 44 1 79 Apr 2 15:20:24 localhost kernel: 3 ef 17 4 0 44 1 ae Aston CAM hot-plugged, no module reload: Apr 2 15:23:45 localhost kernel: 3 ef 16 e6 80 41 1 50 Apr 2 15:23:48 localhost kernel: 3 ef 17 9 80 41 1 2c Apr 2 15:23:49 localhost kernel: 3 ef 17 13 80 41 1 22 Apr 2 15:23:50 localhost kernel: 3 ef 17 4 80 41 1 31 Apr 2 15:23:51 localhost kernel: 3 ef 16 f4 80 41 1 42 Apr 2 15:23:52 localhost kernel: 3 ef 16 e7 80 41 1 4f Apr 2 15:24:04 localhost kernel: 3 ef 17 18 80 41 1 1d Apr 2 15:24:06 localhost kernel: 3 ef 16 f6 80 41 1 40 Aston CAM after module reload: Apr 2 15:25:02 localhost kernel: 3 ef 16 ee 80 41 1 48 Apr 2 15:25:03 localhost kernel: 3 ef 16 e8 80 41 1 4e Apr 2 15:25:05 localhost kernel: 3 ef 16 f9 80 41 1 3d Apr 2 15:25:06 localhost kernel: 3 ef 17 22 80 41 1 13 Apr 2 15:25:07 localhost kernel: 3 ef 16 eb 80 41 1 4b Apr 2 15:25:08 localhost kernel: 3 ef 17 30 80 41 1 5 Apr 2 15:25:09 localhost kernel: 3 ef 17 b 80 41 1 2a Apr 2 15:25:10 localhost kernel: 3 ef 16 e8 80 41 1 4e SCM CAM hot-plugged, no module reload: Apr 2 15:26:30 localhost kernel: 3 ef 17 1c 80 41 1 19 Apr 2 15:26:31 localhost kernel: 3 ef 17 7 80 41 1 2e Apr 2 15:26:32 localhost kernel: 3 ef 16 fd 80 44 1 36 Apr 2 15:26:33 localhost kernel: 3 ef 17 1b 80 44 1 17 Apr 2 15:26:34 localhost kernel: 3 ef 17 11 80 41 1 24 Apr 2 15:26:35 localhost kernel: 3 ef 17 f 80 44 1 23 Apr 2 15:26:36 localhost kernel: 3 ef 17 3 80 44 1 2f Apr 2 15:26:37 localhost kernel: 3 ef 16 ed 80 44 1 46 Apr 2 15:26:38 localhost kernel: 3 ef 17 28 80 41 1 d Here the only case where the value returned by byte[5] is shaky. At this point, the communication with the CAM is broken. SCM CAM plugged, after module reload: Apr 2 15:27:49 localhost kernel: 3 ef 17 24 80 44 1 e Apr 2 15:27:59 localhost kernel: 3 ef 16 fb 80 44 1 38 Apr 2 15:28:00 localhost kernel: 3 ef 17 33 80 44 1 ff Apr 2 15:28:00 localhost kernel: 3 ef 17 b 80 44 1 27 Apr 2 15:28:01 localhost kernel: 3 ef 16 fc 80 44 1 37 Apr 2 15:28:02 localhost kernel: 3 ef 16 e2 80 44 1 51 Apr 2 15:28:03 localhost kernel: 3 ef 16 ef 80 44 1 44 Apr 2 15:28:04 localhost kernel: 3 ef 16 f8 80 44 1 3b Apr 2 15:28:04 localhost kernel: 3 ef 17 c 80 44 1 26
