Quoting Michal Wajdeczko (2017-09-07 16:55:39) > On Thu, Sep 07, 2017 at 02:44:41PM +0100, Chris Wilson wrote: > > If the user bypasses i915 and accesses mmio directly, that easily > > confuses our automatic mmio debugging (any error we then detect is > > likely to be as a result of the user). Since we expect userspace to open > > debugfs/i915_forcewake_user if i915.ko is loaded and they want mmio > > access, that makes the opportune time to disable our debugging for > > duration of the bypass. > > > > v2: Move the fiddling of uncore internals to uncore.c > > > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102543 > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxxxxxxxx> > > --- > > <snip> > > > +/** > > + * intel_uncore_forcewake_user_get - claim forcewake on behalf of userspace > > + * @dev_priv: i915 device instance > > + * > > + * This function is a wrapper around intel_uncore_forcewake_get() to acquire > > + * the GT powerwell and in the process disable our debugging for the > > + * duration of userspace's bypass. > > + */ > > +void intel_uncore_forcewake_user_get(struct drm_i915_private *dev_priv) > > Maybe little off-topic: This file already uses in many places "i915" as a name > for the "drm_i915_private" param (which is the preferred name over "dev_priv"). > Why for this new function you are still using legacy name ? > > Is it due to the fact that you want to avoid name overload as you want to > access global "i915"? If so, what is our long term plan to avoid such clashes. Bingo. i915_params. Plus also killing off modules options as often as possible. Very few things should exist at the module level and not the device level or below, and as a rule of thumb all are workarounds for driver bugs. (The most acceptable are for testing quirks, at some point you have to ask a user if the hw works with a certain flag set or not, before we encapsulate that into a quirk table.) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
