Hi,
the next-1a.diff was thought only for the Diablo Cam, which was working before next-1.diff.
The only new for this CAM was the read and dump of the Attribute Memory Area. None of my CAMs had any problem with it.
Helmut
Beiträge von HelmutB
-
-
The MatrixAir is really strange. How long needs the initialization of this CAM in your PanasonicTV ?
Does the Diablo work again, if I skip the read und dump of the Attribute Memory? -> next1a.diff (on top of netxt1.diff)
If so, can you then re-check it with #define QUERY_XFIRWARE 1 in line 79 of wintv-ci-core.c.
I dont need a log, just a short information.
Helmut
-
No unusual register settings in the MatrixAir - so lets try a longer USB timeout - the firmware would wait 15 seconds while the CAM is switching to IO-Mode.
Alles anzeigenDiff- --- wintv-ci-core.c.next1 2019-02-15 00:18:49.530832659 +0100
- +++ wintv-ci-core.c 2019-02-15 17:15:52.138719445 +0100
- @@ -74,7 +74,8 @@ static struct usb_id_info usb2_ci_info =
- #define VR_A3_EXTRAM 0xA3 /* handled with code-bulker firmware only */
- #define USB_CTL_TIMEOUT 2000
- -#define USB_CMD_TIMEOUT 5000 /* 5 seconds */
- +//#define USB_CMD_TIMEOUT 5000 /* 5 seconds */
- +#define USB_CMD_TIMEOUT 25000 /* 25 seconds */
- static int ezusb_ctrl_write(struct wintv_ci_dev *wintvci,
- unsigned char request,
I dont know what's now wrong with the DiabloCam - have you tested it immediatly following the MatrixAir - then please try it again with the CI disconnected in between.
Helmut
-
9000H : Here's the new patch with 3 additional firmware features - two for reading and writing the card configuration area and one for initializing CAMs in a different way.
Should work with ACL 2.2, probably not yet with MatrixAir.
Helmut
-
The correct setting/clearing of the SR and SW bits in the control register is (hopefully) done by firmware, the driver has no write access to this register.
But you are right - I should check the status-byte in the ca_poll_tpdu() function to detect unexpected bits.
Helmut
Edit:
The mentioned issue - if it is / was really one - has it never done into the kernel's dvb_ca_en50221.c - or I am wrong?
-
jrie Etwas OT, aber wie schnell ist "deutlich schneller" ?
Ich verwende Gentoo/OpenRC, und da braucht VDR bis er alle Sachen beisammen hat (Tuner,CAM) für den Start gefühlt zumindest genau so lange wie der reine Bootvorgang dauert.
Helmut
-
Hi Yuri,
Unfortunately, I know this CA timeout-error very well.
It happens occasionally when no more data is written to the CI interface or the time interval between 2 transmissions becomes too long.
I guess it has something to do with the timing of reading and writing URBs. In any case, the CA interface is also blocked.
This blockade could be solved with another transfer to the CI. But because of the timeout, the CAM status is switched to "No CAM", and so no further data will be sent to the CI - a deadlock.I think I will implement a kind of heartbeat that keeps the CI busy and the CA responsive.
But right now I'm doing a firmware patch for CAMs with special needs.
9000H I have almost completed the patch, I need a few more tests and may post the patch tonight or tomorrow.
It should work with the ACL 2.2 and give at least some explanations for the MatrixAir.
Helmut
-
For the wintvci driver, it is the way URBs are transmitted.
The start time of a single URB transmission is assigned by a scheduler to the next free time slot. There is one time slot every millisecond and depending on usb traffic or delays due hardware tasks, the assigned next free slot may be a few milliseconds in the future.
in your case it only took only 1 millisecond to transfer the small data package but about 2 milliseconds waiting in the scheduler.
Therefore, wasting 2/3rd of the time, only 326 URB transmissions per second were possible.
What I ask myself: if minisatip writes to the driver over 300 times per second at only 16 Mbps, then what is at 48 Mbps or even 96 Mbps ?
Will minisatip then really try 1000x or 2000x (!) Writes per second ?
Helmut
-
Yury - you have to change this line too.
Alles anzeigenDiff- --- wintv-ci-ci.c.orig 2019-01-22 00:39:35.432430704 +0100
- +++ wintv-ci-ci.c 2019-02-12 00:40:56.170987890 +0100
- @@ -373,7 +373,7 @@ static int ci_isoc_init(struct ci_device
- int num_transfers = min(ISOC_NUM_TRANSFERS, ISOC_MAX_TRANSFERS);
- int num_uframes = min(ISOC_NUM_UFRAMES, ISOC_MAX_UFRAMES);
- - int min_submit_uf = min(ISOC_MIN_UF_SUBMIT, ISOC_MIN_UF_CHUNK);
- + int min_submit_uf = min(ISOC_MIN_UF_SUBMIT, ISOC_MAX_UFRAMES-1);
- /* OUT */
- ep = &ci_dev->ep_isoc_out;
Helmut
-
Hi Yuri,
[80333.877045] +++ TS-BITRATE : 15.79 Mbit/s, 328.20 CAM-subs/s, URB-load: 0.83%, TS-miss: 12
The number of data transfers (CAM-subs) to the CAM is very high (or too high).
With normal DVB-T2/S2 there are usually only 10 to 20 CAM-submissions per second. So, minisatip delivers many, but only very small data chunks.
By default the wintvci driver starts submitting URBs to the CAM if there are at least 32 TS-packets in the buffer.
You can increase this value by changing ISOC_MIN_UF_SUBMIT from 8 to 64 in wintv-ci.c, line 45.
It should be a multiple of 8, the (theoretical) maximum is the full URB buffer size of 960 - 1.
Helmut
-
Hi Yuri,
what exactly do you mean with "latency" ? The time it needs to see a decoded picture on the screen?
Helmut
-
Is the Matrix CAM in some kind of power-down mode?
This [ 9550.621568] wintv_usb2ci: parse_cis : CFG_REGS present [0-7] = 0x03 says, that there is a second configuration register available - the CSR (Configuration and Status Register).
I will look on it tomorrow.
Helmut
-
The timeouts with cor5.diff are caused by a wrong jump-target in the firmware-patch.
Here is the modified version.
Helmut
-
Good!
But one small mistake in the patches:
Can you modify this line in the func CI_70_WriteCor() and rerun the test with ACL and Matrix. cor5.diff should be enough.
// wrongbuf[2] |= 0x0;
// right
buf[2] = 0x0;
Helmut
-
9000H : I tried a similar Firmware with my Alphacrypt classic but I can't reproduce the behavior of your ACL 2.2.
Here 2 more patches which may help to understand the problem.
Both patches modifies the firmware "wintvci_r2.fw" - they increase a short delay and makes it possible for me to read the value of the COR.
The patches are similar, but in "patched_write_cor6.diff" the COR is not compared against the written config-value and so the function does not fail immediately with an read-error on a missmatch.
If you test these patches, dont forget to un-/replug the CI to get the modifies firmware loaded.
Helmut
-
One more test - mainly to understand the Diablo CAM.
Check if write_cor2 would work in reversed order too.
Helmut
-
Good !
And now a slight variant of "write_COR2.diff" and one without touching the COR at all (usually not working, but another test for the ACL 2.2).Helmut
-
An other blind try with LevelIRQ-bit set.
Alles anzeigenDiff: write_COR2.diff- --- wintv-ci-core.c.git 2018-11-17 18:30:57.793456610 +0100
- +++ wintv-ci-core.c 2019-02-03 11:18:27.280060930 +0100
- @@ -427,7 +427,7 @@ done:
- if (cinfo->to_state)
- cam_state_set(wintvci, cinfo->to_state); /* set new cam-state */
- }
- - else if (rc != CI_ERR_90_CMD_INV)
- + else if (rc != CI_ERR_90_CMD_INV && CI_CMD != CI_70_WRITE_COR)
- cam_state_set(wintvci, USBCI_STATE_NON);
- mutex_unlock(&wintvci->usb_mutex);
- @@ -518,7 +518,16 @@ static int CI_70_WriteCOR(struct wintv_c
- buf[3] = 0; /* FW-Ver. 3 and 4 (?) */
- buf[4] = 0;
- + buf[2] |= 0x40; /* LevelIRQ */
- + pr_info("%s - cfg_option: 0x%02X\n", __func__, (char)buf[2]);
- rc = CI_WriteExchange(wintvci, CI_70_WRITE_COR, NULL, buf, sizeof buf);
- + if (rc) {
- + buf[2] = cfg_option;
- + pr_info("%s - cfg_option: 0x%02X\n", __func__, buf[2]);
- + rc = CI_WriteExchange(wintvci, CI_70_WRITE_COR, NULL, buf, sizeof buf);
- + }
- + if (rc)
- + cam_state_set(wintvci, USBCI_STATE_NON);
- return rc;
- }
Helmut
-
I don't think so, For me it looks more CAM related.
And here one more try:
On my CAMs i can write to the Config-Option.Register only once. If i write to it a second time i get the same read error as the non-working CAMs.
So, what if the COR is allready configured after a reset ? If so, we can simple ignore this error.
Alles anzeigenDiff: write_COR.diff- --- wintv-ci-core.c.git 2018-11-17 18:30:57.793456610 +0100
- +++ wintv-ci-core.c 2019-02-02 00:15:15.721297859 +0100
- @@ -413,6 +413,9 @@ static int CI_WriteExchange(struct wintv
- }
- rc = CI_read_CMD_REPLY(wintvci, CI_CMD_R, reply, debug);
- + if (rc && (rc == CI_ERR_10_LPDU_READ && CI_CMD == CI_70_WRITE_COR))
- + rc = 0;
- +
- t_response = jiffies_to_msecs(jiffies - t_start);
- if (t_response > 50) /* typical 30ms - 33ms */
Helmut
-
The last Alphacrypt log is as expected - no improvement.
But the MATRIX CAM is really different
[181540.876165] wintv_usb2ci: parse_cis : CFG_REGS present [0-7] = 0x03
With all non-working CAMs there seems to be an issue when accessing the configuration register.
But frome the driver-side there is, as far as i know, no other way to do it.
I really have to look for one of these non-working CAMs for testings.
Helmut
