qcom-tcs.txt 5.0 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166
  1. TCS Mailbox:
  2. ------------
  3. Trigger Command Set (TCS) is the mailbox mechanism for communicating with
  4. the hardened resource accelerators. Requests to the resources can be written
  5. to the mailbox registers and using a (addr, val) pair and triggered. Messages
  6. in the mailbox are then sent in sequence over an internal bus.
  7. The implementation of the TCS mailbox, follows the mailbox controller
  8. architecture [1]. The logical block (DRV) is a part of the h/w entity
  9. (Resource State Coordinator a.k.a RSC) that can handle a multiple sleep and
  10. active/wake resource request related functionality including the mailbox.
  11. Multiple such DRVs can exist in a SoC and can be written to from Linux. The
  12. structure of each DRV follows the same template with a few variations that are
  13. captured by the properties here.
  14. Each DRV could have 'm' TCS instances. Each TCS could have 'n' slots. Each
  15. slot has a header (u32), address (u32), data (u32), status (u32) and a
  16. read-response (u32). A TCS when triggered will send all the enabled commands
  17. of the 'n' commands in that slot in sequence.
  18. A TCS may be triggered from Linux or triggered by the F/W after all the CPUs
  19. have powered off to faciliate idle power saving. TCS could be classified as -
  20. SLEEP, /* Triggered by F/W and not by Linux */
  21. WAKE, /* Triggered by F/W, may be used by Linux */
  22. ACTIVE, /* Triggered by Linux */
  23. CONTROL /* Triggered by F/W */
  24. Requests can be made for the state of a resource, when the subsystem is active
  25. or idle. When all subsystems like Modem, GPU, CPU are idle, the resource state
  26. will be an aggregeate of the sleep votes from each of those subsystem. Drivers
  27. may request a sleep value for their shared resources in addition to the active
  28. mode requests.
  29. Control requests are instance specific requests that may or may not reach an
  30. accelerator. Only one platform device in Linux can request a control channel
  31. on a DRV.
  32. CONTROLLER:
  33. ----------
  34. PROPERTIES:
  35. - compatible:
  36. Usage: required
  37. Value type: <string>
  38. Definition: Should be "qcom,tcs-drv".
  39. - reg:
  40. Usage: required
  41. Value type: <prop-encoded-array>
  42. Definition: the first element specifies the base address of the DRV,
  43. the second element specifies the size of the region.
  44. - #mbox-cells:
  45. Usage: required
  46. Value type: <u32>
  47. Definition: the number of mail-box cells. Must be 1.
  48. - interrupts:
  49. Usage: required
  50. Value type: <prop-encoded-interrupt>
  51. Definition: the interrupt that trips when a message complete/response
  52. is received for this DRV from the accelertors.
  53. - qcom,drv-id:
  54. Usage: required
  55. Value type: <u32>
  56. Definition: the id of the DRV in the RSC block.
  57. - qcom, tcs-config:
  58. Usage: required
  59. Value type: <prop-encoded-array>
  60. Definition: the tuple definining the configuration of TCS.
  61. Must have 2 cells which describe each TCS type.
  62. <type number_of_tcs>
  63. - Cell #1 (TCS Type): Only the TCS types can be specified -
  64. SLEEP_TCS
  65. WAKE_TCS
  66. ACTIVE_TCS
  67. CONTROL_TCS
  68. - Cell #2 (Number of TCS): <u32>
  69. - label:
  70. Usage: optional
  71. Value type: <string>
  72. Definition: Name for the mailbox. The name would be used in trace logs.
  73. EXAMPLE 1:
  74. For a TCS whose RSC base address is is 0x179C0000 and is at a DRV of 2, the
  75. register offsets for DRV2 start at 0D00, the register calculations are like
  76. this -
  77. First tuple: 0x179C0000 + 0x10000 * 2 = 0x179E0000
  78. Second tuple: 0x179E0000 + 0xD00 = 0x179E0D00
  79. apps_rsc: mailbox@179e000 {
  80. compatible = "qcom,tcs_drv";
  81. label = "apps_rsc";
  82. reg = <0x179E0000 0x10000>, <0x179E0D00 0x3000>;
  83. interrupts = <0 5 0>;
  84. #mbox-cells = <1>;
  85. qcom,drv-id = <2>;
  86. qcom,tcs-config = <SLEEP_TCS 3>,
  87. <WAKE_TCS 3>,
  88. <ACTIVE_TCS 2>,
  89. <CONTROL_TCS 1>;
  90. };
  91. EXAMPLE 2:
  92. For a TCS whose RSC base address is 0xAF20000 and is at DRV of 0, the register
  93. offsets for DRV0 start at 01C00, the register calculations are like this -
  94. First tuple: 0xAF20000
  95. Second tuple: 0xAF20000 + 0x1C00
  96. disp_rsc: mailbox@af20000 {
  97. status = "disabled";
  98. label = "disp_rsc";
  99. compatible = "qcom,tcs-drv";
  100. reg = <0xAF20000 0x10000>, <0xAF21C00 0x3000>;
  101. interrupts = <0 129 0>;
  102. #mbox-cells = <1>;
  103. qcom,drv-id = <0>;
  104. qcom,tcs-config = <SLEEP_TCS 1>,
  105. <WAKE_TCS 1>,
  106. <ACTIVE_TCS 0>,
  107. <CONTROL_TCS 1>;
  108. };
  109. CLIENT:
  110. -------
  111. A device needing to communicate with the accelerators should specify the
  112. common mailbox client properties described in [1]. mbox-names can be used to
  113. provide a string name optionally for driver to lookup by name.
  114. - mboxes:
  115. Usage: required, if the device wants to communicate with the mailbox
  116. Value type: <prop-encoded-array>
  117. Definition: The tuple has an handle to the mailbox instance the client
  118. as the first argument, the second argument must be 0. This
  119. is one per MBOX controller addressed.
  120. EXAMPLE:
  121. leaky_device@0 {
  122. <...>;
  123. mbox-names = <"leaky-channel">;
  124. mboxes = <&tcs_box 0>;
  125. };
  126. leaky_device@1 {
  127. <...>;
  128. mbox-names = <"apps", "display">;
  129. mboxes = <&tcs_box 0>, <&dsp_box 0>;
  130. };
  131. power_ctrl@0 {
  132. <...>;
  133. mbox-names = <"rpmh">;
  134. mboxes = <&tcs_box 0>;
  135. };
  136. [1]. Documentation/mailbox.txt