Beiträge von HelmutB


    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.


    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.


    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.


    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.



    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?

    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.


    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 ?


    Yury - you have to change this line too.


    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.

    1. #define ISOC_MIN_UF_CHUNK 8 /* transmit only in chunks of 8 micro-frames (1 full frame) */
    2. //#define ISOC_MIN_UF_SUBMIT ISOC_MIN_UF_CHUNK /* the minimum of data to start a URB submission to the CAM */
    3. #define ISOC_MIN_UF_SUBMIT 64 /* the minimum of data to start a URB submission to the CAM */


    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.


    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.


    An other blind try with LevelIRQ-bit set.


    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.


    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.