GBE: work around baytrail-t hang issue.

There is an unkown issue with baytrail-t platform. It will hang at
utest's compiler_global_constant case. After some investigation,
it turns out to be related to the DWORD GATHER READ send message
on the constand cache data port. I change to use data cache data
port could work around that hang issue.

Now we only fail one more case on baytrail-t compare to the IVB
desktop platform which is the:

profiling_exec()    [FAILED]
   Error: Too large time from submit to start

That may be caused by kernel related issue. And that bug will not
cause serious issue for normal kernel. So after this patch, the
baytrail-t platform should be in a pretty good shape with beignet.

Signed-off-by: Zhigang Gong <zhigang.gong@linux.intel.com>
Reviewed-by: He Junyan <junyan.he@inbox.com>

diff --git a/backend/src/backend/gen_encoder.cpp b/backend/src/backend/gen_encoder.cpp
index 0de4504..a520e79 100644 (file)
--- a/backend/src/backend/gen_encoder.cpp
+++ b/backend/src/backend/gen_encoder.cpp
@@ -206,7 +206,11 @@ namespace gbe
                                      uint32_t msg_length,
                                      uint32_t response_length)
   {
-    const GenMessageTarget sfid = GEN6_SFID_DATAPORT_CONSTANT_CACHE;
+    // FIXME there is a unknown issue with baytrail-t platform, the DWORD scatter
+    // message causes a hang at unit test case compiler_global_constant.
+    // We workaround it to use DATA CACHE instead.
+    const GenMessageTarget sfid = (p->deviceID == PCI_CHIP_BAYTRAIL_T) ?
+                                 GEN_SFID_DATAPORT_DATA_CACHE : GEN6_SFID_DATAPORT_CONSTANT_CACHE;
     setMessageDescriptor(p, insn, sfid, msg_length, response_length);
     insn->bits3.gen7_dword_rw.msg_type = msg_type;
     insn->bits3.gen7_dword_rw.bti = bti;