From: Jani Nikula <jani.nikula@intel.com>
To: Simona Vetter <simona.vetter@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
"Matthew Brost" <matthew.brost@intel.com>,
"Danilo Krummrich" <dakr@kernel.org>,
"Philipp Stanner" <phasta@kernel.org>,
"Christian König" <ckoenig.leichtzumerken@gmail.com>
Subject: Re: [PATCH 3/5] drm/sched: stop passing non struct drm_device to drm_err() and friends
Date: Fri, 24 Jan 2025 13:46:08 +0200 [thread overview]
Message-ID: <87msfgbfjz.fsf@intel.com> (raw)
In-Reply-To: <Z5KeZnJ4HOxs1wuk@phenom.ffwll.local>
On Thu, 23 Jan 2025, Simona Vetter <simona.vetter@ffwll.ch> wrote:
> On Thu, Jan 23, 2025 at 05:09:10PM +0200, Jani Nikula wrote:
>> The expectation is that the struct drm_device based logging helpers get
>> passed an actual struct drm_device pointer rather than some random
>> struct pointer where you can dereference the ->dev member.
>>
>> Convert drm_err(sched, ...) to dev_err(sched->dev, ...) and
>> similar. This matches current usage, as struct drm_device is not
>> available, but drops "[drm]" or "[drm] *ERROR*" prefix from logging.
>>
>> Unfortunately, there's no dev_WARN_ON(), so the conversion is not
>> exactly the same.
>>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>
> For the two previous patches just dev_ makes sense since they're just
> platform drivers, but for drm/sched I wonder whether it wouldn't be better
> to switch from struct device * to struct drm_device * instead. I guess
> might be best to leave that decision to scheduler folks.
I had a very brief look, and it seemed like struct drm_device isn't
passed around in sched. If use of struct drm_device is preferred, I'm
not the best person to figure out how to do that. But the abuse of the
drm_err() and friends macros needs to stop.
> Anyway on the series and with that caveat:
>
> Reviewed-by: Simona Vetter <simona.vetter@ffwll.ch>
Thanks,
Jani.
>
>
>>
>> ---
>>
>> Cc: Matthew Brost <matthew.brost@intel.com>
>> Cc: Danilo Krummrich <dakr@kernel.org>
>> Cc: Philipp Stanner <phasta@kernel.org>
>> Cc: "Christian König" <ckoenig.leichtzumerken@gmail.com>
>> Cc: dri-devel@lists.freedesktop.org
>> ---
>> drivers/gpu/drm/scheduler/sched_entity.c | 2 +-
>> drivers/gpu/drm/scheduler/sched_main.c | 20 +++++++++++---------
>> 2 files changed, 12 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/scheduler/sched_entity.c b/drivers/gpu/drm/scheduler/sched_entity.c
>> index 69bcf0e99d57..e29af71d4b5c 100644
>> --- a/drivers/gpu/drm/scheduler/sched_entity.c
>> +++ b/drivers/gpu/drm/scheduler/sched_entity.c
>> @@ -92,7 +92,7 @@ int drm_sched_entity_init(struct drm_sched_entity *entity,
>> * the lowest priority available.
>> */
>> if (entity->priority >= sched_list[0]->num_rqs) {
>> - drm_err(sched_list[0], "entity with out-of-bounds priority:%u num_rqs:%u\n",
>> + dev_err(sched_list[0]->dev, "entity with out-of-bounds priority:%u num_rqs:%u\n",
>> entity->priority, sched_list[0]->num_rqs);
>> entity->priority = max_t(s32, (s32) sched_list[0]->num_rqs - 1,
>> (s32) DRM_SCHED_PRIORITY_KERNEL);
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c b/drivers/gpu/drm/scheduler/sched_main.c
>> index a48be16ab84f..d1c1f22fd1db 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -103,9 +103,9 @@ static u32 drm_sched_available_credits(struct drm_gpu_scheduler *sched)
>> {
>> u32 credits;
>>
>> - drm_WARN_ON(sched, check_sub_overflow(sched->credit_limit,
>> - atomic_read(&sched->credit_count),
>> - &credits));
>> + WARN_ON(check_sub_overflow(sched->credit_limit,
>> + atomic_read(&sched->credit_count),
>> + &credits));
>>
>> return credits;
>> }
>> @@ -130,9 +130,11 @@ static bool drm_sched_can_queue(struct drm_gpu_scheduler *sched,
>> /* If a job exceeds the credit limit, truncate it to the credit limit
>> * itself to guarantee forward progress.
>> */
>> - if (drm_WARN(sched, s_job->credits > sched->credit_limit,
>> - "Jobs may not exceed the credit limit, truncate.\n"))
>> + if (s_job->credits > sched->credit_limit) {
>> + dev_WARN(sched->dev,
>> + "Jobs may not exceed the credit limit, truncate.\n");
>> s_job->credits = sched->credit_limit;
>> + }
>>
>> return drm_sched_available_credits(sched) >= s_job->credits;
>> }
>> @@ -790,7 +792,7 @@ int drm_sched_job_init(struct drm_sched_job *job,
>> * or worse--a blank screen--leave a trail in the
>> * logs, so this can be debugged easier.
>> */
>> - drm_err(job->sched, "%s: entity has no rq!\n", __func__);
>> + dev_err(job->sched->dev, "%s: entity has no rq!\n", __func__);
>> return -ENOENT;
>> }
>>
>> @@ -1280,7 +1282,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>> if (num_rqs > DRM_SCHED_PRIORITY_COUNT) {
>> /* This is a gross violation--tell drivers what the problem is.
>> */
>> - drm_err(sched, "%s: num_rqs cannot be greater than DRM_SCHED_PRIORITY_COUNT\n",
>> + dev_err(sched->dev, "%s: num_rqs cannot be greater than DRM_SCHED_PRIORITY_COUNT\n",
>> __func__);
>> return -EINVAL;
>> } else if (sched->sched_rq) {
>> @@ -1288,7 +1290,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>> * fine-tune their DRM calling order, and return all
>> * is good.
>> */
>> - drm_warn(sched, "%s: scheduler already initialized!\n", __func__);
>> + dev_warn(sched->dev, "%s: scheduler already initialized!\n", __func__);
>> return 0;
>> }
>>
>> @@ -1343,7 +1345,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
>> Out_check_own:
>> if (sched->own_submit_wq)
>> destroy_workqueue(sched->submit_wq);
>> - drm_err(sched, "%s: Failed to setup GPU scheduler--out of memory\n", __func__);
>> + dev_err(sched->dev, "%s: Failed to setup GPU scheduler--out of memory\n", __func__);
>> return -ENOMEM;
>> }
>> EXPORT_SYMBOL(drm_sched_init);
>> --
>> 2.39.5
>>
--
Jani Nikula, Intel
next prev parent reply other threads:[~2025-01-24 11:46 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-23 15:09 [PATCH 0/5] drm: strict type checking for drm_device based logging helpers Jani Nikula
2025-01-23 15:09 ` [PATCH 1/5] drm/mipi-dsi: stop passing non struct drm_device to drm_err() and friends Jani Nikula
2025-02-25 16:52 ` Luca Ceresoli
2025-01-23 15:09 ` [PATCH 2/5] drm/rockchip: " Jani Nikula
2025-01-23 15:09 ` Jani Nikula
2025-01-24 9:53 ` Andy Yan
2025-01-24 9:53 ` Andy Yan
2025-01-24 11:43 ` Jani Nikula
2025-01-24 11:43 ` Jani Nikula
2025-01-25 3:53 ` Andy Yan
2025-01-25 3:53 ` Andy Yan
2025-02-25 19:34 ` Jani Nikula
2025-02-25 19:34 ` Jani Nikula
2025-02-26 8:33 ` [PATCH " Thomas Zimmermann
2025-02-26 8:33 ` Thomas Zimmermann
2025-02-26 10:36 ` Andy Yan
2025-02-26 10:36 ` Andy Yan
2025-02-26 11:33 ` Jani Nikula
2025-02-26 11:33 ` Jani Nikula
2025-02-24 14:47 ` Louis Chauvet
2025-02-24 14:47 ` Louis Chauvet
2025-01-23 15:09 ` [PATCH 3/5] drm/sched: " Jani Nikula
2025-01-23 19:54 ` Simona Vetter
2025-01-24 11:46 ` Jani Nikula [this message]
2025-01-27 10:11 ` Philipp Stanner
2025-02-24 15:29 ` Tvrtko Ursulin
2025-02-24 14:48 ` Louis Chauvet
2025-01-23 15:09 ` [PATCH 4/5] drm/print: Include drm_device.h Jani Nikula
2025-01-23 15:14 ` Jani Nikula
2025-01-23 16:14 ` Gustavo Sousa
2025-01-24 11:50 ` Jani Nikula
2025-01-24 12:21 ` Gustavo Sousa
2025-01-24 12:55 ` Simona Vetter
2025-01-23 15:09 ` [PATCH 5/5] drm/print: require struct drm_device for drm_err() and friends Jani Nikula
2025-02-24 14:48 ` Louis Chauvet
2025-02-25 16:52 ` Luca Ceresoli
2025-05-15 20:18 ` Bill Wendling
2025-05-15 23:52 ` Bill Wendling
2025-05-16 9:48 ` Jani Nikula
2025-05-16 20:41 ` Bill Wendling
2025-01-23 16:05 ` ✗ Fi.CI.SPARSE: warning for drm: strict type checking for drm_device based logging helpers Patchwork
2025-01-23 16:13 ` ✓ i915.CI.BAT: success " Patchwork
2025-01-24 8:26 ` ✗ i915.CI.Full: failure " Patchwork
2025-03-04 15:07 ` [PATCH 0/5] " Jani Nikula
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=87msfgbfjz.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=ckoenig.leichtzumerken@gmail.com \
--cc=dakr@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=matthew.brost@intel.com \
--cc=phasta@kernel.org \
--cc=simona.vetter@ffwll.ch \
/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.