On Tue, Jan 19, 2016 at 10:16:52AM +0000, Arun Siluvery wrote: > On 19/01/2016 09:00, Daniel Vetter wrote: > >On Thu, Jan 14, 2016 at 03:27:35PM +0000, Arun Siluvery wrote: > >>Some of the HW registers are privileged and cannot be written to from > >>non-privileged batch buffers coming from userspace unless they are added to > >>the HW whitelist. This whitelist is maintained by HW and it is different from > >>SW whitelist. Userspace need write access to them to implement preemption > >>related WA. > >> > >>The reason for using this approach is, the register bits that control > >>preemption granularity at the HW level are not context save/restored; so even > >>if we set these bits always in kernel they are going to change once the > >>context is switched out. We can consider making them non-privileged by > >>default but these registers also contain other chicken bits which should not > >>be allowed to be modified. > >> > >>In the later revisions controlling bits are save/restored at context level but > >>in the existing revisions these are exported via other debug registers and > >>should be on the whitelist. This patch adds changes to provide HW with a list > >>of registers to be whitelisted. HW checks this list during execution and > >>provides access accordingly. > >> > >>HW imposes a limit on the number of registers on whitelist and it is > >>per-engine. At this point we are only enabling whitelist for RCS and we don't > >>foresee any requirement for other engines. > >> > >>The registers to be whitelisted are added using generic workaround list > >>mechanism, even these are only enablers for userspace workarounds. But by > >>sharing this mechanism we get some test assets without additional cost (Mika). > >> > >>v2: rebase > >> > >>v3: parameterize RING_FORCE_TO_NONPRIV() as _MMIO() should be limited to > >>i915_reg.h (Ville), drop inline for wa_ring_whitelist_reg (Mika). > >> > >>v4: improvements suggested by Chris Wilson. > >>Clarify that this is HW whitelist and different from the one maintained in > >>driver. This list is engine specific but it gets initialized along with other > >>WA which is RCS specific thing, so make it clear that we are not doing any > >>cross engine setup during initialization. > >>Make HW whitelist count of each engine available in debugfs. > >> > >>Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >>Reviewed-by: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > >>Cc: Mika Kuoppala <mika.kuoppala@xxxxxxxxx> > >>Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > >>Signed-off-by: Arun Siluvery <arun.siluvery@xxxxxxxxxxxxxxx> > > > >If you resend just single patches to a series you must --in-reply-to the > >individual patch, not the cover letter. Otherwise patchwork won't pick it > >up, which means we don't have CI results for this. > > Hi Daniel, > > Yes I did use --in-reply-to but probably not the correct message-id, will > keep this in mind. > > > > >Since it's been a while probably best to just resend the entire pile. > > > >Also we seem to be missing r-b tags for the actual w/a changes. > yes, actual w/a are yet to be reviewed, I can resend all of them once they > are reviewed or you want me to send it now? Either way is fine I think. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
