All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
To: Maximilian Luz <luzmaximilian@gmail.com>
Cc: Dorian Stoll <dorian.stoll@tmsp.io>, intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] Plans for i915 GuC Submission with regards to IPTS/ME
Date: Mon, 23 Dec 2019 10:55:30 -0800	[thread overview]
Message-ID: <bc31eaa3-c5ed-819f-a94a-1f7ca335ea86@intel.com> (raw)
In-Reply-To: <bc4e8a25-05b5-72fb-8ddd-2275b739f0a5@gmail.com>



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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2019-12-23 18:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-15 11:12 [Intel-gfx] Plans for i915 GuC Submission with regards to IPTS/ME Maximilian Luz
2019-12-16 22:40 ` Daniele Ceraolo Spurio
     [not found]   ` <bc4e8a25-05b5-72fb-8ddd-2275b739f0a5@gmail.com>
2019-12-23 18:55     ` Daniele Ceraolo Spurio [this message]
2019-12-28 12:24       ` Maximilian Luz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc31eaa3-c5ed-819f-a94a-1f7ca335ea86@intel.com \
    --to=daniele.ceraolospurio@intel.com \
    --cc=dorian.stoll@tmsp.io \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=luzmaximilian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.