Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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