@@ -103,6 +103,33 @@ enum { CTB_SEND = 0, CTB_RECV = 1 };
103
103
104
104
enum { CTB_OWNER_HOST = 0 };
105
105
106
+ /*
107
+ * Some H2G commands involve a synchronous response that the driver needs
108
+ * to wait for. In such cases, a timeout is required to prevent the driver
109
+ * from waiting forever in the case of an error (either no error response
110
+ * is defined in the protocol or something has died and requires a reset).
111
+ * The specific command may be defined as having a time bound response but
112
+ * the CT is a queue and that time guarantee only starts from the point
113
+ * when the command reaches the head of the queue and is processed by GuC.
114
+ *
115
+ * Ideally there would be a helper to report the progress of a given
116
+ * command through the CT. However, that would require a significant
117
+ * amount of work in the CT layer. In the meantime, provide a reasonable
118
+ * estimation of the worst case latency it should take for the entire
119
+ * queue to drain. And therefore, how long a caller should wait before
120
+ * giving up on their request. The current estimate is based on empirical
121
+ * measurement of a test that fills the buffer with context creation and
122
+ * destruction requests as they seem to be the slowest operation.
123
+ */
124
+ long intel_guc_ct_max_queue_time_jiffies (void )
125
+ {
126
+ /*
127
+ * A 4KB buffer full of context destroy commands takes a little
128
+ * over a second to process so bump that to 2s to be super safe.
129
+ */
130
+ return (CTB_H2G_BUFFER_SIZE * HZ ) / SZ_2K ;
131
+ }
132
+
106
133
static void ct_receive_tasklet_func (struct tasklet_struct * t );
107
134
static void ct_incoming_request_worker_func (struct work_struct * w );
108
135
0 commit comments