On Sun, Sep 06, 2015 at 07:48:40PM +0300, Francisco Jerez wrote: > Chris Wilson <ch...@chris-wilson.co.uk> writes: > > > On Sun, Sep 06, 2015 at 07:28:12PM +0300, Francisco Jerez wrote: > >> Chris Wilson <ch...@chris-wilson.co.uk> writes: > >> > >> > On Sun, Sep 06, 2015 at 06:12:40PM +0200, Francisco Jerez wrote: > >> >> This stores the result of can_do_pipelined_register_writes() in the > >> >> context struct so we can find out later whether LRI can be used to > >> >> program the L3 configuration. > >> > > >> > LRI are whitelisted by their register. To be generic you must explicitly > >> > test access to the register you want to modify. > >> > -Chris > >> > > >> AFAIK except for the chicken bits used to enable L3 atomics on HSW > >> (which is tested explicitly elsewhere, see PATCH 07), all other > >> registers written to are whitelisted since command parser revision 1 -- > >> I don't think that any released kernel version had the command parser > >> enabled on Gen7 but any of the required registers blacklisted. > > > > At the moment you are not even checking that param. The test is written > > to be independent of knowledge of cmdparser internals and by virtue a > > much stronger test. Use it to your advantage. > > -Chris > > > What advantage do you mean?
Kernel indepencence: > If the test passes the command parser is > either enabled (in which case L3 programming will work) or there is no > actual hardware security (in which case L3 programming will work). If > it fails the command parser is disabled and hardware security enabled > (in which case L3 programming will not work either). Exactly. Which is why I suggest writing the test in that manner. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev