Quoting Yaodong Li (2018-03-23 19:33:15) > As I said, I agree that we would likely solve the enable_guc=1 then > enable_guc=3 case with these changes which I think this the the only benefit > that we can get from the starting from the top way. > But my point is just like the from the bottom way, you are ignoring the > HuC FW size. e.g. you will need to grow the guc wopcm size for the hw > restrictions. > The problem is currently we do have this restriction on huc fw size v.s. > guc wopcm > size. In you solution, you are actually counting on the assumption that > guc fw size should be large enough so that we can ignore the huc fw size > and expect it still works when we set enable_huc=3. and my answer to > this is yes it will work for the cases that guc fw size is large enough, but > still risky to fail in case of guc fw size < huc_fw_size + 16K. and that > comes > to my point: > why not make life easier and accurate - If we decide to support dynamically > switching on/off huc fw loading and the fact we can get actual FW sizes, > why not drop all these assumptions and fix it in a way that we won't be > bothered by any FW side changes? :) Is not the GuC vs. HuC FW size limitation going to be fixed for upcoming platforms? My gut instinct would be to partition based only on the enabled FW sizes, whichever it be. Then just require a reboot if after that partitioning, changing the parameter causes the FW not to fit. Loading the FW, and writing its size to HW registers when there is a kernel command line parameter to disable its use, seems unexpected. Regards, Joonas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
