[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b70d5ddb-24ad-e1f5-8ef9-a486879d0c9e@suse.de>
Date: Sat, 29 Apr 2023 14:28:08 +0200
From: Thomas Zimmermann <tzimmermann@...e.de>
To: Sam Ravnborg <sam@...nborg.org>
Cc: linux-arch@...r.kernel.org, linux-fbdev@...r.kernel.org,
linux-ia64@...r.kernel.org, loongarch@...ts.linux.dev,
arnd@...db.de, deller@....de, chenhuacai@...nel.org,
javierm@...hat.com, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org,
James.Bottomley@...senpartnership.com,
linux-m68k@...ts.linux-m68k.org, geert@...ux-m68k.org,
linux-parisc@...r.kernel.org, vgupta@...nel.org,
sparclinux@...r.kernel.org, kernel@...0n.name,
linux-snps-arc@...ts.infradead.org, davem@...emloft.net,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O
functions
Hi Sam
Am 28.04.23 um 18:54 schrieb Sam Ravnborg:
> Hi Thomas,
>
> On Fri, Apr 28, 2023 at 04:18:38PM +0200, Thomas Zimmermann wrote:
>> I'd be happy to have fb_() wrappers that are I/O helpers without
>> ordering guarantees. I'd just wouldn't want them in <linux/fb.h>
>
> How about throwing them into a new drm_fb.h header file.
> This header file could be the home for all the fb stuff that is
> shared between drm and the legacy fbdev.
>
> Then we may slowly migrate more fbdev stuff to drm and let the legacy
> fbdev stuff use the maintained drm stuff.
> Dunno, the pain may not be worth it.
DRM might not be relevant if we can remove fb_mem*(). So I'd like to go
back to something closer to v1 of these patches. See my reply to Arnd.
Best regards
Thomas
>
> Sam
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
Download attachment "OpenPGP_signature" of type "application/pgp-signature" (841 bytes)
Powered by blists - more mailing lists