This reverts commit 080b4929b7452dc1fea32ac1d32e7e571e7fb38b.
Chris noticed that "negative values wait forever" is indeed intended
behaviour and the issue is just that we didn't have a testcase (fixed
now) and that a regression slipped through (fixed and on track for all
stable kernels).
So lets undo the documentation change for consistency, since working
around kernel regressions isn't good. Practical impact is nil anyway.
v2: Add a note to docs that some kernels have been broken.
Cc: Kristian Høgsberg <krh@xxxxxxxxxxxxx>
Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Reviewed-by: Kristian Høgsberg <krh@xxxxxxxxxxxxx>
Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx>
---
intel/intel_bufmgr_gem.c | 15 ++++++++-------
xf86drmMode.c | 13 ++++++++++++-
2 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index 33d8fbc46242..acbfd4ada209 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/intel_bufmgr_gem.c
@@ -1655,14 +1655,12 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
*
* @bo: buffer object to wait for
* @timeout_ns: amount of time to wait in nanoseconds.
- * If value is less than or equal to 0, return immediately.
+ * If value is less than 0, an infinite wait will occur.
*
- * Returns 0 if the wait was successful ie. the last batch referencing
- * the object has completed within the allotted time. Otherwise some
- * negative return value describes the error. Of particular interest
- * is -ETIME when the wait has failed to yield the desired result.
- * Use a timeout of INT64_MAX to wait indefinitely (well, at least 292
- * years).
+ * Returns 0 if the wait was successful ie. the last batch referencing the
+ * object has completed within the allotted time. Otherwise some negative return
+ * value describes the error. Of particular interest is -ETIME when the wait has
+ * failed to yield the desired result.
*
* Similar to drm_intel_gem_bo_wait_rendering except a timeout parameter allows
* the operation to give up after a certain amount of time. Another subtle
@@ -1675,6 +1673,9 @@ drm_intel_gem_bo_wait_rendering(drm_intel_bo *bo)
* not guarantee that the buffer is re-issued via another thread, or an flinked
* handle. Userspace must make sure this race does not occur if such precision
* is important.
+ *
+ * Note that some kernels have broken the inifite wait for negative values
+ * promise, upgrade to latest stable kernels if this is the case.
*/
drm_public int
drm_intel_gem_bo_wait(drm_intel_bo *bo, int64_t timeout_ns)
diff --git a/xf86drmMode.c b/xf86drmMode.c
index 9ea8fe721842..3a9bb0b6560a 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -477,7 +477,7 @@ drmModeEncoderPtr drmModeGetEncoder(int fd, uint32_t encoder_id)
* Connector manipulation
*/
-drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+drmModeConnectorPtr __drmModeGetConnector(int fd, uint32_t connector_id, bool current)
{
struct drm_mode_get_connector conn, counts;
drmModeConnectorPtr r = NULL;
@@ -485,6 +485,7 @@ drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
retry:
memclear(conn);
conn.connector_id = connector_id;
+ conn.count_modes = current;
if (drmIoctl(fd, DRM_IOCTL_MODE_GETCONNECTOR, &conn))
return 0;
@@ -572,6 +573,16 @@ err_allocs:
return r;
}
+drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+{
+ __drmModeGetConnector(fd, connector_id, false);
+}
+
+drmModeConnectorPtr drmModeGetConnector(int fd, uint32_t connector_id)
+{
+ __drmModeGetConnector(fd, connector_id, true);
+}
+
int drmModeAttachMode(int fd, uint32_t connector_id, drmModeModeInfoPtr mode_info)
{
struct drm_mode_mode_cmd res;
--
2.1.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
