[Intel-gfx] Plans for i915 GuC Submission with regards to IPTS/ME

[Daniele Ceraolo Spurio]

On 12/18/19 10:01 AM, Maximilian Luz wrote:
> Hi,
> 
> On 12/16/19 11:40 PM, Daniele Ceraolo Spurio wrote:
>> Hi,
>>
>> I can't comment on the ITPS side since I have never looked at that
>> side of things, but I can give you an overview of why we turned off
>> GuC submission and what are the short/medium term plans for it.
> 
> By any chance, do you have any idea if it's possible/who we could ask to
> get some more information or some sort of documentation about the
> IPTS/ME/touch-controller interfaces? This could maybe allow us to find
> some sort of work-around not involving GuC.
> 

Unfortunately I have no idea about the docs in this area since it is 
outside the graphics core.

>> TL;DR: The GuC submission interface is changed enough that the code
>> you have is no longer applicable. We're now focused on implementing
>> support for the new interface to re-enable guc submission (gen12+),
>> which is a prerequisite for what you need. IMO any ITPS support on the
>> current tree will have to be postponed until then.
>>
>> The disabling of GuC submission was done because recent binaries
>> (v30+) introduced significant non-backward compatible changes in the
>> interface; given that GuC submission was still not an "official"
>> feature and that even more intrusive interface changes are coming with
>> the upcoming GuC v40+, we decided to just disable the feature for now
>> and wait for all the changes to land on the GuC side before adding
>> support back in. The plan is to re-enable support from either gen11 or
>> gen12, so the gen9 platform will not have it, at least initially. It
>> shouldn't bee too hard to add it in though since the great majority of
>> the code is shared on both the GuC and the i915 side, so I wouldn't
>> exclude us adding it in if there is demand for it.
> 
> Thank you, this is quite helpful. As all devices that I know of using
> IPTS are gen9, GuC support for that generation would be great to have.
> In the mean-time however, I think we will have to try and figure out if
> we can find a work-around, maybe bypassing GuC somehow.

If you only care about gen9, a possible solution would be to 
forward-port just the old GuC submission (instead of the whole i915) 
from a know working kernel. It shouldn't be too bad since the GuC code 
is relatively self-contained, but given the speed at which our 
submission code evolves there might be issue in the interactions between 
the old GuC code and the other parts of the submission flow.

> 
> Just out of curiosity: Are the firmware-changes also done on Windows or
> is this purely Linux specific? Would be interesting to know if they have
> the same problem.
> 

No idea about the details of what goes on on Windows. The firmware is 
OS-agnostic, but they might be using a different version compared to us, 
especially on older platforms.

Daniele

>> The v40 firmware includes an almost complete rework of the submission
>> interface, which is why, in preparation, we removed support from the
>> driver for the legacy structures that are no longer used; we're also
>> not going to use HW doorbells anymore and that's why those have been
>> removed as well. I've had a look at the code in your github tree and
>> most of the things you use are either gone from the interface or have
>> been significantly updated, so I don't think there is an easy way to
>> just port the patch to the new blobs and a significant rewrite is
>> probably going to be required. Re-enabling GuC submission on the new
>> interface, which is our current focus on the i915/GuC integration
>> side, is a prerequisite for that, so IMO unfortunately you'll have to
>> wait until the new interface support lands before any ITPS changes can
>> be considered.
> 
> I suspected that we'll likely have to do a substantial re-write of the
> driver, but it's nice to have confirmation for that so we can at least
> plan a bit ahead.
> 
> Thank you again,
> Maximilian