> Am 02.02.2022 um 13:41 schrieb Paul Cercueil <paul@xxxxxxxxxxxxxxx>: > > > > 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. 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
