> Am 02.02.2022 um 13:41 schrieb Paul Cercueil <p...@crapouillou.net>:
>
>
>
> Le mer., févr. 2 2022 at 13:33:15 +0100, H. Nikolaus Schaller
> <h...@goldelico.com> a écrit :
>>> Am 02.02.2022 um 13:28 schrieb Paul Cercueil <p...@crapouillou.net>:
>>> Le mer., févr. 2 2022 at 13:17:14 +0100, H. Nikolaus Schaller
>>> <h...@goldelico.com> a écrit :
>>>> Hi Paul,
>>>>> Am 02.02.2022 um 13:06 schrieb Paul Cercueil <p...@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
