Re: External display doesn't work (start?) anymore

2024-02-26 Thread Theo de Raadt 
Please stop sending bug reports as images.

I am pretty much deleting all bug reports from you because they show
no effort on your part.

Kirill A. Korinsky  wrote:

> Meanwhile I'd like to add that seems another bug.
> 
> I attach two pictures to this message.
> 1. is screenshot of some corner of the screen;
> 2. is a picture taken by phone (well, I need to clean it, yeah).
> 
> As you may see (2) contians some arifacts which is a real element of UI of
> Telegram Desktop on antoher virtual screen. I've tried to move the screen,
> but doesn't remove an artifact.
> 
> Reboot helps. Disconnect doesn't.
> 
> Thus, artifcat appears only after
> 
>   drm:pid76201:drm_atomic_helper_wait_for_flip_done *ERROR* [drm] *ERROR* 
> [CRTC:51:pipe A] flip_done timed out
> 
> before it, no artifact.
> 
> -- 
> wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-21 Thread Kirill A . Korinsky 
On Thu, 22 Feb 2024 00:36:00 +0100,
Jonathan Gray wrote:
> 
> Try directly connect with DisplayPort or HDMI if you can.  USB Type-C
> involves dealing with another microcontroller.

This Display hasn't got any control nor ports other that USB-C.

See: https://www.lg.com/us/monitors/lg-27md5kl-b-5k-uhd-led-monitor

-- 
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-21 Thread Jonathan Gray 
On Wed, Feb 21, 2024 at 02:12:35PM +0100, Kirill A. Korinsky wrote:
> On Tue, 20 Feb 2024 09:11:35 +0100,
> Jonathan Gray wrote:
> > 
> > Thanks, committed.
> 
> And I found one more unexpected side effect.
> 
> When I connect monitor I need to reconnect it physically some times.
> 
> Seems that it in kind of sleep or hibernate mode, and when I connect
> laptop the first time, it start to boot, but never light up. If I
> recconect the laptop (plug and unplug USB-C), it light up.
> 
> Wired, but this behaviour happenes not always. Seems that it need couple
> of minutes (5-10, not sure) to be disconnected from everything to go
> into that deep sleep state.
> 
> Anz thoughts?

Try directly connect with DisplayPort or HDMI if you can.  USB Type-C
involves dealing with another microcontroller.

Re: External display doesn't work (start?) anymore

2024-02-21 Thread Kirill A . Korinsky 
On Tue, 20 Feb 2024 09:11:35 +0100,
Jonathan Gray wrote:
> 
> Thanks, committed.

And I found one more unexpected side effect.

When I connect monitor I need to reconnect it physically some times.

Seems that it in kind of sleep or hibernate mode, and when I connect
laptop the first time, it start to boot, but never light up. If I
recconect the laptop (plug and unplug USB-C), it light up.

Wired, but this behaviour happenes not always. Seems that it need couple
of minutes (5-10, not sure) to be disconnected from everything to go
into that deep sleep state.

Anz thoughts?

-- 
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-20 Thread Kirill A . Korinsky 
On Tue, 20 Feb 2024 11:08:21 +0100,
Kirill A. Korinsky wrote:
> 
> Anyway, I'll try to reserve some time to dig into cam with hope that
> this nice screen will be fully functional on OpenBSD-7.5.
> 

BTW with the last patch behaviour seems a bit improved.

~ $ video -q -f /dev/video1  
video device /dev/video1:
  encodings: uyvy
  frame sizes (width x height, in pixels) and rates (in frames per second):
320x240: 30, 29, 29, 28, 27, 26, 25, 24, 23, 23, 22, 21, 20, 19, 18, 
17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
640x480: 30, 29, 29, 28, 27, 26, 25, 24, 23, 23, 22, 21, 20, 19, 18, 
17, 16, 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1
  controls: brightness, contrast, saturation, gain, gamma, sharpness, 
white_balance_temperature, backlight_compensation
~ $ ffplay -f v4l2 -list_formats all -i /dev/video1
ffplay version 4.4.4 Copyright (c) 2003-2023 the FFmpeg developers
  built with OpenBSD clang version 16.0.6
  configuration: --enable-shared --arch=amd64 --cc=cc --enable-debug 
--disable-stripping --disable-indev=jack --disable-outdev=sdl2 
--enable-fontconfig --enable-frei0r --enable-gpl --enable-ladspa 
--enable-libaom --enable-libass --enable-libdav1d --enable-libfreetype 
--enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libopus 
--enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis 
--enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 
--enable-libxvid --enable-libzimg --enable-nonfree --enable-openssl 
--enable-libvidstab --extra-cflags='-I/usr/local/include -I/usr/X11R6/include' 
--extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' --extra-ldsoflags= 
--mandir=/usr/local/man --objcc=/usr/bin/false --optflags='-O2 -pipe -g 
-Wno-redundant-decls'
  libavutil  56. 70.100 / 56. 70.100
  libavcodec 58.134.100 / 58.134.100
  libavformat58. 76.100 / 58. 76.100
  libavdevice58. 13.100 / 58. 13.100
  libavfilter 7.110.100 /  7.110.100
  libswscale  5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc55.  9.100 / 55.  9.100
[video4linux2,v4l2 @ 0xcf665842000] Raw   : uyvy422 : 
UYVY : 640x480 320x240
[video4linux2,v4l2 @ 0xcf665842000] Compressed:   mjpeg :
MJPEG : 1920x1080 1280x720 1024x768 640x480 320x240
/dev/video1: Immediate exit requestedB vq=0KB sq=0B f=0/0   
nan:  0.000 fd=   0 aq=0KB vq=0KB sq=0B f=0/0   
~ $ ffplay -f v4l2 -input_format mjpeg -video_size 1280x720 -i /dev/video1
ffplay version 4.4.4 Copyright (c) 2003-2023 the FFmpeg developers
  built with OpenBSD clang version 16.0.6
  configuration: --enable-shared --arch=amd64 --cc=cc --enable-debug 
--disable-stripping --disable-indev=jack --disable-outdev=sdl2 
--enable-fontconfig --enable-frei0r --enable-gpl --enable-ladspa 
--enable-libaom --enable-libass --enable-libdav1d --enable-libfreetype 
--enable-libfribidi --enable-libgsm --enable-libmp3lame --enable-libopus 
--enable-libspeex --enable-libtheora --enable-libv4l2 --enable-libvorbis 
--enable-libvpx --enable-libx264 --enable-libx265 --enable-libxml2 
--enable-libxvid --enable-libzimg --enable-nonfree --enable-openssl 
--enable-libvidstab --extra-cflags='-I/usr/local/include -I/usr/X11R6/include' 
--extra-libs='-L/usr/local/lib -L/usr/X11R6/lib' --extra-ldsoflags= 
--mandir=/usr/local/man --objcc=/usr/bin/false --optflags='-O2 -pipe -g 
-Wno-redundant-decls'
  libavutil  56. 70.100 / 56. 70.100
  libavcodec 58.134.100 / 58.134.100
  libavformat58. 76.100 / 58. 76.100
  libavdevice58. 13.100 / 58. 13.100
  libavfilter 7.110.100 /  7.110.100
  libswscale  5.  9.100 /  5.  9.100
  libswresample   3.  9.100 /  3.  9.100
  libpostproc55.  9.100 / 55.  9.100
[video4linux2,v4l2 @ 0x7429b316000] ioctl(VIDIOC_DQBUF): Invalid argument
[video4linux2,v4l2 @ 0x7429b316000] Could not find codec parameters for stream 
0 (Video: mjpeg, none(bt470bg/unknown/unknown), 1280x720): unspecified pixel 
format
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' 
(500) options
Input #0, video4linux2,v4l2, from '/dev/video1':
  Duration: N/A, bitrate: N/A
  Stream #0:0: Video: mjpeg, none(bt470bg/unknown/unknown), 1280x720, 30 fps, 
30 tbr, 1000k tbn, 1000k tbc
[video4linux2,v4l2 @ 0x7429b316000] ioctl(VIDIOC_DQBUF): Invalid argument
[video4linux2,v4l2 @ 0x7429b316000] ioctl(VIDIOC_DQBUF): Invalid argument
[video4linux2,v4l2 @ 0x7429b316000] ioctl(VIDIOC_DQBUF): Invalid argument
[video4linux2,v4l2 @ 0x7429b316000] ioctl(VIDIOC_DQBUF): Invalid argument
^C  nan M-V:nan fd=   0 aq=0KB vq=0KB sq=0B f=0/0   

It stil frozen after C-c and if I deattach the display, it will be
unstack.

Anyway, before I never saw errors related to ioctl, and it was fronzen
on this stage.

Thus, now it can produce multiple ioctl lines, and is frozen only after
C-c. So, something was changed in the right direction.

-- 
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-20 Thread Kirill A . Korinsky 
On Tue, 20 Feb 2024 09:11:35 +0100,
Jonathan Gray wrote:
>
> Thanks, committed.

Thanks!

Embedded cam into this display doesn't work also, but I haven't got time
to debug it right now.

Thus, discovering that the timeout was the case of issue was quite time
consuming.

Anyway, I'll try to reserve some time to dig into cam with hope that
this nice screen will be fully functional on OpenBSD-7.5.

--
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-20 Thread Jonathan Gray 
On Mon, Feb 19, 2024 at 12:33:09PM +0100, Kirill A. Korinsky wrote:
> On Mon, 19 Feb 2024 12:23:46 +0100,
> Jonathan Gray wrote:
> > 
> > Can you revert that and see if only 1 of the 3 commits is enough?
> > 
> > Diff below includes only
> > "drm/i915/pxp/mtl: Update pxp-firmware response timeout"
> >
> 
> It works.

Thanks, committed.

Re: External display doesn't work (start?) anymore

2024-02-19 Thread Kirill A . Korinsky 
On Mon, 19 Feb 2024 12:23:46 +0100,
Jonathan Gray wrote:
> 
> Can you revert that and see if only 1 of the 3 commits is enough?
> 
> Diff below includes only
> "drm/i915/pxp/mtl: Update pxp-firmware response timeout"
>

It works.

-- 
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-19 Thread Jonathan Gray 
On Mon, Feb 19, 2024 at 12:11:28PM +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> > I'm curious if some of the newer commits in linux change what you see.
> > combined diff below
> 
> Just applied it as https://marc.info/?l=openbsd-bugs=170833357114116=raw 
> on
> local root 
> https://github.com/openbsd/src/commit/cfda45639a5cff5780a6f40814e7d74479c846c3
> 
> And it help.
> 
> Thanks, this is much cleaner than my durty patch.

Can you revert that and see if only 1 of the 3 commits is enough?

Diff below includes only
"drm/i915/pxp/mtl: Update pxp-firmware response timeout"

diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index 89ed5ee9cde..2fde5c360cf 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -81,8 +81,17 @@ out_rq:
 
i915_request_add(rq);
 
-   if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
-   err = -ETIME;
+   if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other 
(non-privileged) path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-priv submission to 
gsccs-hw");
+   if (i915_request_wait(rq, 0, 
msecs_to_jiffies(GSC_HECI_REPLY_LATENCY_MS)) < 0)
+   err = -ETIME;
+   }
 
i915_request_put(rq);
 
@@ -186,6 +195,13 @@ out_rq:
i915_request_add(rq);
 
if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other (privileged) 
path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-non-priv submission to 
gsccs-hw");
if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
  msecs_to_jiffies(timeout_ms)) < 0)
err = -ETIME;
diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 09d3fbdad05..c4308291c00 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -12,6 +12,12 @@ struct i915_vma;
 struct intel_context;
 struct intel_gsc_uc;
 
+#define GSC_HECI_REPLY_LATENCY_MS 500
+/*
+ * Max FW response time is 500ms, but this should be counted from the time the
+ * command has hit the GSC-CS hardware, not the preceding handoff to GuC CTB.
+ */
+
 struct intel_gsc_mtl_header {
u32 validity_marker;
 #define GSC_HECI_VALIDITY_MARKER 0xA578875A
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c 
sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
index 86f58a5bddd..cc81a462492 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
+++ sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.c
@@ -111,7 +111,7 @@ gsccs_send_message(struct intel_pxp *pxp,
 
ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>uc.gsc,
   exec_res->ce, , 
exec_res->bb_vaddr,
-  GSC_REPLY_LATENCY_MS);
+  GSC_HECI_REPLY_LATENCY_MS);
if (ret) {
drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
goto unlock;
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h 
sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
index 298ad38e6c7..9aae779c4da 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
+++ sys/dev/pci/drm/i915/pxp/intel_pxp_gsccs.h
@@ -8,16 +8,14 @@
 
 #include 
 
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
+
 struct intel_pxp;
 
-#define GSC_REPLY_LATENCY_MS 210
-/*
- * Max FW response time is 200ms, to which we add 10ms to account for overhead
- * such as request preparation, GuC submission to hw and pipeline completion 
times.
- */
 #define GSC_PENDING_RETRY_MAXCOUNT 40
 #define GSC_PENDING_RETRY_PAUSE_MS 50
-#define GSCFW_MAX_ROUND_TRIP_LATENCY_MS (GSC_PENDING_RETRY_MAXCOUNT * 
GSC_PENDING_RETRY_PAUSE_MS)
+#define GSCFW_MAX_ROUND_TRIP_LATENCY_MS (GSC_HECI_REPLY_LATENCY_MS + \
+(GSC_PENDING_RETRY_MAXCOUNT * 
GSC_PENDING_RETRY_PAUSE_MS))
 
 #ifdef CONFIG_DRM_I915_PXP
 void intel_pxp_gsccs_fini(struct intel_pxp *pxp);

Re: External display doesn't work (start?) anymore

2024-02-19 Thread Kirill A . Korinsky 
Greetings,

> I'm curious if some of the newer commits in linux change what you see.
> combined diff below

Just applied it as https://marc.info/?l=openbsd-bugs=170833357114116=raw on
local root 
https://github.com/openbsd/src/commit/cfda45639a5cff5780a6f40814e7d74479c846c3

And it help.

Thanks, this is much cleaner than my durty patch.

--
wbr, Kirill

Re: External display doesn't work (start?) anymore

2024-02-19 Thread Jonathan Gray 
On Sun, Feb 18, 2024 at 09:01:13PM +0100, Kirill A. Korinsky wrote:
> Greetings,
> 
> Here an ugly patch which recovers support of LG UltraFine 5K which was broken
> since update drm to linux 6.6.12.
> 
> This Display is quite delicate if not to say unstable, and it won't start with
> timeout other whan 250ms.
> 
> A function intel_pxp_get_backend_timeout_ms returns two possible value: 250 or
> GSCFW_MAX_ROUND_TRIP_LATENCY_MS which is defined at the end as 40 * 50.
> 
> Before an update, this code has only 250 as timeout and it works.
> 
> Possible that intel_pxp_init doesn't initialize pxp->ctrl_gt the same way like
> linux, or such regression exists on linux as well.

I'm curious if some of the newer commits in linux change what you see.
combined diff below

commit 698e19da2914a0021a088b2b5d101d1854862315
Author: Zhanjun Dong 
Date:   Mon Nov 13 14:49:53 2023 -0800

drm/i915: Skip pxp init if gt is wedged

commit fb99e79ee62aaa07d9e77cb3a15c5f1ae2790e6a
Author: Alan Previn 
Date:   Wed Oct 11 14:01:57 2023 +0300

mei: update mei-pxp's component interface with timeouts

commit 8ae272348153ed2fa423f739047a592d9bd55ba2
Author: Alan Previn 
Date:   Sun Sep 17 14:19:31 2023 -0700

drm/i915/pxp/mtl: Update pxp-firmware response timeout

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=698e19da2914a0021a088b2b5d101d1854862315
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fb99e79ee62aaa07d9e77cb3a15c5f1ae2790e6a
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8ae272348153ed2fa423f739047a592d9bd55ba2

diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
index 89ed5ee9cde..2fde5c360cf 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c
@@ -81,8 +81,17 @@ out_rq:
 
i915_request_add(rq);
 
-   if (!err && i915_request_wait(rq, 0, msecs_to_jiffies(500)) < 0)
-   err = -ETIME;
+   if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other 
(non-privileged) path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-priv submission to 
gsccs-hw");
+   if (i915_request_wait(rq, 0, 
msecs_to_jiffies(GSC_HECI_REPLY_LATENCY_MS)) < 0)
+   err = -ETIME;
+   }
 
i915_request_put(rq);
 
@@ -186,6 +195,13 @@ out_rq:
i915_request_add(rq);
 
if (!err) {
+   /*
+* Start timeout for i915_request_wait only after considering 
one possible
+* pending GSC-HECI submission cycle on the other (privileged) 
path.
+*/
+   if (wait_for(i915_request_started(rq), 
GSC_HECI_REPLY_LATENCY_MS))
+   drm_dbg(_uc_to_gt(gsc)->i915->drm,
+   "Delay in gsc-heci-non-priv submission to 
gsccs-hw");
if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
  msecs_to_jiffies(timeout_ms)) < 0)
err = -ETIME;
diff --git sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h 
sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
index 09d3fbdad05..c4308291c00 100644
--- sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
+++ sys/dev/pci/drm/i915/gt/uc/intel_gsc_uc_heci_cmd_submit.h
@@ -12,6 +12,12 @@ struct i915_vma;
 struct intel_context;
 struct intel_gsc_uc;
 
+#define GSC_HECI_REPLY_LATENCY_MS 500
+/*
+ * Max FW response time is 500ms, but this should be counted from the time the
+ * command has hit the GSC-CS hardware, not the preceding handoff to GuC CTB.
+ */
+
 struct intel_gsc_mtl_header {
u32 validity_marker;
 #define GSC_HECI_VALIDITY_MARKER 0xA578875A
diff --git sys/dev/pci/drm/i915/i915_driver.c sys/dev/pci/drm/i915/i915_driver.c
index 059fdca5d58..b5870fe9b26 100644
--- sys/dev/pci/drm/i915/i915_driver.c
+++ sys/dev/pci/drm/i915/i915_driver.c
@@ -810,7 +810,9 @@ int i915_driver_probe(struct drm_i915_private *i915, const 
struct pci_device_id
if (ret)
goto out_cleanup_modeset2;
 
-   intel_pxp_init(i915);
+   ret = intel_pxp_init(i915);
+   if (ret != -ENODEV)
+   drm_dbg(>drm, "pxp init failed with %d\n", ret);
 
ret = intel_display_driver_probe(i915);
if (ret)
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp.c 
sys/dev/pci/drm/i915/pxp/intel_pxp.c
index e079f5b6ee6..41ac603e1a7 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp.c
+++ sys/dev/pci/drm/i915/pxp/intel_pxp.c
@@ -199,6 +199,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
struct

Re: External display doesn't work (start?) anymore

2024-02-18 Thread Kirill A . Korinsky 
Greetings,

Here an ugly patch which recovers support of LG UltraFine 5K which was broken
since update drm to linux 6.6.12.

This Display is quite delicate if not to say unstable, and it won't start with
timeout other whan 250ms.

A function intel_pxp_get_backend_timeout_ms returns two possible value: 250 or
GSCFW_MAX_ROUND_TRIP_LATENCY_MS which is defined at the end as 40 * 50.

Before an update, this code has only 250 as timeout and it works.

Possible that intel_pxp_init doesn't initialize pxp->ctrl_gt the same way like
linux, or such regression exists on linux as well.

Anyway, my approach is hack which fixed my issue, but I haven't got any way to
test it on different hardware, so, I may introduce something.

But I happy that I can use my screen again

P.S. bug report: https://marc.info/?l=openbsd-bugs=170821608101004=2

-- 
wbr, Kirill
diff --git sys/dev/pci/drm/i915/pxp/intel_pxp.c 
sys/dev/pci/drm/i915/pxp/intel_pxp.c
index e079f5b6ee6..528405056ec 100644
--- sys/dev/pci/drm/i915/pxp/intel_pxp.c
+++ sys/dev/pci/drm/i915/pxp/intel_pxp.c
@@ -330,7 +330,8 @@ static int __pxp_global_teardown_restart(struct intel_pxp 
*pxp)
 */
pxp_queue_termination(pxp);
 
-   timeout = intel_pxp_get_backend_timeout_ms(pxp);
+   /* LG UltraFine 5K starts only when timeout is 250 */
+   timeout = 250;
 
if (!wait_for_completion_timeout(>termination, 
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;

Re: External display doesn't work (start?) anymore

2024-02-18 Thread Kirill A . Korinsky 


As attempt to find the cause I've tried different kernels.

The first step was to try kernel before: update drm to linux 6.6.12 [1],
which I suceffuly build and tries on current snapshot system.

The issue was reproduced.

Unfortently I can't simple switch to something before because system doesn't
boot with miltiple crasshes regarding invlaid syscall. I assume that the cause
is PT_OPENBSD_SYSCALLS [2]. I've tried to backport that to early kernel to use
as part of bisect to find who brokes it, but it quite fragile :(

So, here I get all commits which changes sys/dev/pci/drm/i915 between unlock the
base to move to 7.4-current [3] and update drm. It wasn't so many, just 22.

I've reverted all of them in reverse order and tries each separatley [4].

Well, isssue is reproducing with both firmares: from current snapshot and 7.4.

So, I have no idea how to debug it future.

Can anyone suggest anyway?

Footnotes:
[1]  
https://github.com/openbsd/src/commit/f005ef32267c16bdb134f0e9fa4477dbe07c263a

[2]  
https://github.com/openbsd/src/commit/4a066defabc39dafcb616ade6ee82c10212ac361

[3]  
https://github.com/openbsd/src/commit/67babe865022f800d11adfe4f8b70c437e1e3e30

[4]  https://github.com/catap/OpenBSD-src/tree/LG5k-issue

--
wbr, Kirill