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
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
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.
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.
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.
// wrong
buf[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.
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.
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