Re: [PATCH 0/2] drm: xlnx: zynqmp_kms: 16 bpp fixes for Xorg startup on AMD KV260

[Thomas Zimmermann <tzimmermann@suse.de>]

Hi

Am 07.01.26 um 09:00 schrieb Mikko Rapeli:
> Hi,
>
> On Tue, Jan 06, 2026 at 10:29:37AM +0200, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 06/01/2026 09:41, Thomas Zimmermann wrote:
>>> Hi
>>>
>>> Am 22.12.25 um 09:58 schrieb Mikko Rapeli:
>>>> Hi,
>>>>
>>>> On Fri, Dec 19, 2025 at 02:30:11PM +0200, Mikko Rapeli wrote:
>>>>> On Fri, Dec 19, 2025 at 01:59:14PM +0200, Tomi Valkeinen wrote:
>>>>>> On 05/12/2025 14:37, Mikko Rapeli wrote:
>>>>>>> Currently on default yocto images Xorg fails to start on AMD KV260
>>>>>>> because 24/32 color depth gets detected but does not actually work.
>>>>>>>
>>>>>>> These two patches fix the issue and now 16 bpp gets detected
>>>>>>> and Xorg starts and draws on external HDMI display using
>>>>>>> kernel.org based linux-yocto kernel.
>>>>>>>
>>>>>>> Anatoliy Klymenko (1):
>>>>>>>     drm: xlnx: zynqmp_kms: Init fbdev with 16 bit color
>>>>>>>
>>>>>>> Mikko Rapeli (1):
>>>>>>>     drm: xlnx: zynqmp_kms: set preferred_depth to 16 bpp
>>>>>>>
>>>>>>>    drivers/gpu/drm/xlnx/zynqmp_kms.c | 3 ++-
>>>>>>>    1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>> Did you notice the few already sent serieses on the list where the
>>>>>> topic
>>>>>> has been discussed?
>>>>>> [PATCH] drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888
>>>>>> [PATCH 0/3] drm: zynqmp: Make the video plane primary
>>>>> Oh I wasn't aware of these.
>>>>>
>>>>>> Or is there something else on KV260 that messes up the 24 bit color?
>>>>> These look very similar and likely fix the X11 startup. I will give them
>>>>> a try.
>>>> Right, now I've tested:
>>>>
>>>>    * these patches from Anatoliy and me to help X11 use 16bpp mode by
>>>> default
>>>>      and removes the need to manually setup Xorg for 16bpp
>>>>    * "drm: xlnx: zynqmp_dp: Support DRM_FORMAT_XRGB8888" which enables
>>>> the X11 default
>>>>      24bpp to work, no need to set Xorg config to 16bpp
>>>>    * "drm: zynqmp: Make the video plane primary" which also fixes the
>>>> X11 default
>>>>      24bpp to work, no need to set Xorg config to 16bpp
>>>>
>>>> All of these fix HDMI graphics output on AMD KV260 board with yocto
>>>> genericarm64 machine
>>>> and core-image-sato image which includes Xorg. The graphics rendering
>>>> is still
>>>> very slow but I think that is a different problem.
>>>>
>>>> I guess the last series from Sean Anderson is moving forward so I'll
>>>> reply to that thread separately.
>>> Just want to say that the series here improves xlnx and makes it a
>>> 'better' driver. IMHO the changes should be merged independently from
>>> what happens with the other series.
>> I might be missing something, but I don't think I fully agree. Yes, the
>> userspace doesn't seem to be able to cope with the current upstream
>> driver behavior (even if it's not wrong as such, afaics), so in that
>> sense this series is better. But I don't think (almost) anyone really
>> wants to use RGB565 if XRGB8888 is an option? And that's what the other
>> series is trying to achieve, and that series conflicts with this one.
>>
>> So I'd rather try to get a conclusion on Sean's series (or the other one
>> from Mike). If that effort fails, we could go with this series as a backup.
> I did testing of all three different patch series'es on AMD KV260 and
> did not find any performance difference between them. The Xorg
> rendering is still very slow to an external HDMI display.
>
> I don't have an opinion on the graphics formats but just want something
> out to a display by default. I think there is a lot more to fix to get
> the performance into usable state.

I briefly looked through the xlnx driver and found several things to try.

* The update code in [1] appears to always update the whole buffer. 
Setting drm_plane_enable_fb_damage_clips() for the planes will enable 
damage handling. Then flushing only the damaged areas might improve 
performance.

* The driver could set drm_device.mode_config.prefer_shadow to make Xorg 
use a shadow buffer in user space. This often works for devices with 
discrete VRAM.  IDK if non-X compositors also benefit from this.

* If the hardware supports it, setting non-coherent DMA mappings could 
enable caching on the memory buffers. The driver would then have to 
enable damage clips and flush caches by itself where necessary.

Best regards
Thomas

[1] 
https://elixir.bootlin.com/linux/v6.18.3/source/drivers/gpu/drm/xlnx/zynqmp_disp.c#L1109

>
> Cheers,
>
> -Mikko

-- 
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)