[PATCH 7/7] drm/dp_helper: Rate limit timeout errors from drm_dp_i2c_do_msg()
Timeouts can be errors, but timeouts are also usually normal behavior
and happen a lot. Since the kernel already lets us know when we're
suppressing messages due to rate limiting, rate limit timeout errors so
we don't make too much noise in the kernel log.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 43be189..5ca72d25 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -574,7 +574,17 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg)
if (ret == -EBUSY)
continue;
- DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+ /*
+* While timeouts can be errors, they're usually normal
+* behavior (for instance, when a driver tries to
+* communicate with a non-existant DisplayPort device).
+* Avoid spamming the kernel log with timeout errors.
+*/
+ if (ret == -ETIMEDOUT)
+ DRM_DEBUG_KMS_RATELIMITED("transaction timed
out\n");
+ else
+ DRM_DEBUG_KMS("transaction failed: %d\n", ret);
+
return ret;
}
--
2.7.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 6/7] drm: Add ratelimited versions of the DRM_DEBUG* macros
There's a couple of places where this would be useful for drivers (such
as reporting DP aux transaction timeouts).
Signed-off-by: Lyude
---
include/drm/drmP.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d377865..1c4d91b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -231,6 +231,36 @@ void drm_err(const char *format, ...);
drm_ut_debug_printk(__func__, fmt, ##args); \
} while (0)
+#define _DRM_DEFINE_DEBUG_RATELIMITED(level, fmt, args...) \
+ do {\
+ if (unlikely(drm_debug & DRM_UT_ ## level)) { \
+ static DEFINE_RATELIMIT_STATE( \
+ _rs,\
+ DEFAULT_RATELIMIT_INTERVAL, \
+ DEFAULT_RATELIMIT_BURST); \
+ \
+ if (__ratelimit(&_rs)) {\
+ drm_ut_debug_printk(__func__, fmt, \
+ ##args);\
+ } \
+ } \
+ } while (0)
+
+/**
+ * Rate limited debug output. Like DRM_DEBUG() but won't flood the log.
+ *
+ * \param fmt printf() like format string.
+ * \param arg arguments
+ */
+#define DRM_DEBUG_RATELIMITED(fmt, args...)\
+ _DRM_DEFINE_DEBUG_RATELIMITED(CORE, fmt, ##args)
+#define DRM_DEBUG_DRIVER_RATELIMITED(fmt, args...) \
+ _DRM_DEFINE_DEBUG_RATELIMITED(DRIVER, fmt, ##args)
+#define DRM_DEBUG_KMS_RATELIMITED(fmt, args...)
\
+ _DRM_DEFINE_DEBUG_RATELIMITED(KMS, fmt, ##args)
+#define DRM_DEBUG_PRIME_RATELIMITED(fmt, args...) \
+ _DRM_DEFINE_DEBUG_RATELIMITED(PRIME, fmt, ##args)
+
/*@}*/
/***/
--
2.7.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 1/7] drm/dp_helper: Print first error received on failure in drm_dp_dpcd_access()
Since we always retry in drm_dp_dpcd_access() regardless of the error,
we're going to make a lot of noise if the aux->transfer function prints
it's own errors (as is the case with radeon). If we can print the error
code here, this reduces the need for drivers to do this. So instead of
having to print "dp_aux_ch timed out" over 32 times we can just print
once.
Signed-off-by: Lyude
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 8f11b87..43be189 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -223,7 +223,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8
request,
err = ret;
}
- DRM_DEBUG_KMS("too many retries, giving up\n");
+ DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
ret = err;
unlock:
--
2.7.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 3/7] drm/radeon: Don't retry 7 times in radeon_dp_dpcd()
When this code was written, we didn't retry DP aux transactions on any
error, which required retrying important transactions like this in
individual drivers. Since that's no longer the case, retrying here is
not necessary. As well, we retry any aux transaction on any error 32
times. 7 * 32 = 224, which means this loop causes us to retry grabbing
the dpcd 224 times. This is definitely far more then we actually need to
do.
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/atombios_dp.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_dp.c
b/drivers/gpu/drm/radeon/atombios_dp.c
index cead089a..432cb46 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -389,22 +389,21 @@ bool radeon_dp_getdpcd(struct radeon_connector
*radeon_connector)
{
struct radeon_connector_atom_dig *dig_connector =
radeon_connector->con_priv;
u8 msg[DP_DPCD_SIZE];
- int ret, i;
+ int ret;
- for (i = 0; i < 7; i++) {
- ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux,
DP_DPCD_REV, msg,
- DP_DPCD_SIZE);
- if (ret == DP_DPCD_SIZE) {
- memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
+ ret = drm_dp_dpcd_read(&radeon_connector->ddc_bus->aux, DP_DPCD_REV,
msg,
+ DP_DPCD_SIZE);
+ if (ret == DP_DPCD_SIZE) {
+ memcpy(dig_connector->dpcd, msg, DP_DPCD_SIZE);
- DRM_DEBUG_KMS("DPCD: %*ph\n",
(int)sizeof(dig_connector->dpcd),
- dig_connector->dpcd);
+ DRM_DEBUG_KMS("DPCD: %*ph\n", (int)sizeof(dig_connector->dpcd),
+ dig_connector->dpcd);
- radeon_dp_probe_oui(radeon_connector);
+ radeon_dp_probe_oui(radeon_connector);
- return true;
- }
+ return true;
}
+
dig_connector->dpcd[0] = 0;
return false;
}
--
2.7.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
[PATCH 2/7] drm/radeon: Don't print error on aux transaction timeouts
Since it's normal for DRM to retry our aux transaction helpers multiple
times in a row, up to 32 times for each attempted transaction, we're
making a lot of noise that is no longer necessary now that DRM will just
print the return code we give it.
Signed-off-by: Lyude
---
drivers/gpu/drm/radeon/radeon_dp_auxch.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
index db64e00..2d46564 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_auxch.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_auxch.c
@@ -164,7 +164,6 @@ radeon_dp_aux_transfer_native(struct drm_dp_aux *aux,
struct drm_dp_aux_msg *msg
}
if (tmp & AUX_SW_RX_TIMEOUT) {
- DRM_DEBUG_KMS("dp_aux_ch timed out\n");
ret = -ETIMEDOUT;
goto done;
}
--
2.7.4
___
xorg-driver-ati mailing list
xorg-driver-ati@lists.x.org
https://lists.x.org/mailman/listinfo/xorg-driver-ati
When using PBOs to upload texture data, which call triggers the actual DMA operation?
Hi, I am trying to better understand /optimize texture upload on r600 and GCN based GPUs. Currently I use PBOs to upload data generated by a worker thread to textures, using the following steps: 1. Unmap buffer n (from worker) 2. glTexSubImage2D n-1 to texture n-1 3. bin texture n-2 & draw & glutSwapBuffers 4. map buffer n-3 again and pass it to worker thread For each buffer only one step is executed per frame to avoid GPU stalls. However, after I had a look at radeon_gem_objects I am not sure this approach makes a lot of sence. All PBOs are located in system memory (GTT), so as far as I understand it, unmapping a PBO is actually a no-on and doesn't trigger any transfer? However, where is the actual DMA transfer triggerd - by glTexSubImage2D? And at which point the driver checks for DMA completion - at glutSwapBuffers? Furthermore, is it possible to perform async upload and rendering in parallel in case there are no data-dependencies? Some insights would be really great to better optimize the code. Thank you in advance & best regards, Clemens ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
