From: Jason Gerecke <jason.gerecke(a)wacom.com>
We've recently switched from extracting the value of HID_DG_CONTACTMAX
at a fixed offset (which may not be correct for all tablets) to
injecting the report into the driver for the generic codepath to handle.
Unfortunately, this change was made for *all* tablets, even those which
aren't generic. Because `wacom_wac_report` ignores reports from non-
generic devices, the contact count never gets initialized. Ultimately
this results in the touch device itself failing to probe, and thus the
loss of touch input.
This commit adds back the fixed-offset extraction for non-generic devices.
Ref: https://github.com/linuxwacom/input-wacom/issues/155
Fixes: 184eccd40389 ("HID: wacom: generic: read HID_DG_CONTACTMAX from any feature report")
Signed-off-by: Jason Gerecke <jason.gerecke(a)wacom.com>
Reviewed-by: Aaron Armstrong Skomra <aaron.skomra(a)wacom.com>
CC: stable(a)vger.kernel.org # 5.3+
---
drivers/hid/wacom_sys.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/hid/wacom_sys.c b/drivers/hid/wacom_sys.c
index 5ded94b7bf68..cd71e7133944 100644
--- a/drivers/hid/wacom_sys.c
+++ b/drivers/hid/wacom_sys.c
@@ -319,9 +319,11 @@ static void wacom_feature_mapping(struct hid_device *hdev,
data[0] = field->report->id;
ret = wacom_get_report(hdev, HID_FEATURE_REPORT,
data, n, WAC_CMD_RETRIES);
- if (ret == n) {
+ if (ret == n && features->type == HID_GENERIC) {
ret = hid_report_raw_event(hdev,
HID_FEATURE_REPORT, data, n, 0);
+ } else if (ret == 2 && features->type != HID_GENERIC) {
+ features->touch_max = data[1];
} else {
features->touch_max = 16;
hid_warn(hdev, "wacom_feature_mapping: "
--
2.26.0
On Wed, Apr 01, 2020 at 06:53:17PM -0400, Giacomo Comes wrote:
> Hi,
> on my Intel Compute Stick STCK1 (baytrail hdmi audio)
> sound is not working with the kernel 5.6
>
> I have bisected the kernel and I found the commit that introduced the issue:
>
> commit 58d124ea2739e1440ddd743d46c470fe724aca9a
> Author: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com>
> Date: Thu Oct 31 12:26:04 2019 +0100
>
> drm/i915: Complete crtc hw/uapi split, v6.
>
> Now that we separated everything into uapi and hw, it's
> time to make the split definitive. Remove the union and
> make a copy of the hw state on modeset and fastset.
>
> Color blobs are copied in crtc atomic_check(), right
> before color management is checked.
>
> If more information is required please let me know.
Should hopefully be fixed with
commit 2bdd4c28baff ("drm/i915/display: Fix mode private_flags
comparison at atomic_check")
Stable folks, please pick that up for 5.6.x stable releases.
--
Ville Syrjälä
Intel
Sorry, I forgot the "fixes:" in commit
6726ca1a2d531f5a6efc1f785b15606ce837c4dc
I was hoping DRM maintainers would pick it up before it hit mainline,
but it hasn't happened.
Please apply to 5.6.x
The driver is new in 5.6 and this fix is merged for 5.7 already.
Sorry for the inconvenience,
Torsten
commit 4900dda90af2cb13bc1d4c12ce94b98acc8fe64e upstream
Due to async need_flush updating via other buffer mapping, checking
gpu->need_flush in 3 places within etnaviv_buffer_queue can cause GPU
hangs.
This occurs due to need_flush being false for the first 2 checks in that
function, so that the extra dword does not get accounted for, but by the
time we come to check for the third time, gpu->mmu->need_flish is true,
which outputs the flush instruction. This causes the prefetch during the
final link to be off by 1. This causes GPU hangs.
It causes the ring to contain patterns like this:
0x40000005, /* LINK (8) PREFETCH=0x5,OP=LINK */
0x70040010, /* ADDRESS *0x70040010 */
0x40000002, /* LINK (8) PREFETCH=0x2,OP=LINK */
0x70040000, /* ADDRESS *0x70040000 */
0x08010e04, /* LOAD_STATE (1) Base: 0x03810 Size: 1 Fixp: 0 */
0x0000001f, /* GL.FLUSH_MMU := FLUSH_FEMMU=1,FLUSH_UNK1=1,FLUSH_UNK2=1,FLUSH_PEMMU=1,FLUSH_UNK4=1 */
0x08010e03, /* LOAD_STATE (1) Base: 0x0380C Size: 1 Fixp: 0 */
0x00000000, /* GL.FLUSH_CACHE := DEPTH=0,COLOR=0,TEXTURE=0,PE2D=0,TEXTUREVS=0,SHADER_L1=0,SHADER_L2=0,UNK10=0,UNK11=0,DESCRIPTOR_UNK12=0,DESCRIPTOR_UNK13=0 */
0x08010e02, /* LOAD_STATE (1) Base: 0x03808 Size: 1 Fixp: 0 */
0x00000701, /* GL.SEMAPHORE_TOKEN := FROM=FE,TO=PE,UNK28=0x0 */
0x48000000, /* STALL (9) OP=STALL */
0x00000701, /* TOKEN FROM=FE,TO=PE,UNK28=0x0 */
0x08010e00, /* LOAD_STATE (1) Base: 0x03800 Size: 1 Fixp: 0 */
0x00000000, /* GL.PIPE_SELECT := PIPE=PIPE_3D */
0x40000035, /* LINK (8) PREFETCH=0x35,OP=LINK */
0x70041000, /* ADDRESS *0x70041000 */
Here we see a link with prefetch of 5 dwords starting with the 3rd
instruction. It only loads the 5 dwords up and including the final
LOAD_STATE. It needs to include the final LINK instruction.
This was seen on imx6q, and the fix is confirmed to stop the GPU hangs.
The commit referenced inadvertently fixed this issue by checking
gpu->mmu->need_flush once at the start of the function.
Given that this commit is independant, and useful for all version, it
seems sensible to backport it to the stable branches.