Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年12月3日 週五 下午10:03寫道：
>
> On Mon, Nov 29, 2021 at 04:31:57PM +0800, Jian-Hong Pan wrote:
> > Maxime Ripard 於 2021年11月26日 週五 下午11:45寫道：
> > >
> > > On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote:
> > > > Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道：
> > > > >
> > > > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote:
> > > > > > Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道：
> > > > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4:
> > > > > > > kms: Convert to
> > > > > > > atomic helpers") introduced a number of issues in corner cases,
> > > > > > > most of them
> > > > > > > showing themselves in the form of either a vblank timeout or
> > > > > > > use-after-free
> > > > > > > error.
> > > > > > >
> > > > > > > These patches should fix most of them, some of them still being
> > > > > > > debugged.
> > > > > > >
> > > > > > > Maxime
> > > > > > >
> > > > > > > Changes from v1:
> > > > > > > - Prevent a null pointer dereference
> > > > > > >
> > > > > > > Maxime Ripard (6):
> > > > > > > drm/vc4: kms: Wait for the commit before increasing our clock
> > > > > > > rate
> > > > > > > drm/vc4: kms: Fix return code check
> > > > > > > drm/vc4: kms: Add missing drm_crtc_commit_put
> > > > > > > drm/vc4: kms: Clear the HVS FIFO commit pointer once done
> > > > > > > drm/vc4: kms: Don't duplicate pending commit
> > > > > > > drm/vc4: kms: Fix previous HVS commit wait
> > > > > > >
> > > > > > > drivers/gpu/drm/vc4/vc4_kms.c | 42
> > > > > > > ---
> > > > > > > 1 file changed, 19 insertions(+), 23 deletions(-)
> > > > > >
> > > > > > I tested the v2 patches based on latest mainline kernel with RPi 4B.
> > > > > > System can boot up into desktop environment.
> > > > >
> > > > > So the thing that was broken initially isn't anymore?
> > > >
> > > > No. It does not appear anymore.
> > > >
> > > > > > Although it still hit the bug [1], which might be under debugging, I
> > > > > > think these patches LGTM.
> > > > >
> > > > > The vblank timeout stuff is a symptom of various different bugs. Can
> > > > > you
> > > > > share your setup, your config.txt, and what you're doing to trigger
> > > > > it?
> > > >
> > > > I get the RPi boot firmware files from raspberrypi's repository at tag
> > > > 1.20211029 [1]
> > > > And, make system boots:
> > > > RPi firmware -> U-Boot -> Linux kernel (aarch64) with corresponding DTB
> > > >
> > > > The config.txt only has:
> > > > enable_uart=1
> > > > arm_64bit=1
> > > > kernel=uboot.bin
> > > >
> > > > This bug can be reproduced with es2gears command easily. May need to
> > > > wait it running a while.
> > > >
> > > > Mesa: 21.2.2
> > > > libdrm: 2.4.107
> > > > xserver/wayland: 1.20.11 Using wayland
> > > >
> > > > This bug happens with direct boot path as well:
> > > > RPi firmware -> Linux kernel (aarch64) with corresponding DTB
> > > >
> > > > I tried with Endless OS and Ubuntu's RPi 4B images.
> > > > An easy setup is using Ubuntu 21.10 RPi 4B image [2]. Then, replace
> > > > the kernel & device tree blob and edit the config.txt.
> > >
> > > Does it still appear if you raise the core clock in the config.txt file
> > > using: core_freq_min=600 ?
> >
> > It still appears when I raise the core clock in the config.txt file:
> > core_freq_min=600
>
> That's weird, we had some issues like that already but could never point
> exactly what was going on.
>
> Is testing the official raspberrypi kernel an option for you? If so,
> trying the same workload with fkms would certainly help
I tested the raspberrypi kernel on rpi-5.16.y branch at commit
bcb52df6df52 ("xhci: add a quirk to work around a suspected cache bug
on VLI controllers"). Also, enabled the fkms. So, vc4 and v3d are
loaded. However, the "flip_done timed out" error does not appear like
mainline kernel.
Jian-Hong Pan
Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年11月26日 週五 下午11:45寫道： > > On Fri, Nov 19, 2021 at 06:24:34PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道： > > > > > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote: > > > > Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道： > > > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: > > > > > Convert to > > > > > atomic helpers") introduced a number of issues in corner cases, most > > > > > of them > > > > > showing themselves in the form of either a vblank timeout or > > > > > use-after-free > > > > > error. > > > > > > > > > > These patches should fix most of them, some of them still being > > > > > debugged. > > > > > > > > > > Maxime > > > > > > > > > > Changes from v1: > > > > > - Prevent a null pointer dereference > > > > > > > > > > Maxime Ripard (6): > > > > > drm/vc4: kms: Wait for the commit before increasing our clock rate > > > > > drm/vc4: kms: Fix return code check > > > > > drm/vc4: kms: Add missing drm_crtc_commit_put > > > > > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > > > > > drm/vc4: kms: Don't duplicate pending commit > > > > > drm/vc4: kms: Fix previous HVS commit wait > > > > > > > > > > drivers/gpu/drm/vc4/vc4_kms.c | 42 > > > > > --- > > > > > 1 file changed, 19 insertions(+), 23 deletions(-) > > > > > > > > I tested the v2 patches based on latest mainline kernel with RPi 4B. > > > > System can boot up into desktop environment. > > > > > > So the thing that was broken initially isn't anymore? > > > > No. It does not appear anymore. > > > > > > Although it still hit the bug [1], which might be under debugging, I > > > > think these patches LGTM. > > > > > > The vblank timeout stuff is a symptom of various different bugs. Can you > > > share your setup, your config.txt, and what you're doing to trigger it? > > > > I get the RPi boot firmware files from raspberrypi's repository at tag > > 1.20211029 [1] > > And, make system boots: > > RPi firmware -> U-Boot -> Linux kernel (aarch64) with corresponding DTB > > > > The config.txt only has: > > enable_uart=1 > > arm_64bit=1 > > kernel=uboot.bin > > > > This bug can be reproduced with es2gears command easily. May need to > > wait it running a while. > > > > Mesa: 21.2.2 > > libdrm: 2.4.107 > > xserver/wayland: 1.20.11 Using wayland > > > > This bug happens with direct boot path as well: > > RPi firmware -> Linux kernel (aarch64) with corresponding DTB > > > > I tried with Endless OS and Ubuntu's RPi 4B images. > > An easy setup is using Ubuntu 21.10 RPi 4B image [2]. Then, replace > > the kernel & device tree blob and edit the config.txt. > > Does it still appear if you raise the core clock in the config.txt file > using: core_freq_min=600 ? It still appears when I raise the core clock in the config.txt file: core_freq_min=600 Jian-Hong Pan
Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年11月18日 週四 下午6:40寫道： > > On Thu, Nov 18, 2021 at 02:42:58PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道： > > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: > > > Convert to > > > atomic helpers") introduced a number of issues in corner cases, most of > > > them > > > showing themselves in the form of either a vblank timeout or > > > use-after-free > > > error. > > > > > > These patches should fix most of them, some of them still being debugged. > > > > > > Maxime > > > > > > Changes from v1: > > > - Prevent a null pointer dereference > > > > > > Maxime Ripard (6): > > > drm/vc4: kms: Wait for the commit before increasing our clock rate > > > drm/vc4: kms: Fix return code check > > > drm/vc4: kms: Add missing drm_crtc_commit_put > > > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > > > drm/vc4: kms: Don't duplicate pending commit > > > drm/vc4: kms: Fix previous HVS commit wait > > > > > > drivers/gpu/drm/vc4/vc4_kms.c | 42 --- > > > 1 file changed, 19 insertions(+), 23 deletions(-) > > > > I tested the v2 patches based on latest mainline kernel with RPi 4B. > > System can boot up into desktop environment. > > So the thing that was broken initially isn't anymore? No. It does not appear anymore. > > Although it still hit the bug [1], which might be under debugging, I > > think these patches LGTM. > > The vblank timeout stuff is a symptom of various different bugs. Can you > share your setup, your config.txt, and what you're doing to trigger it? I get the RPi boot firmware files from raspberrypi's repository at tag 1.20211029 [1] And, make system boots: RPi firmware -> U-Boot -> Linux kernel (aarch64) with corresponding DTB The config.txt only has: enable_uart=1 arm_64bit=1 kernel=uboot.bin This bug can be reproduced with es2gears command easily. May need to wait it running a while. Mesa: 21.2.2 libdrm: 2.4.107 xserver/wayland: 1.20.11 Using wayland This bug happens with direct boot path as well: RPi firmware -> Linux kernel (aarch64) with corresponding DTB I tried with Endless OS and Ubuntu's RPi 4B images. An easy setup is using Ubuntu 21.10 RPi 4B image [2]. Then, replace the kernel & device tree blob and edit the config.txt. [1] https://github.com/raspberrypi/firmware/tree/1.20211029/boot [2] https://ubuntu.com/download/raspberry-pi Jian-Hong Pan > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=214991 > > > > Tested-by: Jian-Hong Pan > > Thanks! > Maxime
Re: [PATCH v2 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年11月17日 週三 下午5:45寫道： > > Hi, > > The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to > atomic helpers") introduced a number of issues in corner cases, most of them > showing themselves in the form of either a vblank timeout or use-after-free > error. > > These patches should fix most of them, some of them still being debugged. > > Maxime > > Changes from v1: > - Prevent a null pointer dereference > > Maxime Ripard (6): > drm/vc4: kms: Wait for the commit before increasing our clock rate > drm/vc4: kms: Fix return code check > drm/vc4: kms: Add missing drm_crtc_commit_put > drm/vc4: kms: Clear the HVS FIFO commit pointer once done > drm/vc4: kms: Don't duplicate pending commit > drm/vc4: kms: Fix previous HVS commit wait > > drivers/gpu/drm/vc4/vc4_kms.c | 42 --- > 1 file changed, 19 insertions(+), 23 deletions(-) I tested the v2 patches based on latest mainline kernel with RPi 4B. System can boot up into desktop environment. Although it still hit the bug [1], which might be under debugging, I think these patches LGTM. [1] https://bugzilla.kernel.org/show_bug.cgi?id=214991 Tested-by: Jian-Hong Pan
Re: [PATCH 0/6] drm/vc4: kms: Misc fixes for HVS commits
Maxime Ripard 於 2021年11月15日 週一 下午7:31寫道：
>
> Hi,
>
> The conversion to DRM commit helpers (f3c420fe19f8, "drm/vc4: kms: Convert to
> atomic helpers") introduced a number of issues in corner cases, most of them
> showing themselves in the form of either a vblank timeout or use-after-free
> error.
>
> These patches should fix most of them, some of them still being debugged.
>
> Maxime
>
> Maxime Ripard (6):
> drm/vc4: kms: Wait for the commit before increasing our clock rate
> drm/vc4: kms: Fix return code check
> drm/vc4: kms: Add missing drm_crtc_commit_put
> drm/vc4: kms: Clear the HVS FIFO commit pointer once done
> drm/vc4: kms: Don't duplicate pending commit
> drm/vc4: kms: Fix previous HVS commit wait
>
> drivers/gpu/drm/vc4/vc4_kms.c | 36 ++-
> 1 file changed, 14 insertions(+), 22 deletions(-)
>
> --
> 2.33.1
>
Thanks to Maxime's information!
I tried to applied this patch series based on the latest mainline
kernel at commit commit 8ab774587903 ("Merge tag 'trace-v5.16-5' of
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace"),
which almost equals "tags/v5.16-rc1" and tested it on RPi 4B.
However, the system hangs and becomes dead at the kernel message:
[drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
The full dmesg can be found at
https://bugzilla.kernel.org/attachment.cgi?id=299603
If I revert the patch series to the original mainline kernel, system
can boot up.
BR,
Jian-Hong Pan
[BUG] VC4 DRM waiting for flip down makes UI freeze a while with kernel 5.15
Hi,
I tested Linux mainline kernel 5.15 (aarch64) with enabled VC4 on RPi 4B. I
notice UI freezes a while (about 10 seconds) some times.
The kernel shows the error message during the time:
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
[drm:drm_atomic_helper_wait_for_flip_done] *ERROR* [CRTC:68:crtc-3]
flip_done timed out
[drm:drm_atomic_helper_wait_for_dependencies] *ERROR* [CRTC:68:crtc-3]
commit wait timed out
[drm:drm_crtc_commit_wait] *ERROR* flip_done timed out
vc4-drm gpu: [drm] *ERROR* Timed out waiting for commit
Here is the full log:
https://github.com/lategoodbye/rpi-zero/files/7518076/dmesg-5.15.log
It is easy to reproduce this issue by invoking GL related things, for
example "es2gears".
After detail test, I found it is related to these commits:
* f3c420fe19f8 ("drm/vc4: kms: Convert to atomic helpers")
* 82faa3276012 ("drm/vc4: kms: Remove async modeset semaphore")
This issue cannot be reproduced after I revert the commits.
Jian-Hong Pan
Re: [PATCH] drm/rockchip: skip probed failed device
Heiko Stübner 於 2020年9月23日 週三 下午7:16寫道：
>
> Am Mittwoch, 23. September 2020, 13:05:26 CEST schrieb Robin Murphy:
> > On 2020-09-23 07:59, Jian-Hong Pan wrote:
> > > The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
> > >
> > > kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR*
> > > missing extcon or phy
> > > kernel: cdn-dp: probe of fec0.dp failed with error -22
> >
> > Wouldn't it make more sense to simply not enable the DisplayPort node in
> > the upstream DT, until the type-C phy work has been done to make it
> > usable at all?
>
> Or alternatively just disable the cdn-dp Rockchip driver in the kernel config,
> which results in it also not getting probed.
This may be the simplest way.
However, considering generic distro kernels have a policy to enable
all drivers, disabling the DisplayPort node in the upstream DT, until
the type-C phy work has been done may be a better solution for now.
I can prepare a patch for this.
Jian-Hong Pan
> > AIUI the "official" Manjaro kernel is carrying a bunch of
> > hacks to make type-C work via extcon, but they know that isn't an
> > upstreamable solution.
> >
> > Robin.
> >
> > > Then, the device halts all of the DRM related device jobs. For example,
> > > the operations: vop_component_ops, vop_component_ops and
> > > rockchip_dp_component_ops cannot be bound to corresponding devices. So,
> > > Xorg cannot find the correct DRM device.
> > >
> > > This patch skips the probing failed devices to fix this issue.
> > >
> > > Link:
> > > http://lists.infradead.org/pipermail/linux-rockchip/2020-September/022352.html
> > > Signed-off-by: Jian-Hong Pan
> > > ---
> > > drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > index 0f3eb392fe39..de13588602b4 100644
> > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
> > > @@ -331,6 +331,12 @@ static struct component_match
> > > *rockchip_drm_match_add(struct device *dev)
> > >
> > > if (!d)
> > > break;
> > > + if (!d->driver) {
> > > + DRM_DEV_ERROR(d,
> > > + "%s did not probe successfully",
> > > + drv->driver.name);
> > > + continue;
> > > + }
> > >
> > > device_link_add(dev, d, DL_FLAG_STATELESS);
> > > component_match_add(dev, &match, compare_dev, d);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/rockchip: skip probed failed device
The cdn-dp sub driver probes the device failed on PINEBOOK Pro.
kernel: cdn-dp fec0.dp: [drm:cdn_dp_probe [rockchipdrm]] *ERROR* missing
extcon or phy
kernel: cdn-dp: probe of fec0.dp failed with error -22
Then, the device halts all of the DRM related device jobs. For example,
the operations: vop_component_ops, vop_component_ops and
rockchip_dp_component_ops cannot be bound to corresponding devices. So,
Xorg cannot find the correct DRM device.
This patch skips the probing failed devices to fix this issue.
Link:
http://lists.infradead.org/pipermail/linux-rockchip/2020-September/022352.html
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 0f3eb392fe39..de13588602b4 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -331,6 +331,12 @@ static struct component_match
*rockchip_drm_match_add(struct device *dev)
if (!d)
break;
+ if (!d->driver) {
+ DRM_DEV_ERROR(d,
+ "%s did not probe successfully",
+ drv->driver.name);
+ continue;
+ }
device_link_add(dev, d, DL_FLAG_STATELESS);
component_match_add(dev, &match, compare_dev, d);
--
2.28.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 00/80] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime,
Thanks for version 5 patch series!
I applied it based on linux-next tag next-20200828 and build it with
the config [1] to test on RPi 4
However, It fails to get HDMI state machine clock and pixel bcb clock.
Then, vc4-drm probes failed. Full dmseg [2]:
[2.552675] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
HDMI state machine clock
[2.557974] raspberrypi-firmware soc:firmware: Attached to firmware
from 2020-06-01T13:23:40
[2.567612] of_clk_hw_onecell_get: invalid index 14
[2.567636] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get
pixel bvb clock
[2.567664] vc4-drm gpu: failed to bind fef00700.hdmi (ops vc4_hdmi_ops): -2
[2.567731] vc4-drm gpu: master bind failed: -2
[2.567755] vc4-drm: probe of gpu failed with error -2
I decompile bcm2711-rpi-4-b.dtb. Both hdmi@7ef00700 and hdmi@7ef05700
show the clocks member.
hdmi@7ef00700 {
compatible = "brcm,bcm2711-hdmi0";
reg = <0x7ef00700 0x300 0x7ef00300 0x200 0x7ef00f00 0x80
0x7ef00f80 0x80 0x7ef01b00 0x200 0x7ef01f00 0x400 0x7ef00200 0x80
0x7ef04300 0x100 0x7ef2 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x00>;
ddc = <0x18>;
dmas = <0x19 0x0a>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x00 0x1a>;
};
hdmi@7ef05700 {
compatible = "brcm,bcm2711-hdmi1";
reg = <0x7ef05700 0x300 0x7ef05300 0x200 0x7ef05f00 0x80
0x7ef05f80 0x80 0x7ef06b00 0x200 0x7ef06f00 0x400 0x7ef00280 0x80
0x7ef09300 0x100 0x7ef2 0x100>;
reg-names = "hdmi\0dvp\0phy\0rm\0packet\0metadata\0csc\0cec\0hd";
ddc = <0x1b>;
clock-names = "hdmi\0bvb\0audio\0cec";
resets = <0x17 0x01>;
dmas = <0x19 0x11>;
dma-names = "audio-rx";
status = "okay";
clocks = <0x10 0x0d 0x10 0x0e 0x17 0x01 0x1a>;
};
Also re-check runtime device tree, they are the same values as mentioned above:
$ xxd /proc/device-tree/soc/hdmi@7ef00700/clocks
: 0010 000d 0010 000e
0010: 0017 001a
$ xxd /proc/device-tree/soc/hdmi@7ef05700/clocks
: 0010 000d 0010 000e
0010: 0017 0001 001a
Do I miss something?
[1]:
https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-config
[2]:
https://gist.github.com/starnight/649ea5a8384313f0354aca504f78ad70#file-dmesg-log
Jian-Hong Pan
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 00/78] drm/vc4: Support BCM2711 Display Pipeline
Hi Maxime, Thanks for your version 4 patch again. I took the patches and applied them upon next-20200708. I make system cold reboot to multi-user target and the text console shows on the screen. Then, I simply hot re-plug the HDMI cable on HDMI0 port, I not only lose the text console on the screen (the display shows blank, backlight is off), but also kernel does not probe modes for the HDMI connector again. But HDMI1 does probe modes again for hot re-plugging. So, HDMI1 does not hit the issue like HDMI0. * System probes modes only once for HDMI0 port (HDMI-A-1), even hot re-plug HDMI cable to the same port: [ 15.611072] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:HDMI-A-1] probed modes : [ 15.611079] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 15.611085] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 15.611298] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 15.611303] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] [ 15.612184] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] disconnected [ 15.612191] [drm:drm_client_modeset_probe] connector 32 enabled? yes [ 15.612194] [drm:drm_client_modeset_probe] connector 38 enabled? no [ 15.612206] [drm:drm_client_modeset_probe] Not using firmware configuration [ 15.612213] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 32 [ 15.612218] [drm:drm_client_modeset_probe] looking for preferred mode on connector 32 0 [ 15.612221] [drm:drm_client_modeset_probe] found mode 1920x1080 ... [ 108.263384] [drm:output_poll_execute] [CONNECTOR:32:HDMI-A-1] status updated from disconnected to connected [ 108.264307] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] [ 108.264312] [drm:drm_client_modeset_probe] [ 108.264321] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:32:HDMI-A-1] [ 109.303379] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] [ 109.304258] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] disconnected [ 109.304266] [drm:drm_client_modeset_probe] No connectors reported connected with modes * System probes modes again for HDMI1 port (HDMI-A-2), whenever hot re-plug the HDMI cable: [ 797.974649] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] probed modes : [ 797.974656] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 797.974662] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 797.974874] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 797.974880] [drm:drm_client_modeset_probe] connector 32 enabled? no [ 797.974883] [drm:drm_client_modeset_probe] connector 38 enabled? yes [ 797.974895] [drm:drm_client_modeset_probe] Not using firmware configuration [ 797.974901] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 38 [ 797.974905] [drm:drm_client_modeset_probe] looking for preferred mode on connector 38 0 [ 797.974908] [drm:drm_client_modeset_probe] found mode 1920x1080 ... [ 852.242615] vc4-drm gpu: [drm:drm_client_dev_hotplug] fbdev: ret=0 [ 873.718277] [drm:output_poll_execute] [CONNECTOR:38:HDMI-A-2] status updated from disconnected to connected [ 873.718332] vc4-drm gpu: [drm:drm_fb_helper_hotplug_event.part.0] [ 873.718338] [drm:drm_client_modeset_probe] ... [ 874.264013] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:38:HDMI-A-2] probed modes : [ 874.264020] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x48 0x5 [ 874.264026] [drm:drm_mode_debug_printmodeline] Modeline "1920x1080": 60 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x40 0x5 ... [ 874.264239] [drm:drm_mode_debug_printmodeline] Modeline "720x400": 70 28320 720 738 846 900 400 412 414 449 0x40 0x6 [ 874.264244] [drm:drm_client_modeset_probe] connector 32 enabled? no [ 874.264247] [drm:drm_client_modeset_probe] connector 38 enabled? yes [ 874.264259] [drm:drm_client_modeset_probe] Not using firmware configuration [ 874.264264] [drm:drm_client_modeset_probe] looking for cmdline mode on connector 38 [ 874.264268] [drm:drm_client_modeset_probe] looking for preferred mode on connector 38 0 [ 874.264272] [drm:drm_client_modeset_probe] found mode 1920x1080 Here is the full dmesg: https://gist.github.com/starnight/5ffb86af552fedb9b6e5741d0540a878#file-dmesg-v4-log ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年6月29日 週一 下午10:21寫道： > > Hi! > > On Fri, Jun 05, 2020 at 04:44:51PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年6月2日 週二 下午7:04寫道： > > > > > > Hi, > > > > > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote: > > > > Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > > > > > > > > > Hi Daniel, > > > > > > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard > > > > > > wrote: > > > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and > > > > > > > Jian-Hong) if you > > > > > > > want. > > > > > > > > > > > > That would be great, although given the potentially inconsistent > > > > > > results we've been seeing so far it would be great if you could > > > > > > additionally push a git branch somewhere. > > > > > > That way we can have higher confidence that we are applying exactly > > > > > > the same patches to the same base etc. > > > > > > > > > > So I sent a new iteration yesterday, and of course forgot to cc > > > > > you... Sorry for > > > > > that. > > > > > > > > > > I've pushed my current branch here: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms > > > > > > > > Thanks to Maxime! > > > > > > > > I have tried your repository on branch rpi4-kms. The DRM VC4 is used! > > > > But got some issues: > > > > 1. Some weird error message in dmesg. Not sure it is related, or not > > > > [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get > > > > HDMI state machine clock > > > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 > > > > > > That's a deferred probing. The first time the HDMI driver is being > > > probed, the firmware clock driver has not been probed yet. It's making > > > another attempt later on, which succeeds. > > > > > > > 2. The screen flashes suddenly sometimes. > > > > I append drm.debug=0x3 to boot command. Whenever, the screen flashes, > > I notice the logs like this: > > > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling > > vblank on crtc 3, ret: 0 > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 159 (2) > > Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 154 (1) > > Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling > > vblank on crtc 3 > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > auth=1, DRM_IOCTL_MODE_CURSOR > > Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, > > auth=1, DRM_IOCTL_MODE_CURSOR2 > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1) > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1) > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 > > Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] > > crtc 64: clock 148500 kHz framedur 1666 linedur 14814 > > Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling > > vblank on crtc 3, ret: 0 > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 159 (2) > > Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: > > 154 (2) > > > > Here is the full log > > https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56 > > > > > > 3. The higher resolutions, like 1920x1080 ... are lost after hot > > > > re-plug HDMI cable (HDMI0) > > > > I should explain this in more detail. Here are the steps to reproduce > > this issue: > > 1. Before unplug the HDMI cable from HDMI0 port. > > $ xrandr > > Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 > > HDMI-1 connected primary 1920x1080+0+0
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年6月2日 週二 下午7:04寫道： > > Hi, > > On Mon, Jun 01, 2020 at 03:58:26PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > > > > > Hi Daniel, > > > > > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > > > > > I'm about to send a v3 today or tomorrow, I can Cc you (and > > > > > Jian-Hong) if you > > > > > want. > > > > > > > > That would be great, although given the potentially inconsistent > > > > results we've been seeing so far it would be great if you could > > > > additionally push a git branch somewhere. > > > > That way we can have higher confidence that we are applying exactly > > > > the same patches to the same base etc. > > > > > > So I sent a new iteration yesterday, and of course forgot to cc you... > > > Sorry for > > > that. > > > > > > I've pushed my current branch here: > > > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms > > > > Thanks to Maxime! > > > > I have tried your repository on branch rpi4-kms. The DRM VC4 is used! > > But got some issues: > > 1. Some weird error message in dmesg. Not sure it is related, or not > > [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get > > HDMI state machine clock > > https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 > > That's a deferred probing. The first time the HDMI driver is being > probed, the firmware clock driver has not been probed yet. It's making > another attempt later on, which succeeds. > > > 2. The screen flashes suddenly sometimes. I append drm.debug=0x3 to boot command. Whenever, the screen flashes, I notice the logs like this: Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 Jun 01 15:22:40 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: clock 148500 kHz framedur 1666 linedur 14814 Jun 01 15:22:40 endless kernel: [drm:drm_vblank_enable] enabling vblank on crtc 3, ret: 0 Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2) Jun 01 15:22:40 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (1) Jun 01 15:22:40 endless kernel: [drm:vblank_disable_fn] disabling vblank on crtc 3 Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, auth=1, DRM_IOCTL_MODE_CURSOR Jun 01 15:22:42 endless kernel: [drm:drm_ioctl] pid=584, dev=0xe200, auth=1, DRM_IOCTL_MODE_CURSOR2 Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 159 (1) Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_get] OBJ ID: 154 (1) Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: hwmode: htotal 2200, vtotal 1125, vdisplay 1080 Jun 01 15:22:42 endless kernel: [drm:drm_calc_timestamping_constants] crtc 64: clock 148500 kHz framedur 1666 linedur 14814 Jun 01 15:22:42 endless kernel: [drm:drm_vblank_enable] enabling vblank on crtc 3, ret: 0 Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 159 (2) Jun 01 15:22:42 endless kernel: [drm:drm_mode_object_put.part.0] OBJ ID: 154 (2) Here is the full log https://gist.github.com/starnight/85d641819839eddc7a55ca7173990a56 > > 3. The higher resolutions, like 1920x1080 ... are lost after hot > > re-plug HDMI cable (HDMI0) I should explain this in more detail. Here are the steps to reproduce this issue: 1. Before unplug the HDMI cable from HDMI0 port. $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 HDMI-1 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.0059.94 1920x1080i60.0050.0059.94 1680x1050 59.88 1280x1024 75.0260.02 1440x900 59.90 1280x960 60.00 1152x864 75.00 1280x720 60.0050.0059.94 1440x576 50.00 1024x768 75.0370.0760.00 1440x480 60.0059.94 832x624 74.55 800x600 72.1975.0060.3256.25 720x576 50.00 720x480 60.0059.94 640x480 75.0072.8166.6760.0059.94 720x400 70.08 HDMI-2 disconnected (normal left inverted right x axis y axis) 2. Unplug the HDMI cable from HDMI0 port. 3. Plug the HDMI cable to **HDMI1** port. $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 2048 x 2048 HDMI-1 disconnected (normal left inverted right x axis y axis) HDMI-2 connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 521mm x 293mm 1920x1080 60.00*+ 50.0
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年5月28日 週四 下午3:30寫道： > > Hi Daniel, > > On Wed, May 27, 2020 at 05:15:12PM +0800, Daniel Drake wrote: > > On Wed, May 27, 2020 at 5:13 PM Maxime Ripard wrote: > > > I'm about to send a v3 today or tomorrow, I can Cc you (and Jian-Hong) if > > > you > > > want. > > > > That would be great, although given the potentially inconsistent > > results we've been seeing so far it would be great if you could > > additionally push a git branch somewhere. > > That way we can have higher confidence that we are applying exactly > > the same patches to the same base etc. > > So I sent a new iteration yesterday, and of course forgot to cc you... Sorry > for > that. > > I've pushed my current branch here: > https://git.kernel.org/pub/scm/linux/kernel/git/mripard/linux.git/log/?h=rpi4-kms Thanks to Maxime! I have tried your repository on branch rpi4-kms. The DRM VC4 is used! But got some issues: 1. Some weird error message in dmesg. Not sure it is related, or not [5.219321] [drm:vc5_hdmi_init_resources] *ERROR* Failed to get HDMI state machine clock https://gist.github.com/starnight/3f317dca121065a361cf08e91225e389 2. The screen flashes suddenly sometimes. 3. The higher resolutions, like 1920x1080 ... are lost after hot re-plug HDMI cable (HDMI0) Jian-Hong Pan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Jian-Hong Pan 於 2020年5月8日 週五 下午2:20寫道： > > Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道： > > > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote: > > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > > > > > > > Hi, > > > > > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > > > > Hi Maxime, > > > > > > > > > > Thanks for your V2 patch series! I'm testing it. > > > > > > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and > > > > > built. > > > > > System can boot into console text mode, but no graphic UI. > > > > > > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > > > > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > > > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent > > > > > 'vc4-hdmi' already present! > > > > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> > > > > > fef00700.hdmi mapping ok > > > > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > > > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > > > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > > > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' > > > > > already present! > > > > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> > > > > > fef05700.hdmi mapping ok > > > > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > > > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > > > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > > > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > > > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > > > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops > > > > > vc4_crtc_ops) > > > > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 > > > > > ) > > > > > [5.589297] fb0: switching to vc4drmfb from simple > > > > > [5.589433] Console: switching to colour dummy device 80x25 > > > > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 > > > > > (21.10.2013). > > > > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > > > > [5.601079] [ cut here ] > > > > > [5.601095] WARNING: CPU: 2 PID: 127 at > > > > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > [5.601097] Modules linked in: > > > > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > > > > 5.7.0-rc2-00091-ga181df59a930 #7 > > > > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > > > > [5.601112] Workqueue: events deferred_probe_work_func > > > > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > > > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > > > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > > [5.601124] sp : 80001217b410 > > > > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > > > > [5.601129] x27: f650d400 x26: 8a50 > > > > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > > > > [5.601135] x23: 0a50 x22: 0300 > > > > > [5.601137] x21: 08d9ee20 x20: ec535080 > > > > > [5.601140] x19: 00010989e7c0 x18: > > > > > [5.601142] x17: 0001 x16: 5207 > > > > > [5.601145] x15: 4932ad29
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年5月8日 週五 上午1:22寫道： > > On Mon, May 04, 2020 at 02:35:08PM +0800, Jian-Hong Pan wrote: > > Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > > > > > Hi, > > > > > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > > > Hi Maxime, > > > > > > > > Thanks for your V2 patch series! I'm testing it. > > > > > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and > > > > built. > > > > System can boot into console text mode, but no graphic UI. > > > > > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent > > > > 'vc4-hdmi' already present! > > > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi > > > > mapping ok > > > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already > > > > present! > > > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi > > > > mapping ok > > > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops) > > > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 > > > > ) > > > > [5.589297] fb0: switching to vc4drmfb from simple > > > > [5.589433] Console: switching to colour dummy device 80x25 > > > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 > > > > (21.10.2013). > > > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > > > [5.601079] [ cut here ] > > > > [5.601095] WARNING: CPU: 2 PID: 127 at > > > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > > > [5.601097] Modules linked in: > > > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > > > 5.7.0-rc2-00091-ga181df59a930 #7 > > > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > > > [5.601112] Workqueue: events deferred_probe_work_func > > > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > > > [5.601124] sp : 80001217b410 > > > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > > > [5.601129] x27: f650d400 x26: 8a50 > > > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > > > [5.601135] x23: 0a50 x22: 0300 > > > > [5.601137] x21: 08d9ee20 x20: ec535080 > > > > [5.601140] x19: 00010989e7c0 x18: > > > > [5.601142] x17: 0001 x16: 5207 > > > > [5.601145] x15: 4932ad293c92 x14: 0137 > > > > [5.601147] x13: 800010015000 x12: 0001 > > > > [5.601150] x11: 0001 x10: > > > > [5.601152] x9 : x8 : 800010015038 > > > > [5.601154] x7 : 0001 x6 : 80001217b368 > > > > [5.601157] x5 : x4 : 004c > > > > [5.601159] x3 : x2 : 8000113b4ac0 > >
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
Maxime Ripard 於 2020年4月29日 週三 上午12:21寫道： > > Hi, > > On Mon, Apr 27, 2020 at 03:23:42PM +0800, Jian-Hong Pan wrote: > > Hi Maxime, > > > > Thanks for your V2 patch series! I'm testing it. > > > > This patch series is applied upon mainline kernel 5.7-rc2 cleanly and built. > > System can boot into console text mode, but no graphic UI. > > > > Get the error in vc5_hdmi_phy_init(), and full dmesg is at [1]: > > > > [5.587543] vc4_hdmi fef00700.hdmi: Unknown register ID 46 > > [5.587700] debugfs: Directory 'fef00700.hdmi' with parent 'vc4-hdmi' > > already present! > > [5.588070] vc4_hdmi fef00700.hdmi: vc4-hdmi-hifi <-> fef00700.hdmi > > mapping ok > > [5.588076] vc4_hdmi fef00700.hdmi: ASoC: no DMI vendor name! > > [5.588263] vc4-drm gpu: bound fef00700.hdmi (ops vc4_hdmi_ops) > > [5.588299] vc4_hdmi fef05700.hdmi: Unknown register ID 46 > > [5.588373] debugfs: Directory 'vc4-hdmi' with parent 'asoc' already > > present! > > [5.588673] vc4_hdmi fef05700.hdmi: vc4-hdmi-hifi <-> fef05700.hdmi > > mapping ok > > [5.588677] vc4_hdmi fef05700.hdmi: ASoC: no DMI vendor name! > > [5.588809] vc4-drm gpu: bound fef05700.hdmi (ops vc4_hdmi_ops) > > [5.588854] vc4-drm gpu: bound fe806000.vec (ops vc4_vec_ops) > > [5.588897] vc4-drm gpu: bound fe004000.txp (ops vc4_txp_ops) > > [5.588934] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops) > > [5.588990] vc4-drm gpu: bound fe206000.pixelvalve (ops vc4_crtc_ops) > > [5.589030] vc4-drm gpu: bound fe207000.pixelvalve (ops vc4_crtc_ops) > > [5.589074] vc4-drm gpu: bound fe20a000.pixelvalve (ops vc4_crtc_ops) > > [5.589106] vc4-drm gpu: bound fe216000.pixelvalve (ops vc4_crtc_ops) > > [5.589145] vc4-drm gpu: bound fec12000.pixelvalve (ops vc4_crtc_ops) > > [5.589294] checking generic (3e513000 6d8c00) vs hw (0 ) > > [5.589297] fb0: switching to vc4drmfb from simple > > [5.589433] Console: switching to colour dummy device 80x25 > > [5.589481] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). > > [5.589816] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0 > > [5.601079] [ cut here ] > > [5.601095] WARNING: CPU: 2 PID: 127 at > > drivers/gpu/drm/vc4/vc4_hdmi_phy.c:413 vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601097] Modules linked in: > > [5.601103] CPU: 2 PID: 127 Comm: kworker/2:1 Not tainted > > 5.7.0-rc2-00091-ga181df59a930 #7 > > [5.601105] Hardware name: Raspberry Pi 4 Model B (DT) > > [5.601112] Workqueue: events deferred_probe_work_func > > [5.601116] pstate: 2005 (nzCv daif -PAN -UAO) > > [5.601119] pc : vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601123] lr : vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601124] sp : 80001217b410 > > [5.601126] x29: 80001217b410 x28: ec6370f0 > > [5.601129] x27: f650d400 x26: 8a50 > > [5.601132] x25: 8000113b4ac0 x24: 2060 > > [5.601135] x23: 0a50 x22: 0300 > > [5.601137] x21: 08d9ee20 x20: ec535080 > > [5.601140] x19: 00010989e7c0 x18: > > [5.601142] x17: 0001 x16: 5207 > > [5.601145] x15: 4932ad293c92 x14: 0137 > > [5.601147] x13: 800010015000 x12: 0001 > > [5.601150] x11: 0001 x10: > > [5.601152] x9 : x8 : 800010015038 > > [5.601154] x7 : 0001 x6 : 80001217b368 > > [5.601157] x5 : x4 : 004c > > [5.601159] x3 : x2 : 8000113b4ac0 > > [5.601162] x1 : 8000120c5f44 x0 : dc8984ff > > [5.601164] Call trace: > > [5.601169] vc5_hdmi_phy_init+0x7ac/0x2078 > > [5.601172] vc4_hdmi_encoder_enable+0x1b8/0x1ac0 > > [5.601176] drm_atomic_helper_commit_modeset_enables+0x224/0x248 > > [5.601179] vc4_atomic_complete_commit+0x400/0x558 > > [5.601182] vc4_atomic_commit+0x1e0/0x200 > > [5.601185] drm_atomic_commit+0x4c/0x60 > > [5.601190] drm_client_modeset_commit_atomic.isra.0+0x17c/0x238 > > [5.601192] drm_client_modeset_commit_locked+0x5c/0x198 > > [5.601195] drm_client_modeset_commit+0x30/0x58 > > [5.601201] drm_fb_helper_restore_fbdev_mode_unlocked+0x78/0xe0 > > [5.601204] drm_fb_helper_set_par+0x30/0x68 > > [5.601208] fbcon_init+0x3d
[PATCH] drm/radeon: drm/amdgpu: Disable [1002:6611] in radeon
The AMD/ATI Oland [1002:6611]'s HDMI output status is not synchronous
as shown on UI after hot re-plug the HDMI cable, if it is radeon in
used. The amdgpu module does not hit this issue.
This patch disables [1002:6611] in radeon and enables it in amdgpu.
Fixes: https://gitlab.freedesktop.org/drm/amd/-/issues/1117
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 11 +++
include/drm/drm_pciids.h| 1 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 8ea86ffdea0d..1ad6f13a5bc0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1017,6 +1017,15 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static struct drm_driver kms_driver;
+static void amdgpu_pci_fixup(struct pci_dev *pdev)
+{
+#ifdef CONFIG_DRM_AMDGPU_SI
+ /* [1002:6611] is disabled in radeon, so enable si_support in amdgpu. */
+ if (pdev->vendor == PCI_VENDOR_ID_ATI && pdev->device == 0x6611)
+ amdgpu_si_support = 1;
+#endif
+}
+
static int amdgpu_pci_probe(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
@@ -1036,6 +1045,8 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
return -ENODEV;
}
+ amdgpu_pci_fixup(pdev);
+
#ifdef CONFIG_DRM_AMDGPU_SI
if (!amdgpu_si_support) {
switch (flags & AMD_ASIC_MASK) {
diff --git a/include/drm/drm_pciids.h b/include/drm/drm_pciids.h
index b7e899ce44f0..57368a0f5b82 100644
--- a/include/drm/drm_pciids.h
+++ b/include/drm/drm_pciids.h
@@ -171,7 +171,6 @@
{0x1002, 0x6607, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6608, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6610, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
- {0x1002, 0x6611, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6613, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6617, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
{0x1002, 0x6620, PCI_ANY_ID, PCI_ANY_ID, 0, 0,
CHIP_OLAND|RADEON_IS_MOBILITY|RADEON_NEW_MEMMAP}, \
--
2.26.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 00/91] drm/vc4: Support BCM2711 Display Pipelin
[5.601263] bus_for_each_drv+0x78/0xc8 [5.601265] __device_attach+0xe4/0x140 [5.601267] device_initial_probe+0x14/0x20 [5.601269] bus_probe_device+0x9c/0xa8 [5.601271] deferred_probe_work_func+0x74/0xb0 [5.601276] process_one_work+0x1bc/0x338 [5.601279] worker_thread+0x1f8/0x428 [5.601282] kthread+0x138/0x158 [5.601286] ret_from_fork+0x10/0x1c [5.601288] ---[ end trace cfba0996218c3f3d ]--- [1]: https://gist.github.com/starnight/2236cf350737e3b0e9f05135fc7c910e Jian-Hong Pan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 70/89] drm/vc4: hdmi: Remove vc4_dev hdmi pointer
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
> index 1e44a3a8c2b0..d5c832c99460 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.h
> +++ b/drivers/gpu/drm/vc4/vc4_drv.h
> @@ -73,7 +73,6 @@ struct vc4_perfmon {
> struct vc4_dev {
> struct drm_device *dev;
>
> - struct vc4_hdmi *hdmi;
Tested the building based on kernel v5.6-rc4 and linux-next/next-20200225.
The hdmi removed here still be used in drivers/gpu/drm/vc4/vc4_hdmi.c.
If DRM_VC4_HDMI_CEC is not disabled in building config, then it will hit
building error.
Jian-Hong Pan
> struct vc4_hvs *hvs;
> struct vc4_v3d *v3d;
> struct vc4_dpi *dpi;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/hdmi: enable resolution 3840x2160 for type 1 HDMI
Type 1 HDMI may be version 1.3 or upper, which supports higher max TMDS
clock for higher resolutions, like 3840x2160. This patch sets max TMDS
clock according to the chip, if the adapter is type 1 HDMI.
Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=112018
Fixes: b1ba124d8e95 ("drm/i915: Respect DP++ adaptor TMDS clock limit")
Signed-off-by: Jian-Hong Pan
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index e02f0faecf02..74e4426ffcad 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2454,6 +2454,7 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
+ struct intel_encoder *encoder = &hdmi_to_dig_port(hdmi)->base;
enum port port = hdmi_to_dig_port(hdmi)->base.port;
struct i2c_adapter *adapter =
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
@@ -2488,8 +2489,16 @@ intel_hdmi_dp_dual_mode_detect(struct drm_connector
*connector, bool has_edid)
return;
hdmi->dp_dual_mode.type = type;
- hdmi->dp_dual_mode.max_tmds_clock =
- drm_dp_dual_mode_max_tmds_clock(type, adapter);
+ /* Type 1 HDMI may be version 1.3 or upper, which supports higher max
+* TMDS clock for higher resolutions, like 3840x2160. So, set it
+* according to the chip, if the adapter is type 1 HDMI.
+*/
+ if (type == DRM_DP_DUAL_MODE_TYPE1_HDMI)
+ hdmi->dp_dual_mode.max_tmds_clock =
+ intel_hdmi_source_max_tmds_clock(encoder);
+ else
+ hdmi->dp_dual_mode.max_tmds_clock =
+ drm_dp_dual_mode_max_tmds_clock(type, adapter);
DRM_DEBUG_KMS("DP dual mode adaptor (%s) detected (max TMDS clock: %d
kHz)\n",
drm_dp_get_dual_mode_type_name(type),
--
2.23.0
[PATCH] i915: disable framebuffer compression on GeminiLake
From: Daniel Drake On many (all?) the Gemini Lake systems we work with, there is frequent momentary graphical corruption at the top of the screen, and it seems that disabling framebuffer compression can avoid this. The ticket was reported 6 months ago and has already affected a multitude of users, without any real progress being made. So, lets disable framebuffer compression on GeminiLake until a solution is found. Buglink: https://bugs.freedesktop.org/show_bug.cgi?id=108085 Signed-off-by: Daniel Drake Signed-off-by: Jian-Hong Pan --- drivers/gpu/drm/i915/intel_fbc.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c index 656e684e7c9a..fc018f3f53a1 100644 --- a/drivers/gpu/drm/i915/intel_fbc.c +++ b/drivers/gpu/drm/i915/intel_fbc.c @@ -1278,6 +1278,10 @@ static int intel_sanitize_fbc_option(struct drm_i915_private *dev_priv) if (!HAS_FBC(dev_priv)) return 0; + /* https://bugs.freedesktop.org/show_bug.cgi?id=108085 */ + if (IS_GEMINILAKE(dev_priv)) + return 0; + if (IS_BROADWELL(dev_priv) || INTEL_GEN(dev_priv) >= 9) return 1; -- 2.21.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
