From: Gustavo Sousa <gustavo.sousa@intel.com>
To: Luca Coelho <luca@coelho.fi>, <intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 2/4] drm/i915/dmc_wl: Add debugfs for untracked offsets
Date: Thu, 23 Jan 2025 11:41:16 -0300 [thread overview]
Message-ID: <173764327664.34727.14226347289032890419@intel.com> (raw)
In-Reply-To: <56e59e5c283bf749c8c047efc5f36d91459fae17.camel@coelho.fi>
Quoting Luca Coelho (2025-01-22 06:06:00-03:00)
>On Fri, 2025-01-17 at 19:06 -0300, Gustavo Sousa wrote:
>> The DMC wakelock code needs to keep track of register offsets that need
>> the wakelock for proper access. If one of the necessary offsets are
>> missed, then the failure in asserting the wakelock is very likely to
>> cause problems down the road.
>>
>> A miss could happen for at least two different reasons:
>>
>> - We might have forgotten to add the offset (or range) to the relevant
>> tables tracked by the driver in the first place.
>>
>> - Or updates to either the DMC firmware or the display IP that require
>> new offsets to be tracked and we fail to realize that.
>>
>> To help capture these cases, let's introduce a debugfs interface for the
>> DMC wakelock.
>>
>> In this part, we export a buffer containing offsets of registers that
>> were considered not needing the wakelock by our driver. In an upcoming
>> change we will also allow defining an extra set of offset ranges to be
>> tracked by our driver.
>>
>> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com>
>> ---
>
>This looks great overall!
>
>A couple of comments below.
>
>
>[...]
>> +static bool untracked_has_recent_offset(struct intel_display *display, u32 offset)
>> +{
>> + struct intel_dmc_wl_dbg *dbg = &display->wl.dbg;
>> + int look_back = 32;
>> + size_t i;
>> +
>> + if (look_back > dbg->untracked.len)
>> + look_back = dbg->untracked.len;
>> +
>> + i = dbg->untracked.head;
>> +
>> + while (look_back--) {
>> + if (i == 0)
>> + i = dbg->untracked.size;
>
>If size < 32, you would check some values twice, right? Probably not a
>real case scenario, and it wouldn't matter much, but it took me a bit
>to wrap my head around this.
Nope. If look_back is greater than the current number of offsets, it
will be just reset to that count (see the "if (look_back >
dbg->untracked.len)" above).
Note that the number of valid elements in the circular buffer is tracked
with untracked.len, while untracked.size is actually the capacity. Maybe
I should have used that name for the member instead?
>
>[...]
>> +void intel_dmc_wl_debugfs_log_untracked(struct intel_display *display, u32 offset)
>> +{
>> + struct intel_dmc_wl_dbg *dbg = &display->wl.dbg;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&dbg->lock, flags);
>> +
>> + if (!dbg->untracked.size)
>> + goto out_unlock;
>> +
>> + /* Save some space by not repeating recent offsets. */
>> + if (untracked_has_recent_offset(display, offset))
>> + goto out_unlock;
>> +
>> + dbg->untracked.offsets[dbg->untracked.head] = offset;
>> + dbg->untracked.head = (dbg->untracked.head + 1) % dbg->untracked.size;
>> + if (dbg->untracked.len < dbg->untracked.size)
>> + dbg->untracked.len++;
>> +
>> + if (dbg->untracked.len == dbg->untracked.size && !dbg->untracked.overflow) {
>> + dbg->untracked.overflow = true;
>> + drm_warn(display->drm, "Overflow detected in DMC wakelock debugfs untracked offsets\n");
>> + }
>
>Couldn't it be useful to print overflows every time they occur? Maybe
>convert overflow to a uint to track how many times it happened? (though
>maybe this is a bit overkill).
The warning is just to let the user know that the buffer doesn't have
every untracked offset that has been seen since enabling the logging.
The best thing to do in this case is to try a bigger size or try to
reduce the execution to be tracked (maybe a smaller test case).
I'm not sure how providing a count would be useful here.
--
Gustavo Sousa
>
>[...]
>
>--
>Cheers,
>Luca.
>
next prev parent reply other threads:[~2025-01-23 14:41 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-17 22:06 [PATCH 0/4] drm/i915/dmc_wl: Introduce debugfs interface Gustavo Sousa
2025-01-17 22:06 ` [PATCH 1/4] drm/i915/dmc_wl: Pass offset instead of reg to range table iterator Gustavo Sousa
2025-01-22 8:23 ` Luca Coelho
2025-01-17 22:06 ` [PATCH 2/4] drm/i915/dmc_wl: Add debugfs for untracked offsets Gustavo Sousa
2025-01-22 9:06 ` Luca Coelho
2025-01-23 14:41 ` Gustavo Sousa [this message]
2025-01-30 9:33 ` Luca Coelho
2025-01-23 16:11 ` Vivekanandan, Balasubramani
2025-01-23 16:41 ` Gustavo Sousa
2025-01-30 8:54 ` Vivekanandan, Balasubramani
2025-01-27 9:47 ` Jani Nikula
2025-01-27 11:17 ` Gustavo Sousa
2025-01-27 11:59 ` Jani Nikula
2025-01-27 12:55 ` Gustavo Sousa
2025-01-17 22:06 ` [PATCH 3/4] drm/i915/dmc_wl: Add extra_ranges debugfs Gustavo Sousa
2025-01-22 10:19 ` Luca Coelho
2025-01-23 15:52 ` Gustavo Sousa
2025-01-30 9:18 ` Luca Coelho
2025-01-30 8:30 ` Vivekanandan, Balasubramani
2025-01-30 8:49 ` Vivekanandan, Balasubramani
2025-01-17 22:06 ` [PATCH 4/4] drm/i915/dmc_wl: Enable the debugfs only with enable_dmc_wl_debugfs=1 Gustavo Sousa
2025-01-22 10:24 ` Luca Coelho
2025-01-23 16:10 ` Gustavo Sousa
2025-01-30 9:28 ` Luca Coelho
2025-01-27 12:01 ` Jani Nikula
2025-01-27 12:02 ` Jani Nikula
2025-01-27 13:24 ` Gustavo Sousa
2025-01-27 13:35 ` Jani Nikula
2025-01-27 13:50 ` Gustavo Sousa
2025-01-27 14:40 ` Jani Nikula
2025-01-30 8:46 ` Vivekanandan, Balasubramani
2025-01-17 22:14 ` ✓ CI.Patch_applied: success for drm/i915/dmc_wl: Introduce debugfs interface Patchwork
2025-01-17 22:15 ` ✗ CI.checkpatch: warning " Patchwork
2025-01-17 22:16 ` ✓ CI.KUnit: success " Patchwork
2025-01-17 22:34 ` ✓ CI.Build: " Patchwork
2025-01-17 22:36 ` ✓ CI.Hooks: " Patchwork
2025-01-17 22:38 ` ✓ CI.checksparse: " Patchwork
2025-01-17 23:06 ` ✓ Xe.CI.BAT: " Patchwork
2025-01-18 13:06 ` ✗ 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=173764327664.34727.14226347289032890419@intel.com \
--to=gustavo.sousa@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=luca@coelho.fi \
/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