Thread (81 messages) 81 messages, 7 authors, 2022-04-25

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

From: Sascha Hauer <s.hauer@pengutronix.de>
Date: 2022-03-30 10:20:56
Also in: dri-devel, linux-arm-kernel, linux-rockchip

On Wed, Mar 30, 2022 at 12:01:05PM +0200, piotro.oniszczuk@google.com wrote:
quoted
Wiadomość napisana przez Sascha Hauer [off-list ref] w dniu 30.03.2022, o godz. 11:45:

On Wed, Mar 30, 2022 at 10:41:56AM +0200, piotro.oniszczuk@google.com wrote:

Let me rephrase this: The above sets a plane, but it doesn't set a mode
on the crtc. When my system boots up then the output of modetest looks
like this:

Encoders:
id      crtc    type    possible crtcs  possible clones
68      0       TMDS    0x00000001      0x00000001
Connectors:
id      encoder status          name            size (mm)       modes  encoders
69      0       connected       HDMI-A-1        530x300         9      68
CRTCs:
id      fb      pos     size
67      0       (0,0)   (0x0)
 #0  nan 0 0 0 0 0 0 0 0 0 flags: ; type: 

No mode is set on the CRTC and the encoder/connector/crtc are not bound
to each other, consequently the screen is in standby. "modetest -P
43@67:1920x1080@NV12" doesn't change this, still no mode set. Hence my
question: How did you set a mode initially?
Ah ok. I see your point.
mode is set by app (player). 

Sequence was like this:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)
quoted
quoted
quoted
I'm not sure that above command only sets plane.
On other SoCs i’m testing it gives expected results: diagonal colored stripes.
There is single exception: rk356x with vop2 - where screen is green unless i „fix/enable” by playing with plane #69   
quoted
I did with "modetest -s 69@67:1920x1080 -d" and with this it works as
expected, I can't reproduce any green screen issue here.
I see you are using plane #69.
Why not #43?
I used "modetest -s 69@67:1920x1080 -d" to set a mode. The '69' is the
connector id, not a plane.
ack.
typo from my side.

it was
modetest -P 49@67:1920x1080@NV12

quoted
quoted
Is plane #43 working ok for you?
Yes.
So it looks your testing method of #43 is not meaningful for verifying issue we are discussing here.

In my case:
12 SOC (except rk356x VOP2) gives me:
-boot board
-start app
-on UI select playback
-playback is ok
-exit app
-run modetest -P XX@YY:1920x1080@NV12 (diagonal stripes)

(XX/YY are plane/connector elected by app: plane@conector with format matching provider format) 

rk356x with vop2 v9:
-boot board
-start app
-on UI select playback
-playback has green screen
-exit app
-run modetest -P 43@67:1920x1080@NV12 (the same green screen like in playback)
-run modetest -P 49@67:1920x1080@NV12 (works ok)
-run modetest -P 43@67:1920x1080@NV12 (now works ok)
Does it change anything if you do a "modetest -s 69@67:1920x1080" before
starting the app? Or if you run "modetest -P 43@67:1920x1080@NV12"
before starting the app? Or other combinations thereof?

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help