On Wed, 14 Feb 2018 02:18:29 +0100, Yaodong Li <yaodong.li@xxxxxxxxx>
wrote:
On 02/13/2018 09:39 AM, Michal Wajdeczko wrote:
<snip>
+
+#define DEFINE_LOCKABLE_REG(var, rg, lb, func) \
+ struct lockable_reg var = { \
+ .name = #rg, \
+ .guc = guc_wopcm_to_guc(guc_wopcm), \
btw, implicit macro params are evil...
Agree. but seems we always use similar approach in
I915_READ/WRITE().O:-)
True, but the only reason why it is still not fixed is that
it requires changes in too many places ...
<snip>
+ * @load_huc_fw: whether need to configure GuC to load HuC firmware.
I'm not sure that we need to track this flag inside structure.
It is just a parameter for doing partitioning and final check.
I think it's related to actual reg configuration. Any suggestions since
we do need it in hw_init to setup offset reg?
You can do partitioning at intel_wopcm level, but program hw at intel_uc
level when you know for sure if HuC is in use. Note that there is no wrong
in using results from WOPCM partitioning outside of intel_wopmc.
As mentioned before, we can avoid this flag and "valid" flag if do
partitioning and validation *before* writing final results to the
struct.
In current code, we do verify the ggtt offset against wopcm top in our
current code which means
current code won't trust the fact that ggtt offset would never be used
after uc/guc init failed.
But after failure in WOPCM partitioning, which should be done sooner than
uc init, we should abort driver load, so there shall be no access to ggtt.
This is the reason for this valid bit (which clearly suggests the struct
is ready to use) - I won't
I'm not sure that "valid" flag approach is correct - you should trust your
code path, otherwise you will have to add "valid" flags to every structure
and this is not a scalable solution ;)
assume the ggtt_offset would never be called even if the uc/guc_init
returned failure.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
