From: kernel test robot <lkp@intel.com>
To: Vinod Govindapillai <vinod.govindapillai@intel.com>,
intel-xe@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: oe-kbuild-all@lists.linux.dev, vinod.govindapillai@intel.com,
ville.syrjala@intel.com, uma.shankar@intel.com
Subject: Re: [PATCH v2 3/6] drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()
Date: Sat, 21 Feb 2026 20:31:16 +0800 [thread overview]
Message-ID: <202602212005.vv7AJP3Z-lkp@intel.com> (raw)
In-Reply-To: <20260220170908.201422-4-vinod.govindapillai@intel.com>
Hi Vinod,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-i915/for-linux-next]
[also build test ERROR on drm-tip/drm-tip linus/master next-20260220]
[cannot apply to drm-i915/for-linux-next-fixes drm-xe/drm-xe-next v6.19]
[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/Vinod-Govindapillai/drm-xe-fbdev-Fix-BIOS-FB-vs-s-stolen-size-check/20260221-013114
base: https://gitlab.freedesktop.org/drm/i915/kernel.git for-linux-next
patch link: https://lore.kernel.org/r/20260220170908.201422-4-vinod.govindapillai%40intel.com
patch subject: [PATCH v2 3/6] drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen()
config: x86_64-randconfig-076-20260221 (https://download.01.org/0day-ci/archive/20260221/202602212005.vv7AJP3Z-lkp@intel.com/config)
compiler: gcc-12 (Debian 12.4.0-5) 12.4.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260221/202602212005.vv7AJP3Z-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/202602212005.vv7AJP3Z-lkp@intel.com/
All errors (new ones prefixed by >>):
ld: drivers/gpu/drm/i915/i915_initial_plane.o: in function `initial_plane_vma':
>> drivers/gpu/drm/i915/i915_initial_plane.c:120:(.text+0x103c): undefined reference to `intel_fbdev_fb_prefer_stolen'
vim +120 drivers/gpu/drm/i915/i915_initial_plane.c
85
86 static struct i915_vma *
87 initial_plane_vma(struct drm_i915_private *i915,
88 struct intel_initial_plane_config *plane_config)
89 {
90 struct intel_memory_region *mem;
91 struct drm_i915_gem_object *obj;
92 struct drm_mm_node orig_mm = {};
93 struct i915_vma *vma;
94 resource_size_t phys_base;
95 unsigned int tiling;
96 u32 base, size;
97 u64 pinctl;
98
99 if (plane_config->size == 0)
100 return NULL;
101
102 if (!initial_plane_phys(i915, plane_config))
103 return NULL;
104
105 phys_base = plane_config->phys_base;
106 mem = plane_config->mem;
107
108 base = round_down(plane_config->base, I915_GTT_MIN_ALIGNMENT);
109 size = round_up(plane_config->base + plane_config->size,
110 mem->min_page_size);
111 size -= base;
112
113 /*
114 * If the FB is too big, just don't use it since fbdev is not very
115 * important and we should probably use that space with FBC or other
116 * features.
117 */
118 if (IS_ENABLED(CONFIG_FRAMEBUFFER_CONSOLE) &&
119 mem == i915->mm.stolen_region &&
> 120 !intel_fbdev_fb_prefer_stolen(&i915->drm, size)) {
121 drm_dbg_kms(&i915->drm, "Initial FB size exceeds half of stolen, discarding\n");
122 return NULL;
123 }
124
125 obj = i915_gem_object_create_region_at(mem, phys_base, size,
126 I915_BO_ALLOC_USER |
127 I915_BO_PREALLOC);
128 if (IS_ERR(obj)) {
129 drm_dbg_kms(&i915->drm, "Failed to preallocate initial FB in %s\n",
130 mem->region.name);
131 return NULL;
132 }
133
134 /*
135 * Mark it WT ahead of time to avoid changing the
136 * cache_level during fbdev initialization. The
137 * unbind there would get stuck waiting for rcu.
138 */
139 i915_gem_object_set_cache_coherency(obj, HAS_WT(i915) ?
140 I915_CACHE_WT : I915_CACHE_NONE);
141
142 tiling = intel_fb_modifier_to_tiling(plane_config->fb->base.modifier);
143
144 switch (tiling) {
145 case I915_TILING_NONE:
146 break;
147 case I915_TILING_X:
148 case I915_TILING_Y:
149 obj->tiling_and_stride =
150 plane_config->fb->base.pitches[0] |
151 tiling;
152 break;
153 default:
154 MISSING_CASE(tiling);
155 goto err_obj;
156 }
157
158 /*
159 * MTL GOP likes to place the framebuffer high up in ggtt,
160 * which can cause problems for ggtt_reserve_guc_top().
161 * Try to pin it to a low ggtt address instead to avoid that.
162 */
163 base = 0;
164
165 if (base != plane_config->base) {
166 struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
167 int ret;
168
169 /*
170 * Make sure the original and new locations
171 * can't overlap. That would corrupt the original
172 * PTEs which are still being used for scanout.
173 */
174 ret = i915_gem_gtt_reserve(&ggtt->vm, NULL, &orig_mm,
175 size, plane_config->base,
176 I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
177 if (ret)
178 goto err_obj;
179 }
180
181 vma = i915_vma_instance(obj, &to_gt(i915)->ggtt->vm, NULL);
182 if (IS_ERR(vma))
183 goto err_obj;
184
185 retry:
186 pinctl = PIN_GLOBAL | PIN_OFFSET_FIXED | base;
187 if (!i915_gem_object_is_lmem(obj))
188 pinctl |= PIN_MAPPABLE;
189 if (i915_vma_pin(vma, 0, 0, pinctl)) {
190 if (drm_mm_node_allocated(&orig_mm)) {
191 drm_mm_remove_node(&orig_mm);
192 /*
193 * Try again, but this time pin
194 * it to its original location.
195 */
196 base = plane_config->base;
197 goto retry;
198 }
199 goto err_obj;
200 }
201
202 if (i915_gem_object_is_tiled(obj) &&
203 !i915_vma_is_map_and_fenceable(vma))
204 goto err_obj;
205
206 if (drm_mm_node_allocated(&orig_mm))
207 drm_mm_remove_node(&orig_mm);
208
209 drm_dbg_kms(&i915->drm,
210 "Initial plane fb bound to 0x%x in the ggtt (original 0x%x)\n",
211 i915_ggtt_offset(vma), plane_config->base);
212
213 return vma;
214
215 err_obj:
216 if (drm_mm_node_allocated(&orig_mm))
217 drm_mm_remove_node(&orig_mm);
218 i915_gem_object_put(obj);
219 return NULL;
220 }
221
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
next prev parent reply other threads:[~2026-02-21 12:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-20 17:09 [PATCH v2 0/6] update the stolen memory allocation preference Vinod Govindapillai
2026-02-20 17:09 ` [PATCH v2 1/6] drm/xe/fbdev: Fix BIOS FB vs.s stolen size check Vinod Govindapillai
2026-02-24 18:21 ` Shankar, Uma
2026-02-20 17:09 ` [PATCH v2 2/6] drm/i915/display: remove the usage of dev_priv Vinod Govindapillai
2026-02-24 13:17 ` Kahola, Mika
2026-02-20 17:09 ` [PATCH v2 3/6] drm/i915/fbdev: Extract intel_fbdev_fb_prefer_stolen() Vinod Govindapillai
2026-02-21 12:31 ` kernel test robot [this message]
2026-02-21 13:44 ` kernel test robot
2026-02-24 18:55 ` Shankar, Uma
2026-02-20 17:09 ` [PATCH v2 4/6] drm/xe/fbdev: " Vinod Govindapillai
2026-02-20 17:09 ` [PATCH v2 5/6] drm/xe/fbdev: print info about stolen memory preference for fbdev Vinod Govindapillai
2026-02-24 18:36 ` Shankar, Uma
2026-02-20 17:09 ` [PATCH v2 6/6] drm/i915/fbdev: " Vinod Govindapillai
2026-02-24 18:37 ` Shankar, Uma
2026-02-20 18:21 ` ✓ CI.KUnit: success for update the stolen memory allocation preference (rev2) Patchwork
2026-02-20 18:37 ` ✗ CI.checksparse: warning " Patchwork
2026-02-20 18:59 ` ✗ Xe.CI.BAT: failure " Patchwork
2026-02-21 9:24 ` ✗ Xe.CI.FULL: " Patchwork
2026-02-25 11:12 ` [PATCH v2 0/6] update the stolen memory allocation preference Kahola, Mika
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=202602212005.vv7AJP3Z-lkp@intel.com \
--to=lkp@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=uma.shankar@intel.com \
--cc=ville.syrjala@intel.com \
--cc=vinod.govindapillai@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox