| Message ID | 20180119100005.9072-3-tvrtko.ursulin@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Quoting Tvrtko Ursulin (2018-01-19 10:00:05) > From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > > Setting up the workaround batch buffers can fail either due programming > errors which will be caught in development, or by the inability to > allocate a 4k object and pin it in GGTT at runtime. > > Since this is highly unlikely, and it is not deterministic to allow driver > operation to continue with unknown status of workarounds, it is better to > fail engine initialization explicitly under those circumstances. Not entirely. Failing the driver load leaves the system without a display / console. Disabling GPU execution is one response, but that is likely to happen if the w/a requirement was severe enough. We are not expecting to see an -EIO at this point in the init sequence and all other errors abort the driver load. -Chris
On 19/01/2018 10:09, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2018-01-19 10:00:05) >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> >> >> Setting up the workaround batch buffers can fail either due programming >> errors which will be caught in development, or by the inability to >> allocate a 4k object and pin it in GGTT at runtime. >> >> Since this is highly unlikely, and it is not deterministic to allow driver >> operation to continue with unknown status of workarounds, it is better to >> fail engine initialization explicitly under those circumstances. > > Not entirely. Failing the driver load leaves the system without a > display / console. Disabling GPU execution is one response, but that > is likely to happen if the w/a requirement was severe enough. > > We are not expecting to see an -EIO at this point in the init sequence > and all other errors abort the driver load. Fair enough, I did not think about deeper consequences but only assumed we would run without one engine. Assumptions assumptions! Regards, Tvrtko
Quoting Tvrtko Ursulin (2018-01-19 10:29:12) > > On 19/01/2018 10:09, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-01-19 10:00:05) > >> From: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > >> > >> Setting up the workaround batch buffers can fail either due programming > >> errors which will be caught in development, or by the inability to > >> allocate a 4k object and pin it in GGTT at runtime. > >> > >> Since this is highly unlikely, and it is not deterministic to allow driver > >> operation to continue with unknown status of workarounds, it is better to > >> fail engine initialization explicitly under those circumstances. > > > > Not entirely. Failing the driver load leaves the system without a > > display / console. Disabling GPU execution is one response, but that > > is likely to happen if the w/a requirement was severe enough. > > > > We are not expecting to see an -EIO at this point in the init sequence > > and all other errors abort the driver load. > > Fair enough, I did not think about deeper consequences but only assumed > we would run without one engine. Assumptions assumptions! It's not a bad idea :) The next time we give the init a spring clean we may try that (minimising the impact of any specific failure). -Chris
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 74d7989389e1..6067c5fe6889 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -2054,13 +2054,8 @@ int logical_render_ring_init(struct intel_engine_cs *engine) ret = intel_init_workaround_bb(engine); if (ret) { - /* - * We continue even if we fail to initialize WA batch - * because we only expect rare glitches but nothing - * critical to prevent us from using GPU - */ - DRM_ERROR("WA batch buffer initialization failed: %d\n", - ret); + DRM_ERROR("WA batch buffer initialization failed: %d\n", ret); + return ret; } return logical_ring_init(engine);