Message Passing SRIO example and DOORBELL's info field

Igor,

(1) Based on Mailbox, letter, source ID, and Destination ID the data is assigned the destination CPPI queue ID (QID) and flow ID.

You can get more detail of SRIO operations and specifics at the training videos. http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT110027

This diagram was found in Serial RapidIO (SRIO).

(2) I am not sure what you mean. Can you please clarify? I think you want to avoid using the INFO field to indicate which DOORBELL register interrupt bit to be set. If that is the case, then you can't do that. 

Thanks

Elush

------------------------------------------------------------------------------------------

Please click Verify Answer if I have answered your question.

Elush, Thank you for your answer. Indeed, what I wanted with (2) was to modify the behavior of Doorbell packet servicing so that a single, hard-coded interrupt was used. That way I could use the 16 bits of the INFO field to transmit application data (for notifications, basically).

Regarding the SRIOLoopbackDioIsr example in pdk_C6670_1_0_0_17, is it possible to use a blocking SRIO_sockRecv() to wait until a SRIO_sockSend() ? To have this further explained, I wanted (by whatever means) to start processing the buffer which is written to by the SRIO peripheral inside the dioSocketsWithISR() call. My understanding of the example is that CORE_SYS_INIT will first issue a Srio_Ftype_WRITE request with Srio_Ttype_Write_NWRITE_R transaction to write to some predetermined buffer, but it is unclear how I could 'catch' this write's completion 'event' so that I could use the results inside the buffer, hence the blocking sockRecv() idea above.

Igor,

If you look at the doxygen file in the PDK, pdk_C6670_XXX\packages\ti\drv\srio\docs\doxygen\html, you will see a deeper description of the functions used in the example projects.

Under SRIO_sockRecv(), you see that "The function is used to receive data from the SRIO socket. For blocking sockets this API will block and will only return once data is received for non-blocking sockets the API will return 0 if no data is available. If data is available on the socket; the receive API will pass back the data to the callee. For Raw Sockets data is passed up as a buffer descriptor while for normal sockets the data is passed as pointer to the data payload." 

To make a socket blocking, you need to set it in the Srio_sockOpen(Srio DrvHandle hSrio, Srio_SocketType type, uint16_t isBlocking). Set it to 1 to make a blocking socket. 

Once again, this is all in the doxygen file found in each PDK.

Thanks

Elush

------------------------------------------------------------------------------------------

Please click Verify Answer if I have answered your question.

Elush, my problem is not how to make the socket 'blocking'. What I want to figure out is a way to 'catch' the completion of DIO transactions. For example, say core 0 wants to issue a DIO ftype5 (WRITE) ttype5 (NWRITE_R) operation -- which is exactly what the SRIOLoopbackDioIsr example does. To do that, core 0 will eventually call SRIO_sockSend_DIO(). How can I, in some other core, for example core 1, detect that the DIO operation has finished so that I can process the data? Is it done by having core 1 call SRIO_sockRecv() ? I am in doubt if that is the case because the DIO socket binding information seem insufficient. The SRIO User Guide (sprugw1a) seems to answer that in section 2.3.9.1.1, and the answer seems to be that after the DIO operation above (ftype5 ttype5), core 0 (the sending core) must send a DOORBELL. Does TI's SRIO driver code do that automatically so that all I have to do is set Srio_DioBindAddrInfo.doorbellValid ?

Igor,

Your presumption is correct. You must use a DOORBELL. Please look at the Interrupt Registers to set your DOORBELL to do the desired action. Also, you must set the DOORBELL value and info in the LSU registers in Figure 2-5 of the SRIO User Guide (the User Guide has been updated recently). 

Elush Shirazpour

Elush,

I believe I have encountered a problem in using Srio_SockRecv() for doorbells. I believe the correct usage here is to call Srio_SetSockOpt (option Srio_Opt_REGISTER_DOORBELL) to 'register' this socket as the one which will be woken up when Srio_dioCompletionIsr() runs.

However, this mechanism seems to have a problem: Srio_SetSockOpt()'s third parameter, "void* optval", is first converted to a 'uint16_t' and then re-converted to a 'uint32_t' so the doorbell bit and doorbell register fields can be fetched. Here is the actual [relevant] code from pdk_C6670_1_0_0_17:

        case Srio_Opt_REGISTER_DOORBELL:
        {
            uint8_t     doorbellBit;
            uint8_t     doorbellReg;
            uint16_t    doorbellInfo;
            void*       csInfo;

#ifdef SRIO_DRV_DEBUG
            /* Option is valid only for DIO sockets. */
            if (ptr_srioSocket->type != Srio_SocketType_DIO)
                break;

            /* This option takes a 'uint16_t' configuration data */
            if (optlen != sizeof(uint16_t))`
                break;
#endif
            /* Get the doorbell information. */
            doorbellInfo = *(uint16_t *)optval;

            /* Extract the doorbell register and bit information. */
            doorbellReg = SRIO_GET_DBELL_REG((uint32_t)doorbellInfo);
            doorbellBit = SRIO_GET_DBELL_BIT((uint32_t)doorbellInfo);

What is generated from the SRIO_SET_DBELL_INFO macro (and therefore passed to this code) can never fit that 'doorbellInfo' variable.

I wonder if anyone has managed to unblock a [blocking] Srio_SockRecv() call waiting on a doorbell, because Srio_SockRecv() will pend on the socket's semaphore until Srio_dioCompletionIsr() posts it, but with this code the socketDoorbellDatabase[][] variable will never be correctly updated, and it is this database that holds the pointer to the original socket.

Please verify.