On 01/07/2019 01:35 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 21:28:48)
On 01/07/2019 10:50 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-01-07 18:31:52)
Were you already
planning/working on something along the lines of the possible solution
mentioned in the commit message? Just trying to understand what the
status is before jumping in to avoid duplication of work ;)
The compromises required (reserving space for the firmware) seem like it
will just end up with a lot of screaming to make it mutexless today.
Aren't we already keeping some GuC stuff perma-pinned (e.g. the
stage_desc_pool)? Current Gen11+ firmware needs more space and uses
objects up to tens of MBs, the blobs aren't that big in comparison.
Hmm, there's always the guc reserved region (top/bottom). Is that large
enough to store the firmware, and would it be legal to load from those
addresses? (After the dma transfer we wouldn't use those ourselves, so
the guc is free to utilise them for its scratch. Then after the guc is
reset, we would put the firmware there again for dma xfer).
-Chris
I've asked and the DMA engine should be able to fetch from there, so
this sounds like quite a good compromise. We wouldn't need to move the
blob after the reset either because those regions are not accessible at
all by GuC and they're not used by the firmware in any way. The top
region in particular is several MBs big, so the firmware would fit quite
nicely in there.
Daniele
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
