From: kernel test robot <lkp@intel.com>
To: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>,
alexander.deucher@amd.com, christian.koenig@amd.com,
ltuikov89@gmail.com, matthew.brost@intel.com,
maarten.lankhorst@linux.intel.com, mripard@kernel.org,
tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch,
dri-devel@lists.freedesktop.org, ville.syrjala@linux.intel.com,
rostedt@goodmis.org
Cc: oe-kbuild-all@lists.linux.dev,
Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Subject: Re: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
Date: Fri, 7 Jun 2024 08:34:49 +0800 [thread overview]
Message-ID: <202406070826.ASQuMJ48-lkp@intel.com> (raw)
In-Reply-To: <20240606130629.214827-2-pierre-eric.pelloux-prayer@amd.com>
Hi Pierre-Eric,
kernel test robot noticed the following build errors:
[auto build test ERROR on linus/master]
[also build test ERROR on v6.10-rc2 next-20240606]
[cannot apply to drm-xe/drm-xe-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Pierre-Eric-Pelloux-Prayer/drm-sched-store-the-drm_device-instead-of-the-device/20240606-211050
base: linus/master
patch link: https://lore.kernel.org/r/20240606130629.214827-2-pierre-eric.pelloux-prayer%40amd.com
patch subject: [PATCH v3 1/4] drm/sched: store the drm_device instead of the device
config: arm64-defconfig (https://download.01.org/0day-ci/archive/20240607/202406070826.ASQuMJ48-lkp@intel.com/config)
compiler: aarch64-linux-gcc (GCC) 13.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240607/202406070826.ASQuMJ48-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202406070826.ASQuMJ48-lkp@intel.com/
All errors (new ones prefixed by >>):
In file included from include/linux/device.h:15,
from include/drm/drm_print.h:31,
from include/drm/drm_mm.h:51,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:42,
from drivers/gpu/drm/imagination/pvr_gem.h:12,
from drivers/gpu/drm/imagination/pvr_fw.h:9,
from drivers/gpu/drm/imagination/pvr_device.h:9,
from drivers/gpu/drm/imagination/pvr_context.h:17,
from drivers/gpu/drm/imagination/pvr_queue.c:8:
drivers/gpu/drm/imagination/pvr_queue.c: In function 'pvr_queue_timedout_job':
>> drivers/gpu/drm/imagination/pvr_queue.c:807:22: error: passing argument 1 of '_dev_err' from incompatible pointer type [-Werror=incompatible-pointer-types]
807 | dev_err(sched->dev, "Job timeout\n");
| ~~~~~^~~~~
| |
| struct drm_device *
include/linux/dev_printk.h:110:25: note: in definition of macro 'dev_printk_index_wrap'
110 | _p_func(dev, fmt, ##__VA_ARGS__); \
| ^~~
drivers/gpu/drm/imagination/pvr_queue.c:807:9: note: in expansion of macro 'dev_err'
807 | dev_err(sched->dev, "Job timeout\n");
| ^~~~~~~
include/linux/dev_printk.h:50:36: note: expected 'const struct device *' but argument is of type 'struct drm_device *'
50 | void _dev_err(const struct device *dev, const char *fmt, ...);
| ~~~~~~~~~~~~~~~~~~~~~^~~
cc1: some warnings being treated as errors
vim +/_dev_err +807 drivers/gpu/drm/imagination/pvr_queue.c
eaf01ee5ba28b9 Sarah Walker 2023-11-22 787
eaf01ee5ba28b9 Sarah Walker 2023-11-22 788 /**
eaf01ee5ba28b9 Sarah Walker 2023-11-22 789 * pvr_queue_timedout_job() - Handle a job timeout event.
eaf01ee5ba28b9 Sarah Walker 2023-11-22 790 * @s_job: The job this timeout occurred on.
eaf01ee5ba28b9 Sarah Walker 2023-11-22 791 *
eaf01ee5ba28b9 Sarah Walker 2023-11-22 792 * FIXME: We don't do anything here to unblock the situation, we just stop+start
eaf01ee5ba28b9 Sarah Walker 2023-11-22 793 * the scheduler, and re-assign parent fences in the middle.
eaf01ee5ba28b9 Sarah Walker 2023-11-22 794 *
eaf01ee5ba28b9 Sarah Walker 2023-11-22 795 * Return:
eaf01ee5ba28b9 Sarah Walker 2023-11-22 796 * * DRM_GPU_SCHED_STAT_NOMINAL.
eaf01ee5ba28b9 Sarah Walker 2023-11-22 797 */
eaf01ee5ba28b9 Sarah Walker 2023-11-22 798 static enum drm_gpu_sched_stat
eaf01ee5ba28b9 Sarah Walker 2023-11-22 799 pvr_queue_timedout_job(struct drm_sched_job *s_job)
eaf01ee5ba28b9 Sarah Walker 2023-11-22 800 {
eaf01ee5ba28b9 Sarah Walker 2023-11-22 801 struct drm_gpu_scheduler *sched = s_job->sched;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 802 struct pvr_queue *queue = container_of(sched, struct pvr_queue, scheduler);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 803 struct pvr_device *pvr_dev = queue->ctx->pvr_dev;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 804 struct pvr_job *job;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 805 u32 job_count = 0;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 806
eaf01ee5ba28b9 Sarah Walker 2023-11-22 @807 dev_err(sched->dev, "Job timeout\n");
eaf01ee5ba28b9 Sarah Walker 2023-11-22 808
eaf01ee5ba28b9 Sarah Walker 2023-11-22 809 /* Before we stop the scheduler, make sure the queue is out of any list, so
eaf01ee5ba28b9 Sarah Walker 2023-11-22 810 * any call to pvr_queue_update_active_state_locked() that might happen
eaf01ee5ba28b9 Sarah Walker 2023-11-22 811 * until the scheduler is really stopped doesn't end up re-inserting the
eaf01ee5ba28b9 Sarah Walker 2023-11-22 812 * queue in the active list. This would cause
eaf01ee5ba28b9 Sarah Walker 2023-11-22 813 * pvr_queue_signal_done_fences() and drm_sched_stop() to race with each
eaf01ee5ba28b9 Sarah Walker 2023-11-22 814 * other when accessing the pending_list, since drm_sched_stop() doesn't
eaf01ee5ba28b9 Sarah Walker 2023-11-22 815 * grab the job_list_lock when modifying the list (it's assuming the
eaf01ee5ba28b9 Sarah Walker 2023-11-22 816 * only other accessor is the scheduler, and it's safe to not grab the
eaf01ee5ba28b9 Sarah Walker 2023-11-22 817 * lock since it's stopped).
eaf01ee5ba28b9 Sarah Walker 2023-11-22 818 */
eaf01ee5ba28b9 Sarah Walker 2023-11-22 819 mutex_lock(&pvr_dev->queues.lock);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 820 list_del_init(&queue->node);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 821 mutex_unlock(&pvr_dev->queues.lock);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 822
eaf01ee5ba28b9 Sarah Walker 2023-11-22 823 drm_sched_stop(sched, s_job);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 824
eaf01ee5ba28b9 Sarah Walker 2023-11-22 825 /* Re-assign job parent fences. */
eaf01ee5ba28b9 Sarah Walker 2023-11-22 826 list_for_each_entry(job, &sched->pending_list, base.list) {
eaf01ee5ba28b9 Sarah Walker 2023-11-22 827 job->base.s_fence->parent = dma_fence_get(job->done_fence);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 828 job_count++;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 829 }
eaf01ee5ba28b9 Sarah Walker 2023-11-22 830 WARN_ON(atomic_read(&queue->in_flight_job_count) != job_count);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 831
eaf01ee5ba28b9 Sarah Walker 2023-11-22 832 /* Re-insert the queue in the proper list, and kick a queue processing
eaf01ee5ba28b9 Sarah Walker 2023-11-22 833 * operation if there were jobs pending.
eaf01ee5ba28b9 Sarah Walker 2023-11-22 834 */
eaf01ee5ba28b9 Sarah Walker 2023-11-22 835 mutex_lock(&pvr_dev->queues.lock);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 836 if (!job_count) {
eaf01ee5ba28b9 Sarah Walker 2023-11-22 837 list_move_tail(&queue->node, &pvr_dev->queues.idle);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 838 } else {
eaf01ee5ba28b9 Sarah Walker 2023-11-22 839 atomic_set(&queue->in_flight_job_count, job_count);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 840 list_move_tail(&queue->node, &pvr_dev->queues.active);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 841 pvr_queue_process(queue);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 842 }
eaf01ee5ba28b9 Sarah Walker 2023-11-22 843 mutex_unlock(&pvr_dev->queues.lock);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 844
eaf01ee5ba28b9 Sarah Walker 2023-11-22 845 drm_sched_start(sched, true);
eaf01ee5ba28b9 Sarah Walker 2023-11-22 846
eaf01ee5ba28b9 Sarah Walker 2023-11-22 847 return DRM_GPU_SCHED_STAT_NOMINAL;
eaf01ee5ba28b9 Sarah Walker 2023-11-22 848 }
eaf01ee5ba28b9 Sarah Walker 2023-11-22 849
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2024-06-07 0:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-06 13:06 [PATCH v3 0/4] Improve gpu_scheduler trace events Pierre-Eric Pelloux-Prayer
2024-06-06 13:06 ` [PATCH v3 1/4] drm/sched: store the drm_device instead of the device Pierre-Eric Pelloux-Prayer
2024-06-06 13:18 ` Christian König
2024-06-06 13:23 ` Ville Syrjälä
2024-06-06 16:38 ` Matthew Brost
2024-06-07 13:55 ` Pierre-Eric Pelloux-Prayer
2024-06-07 0:34 ` kernel test robot [this message]
2024-06-08 0:36 ` kernel test robot
2024-06-06 13:06 ` [PATCH v3 2/4] drm/sched: add dev_index=xx to the drm_sched_process_job event Pierre-Eric Pelloux-Prayer
2024-06-06 13:06 ` [PATCH v3 3/4] drm/sched: cleanup gpu_scheduler trace events Pierre-Eric Pelloux-Prayer
2024-06-06 13:19 ` Steven Rostedt
2024-06-06 13:23 ` Christian König
2024-06-07 13:21 ` Pierre-Eric Pelloux-Prayer
2024-06-06 13:06 ` [PATCH v3 4/4] drm/sched: trace dependencies for gpu jobs Pierre-Eric Pelloux-Prayer
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=202406070826.ASQuMJ48-lkp@intel.com \
--to=lkp@intel.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=christian.koenig@amd.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=ltuikov89@gmail.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=pierre-eric.pelloux-prayer@amd.com \
--cc=rostedt@goodmis.org \
--cc=tzimmermann@suse.de \
--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 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.