| Message ID | 20200925183654.723338620@rtp-net.org |
|---|---|
| Headers | show |
| Series | RFC: Pinebook pro EDP support | expand |
On 25/09/2020 21:36, Arnaud Patard (Rtp) wrote: > This patchset add support for the rk3399 edp. It has been tested on the pinebook > pro devices. The only missing part is a hack used to get stable edp output after > a warn reset, which is possibly specific to this device. I'm not sure if it's suitable > for merge. > > The changes have been written by studying the linux code, since I didn't find any > manual for theses part of the RK3399 SoC. > > On the linux kernel side, on recent kernels, it needs commit "pwm: rockchip: Keep enabled PWMs > running while probing" otherwise the pinebook pro will freeze when probing > the display. > > The kernel is also randomly failing to display something on my device. When this > occurs, the kernel has this following message: > rockchip-pm-domain ff310000.power-management:power-controller: failed to set idle on domain 'pd_vopl', val=0 > I've yet to find what's the issue. I've been trying to test your patches on a rk3399-gru-kevin with these patches and as a result I've posted some patches for cros_ec_pwm as a backlight [1], and have some yet-to-be-posted ones for kevin and bob because I don't truly know if they work [2]. (I don't even have the appropriate hardware to get a serial console / debug this board, thus the motivation to get the screen working). It should be possible for someone with a kevin or bob to tinker on my test branch and get more conclusive outcomes than I did, maybe even get everything fully working! [1] https://patchwork.ozlabs.org/project/uboot/list/?series=204353 [2] https://github.com/alpernebbi/u-boot/commits/rk3399-gru-kevin/wip Anyway, here's how it goes for me. I start from the Chrome OS firmware showing some white-background bitmap on the screen with the backlight enabled. I press CTRL+L to tell it to chainload my U-Boot build. I don't know if/how chainloading this way affects any of this. AFAICT, the firmware doesn't clear or turn off the backlight before doing so, because when VIDEO_ROCKCHIP_MAX_{X,Y}RES={3840,2160} the screen doesn't clear. I have to set {2400,1600} as it's the resolution of my panel. Maybe you should test this on Pinebook Pro as well, the defaults are {1920,1080} (same as its panel), but DISPLAY_ROCKCHIP_HDMI for example would change it. With those initial conditions I see the the screen progressively clearing to black then the backlight turns off after a while. I think the clearing part hints this patchset is at least doing something. I had also tried commenting out "enable-gpios" code in pwm_backlight.c (when I didn't really know how to turn it on properly), that results in the backlight turn on immediately after it turns off, where I see a small white artifact (?) on the mid-right part of the bottom of the screen, for a frame or so. Overall, I never see any content on the display and it's always black. Even unsetting CONFIG_SYS_WHITE_ON_BLACK doesn't change anything. Wish I could've been more helpful, but all this is as far as I could figure out right now.
Alper Nebi Yasak <alpernebiyasak@gmail.com> writes: Hi, > On 25/09/2020 21:36, Arnaud Patard (Rtp) wrote: >> This patchset add support for the rk3399 edp. It has been tested on the pinebook >> pro devices. The only missing part is a hack used to get stable edp output after >> a warn reset, which is possibly specific to this device. I'm not sure if it's suitable >> for merge. >> >> The changes have been written by studying the linux code, since I didn't find any >> manual for theses part of the RK3399 SoC. >> >> On the linux kernel side, on recent kernels, it needs commit "pwm: rockchip: Keep enabled PWMs >> running while probing" otherwise the pinebook pro will freeze when probing >> the display. >> >> The kernel is also randomly failing to display something on my device. When this >> occurs, the kernel has this following message: >> rockchip-pm-domain ff310000.power-management:power-controller: failed to set idle on domain 'pd_vopl', val=0 >> I've yet to find what's the issue. > > I've been trying to test your patches on a rk3399-gru-kevin with these > patches and as a result I've posted some patches for cros_ec_pwm as a > backlight [1], and have some yet-to-be-posted ones for kevin and bob > because I don't truly know if they work [2]. (I don't even have the > appropriate hardware to get a serial console / debug this board, thus > the motivation to get the screen working). > > It should be possible for someone with a kevin or bob to tinker on my > test branch and get more conclusive outcomes than I did, maybe even get > everything fully working! > > [1] https://patchwork.ozlabs.org/project/uboot/list/?series=204353 > [2] https://github.com/alpernebbi/u-boot/commits/rk3399-gru-kevin/wip > > > Anyway, here's how it goes for me. I start from the Chrome OS firmware > showing some white-background bitmap on the screen with the backlight > enabled. I press CTRL+L to tell it to chainload my U-Boot build. I don't > know if/how chainloading this way affects any of this. > > AFAICT, the firmware doesn't clear or turn off the backlight before > doing so, because when VIDEO_ROCKCHIP_MAX_{X,Y}RES={3840,2160} the > screen doesn't clear. I have to set {2400,1600} as it's the resolution > of my panel. Maybe you should test this on Pinebook Pro as well, the > defaults are {1920,1080} (same as its panel), but DISPLAY_ROCKCHIP_HDMI > for example would change it. Here, it's set to 1920x1080, and I have CONFIG_DISPLAY_ROCKCHIP_HDMI disabled, since there's no HDMI output on the PBP. Can you try with the screen size set to the one of your panel and disable the HDMI output ? I suspect it won't change anything, but worth trying. > > With those initial conditions I see the the screen progressively > clearing to black then the backlight turns off after a while. I think > the clearing part hints this patchset is at least doing something. I see that you've added the needed rockchip,panel properties, so it's possible it's related to the driver but I'm surprised that the blacklight turns off. iirc, the driver is only turning it on. > > I had also tried commenting out "enable-gpios" code in pwm_backlight.c > (when I didn't really know how to turn it on properly), that results in > the backlight turn on immediately after it turns off, where I see a > small white artifact (?) on the mid-right part of the bottom of the > screen, for a frame or so. > > Overall, I never see any content on the display and it's always black. > Even unsetting CONFIG_SYS_WHITE_ON_BLACK doesn't change anything. > > Wish I could've been more helpful, but all this is as far as I could > figure out right now. Some logs would be nice. If USB is working or if the laptop has ethernet, maybe you could try netconsole (doc/README.NetConsole) with CONSOLE_MUX. I've not used that for ages, but there's no reason for it to be broken. btw, I'm not sure what's the current practice in uboot m-l, but maybe we can go on debugging your issue off-list ? Arnaud
On 28/09/2020 09:41, Arnaud Patard (Rtp) wrote: > Here, it's set to 1920x1080, and I have CONFIG_DISPLAY_ROCKCHIP_HDMI > disabled, since there's no HDMI output on the PBP. Can you try with the > screen size set to the one of your panel and disable the HDMI output ? > I suspect it won't change anything, but worth trying. Disabling DISPLAY_ROCKCHIP_HDMI (and those other than EDP) didn't change anything with 2400x1600. (What I was saying is if someone in the future enables it on PBP, the eDP would likely break; but maybe that already happens with the existing code in non-rk3399 devices. A minor issue, though.) > I see that you've added the needed rockchip,panel properties, so it's > possible it's related to the driver but I'm surprised that the > blacklight turns off. iirc, the driver is only turning it on. FWIW, commenting out panel_enable_backlight() in rk_edp.c or adding a panel_set_backlight() after that call didn't get the backlight to stop turning off or get it turned on before my loop in board_late_init(). Weird. > Some logs would be nice. If USB is working or if the laptop has > ethernet, maybe you could try netconsole (doc/README.NetConsole) with > CONSOLE_MUX. I've not used that for ages, but there's no reason for it > to be broken. It doesn't have ethernet, I don't think USB works either -- assuming you mean I'd use a USB-to-Ethernet adapter. > btw, I'm not sure what's the current practice in uboot m-l, but maybe we > can go on debugging your issue off-list ? Sure. At least, I guess most of it would be spam-ish to the people already in Cc.