Port -client drivers to use the PRM

This document describes how to port client drivers to use the PRM.

Purpose

Device drivers must register as clients -to access services of the PRM.

Introduction

Kernel -side components can access PRM services through exported kernel side APIs -by including resourceman.h and linking against the static -library provided by the PRM. See setup -and configuration requirements.

Porting client drivers

Kernel side components -register as clients with the PRM from their entry point during kernel boot -and device drivers register as clients on channel opening.

User side -components can access PRM services through a user side proxy interface. See user-side for -more information.

To guarantee deterministic behaviour during resource -state change and read operations (mainly on a long latency resource), clients -should pre-allocate ‘client level’ objects and request objects using AllocReserve(). -This needs to be done immediately after registering as clients of the PRM.

Before -de-registering as clients from PRM, device drivers must:

Cancel any pending asynchronous -request with CancelAsyncRequestCallback(). If CancelAsyncRequestCallback returns KErrInUse the -client must wait for the request to complete before proceeding with deregistration -as the asynchronous request has started processing and will run to completion,
Cancel all resource -state change notification requests issued by this client using CancelNotification(),
Delete the asynchronous -callback objects and notification objects created by this client to avoid -memory leak.

Omissions

PRM APIs cannot be called from a Null thread, -ISR or from DFC thread1. However it might be possible that ISR need to operate -on a power resource, for example, a power supply may need to be turned on -before a hardware register that an ISR is interested on can be read. In this -case Base port developers need to access the power resource directly. In order -for the PRM to provide a consistent view of power resources any resource manipulators -in an ISR must leave them unchanged, so in the above example, the ISR must -turn OFF the power supply after it read the registers.

-Porting the -Power Resource Manager -Implement -the controllable power resources -Implement -the PSL for the target -Debugging -the PRM -Testing the -PRM PSL + + + + + +Port client drivers to use the PRMThis document describes how to port client drivers to use +the PRM. +

Purpose

Device drivers must register as clients to access services of +the PRM.

Introduction

Kernel side components +can access PRM services through exported kernel side APIs by including resourceman.h and linking against the static library provided +by the PRM. See setup and configuration requirements.

Porting +client drivers

Kernel side components register as clients +with the PRM from their entry point during kernel boot and device +drivers register as clients on channel opening.

User side +components can access PRM services through a user side proxy interface. +See user-side for more information.

To guarantee deterministic +behaviour during resource state change and read operations (mainly +on a long latency resource), clients should pre-allocate ‘client level’ +objects and request objects using AllocReserve(). This needs to be done immediately after registering as clients +of the PRM.

Before de-registering as clients from PRM, device +drivers must:

Cancel any pending +asynchronous request with CancelAsyncRequestCallback(). If CancelAsyncRequestCallback returns KErrInUse the client must wait for the request to complete +before proceeding with deregistration as the asynchronous request +has started processing and will run to completion,
Cancel all resource +state change notification requests issued by this client using CancelNotification(),
Delete the asynchronous +callback objects and notification objects created by this client to +avoid memory leak.

Omissions

PRM APIs cannot be called from +a Null thread, ISR or from DFC thread1. However it might be possible +that ISR need to operate on a power resource, for example, a power +supply may need to be turned on before a hardware register that an +ISR is interested on can be read. In this case Base port developers +need to access the power resource directly. In order for the PRM to +provide a consistent view of power resources any resource manipulators +in an ISR must leave them unchanged, so in the above example, the +ISR must turn OFF the power supply after it read the registers.

+Porting +the Power Resource Manager +Implement +the controllable power resources +Implement +the PSL for the target +Debugging +the PRM +Testing +the PRM PSL

\ No newline at end of file