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.
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.
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.
Daniele
On 12/15/19 3:12 AM, Maximilian Luz wrote:
Hello,
I am working together with a small team of volunteers on a project that
aims to make Linux usable on Microsoft Surface devices (linux-surface).
The touchscreens of these devices use Intel Precise Touch & Stylus
(IPTS) technology, which makes use of the GPU (through GuC submission)
to process touch input events. Since IPTS is not supported by upstream
Linux, the linux-surface project relies on kernel patches and
out-of-tree drivers to make it work properly under Linux.
The driver we are currently using was written by an Intel employee back
in 2016, and has since been somewhat updated and maintained by
linux-surface. However, due to how the IPTS hardware works, the driver
has to use GuC submission to setup the connections between the GPU and
the Intel ME / touch controller. This is made possible by patching an
IPTS-specific API into the i915 driver that allows the IPTS driver to
issue commands to the GuC.
Now, starting with Linux 5.3, a bunch of changes were done to the i915
driver that made it impossible for us to use the IPTS driver like we did
before. First, GuC submission got disabled, and recently there was a
list of patches sent to this mailing list that removes the GuC APIs that
we have been using entirely. We have a rough understanding about how the
hardware works, but for the most part, the connection between the
various parts of IPTS (ME, GuC) is a giant black-box for us.
Currently the way that IPTS and the driver work is like this:
- the IPTS driver allocates a GuC client a doorbell, and a bunch of
touch input / output buffers, and passes the addresses to the ME
- the driver loads a vendor specific firmware file and uploads it to the
GPU
- the ME fills up the touch input buffer, and rings the GuC doorbell
- the firmware that was uploaded to the GPU processes the data from the
input buffer into HID events, and saves them into the output buffers
- the IPTS driver polls for changes in those buffers and relays the
contents into the kernels HID subsystem
Is there any chance that you have an idea about if it will be possible
to update the IPTS driver that is out there to work with the new GuC API
that is coming into i915, and how we might have to go about that?
As you see, the most part of this happens in the firmware, and the
driver just sets up the messaging framework around it. This makes it
hard for us to think of a possible solution without having a deep
understanding and insight into the hardware.
Another problem is that, except for the very latest generation of
Surface devices that was released some weeks ago, all devices that use
IPTS are either Skylake or Kabylake. While researching about this, we
found some comments, stating that any form of GuC submission might only
be supported on Icelake in the future. A patch
(https://patchwork.freedesktop.org/patch/335793/) on the other hand
reads like it would be re-enabled on all devices. Can you clarify if GuC
is intended to be re-enabled on all (Gen9+) devices?
We hope you can provide us with any help in getting this updated to
support future Linux releases. The Surface devices are pretty good
hardware-wise, and it would be great to continue to use them under Linux
with a working touchscreen.
Regards,
Maximilian Luz
---
Various links that might provide more insight into the IPTS side:
- Original IPTS implementation:
https://github.com/ipts-linux-org/ipts-linux-new
- Updated version of IPTS, with support* for linux 5.3:
https://github.com/qzed/linux-surface-kernel/tree/v5.3-surface-devel/drivers/misc/ipts
* Support for 5.3 is currently done by porting the i915 driver from
5.2 to
the newer kernel, since it still supports GuC submission. It is an
_awful_
hack but none of us had time to really dive into this issue back
then, and
this seemed like the easiest solution.
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
