Am 02.02.2022 um 13:41 schrieb Paul Cercueil paul@crapouillou.net:
Le mer., févr. 2 2022 at 13:33:15 +0100, H. Nikolaus Schaller hns@goldelico.com a écrit :
Am 02.02.2022 um 13:28 schrieb Paul Cercueil paul@crapouillou.net: Le mer., févr. 2 2022 at 13:17:14 +0100, H. Nikolaus Schaller hns@goldelico.com a écrit :
Hi Paul,
Am 02.02.2022 um 13:06 schrieb Paul Cercueil paul@crapouillou.net: 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.
Hm. What I don't get is why the jz4780 doesn't support that equally well with existing code? To me it looks mainly like an extended jz4740. But I have to admit that I did not study this deeply.
I am happy with a working desktop HDMI setup...
BR, Nikolaus