From: Sam Ravnborg <sam@ravnborg.org>
To: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH v2] drm/dp: Include the AUX CH name in the debug messages
Date: Thu, 14 May 2020 21:01:46 +0200 [thread overview]
Message-ID: <20200514190146.GA277929@ravnborg.org> (raw)
In-Reply-To: <20200514184040.20700-1-ville.syrjala@linux.intel.com>
Hi Ville.
On Thu, May 14, 2020 at 09:40:40PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
>
> To make it easier to figure out what caused a particular debug
> message let's print out aux->name.
>
> v2: Convert drm_dp_send_real_edid_checksum() too
>
> Cc: Sam Ravnborg <sam@ravnborg.org>
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
> IIRC Sam suggested that I switch to per-device logging functions at the
> same time.
I could imagine I did.
> Sadly that's going to require some amount of actual work:
> For i915/amdgpu/nouveau/etc. aux->dev is connector->kdev instead of the
> pdev->dev we want, which we could handle by walking up the tree several
> levels. However it looks like some of the armish drivers stick pdev->dev
> directly into aux->dev so there we don't want to walk up the tree. This
> means either one set of drivers will need to change their aux->dev
> assignment approach, or we're going to need another device pointer in
> there. I didn't even want to look what the bridge drivers put there.
> In the meantime I refreshed the original patch which at least lets
> us see aux->name...
Thanks for the detailed explanation.
Patch is:
Acked-by: Sam Ravnborg <sam@ravnborg.org>
>
> drivers/gpu/drm/drm_dp_helper.c | 67 ++++++++++++++++++---------------
> 1 file changed, 37 insertions(+), 30 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 43e57632b00a..743ead068a43 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -257,7 +257,8 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request,
> err = ret;
> }
>
> - DRM_DEBUG_KMS("Too many retries, giving up. First error: %d\n", err);
> + DRM_DEBUG_KMS("%s: Too many retries, giving up. First error: %d\n",
> + aux->name, err);
> ret = err;
>
> unlock:
> @@ -376,43 +377,44 @@ bool drm_dp_send_real_edid_checksum(struct drm_dp_aux *aux,
>
> if (drm_dp_dpcd_read(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
> &auto_test_req, 1) < 1) {
> - DRM_ERROR("DPCD failed read at register 0x%x\n",
> - DP_DEVICE_SERVICE_IRQ_VECTOR);
> + DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> + aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
> auto_test_req &= DP_AUTOMATED_TEST_REQUEST;
>
> if (drm_dp_dpcd_read(aux, DP_TEST_REQUEST, &link_edid_read, 1) < 1) {
> - DRM_ERROR("DPCD failed read at register 0x%x\n",
> - DP_TEST_REQUEST);
> + DRM_ERROR("%s: DPCD failed read at register 0x%x\n",
> + aux->name, DP_TEST_REQUEST);
> return false;
> }
> link_edid_read &= DP_TEST_LINK_EDID_READ;
>
> if (!auto_test_req || !link_edid_read) {
> - DRM_DEBUG_KMS("Source DUT does not support TEST_EDID_READ\n");
> + DRM_DEBUG_KMS("%s: Source DUT does not support TEST_EDID_READ\n",
> + aux->name);
> return false;
> }
>
> if (drm_dp_dpcd_write(aux, DP_DEVICE_SERVICE_IRQ_VECTOR,
> &auto_test_req, 1) < 1) {
> - DRM_ERROR("DPCD failed write at register 0x%x\n",
> - DP_DEVICE_SERVICE_IRQ_VECTOR);
> + DRM_ERROR("%s: DPCD failed write at register 0x%x\n",
> + aux->name, DP_DEVICE_SERVICE_IRQ_VECTOR);
> return false;
> }
>
> /* send back checksum for the last edid extension block data */
> if (drm_dp_dpcd_write(aux, DP_TEST_EDID_CHECKSUM,
> &real_edid_checksum, 1) < 1) {
> - DRM_ERROR("DPCD failed write at register 0x%x\n",
> - DP_TEST_EDID_CHECKSUM);
> + DRM_ERROR("%s: DPCD failed write at register 0x%x\n",
> + aux->name, DP_TEST_EDID_CHECKSUM);
> return false;
> }
>
> test_resp |= DP_TEST_EDID_CHECKSUM_WRITE;
> if (drm_dp_dpcd_write(aux, DP_TEST_RESPONSE, &test_resp, 1) < 1) {
> - DRM_ERROR("DPCD failed write at register 0x%x\n",
> - DP_TEST_RESPONSE);
> + DRM_ERROR("%s: DPCD failed write at register 0x%x\n",
> + aux->name, DP_TEST_RESPONSE);
> return false;
> }
>
> @@ -737,10 +739,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> * Avoid spamming the kernel log with timeout errors.
> */
> if (ret == -ETIMEDOUT)
> - DRM_DEBUG_KMS_RATELIMITED("transaction timed out\n");
> + DRM_DEBUG_KMS_RATELIMITED("%s: transaction timed out\n",
> + aux->name);
> else
> - DRM_DEBUG_KMS("transaction failed: %d\n", ret);
> -
> + DRM_DEBUG_KMS("%s: transaction failed: %d\n",
> + aux->name, ret);
> return ret;
> }
>
> @@ -754,11 +757,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> break;
>
> case DP_AUX_NATIVE_REPLY_NACK:
> - DRM_DEBUG_KMS("native nack (result=%d, size=%zu)\n", ret, msg->size);
> + DRM_DEBUG_KMS("%s: native nack (result=%d, size=%zu)\n",
> + aux->name, ret, msg->size);
> return -EREMOTEIO;
>
> case DP_AUX_NATIVE_REPLY_DEFER:
> - DRM_DEBUG_KMS("native defer\n");
> + DRM_DEBUG_KMS("%s: native defer\n", aux->name);
> /*
> * We could check for I2C bit rate capabilities and if
> * available adjust this interval. We could also be
> @@ -772,7 +776,8 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> continue;
>
> default:
> - DRM_ERROR("invalid native reply %#04x\n", msg->reply);
> + DRM_ERROR("%s: invalid native reply %#04x\n",
> + aux->name, msg->reply);
> return -EREMOTEIO;
> }
>
> @@ -787,13 +792,13 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> return ret;
>
> case DP_AUX_I2C_REPLY_NACK:
> - DRM_DEBUG_KMS("I2C nack (result=%d, size=%zu)\n",
> - ret, msg->size);
> + DRM_DEBUG_KMS("%s: I2C nack (result=%d, size=%zu)\n",
> + aux->name, ret, msg->size);
> aux->i2c_nack_count++;
> return -EREMOTEIO;
>
> case DP_AUX_I2C_REPLY_DEFER:
> - DRM_DEBUG_KMS("I2C defer\n");
> + DRM_DEBUG_KMS("%s: I2C defer\n", aux->name);
> /* DP Compliance Test 4.2.2.5 Requirement:
> * Must have at least 7 retries for I2C defers on the
> * transaction to pass this test
> @@ -807,12 +812,13 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg)
> continue;
>
> default:
> - DRM_ERROR("invalid I2C reply %#04x\n", msg->reply);
> + DRM_ERROR("%s: invalid I2C reply %#04x\n",
> + aux->name, msg->reply);
> return -EREMOTEIO;
> }
> }
>
> - DRM_DEBUG_KMS("too many retries, giving up\n");
> + DRM_DEBUG_KMS("%s: Too many retries, giving up\n", aux->name);
> return -EREMOTEIO;
> }
>
> @@ -841,8 +847,8 @@ static int drm_dp_i2c_drain_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *o
> return err == 0 ? -EPROTO : err;
>
> if (err < msg.size && err < ret) {
> - DRM_DEBUG_KMS("Partial I2C reply: requested %zu bytes got %d bytes\n",
> - msg.size, err);
> + DRM_DEBUG_KMS("%s: Partial I2C reply: requested %zu bytes got %d bytes\n",
> + aux->name, msg.size, err);
> ret = err;
> }
>
> @@ -1021,11 +1027,12 @@ static void drm_dp_aux_crc_work(struct work_struct *work)
> }
>
> if (ret == -EAGAIN) {
> - DRM_DEBUG_KMS("Get CRC failed after retrying: %d\n",
> - ret);
> + DRM_DEBUG_KMS("%s: Get CRC failed after retrying: %d\n",
> + aux->name, ret);
> continue;
> } else if (ret) {
> - DRM_DEBUG_KMS("Failed to get a CRC: %d\n", ret);
> + DRM_DEBUG_KMS("%s: Failed to get a CRC: %d\n",
> + aux->name, ret);
> continue;
> }
>
> @@ -1387,8 +1394,8 @@ int drm_dp_read_desc(struct drm_dp_aux *aux, struct drm_dp_desc *desc,
>
> dev_id_len = strnlen(ident->device_id, sizeof(ident->device_id));
>
> - DRM_DEBUG_KMS("DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 0x%04x\n",
> - is_branch ? "branch" : "sink",
> + DRM_DEBUG_KMS("%s: DP %s: OUI %*phD dev-ID %*pE HW-rev %d.%d SW-rev %d.%d quirks 0x%04x\n",
> + aux->name, is_branch ? "branch" : "sink",
> (int)sizeof(ident->oui), ident->oui,
> dev_id_len, ident->device_id,
> ident->hw_rev >> 4, ident->hw_rev & 0xf,
> --
> 2.26.2
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2020-05-14 19:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-14 18:40 [Intel-gfx] [PATCH v2] drm/dp: Include the AUX CH name in the debug messages Ville Syrjala
2020-05-14 19:01 ` Sam Ravnborg [this message]
2020-05-15 16:43 ` [Intel-gfx] ✗ Fi.CI.BAT: failure for " Patchwork
2020-06-03 15:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp: Include the AUX CH name in the debug messages (rev2) Patchwork
2020-06-04 4:43 ` [Intel-gfx] ✓ Fi.CI.IGT: " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200514190146.GA277929@ravnborg.org \
--to=sam@ravnborg.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=ville.syrjala@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox