From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@intel.com>
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Imre Deak <imre.deak@intel.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Matt Wagantall <mattw@codeaurora.org>,
Dejin Zheng <zhengdejin5@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 18/18] drm/i915/ddi: prefer read_poll_timeout() over readx_poll_timeout()
Date: Fri, 27 Jun 2025 15:53:12 +0300 [thread overview]
Message-ID: <aF6UOCLdO0fGHGA9@intel.com> (raw)
In-Reply-To: <59bcc15dd4debf00ee0c7b430a3b701462ac9de7.1751023767.git.jani.nikula@intel.com>
On Fri, Jun 27, 2025 at 02:36:32PM +0300, Jani Nikula wrote:
> Unify on using read_poll_timeout() throughout instead of mixing with
> readx_poll_timeout(). While the latter can be ever so slightly simpler,
> they are both complicated enough that it's better to unify on one
> approach only.
>
> While at it, better separate the handling of error returns from
> drm_dp_dpcd_readb() and the actual status byte. This is best achieved by
> inlining the read_fec_detected_status() function.
>
> Cc: Imre Deak <imre.deak@intel.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 33 +++++++++---------------
> 1 file changed, 12 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 0405396c7750..fc4587311607 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -2339,34 +2339,25 @@ static void intel_dp_sink_set_fec_ready(struct intel_dp *intel_dp,
> drm_dbg_kms(display->drm, "Failed to clear FEC detected flags\n");
> }
>
> -static int read_fec_detected_status(struct drm_dp_aux *aux)
> -{
> - int ret;
> - u8 status;
> -
> - ret = drm_dp_dpcd_readb(aux, DP_FEC_STATUS, &status);
> - if (ret < 0)
> - return ret;
> -
> - return status;
> -}
> -
> static int wait_for_fec_detected(struct drm_dp_aux *aux, bool enabled)
> {
> struct intel_display *display = to_intel_display(aux->drm_dev);
> int mask = enabled ? DP_FEC_DECODE_EN_DETECTED : DP_FEC_DECODE_DIS_DETECTED;
> - int status;
> - int err;
> + u8 status = 0;
> + int ret, err;
>
> - err = readx_poll_timeout(read_fec_detected_status, aux, status,
> - status & mask || status < 0,
> - 10000, 200000);
> + ret = read_poll_timeout(drm_dp_dpcd_readb, err,
> + err || (status & mask),
> + 10 * 1000, 200 * 1000, false,
> + aux, DP_FEC_STATUS, &status);
I think I hate these macros. It's very hard to tell from this
soup what is actually being done here.
The 'val', 'op', and 'args' look very disconnected here even though
they are always part of the same thing. Is there a reason they can't
just be a single 'op' parameter like we have in wait_for() so you can
actually see the code?
Ie.
read_poll_timeout(err = drm_dp_dpcd_readb(aux, DP_FEC_STATUS, &status),
err || (status & mask),
10 * 1000, 200 * 1000, false);
?
>
> - if (err || status < 0) {
> + /* Either can be non-zero, but not both */
> + ret = ret ?: err;
> + if (ret) {
> drm_dbg_kms(display->drm,
> - "Failed waiting for FEC %s to get detected: %d (status %d)\n",
> - str_enabled_disabled(enabled), err, status);
> - return err ? err : status;
> + "Failed waiting for FEC %s to get detected: %d (status 0x%02x)\n",
> + str_enabled_disabled(enabled), ret, status);
> + return ret;
> }
>
> return 0;
> --
> 2.39.5
--
Ville Syrjälä
Intel
next prev parent reply other threads:[~2025-06-27 12:53 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 11:36 [PATCH 00/18] drm/i915/display: convert to generic read_poll_timeout() Jani Nikula
2025-06-27 11:36 ` [PATCH 01/18] drm/i915/hdmi: use generic read_poll_timeout() instead of __wait_for() Jani Nikula
2025-06-27 11:36 ` [PATCH 02/18] drm/i915/hdcp: " Jani Nikula
2025-06-29 13:39 ` Kandpal, Suraj
2025-06-27 11:36 ` [PATCH 03/18] drm/i915/dsi: use generic read_poll_timeout() instead of wait_for_us() Jani Nikula
2025-06-27 11:36 ` [PATCH 04/18] drm/i915/dsi-pll: use generic read_poll_timeout() instead of wait_for() Jani Nikula
2025-06-27 11:36 ` [PATCH 05/18] drm/i915/gmbus: use generic read_poll_timeout*() instead of wait_for*() Jani Nikula
2025-06-27 11:36 ` [PATCH 06/18] drm/i915/wm: use generic read_poll_timeout() instead of wait_for() Jani Nikula
2025-06-27 11:36 ` [PATCH 07/18] drm/i915/cdclk: " Jani Nikula
2025-06-27 11:36 ` [PATCH 08/18] drm/i915/power: " Jani Nikula
2025-06-27 11:36 ` [PATCH 09/18] drm/i915/power-well: use generic read_poll_timeout() instead of wait_for() for DKL PHY Jani Nikula
2025-06-27 11:36 ` [PATCH 10/18] drm/i915/power-well: use generic read_poll_timeout() instead of wait_for() for VLV/CHV Jani Nikula
2025-06-27 11:36 ` [PATCH 11/18] drm/i915/dp: use generic read_poll_timeout() instead of wait_for() Jani Nikula
2025-06-27 11:36 ` [PATCH 12/18] drm/i915/dp: use generic read_poll_timeout() instead of wait_for() in link training Jani Nikula
2025-06-27 11:36 ` [PATCH 13/18] drm/i915/vblank: use generic read_poll_timeout() instead of wait_for() Jani Nikula
2025-06-27 11:36 ` [PATCH 14/18] drm/i915/tc: " Jani Nikula
2025-06-27 11:36 ` [PATCH 15/18] drm/i915/dsb: " Jani Nikula
2025-06-27 11:36 ` [PATCH 16/18] drm/i915/lspcon: " Jani Nikula
2025-06-27 11:36 ` [PATCH 17/18] drm/i915/opregion: " Jani Nikula
2025-06-27 11:36 ` [PATCH 18/18] drm/i915/ddi: prefer read_poll_timeout() over readx_poll_timeout() Jani Nikula
2025-06-27 12:00 ` Imre Deak
2025-06-27 12:43 ` Jani Nikula
2025-06-27 12:53 ` Ville Syrjälä [this message]
2025-06-27 13:34 ` Jani Nikula
2025-06-27 15:40 ` Ville Syrjälä
2025-06-27 16:26 ` Jani Nikula
2025-06-27 17:32 ` Ville Syrjälä
2025-06-30 20:52 ` David Laight
2025-06-27 14:15 ` [PATCH v2] " Jani Nikula
2025-06-30 14:41 ` ✓ i915.CI.BAT: success for drm/i915/display: convert to generic read_poll_timeout() (rev2) Patchwork
2025-06-30 15:35 ` ✗ CI.checkpatch: warning " Patchwork
2025-06-30 15:36 ` ✓ CI.KUnit: success " Patchwork
2025-06-30 15:50 ` ✗ CI.checksparse: warning " Patchwork
2025-06-30 16:17 ` ✓ Xe.CI.BAT: success " Patchwork
2025-07-01 5:54 ` ✓ i915.CI.Full: " Patchwork
2025-07-01 17:57 ` ✗ Xe.CI.Full: failure " 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=aF6UOCLdO0fGHGA9@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=geert+renesas@glider.be \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mattw@codeaurora.org \
--cc=zhengdejin5@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.