• State TI Thinks Resolved
  • Locked Locked
  • Replies 1 reply
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 687 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Host Base Device ID Lock CSR in C6455

Renaissance
Intellectual 925 points

In SRIO registers, there are several related to Device ID. My understanding is that:

-         RapidIO DEVICEID Register should be the same as Base Device ID CSR

-         if bit 4 of the PE_FEAT Register is set, the 16 bit ID will be used. Otherwise, the 8 bit ID will be used.

However, What kind of role is the Host Base Device ID Lock CSR playing here? In the SRIO document spru976, it told me to see section 2.4.2 of the RatpidIO spec for descrption, but I found this section does not exit. I try to understand what is written in the field description as following in this document:

 

Table 105. Host Base Device ID Lock CSR (HOST_BASE_ID_LOCK) Field Descriptions

Bit Field Value Description

31-16 Reserved Reserved

15-0 HOST_BASE_DE VICEID  This is the base ID for the Host PE that is initializing this PE.

 

Can any of you give me some hint how this Host Base Device ID Lock CSR works?

Thank you very much

  • 0
    TI__Mastermind 23525 points

    The operation of the Host Base DeviceID register is detailed in:

     

    http://www.rapidio.org/specs/disclaimer?specfile=/zdata/specs/cmn_trnspt.pdf   section 3.5.2

     

    Essentially, it offers semaphore functionality when there is more than one system host.  If one host acquires the lock on this register, the other host should avoid initializing or configuring this endpoint.  Under this usage model, a host is required to read the register and verify it has the lock before programming any of the endpoint's registers.

    BTW, the bit 4 in the PE_FEAT register doesn't actually control the 8b versus 16b deviceID usage, it simply indicates what can be supported.  8b has to be supported at a minimum.  The tt field of the transaction can be used to determine 8b versus 16b IDs on a transaction basis.  Typically, these are not intermixed on an endpoint basis.

    Regards,

    Travis