[REGRESSION] HDMI connector detection broken in 6.3 on Intel(R) Celeron(R) N3060 integrated graphics
The following is a copy an issue I posted to drm/i915 gitlab [1] two
months ago. I repost it to the mailing lists in hope that it will help
the right people pay attention to it.
After kernel upgrade from 6.2.13 to 6.3 HDMI connector detection is
broken for me. Issue is 100% reproducible:
1. Start system as usual with HDMI connected.
2. Disconnect HDMI
3. Connect HDMI back
4. Get "no signal" on display, connector status in sysfs is disconnected
Curiously, running xrandr over ssh like
ssh qnap251.local env DISPLAY=:0 xrandr
makes display come back. drm-tip tip is affected as well (last test
2023-08-02).
Bisecting points at a4e771729a51 ("drm/probe_helper: sort out poll_running vs
poll_enabled").
Reverting that commit on top of 6.3 fixes the issue for me.
System information:
* System architecture: x86_64
* Kernel version: 6.3.arch1
* Linux distribution: Arch Linux
* Machine: QNAP TS-251A, CPU: Intel(R) Celeron(R) CPU N3060 @ 1.60GHz
* Display connector: single HDMI display
* dmesg with debug information (captured on drm-tip, following above 4 steps):
[2]
* xrandr output:
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
DP-1 disconnected (normal left inverted right x axis y axis)
HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y
axis) 708mm x 398mm
1920x1080 60.00*+ 50.0059.9430.0025.0024.00
29.9723.98
1920x1080i60.0050.0059.94
1360x768 59.80
1280x768 60.35
1280x720 60.0050.0059.94
1024x768 75.0370.0760.00
832x624 74.55
800x600 75.0060.32
720x576 50.00
720x480 60.0059.94
640x480 75.0060.0059.94
720x400 70.08
DP-2 disconnected (normal left inverted right x axis y axis)
HDMI-2 disconnected (normal left inverted right x axis y axis)```
I'm willing to provide additional information and/or test fixes.
[1] https://gitlab.freedesktop.org/drm/intel/-/issues/8451
[2]
https://gitlab.freedesktop.org/drm/intel/uploads/fda7aff0b13ef20962856c2c7be51544/dmesg.txt
#regzbot introduced: a4e771729a51
--
Best regards,
Mikhail Rudenko
Re: [REGRESSION] HDMI connector detection broken in 6.3 on Intel(R) Celeron(R) N3060 integrated graphics
Hi, Thorsten! On 2023-08-11 at 08:45 +02, Thorsten Leemhuis wrote: > [CCing the i915 maintainers and the dri maintainers] > > Hi, Thorsten here, the Linux kernel's regression tracker. > > On 10.08.23 21:33, Mikhail Rudenko wrote: >> The following is a copy an issue I posted to drm/i915 gitlab [1] two >> months ago. I repost it to the mailing lists in hope that it will help >> the right people pay attention to it. > > Thx for your report. Wonder why Dmitry (who authored a4e771729a51) or > Thomas (who committed it) it didn't look into this, but maybe the i915 > devs didn't forward the report to them. > > Let's see if these mails help. Just wondering: does reverting > a4e771729a51 from 6.5-rc5 or drm-tip help as well? I've redone my tests with 6.5-rc5, and here are the results: (1) 6.5-rc5 -> still affected (2) 6.5-rc5 + revert a4e771729a51 -> not affected (3) 6.5-rc5 + two patches [1][2] suggested on i915 gitlab by @ideak -> not affected (!) Should we somehow tell regzbot about (3)? > BTW, there was an earlier report about a problem with a4e771729a51 that > afaics was never addressed, but it might be unrelated. > > https://lore.kernel.org/all/20230328023129.3596968-1-zhouzong...@kylinos.cn/ > > Ciao, Thorsten [1] https://patchwork.freedesktop.org/patch/548590/?series=121050&rev=1 [2] https://patchwork.freedesktop.org/patch/548591/?series=121050&rev=1 -- Best regards, Mikhail Rudenko
Re: DMA-BUFs always uncached on arm64, causing poor camera performance on Librem 5
Hi, Pavel, On 2025-07-10 at 10:24 +02, Pavel Machek wrote: > [[PGP Signed Part:Undecided]] > Hi! > > It seems that DMA-BUFs are always uncached on arm64... which is a > problem. > > I'm trying to get useful camera support on Librem 5, and that includes > recording vidos (and taking photos). Earlier this year i tried to solve a similar issue on rkisp1 (Rockchip 3399), and done some measurements, showing that non-coherent buffers + cache flushing for buffers is a viable approach [1]. Unfortunately, that effort stalled, but maybe patch "[PATCH v4 1/2] media: videobuf2: Fix dmabuf cache sync/flush in dma-contig" will be useful to you. [1] https://lore.kernel.org/all/20250303-b4-rkisp-noncoherent-v4-0-e32e843fb...@gmail.com/ > memcpy() from normal memory is about 2msec/1MB. Unfortunately, for > DMA-BUFs it is 20msec/1MB, and that basically means I can't easily do > 760p video recording. Plus, copying full-resolution photo buffer takes > more than 200msec! > > There's possibility to do some processing on GPU, and its implemented here: > > https://gitlab.com/tui/tui/-/tree/master/icam?ref_type=heads > > but that hits the same problem in the end -- data is in DMA-BUF, > uncached, and takes way too long to copy out. > > And that's ... wrong. DMA ended seconds ago, complete cache flush > would be way cheaper than copying single frame out, and I still have > to deal with uncached frames. > > So I have two questions: > > 1) Is my analysis correct that, no matter how I get frame from v4l and > process it on GPU, I'll have to copy it from uncached memory in the > end? > > 2) Does anyone have patches / ideas / roadmap how to solve that? It > makes GPU unusable for computing, and camera basically unusable for > video. > > Best regards, > Pavel -- Best regards, Mikhail Rudenko
