![]() |
![]() |
The Resource Manager low level driver (RM LLD) is designed to provide initialization and permissions checking for LLD resources. A system integrator can specify DSP permissions for LLD resources within the system. The resource permissions are stored in the RM LLD and used to validate resource requests from supported LLDs. Currently, the RM LLD supports permissions for the following LLDs
The system integrator must specify the supported LLD resource permissions for all DSPs prior to compile time. An array of Rm_Resource objects must be created. Each Rm_Resource entry in the array specifies a resource type, start and end range for the resource, and the initialization and usage permissions for the resource for each DSP. For an example resource table definitions please see the rmResourceTable array defined in the resource_table\ directory. This resource table assigns full initialization and usage permissions to all DSPs for all supported resources. Please note that the resouce table must start with the RM_RESOURCE_MAGIC_NUMBER entry and end with the RM_RESOURCE_FINAL_ENTRY. These first and last entries are used the RM LLD to validate and parse the resource table.
The RM LLD must be initialized and started prior to all supported LLD initialization and start routines. The Rm_init function should be invoked, and passed a pointer to the integrator defined resource table, on the master DSP core in the system. All other DSP cores should invoke the Rm_start API. The Rm_init function first initializes the internal permission tables to deny all DSPs access to all resources. Next the Rm_init function parses the resource table provided and copies all specified permissions into the internal tables. When the permission transfer completes the Rm_init function writes a global synchronization object which the Rm_start functions are spinning on. The slave cores that have invoked Rm_start will stop spinning once the global synchronization has been written. At this time Rm_start will invalidate all internal permission tables so that no further cache invalidate operations need to be performed when checking resource permissions in the data path. The upfront cache invalidate operation is possible because the RM LLD does not allow dynamic resource permission modifications. The permissions defined by the system integrator and loaded during RM initialization are static throughout the system up-time.
The RM LLD must be registered with a supported LLD in order for the supported LLD to perform resource permission checks. If the RM LLD is not registered with a supported LLD the LLD will operate as if the RM LLD is not there. This maintains full backwards compatability with existing applications not using the RM LLD. In order to register the RM LLD with supported LLDs the following steps should be taken
All internal RM LLD permission tables are placed into a single memory section called ".rm". This memory section MUST be placed in shared memory (MSMC or DDR). The permission tables are shared between all DSPs utilizing the RM LLD.
In summary, the initialization flow if the RM LLD is to be utilized should look like the following:
Master DSP Core:
Slave DSP Cores: