Chris Wilson <ch...@chris-wilson.co.uk> writes: > 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.
I'm sure you had some specific practical advantage in mind? Bashing the rather sensitive L3 configuration registers to see if something sticks is a hack with potential implications. I'd prefer to avoid that unless there is a reason why it could be useful. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev