On Wed, 02 Jan 2019, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > On 31/12/2018 14:56, Jani Nikula wrote: >> @@ -2198,10 +2199,11 @@ intel_info(const struct drm_i915_private *dev_priv) >> } >> >> #define INTEL_INFO(dev_priv) intel_info((dev_priv)) >> +#define RUNTIME_INFO(dev_priv) (&(dev_priv)->__runtime) > > Do we want to keep the const trick like with INTEL_INFO in order to make > accidental modifications harder? Argument is different there than with > static info. I did think about it, but I don't want to repeat mkwrite_device_info(). I understand we have three classes of data: 1) immutable 2) immutable after one-time runtime init 3) mutable Currently we mix all of them, the intention here is to split out 1 from 2&3, the latter two remaining conflated. I'd like to see how this pans out before worrying about the difference between 2&3. >> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c b/drivers/gpu/drm/i915/i915_gpu_error.c >> index 2bd7991ec9af..6238a06b6d4e 100644 >> --- a/drivers/gpu/drm/i915/i915_gpu_error.c >> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c >> @@ -594,13 +594,14 @@ static void print_error_obj(struct drm_i915_error_state_buf *m, >> >> static void err_print_capabilities(struct drm_i915_error_state_buf *m, >> const struct intel_device_info *info, >> + const struct intel_runtime_info *runtime, >> const struct intel_driver_caps *caps) >> { >> struct drm_printer p = i915_error_printer(m); >> >> intel_device_info_dump_flags(info, &p); > > If I am not missing something here we now miss the runtime flags being > dumped. > > A bit later: Ah ok, you haven't yet added any flags to runtime info in > this patch. *grin* Like I said, not as complete as your series. > Looks okay to me. > > The only thing which worries me is that one day we end up with too > little in static vs runtime and decide having two separate sources of > info is only a hassle. (Like if the DCE/LTO path either does not happen, > or ends up not needing this completely.) > > I suppose it is worth exploring and we can always go back easily if all > else fails. I at least want to have another go at the subplatform/devid > centralization. > > Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> Thanks, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx