Skip to content

Commit

Permalink
Merge pull request #23 from lftan/fix-links
Browse files Browse the repository at this point in the history
Fix broken links
  • Loading branch information
pathakraul authored Apr 18, 2024
2 parents 4441e70 + 1f2c697 commit 52a4629
Show file tree
Hide file tree
Showing 5 changed files with 20 additions and 16 deletions.
1 change: 1 addition & 0 deletions src/intro.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,7 @@ An RPMI agent is an implementation instance of the RPMI Messaging Protocol and T
agent in S-mode for some RPMI services, an M-mode RPMI agent also enhances
security.

[#img-transport-topologies]
.Transport for M-Mode and S-Mode
image::transport-topologies.png[width=800,height=800]

Expand Down
8 changes: 5 additions & 3 deletions src/message-protocol.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -39,7 +39,7 @@ each service dictates if acknowledgment is mandatory or not.
==== NOTIFICATIONS
Notifications are messages which are sent asynchronously from PuC to AP to
notify about the events happening in the system related to various service
groups. Notifications are covered in detail in below section <<ADD LINK HERE>>
groups. Notifications are covered in detail in below <<Notifications>>.

=== Message Format
On the AP side, each call to a service results in a message request to the PuC.
Expand Down Expand Up @@ -143,8 +143,8 @@ can include the system states, power states, errors/faults in the system etc.
Action taken on behalf of any event notification is completely dependent on the
AP and they can be ignored. Platform Microcontroller may combine multiple events
into a single message depending on the available space in the message data.
Individual events may also have additional data associated. _Figure 3.4_ shows
the notification message format.
Individual events may also have additional data associated. <<img-notification-format>>
shows the notification message format.

Each service group will have a notification service with fixed `SERVICE_ID=0x00`
across every service group. Notifications are sent from PuC to AP with events
Expand Down Expand Up @@ -174,6 +174,8 @@ header.
Event data and its format depend on the service group and details are present in
respective service group sections.

[#img-notification-format]
.Notification Format
image::notification-format.png[500,600]

[#table_notification_message_format]
Expand Down
2 changes: 1 addition & 1 deletion src/srvgrp-base.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -64,7 +64,7 @@ Below table lists the services in this group:
==== Base Notifications
Platform Microcontroller can send asynchronous notifications to AP via this
service. There can be multiple types of events classified in the Base service
group which can be combined into a single message as depicted in _Figure 3.5_.
group which can be combined into a single message as depicted in <<Notifications>>.
If Platform Microcontroller has multiple events for the same type, Platform Microcontroller can send the single instance of that event that was received
last.
[#table_base_srvgroup_events]
Expand Down
12 changes: 6 additions & 6 deletions src/srvgrp-hart-state-management.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -113,7 +113,7 @@ processor.
[cols="5,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Service completed successfully and hart is started.
! RPMI_SUCCESS ! Service completed successfully and hart is stopped.
! RPMI_ERROR_DENIED ! Not allowed due to current hart state which is platform
specific
!===
Expand Down Expand Up @@ -147,7 +147,7 @@ _Only used for non-retentive suspend types._
[cols="6,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Service completed successfully and hart is started.
! RPMI_SUCCESS ! Service completed successfully.
! RPMI_ERROR_INVALID_PARAMETER ! Invalid SUSPEND_TYPE.
!===
- Other errors <<table_error_codes>>
Expand All @@ -173,7 +173,7 @@ This service gets the running status of a Hart.
[cols="6,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Notifications are subscribed successfully.
! RPMI_SUCCESS ! Service completed successfully.
! RPMI_ERROR_INVALID_PARAMETER ! Invalid HART_ID.
!===
- Other errors <<table_error_codes>>
Expand Down Expand Up @@ -211,7 +211,7 @@ This service gets the list of harts with a specified Hart ID start index
[cols="6,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Notifications are subscribed successfully.
! RPMI_SUCCESS ! Service completed successfully.
! RPMI_ERROR_INVALID_PARAMETER ! Invalid START_INDEX.
!===
- Other errors <<table_error_codes>>
Expand Down Expand Up @@ -245,7 +245,7 @@ items.
[cols="7,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Notifications are subscribed successfully.
! RPMI_SUCCESS ! Service completed successfully.
! RPMI_ERROR_INVALID_PARAMETER ! Invalid START_INDEX.
!===
- Other errors <<table_error_codes>>
Expand Down Expand Up @@ -276,7 +276,7 @@ Get attributes of a suspend type.
[cols="7,5"]
!===
! *Error Code* ! *Description*
! RPMI_SUCCESS ! Notifications are subscribed successfully.
! RPMI_SUCCESS ! Service completed successfully.
! RPMI_ERROR_INVALID_PARAMETER ! Invalid SUSPEND_TYPE.
!===
- Other errors <<table_error_codes>>
Expand Down
13 changes: 7 additions & 6 deletions src/transport.adoc
100644 → 100755
Original file line number Diff line number Diff line change
Expand Up @@ -9,8 +9,8 @@ a privilege level of a set of APs and one PuC. There can be multiple RPMI
transport instances between a set of APs and one PuC. For example: there can
be a separate transport instance between each privilege level of APs and one
PuC. A platform can also have multiple PuCs with each having its own set of
RPMI transport to communicate with the APs. The _Figure 1.2_ above shows
different topologies of RPMI transport.
RPMI transport to communicate with the APs. The <<img-transport-topologies>>
above shows different topologies of RPMI transport.

The physical medium of an RPMI transport can be shared memory or some other
medium. This specification only defines a shared memory based RPMI
Expand Down Expand Up @@ -86,11 +86,12 @@ and
==== Layout of Shared Memory
The shared memory RPMI Transport defines four shared memory based queues for
bidirectional synchronous/asynchronous communication between an AP and PuC.
The detailed layout of the shared memory and queues is shown in Figure 2.1. All
queues in the shared memory are contiguous and of equal size. Sequence of the queues is
arranged such that queues which enable Request-Acknowledgement for a side either
AP to PuC or vice versa are together.
The detailed layout of the shared memory and queues is shown in <<img-shmem-layout>>.
All queues in the shared memory are contiguous and of equal size. Sequence of
the queues is arranged such that queues which enable Request-Acknowledgement
for a side either AP to PuC or vice versa are together.

[#img-shmem-layout]
.Memory Layout of Shared Memory
image::shmem-layout.png[600,600]

Expand Down

0 comments on commit 52a4629

Please sign in to comment.