[patch 0/8] RFC: Pinebook pro EDP support

[Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>]

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