From: Jani Nikula <jani.nikula@linux.intel.com>
To: imre.deak@intel.com
Cc: intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org,
Imre Deak <imre.deak@gmail.com>
Subject: Re: [PATCH 11/20] drm/i915/dp: Reprobe connector if getting/acking device IRQs fails
Date: Thu, 26 Jun 2025 13:46:27 +0300 [thread overview]
Message-ID: <9cef5bf7a30fca73313e9b178bf65f1ac2842141@intel.com> (raw)
In-Reply-To: <aF0kbmZ34PeclKW_@ideak-desk>
On Thu, 26 Jun 2025, Imre Deak <imre.deak@intel.com> wrote:
> On Thu, Jun 26, 2025 at 01:23:12PM +0300, Jani Nikula wrote:
>> On Thu, 26 Jun 2025, Imre Deak <imre.deak@intel.com> wrote:
>> > On Thu, Jun 26, 2025 at 12:12:11PM +0300, Jani Nikula wrote:
>> >> On Thu, 26 Jun 2025, Imre Deak <imre.deak@intel.com> wrote:
>> >> > From: Imre Deak <imre.deak@gmail.com>
>> >> >
>> >> > An AUX access failure during HPD IRQ handling should be handled by
>> >> > falling back to a full connector detection, ensure that if the failure
>> >> > happens while reading/acking a device service IRQ.
>> >> >
>> >> > Signed-off-by: Imre Deak <imre.deak@gmail.com>
>> >> > ---
>> >> > drivers/gpu/drm/i915/display/intel_dp.c | 21 +++++++++++++++------
>> >> > 1 file changed, 15 insertions(+), 6 deletions(-)
>> >> >
>> >> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > index 7793a72983abd..7eb208d2c321b 100644
>> >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> >> > @@ -5393,16 +5393,20 @@ void intel_dp_check_link_state(struct intel_dp *intel_dp)
>> >> > intel_encoder_link_check_queue_work(encoder, 0);
>> >> > }
>> >> >
>> >> > -static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
>> >> > +static bool intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
>> >>
>> >> I don't think "check" is very intuitive in function names. Check
>> >> something, but then what? Is it like an assert or does it do something
>> >> active or what?
>> >>
>> >> What does a boolean return from a check function mean?
>> >>
>> >> It's not obvious to the reader at all.
>> >
>> > I agree, but in this patch I didn't want to change the function name.
>>
>> Arguably adding a return value changes the meaning already...
>>
>> >
>> >>
>> >> > {
>> >> > struct intel_display *display = to_intel_display(intel_dp);
>> >> > u8 val;
>> >> >
>> >> > if (drm_dp_dpcd_readb(&intel_dp->aux,
>> >> > - DP_DEVICE_SERVICE_IRQ_VECTOR, &val) != 1 || !val)
>> >> > - return;
>> >> > + DP_DEVICE_SERVICE_IRQ_VECTOR, &val) != 1)
>> >> > + return true;
>> >>
>> >> Looks like true means the check failed... while usually true for boolean
>> >> functions means success.
>> >
>> > The function returns true as before if a full connector detection is needed.
>>
>> But it didn't return anything before! And that meaning is not conveyed
>> to the reader in *any* reasonable way!
>
> This function is the counterpart of intel_dp_check_link_service_irq()
> both functions having the same purpose, reading and handling HPD IRQs.
> The latter one's return value is true if a reprobe is needed and this
> patch doesn't change that, it keeps the two functions behave the same
> way.
>
>> The absolute minimum is to add a comment (mind you, kernel-doc is
>> overkill) stating what the return value means.
>
> The function name will change in a follow-up patch and I think that
> doesn't require a comment on the return value.
>
>> >>
>> >> >
>> >> > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, val);
>> >> > + if (!val)
>> >> > + return false;
>> >> > +
>> >> > + if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, val) != 1)
>> >> > + return true;
>> >> >
>> >> > if (val & DP_AUTOMATED_TEST_REQUEST)
>> >> > intel_dp_test_request(intel_dp);
>> >>
>> >> Whoa, it's not a *check* function at all?! It actually *handles* the
>> >> service irqs.
>> >>
>> >> Can we rephrase the function name?
>> >
>> > I want to keep the function name in this patch. In the following patches
>> > I will separate this part and rename it to
>> > intel_dp_get_and_ack_device_service_irq().
>>
>> Right, saw that now. But even for that function name the meaning of the
>> return value is ambiguous.
>
> All the get/ack IRQ functions in intel_dp.c return true for success.
Argh. You just said it doesn't mean success/failure, it means if full
connector detection is needed?!
BR,
Jani
>
>>
>> BR,
>> Jani.
>>
>> >
>> >
>> >> int intel_dp_handle_device_service_irq() and int returns maybe?
>> >> BR,
>> >> Jani.
>> >>
>> >> > @@ -5412,6 +5416,8 @@ static void intel_dp_check_device_service_irq(struct intel_dp *intel_dp)
>> >> >
>> >> > if (val & DP_SINK_SPECIFIC_IRQ)
>> >> > drm_dbg_kms(display->drm, "Sink specific irq unhandled\n");
>> >> > +
>> >> > + return false;
>> >> > }
>> >> >
>> >> > static bool intel_dp_check_link_service_irq(struct intel_dp *intel_dp)
>> >> > @@ -5476,8 +5482,11 @@ intel_dp_short_pulse(struct intel_dp *intel_dp)
>> >> > /* No need to proceed if we are going to do full detect */
>> >> > return false;
>> >> >
>> >> > - intel_dp_check_device_service_irq(intel_dp);
>> >> > - reprobe_needed = intel_dp_check_link_service_irq(intel_dp);
>> >> > + if (intel_dp_check_device_service_irq(intel_dp))
>> >> > + reprobe_needed = true;
>> >> > +
>> >> > + if (intel_dp_check_link_service_irq(intel_dp))
>> >> > + reprobe_needed = true;
>> >> >
>> >> > /* Handle CEC interrupts, if any */
>> >> > drm_dp_cec_irq(&intel_dp->aux);
>> >>
>> >> --
>> >> Jani Nikula, Intel
>>
>> --
>> Jani Nikula, Intel
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-06-26 10:46 UTC|newest]
Thread overview: 66+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-26 8:20 [PATCH 00/20] drm/i915/dp: Fix few SST HPD IRQ handling issues Imre Deak
2025-06-26 8:20 ` [PATCH 01/20] drm/i915/dp_mst: Reprobe connector if the IRQ ESI read failed Imre Deak
2025-06-27 7:42 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 02/20] drm/i915/dp_mst: Verify the link status always the same way Imre Deak
2025-06-26 8:31 ` Jani Nikula
2025-06-27 15:19 ` Imre Deak
2025-07-03 11:14 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 03/20] drm/i915/dp_mst: Reuse intel_dp_check_link_state() in the HPD IRQ handler Imre Deak
2025-07-01 7:50 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 04/20] drm/i915/dp: Handle a tunneling IRQ after acking it Imre Deak
2025-07-01 8:02 ` Luca Coelho
2025-07-01 8:32 ` Imre Deak
2025-07-01 8:47 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 05/20] drm/i915/dp: Handle the RX_CAP_CHANGED HPD IRQ Imre Deak
2025-07-01 8:03 ` Luca Coelho
2025-07-01 10:30 ` Imre Deak
2025-07-03 11:16 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 06/20] drm/i915/dp: Handle the DOWNSTREAM_PORT_STATUS_CHANGED event Imre Deak
2025-07-01 8:52 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 07/20] drm/i915/dp: Don't clobber the encoder state in the HPD IRQ handler Imre Deak
2025-07-01 8:56 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 08/20] drm/i915/dp: Remove the device service IRQ handling from connector detect Imre Deak
2025-07-01 9:00 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 09/20] drm/i915/dp: Fix the device service IRQ DPCD_REV check Imre Deak
2025-07-01 9:01 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 10/20] drm/i915/dp: Fix the link " Imre Deak
2025-07-01 9:12 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 11/20] drm/i915/dp: Reprobe connector if getting/acking device IRQs fails Imre Deak
2025-06-26 9:12 ` Jani Nikula
2025-06-26 9:35 ` Imre Deak
2025-06-26 10:23 ` Jani Nikula
2025-06-26 10:43 ` Imre Deak
2025-06-26 10:46 ` Jani Nikula [this message]
2025-06-26 10:56 ` Imre Deak
2025-07-03 11:28 ` Luca Coelho
2025-07-03 11:43 ` Imre Deak
2025-07-07 10:05 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 12/20] drm/i915/dp: Reprobe connector if getting/acking link service " Imre Deak
2025-07-03 11:37 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 13/20] drm/i915/dp: Return early if getting/acking device " Imre Deak
2025-07-03 11:59 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 14/20] drm/i915/dp: Return early if getting/ackink link " Imre Deak
2025-07-03 12:29 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 15/20] drm/i915/dp: Read/ack sink count and sink IRQs for SST as it's done for MST Imre Deak
2025-07-03 13:02 ` Luca Coelho
2025-07-03 13:14 ` Imre Deak
2025-07-03 13:24 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 16/20] drm/i915/dp: Print debug message for a sink connected off request Imre Deak
2025-07-03 13:03 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 17/20] drm/i915/dp: Check SST link status while handling link service IRQs Imre Deak
2025-07-03 13:05 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 18/20] drm/i915/dp_mst: Reuse intel_dp_handle_link_service_irq() Imre Deak
2025-07-03 13:07 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 19/20] drm/i915/dp: Ack only the handled device service IRQs Imre Deak
2025-07-03 13:14 ` Luca Coelho
2025-07-03 13:18 ` Imre Deak
2025-07-03 13:27 ` Imre Deak
2025-07-03 13:34 ` Luca Coelho
2025-06-26 8:20 ` [PATCH 20/20] drm/i915/dp: Ack only the handled link " Imre Deak
2025-07-03 13:18 ` Luca Coelho
2025-06-26 8:37 ` ✓ CI.KUnit: success for drm/i915/dp: Fix few SST HPD IRQ handling issues Patchwork
2025-06-26 8:55 ` ✗ CI.checksparse: warning " Patchwork
2025-06-26 9:18 ` ✓ Xe.CI.BAT: success " Patchwork
2025-06-26 13:06 ` ✓ i915.CI.BAT: " Patchwork
2025-06-26 22:48 ` ✗ i915.CI.Full: failure " Patchwork
2025-06-27 8:21 ` ✗ Xe.CI.Full: " 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=9cef5bf7a30fca73313e9b178bf65f1ac2842141@intel.com \
--to=jani.nikula@linux.intel.com \
--cc=imre.deak@gmail.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
/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.