Le mer., févr. 2 2022 at 13:33:15 +0100, H. Nikolaus Schaller
<hns@xxxxxxxxxxxxx> a écrit :
Am 02.02.2022 um 13:28 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>:
Le mer., févr. 2 2022 at 13:17:14 +0100, H. Nikolaus Schaller
<hns@xxxxxxxxxxxxx> a écrit :
Hi Paul,
Am 02.02.2022 um 13:06 schrieb Paul Cercueil
<paul@xxxxxxxxxxxxxxx>:
Hi Nikolaus,
@@ -446,6 +454,9 @@ static int
ingenic_drm_plane_atomic_check(struct drm_plane *plane,
if (!crtc)
return 0;
+ if (plane == &priv->f0)
+ return -EINVAL;
This will break JZ4725B -> JZ4770 SoCs, the f0 plane is
perfectly usable there.
Hm. I think it was your request/proposal to add this [1]?
Because otherwise with your current patchset the f0 plane does
not work *on JZ4780*.
Not that I am eager to fix that, but...
maybe it could be better to fix than having the check and -EINVAL
depend on SoC compatible string
(or some new flag in soc_info. plane_f0_not_working)?
Totally agree! A proper fix would be much better. A
"plane_f0_not_working" in the meantime is OK with me.
Ok, then I'll prepare a v13 with plane_f0_not_working.
Note that there are other things not working with your current
implementation, for instance you cannot set the X/Y start position
of the f1 plane, which means it's only really usable for fullscreen
desktop/windows.
Is setting x/y possible for the other SoC?
Yes. They support different x/y positions, sizes, and pixel format for
both f0, f1 and IPU planes.
-Paul
It does work on older SoCs.
What I have forgotten is why the f0 plane should not be usable
for jz4780.
We return an error here to prevent userspace from using the f0
plane until it's effectively working on the JZ4780.
Well, what would be not working with that plane if user-space
would try to use it?
From what I remember, it wouldn't show anything on screen, and
after that trying to use the f1 plane wouldn't work either.
Ok. That may become a big project to fix. So let's do step 1 first.
BR and thanks,
NIkolaus
