WinTV-CI / Cinergy-USB-CI und ddci2

  • 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

  • However, with modified drivers i have this strace output: (after about one minute):

    Not so much...


    BR,

    Yuri

  • Hi Helmut,

    sometimes device stalled with such errors in dmesg:


    Is possible recovery from this situation except disconnect and reload firmware? And where may be source this errors?


    BR,

    Yuri

  • 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

  • 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?

  • 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

  • Hi,

    the ACL 2.2


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Hi,

    the Matrix CAM Air

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Hi,

    the Diablo CAM has issues now

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • 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

  • Hi,

    now with the ACL 2.2 and the higher timeout

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Hi,


    now the Matrix CAM Air

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Hi,

    the Diablo CAM


    the forum has a 10000 Char limit for posting code so I did use pastebinit this time

    http://paste.ubuntu.com/p/fVpQz9zCpZ/

    The bet result up to now was the COR6 patch where both ACL 2.2 and Diablo CAM work.


    I do not care to much about the Matrix CAM Air as this is a not so common CAM.


    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • 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

  • Hi,

    the ACL 2.2 next-1a

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

  • Hi,

    the Matrix CAM Air next-1a

    CU

    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.