From: Zhigang Gong Date: Thu, 17 Apr 2014 06:59:00 +0000 (+0800) Subject: GBE: work around baytrail-t hang issue. X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=f766b48b18a53b2310211c6f219dc3480aca8c34;p=contrib%2Fbeignet.git 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 Reviewed-by: He Junyan --- diff --git a/backend/src/backend/gen_encoder.cpp b/backend/src/backend/gen_encoder.cpp index 0de4504..a520e79 100644 --- 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;