On Wed, 02 Jan 2019, Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> wrote: > On 02/01/2019 09:13, Jani Nikula wrote: >> On Tue, 01 Jan 2019, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote: >>> Quoting Jani Nikula (2018-12-31 14:56:40) >>>> The mkwrite_device_info removal series [1] seems to have stalled. I'm >>>> trying to nudge things forward a bit with this series. This isn't near >>>> as complete as Tvrtko's work, but does some of the prep work I wanted, >>>> specifically using INTEL_INFO() and RUNTIME_INFO() to access the >>>> fields. There are obviously conflicts, but mostly I think this should >>>> make the rest of Tvrtko's work easier, not harder. >>>> >>>> BR, >>>> Jani. >>>> >>>> >>>> [1] https://patchwork.freedesktop.org/series/52381/ >>>> >>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxxxxxxxx> >>>> >>>> >>>> Jani Nikula (6): >>>> drm/i915: start moving runtime device info to a separate struct >>>> drm/i915/reg: abstract display_mmio_offset access >>>> drm/i915: pass dev_priv to intel_device_info_runtime_init() >>>> drm/i915: always use INTEL_INFO() to access device info >>>> drm/i915: drop intel_device_info_dump() >>>> drm/i915: rename dev_priv info to __info to avoid usage >>> >>> Looked ok, and didn't see anything odd compared to my own attempts. >>> Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> >> >> Thanks for the review. >> >> Tvrtko, I'd still like to get your ack before I go ahead and push >> these. Also, do you think you'll have time in the near future to pick up >> your series, or shall I? > > I missed Chris had already reviewed it. Yeah, series looks fine to me. Thanks for your reviews too, pushed the series. > With regards to the second part, after your work what I think would be > left from mine is: > > * move some more fields/flags to runtime info > * subplatform/devid consolidation > * looking at how to wean selftests off modifying the gen field Once we make dev_priv->info a pointer to the static const structs, I think the selftests can make a copy, and point dev_priv->info at that instead, and go wild. There might be a slight chicken and egg issue to deal with in the patch series ordering though to keep it clean. > * maybe introducting INTEL_SSEU to avoid many RUNTIME_INFO(...)->sseu > > If you are in a hurry and have time you can take over, or if you are > just in a hurry I might be able to do within a week or two. I'll eyeball it a bit, and let you know if I do anything to avoid duplicating the effort. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx