[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230428165412.GA4010212@ravnborg.org>
Date: Fri, 28 Apr 2023 18:54:12 +0200
From: Sam Ravnborg <sam@...nborg.org>
To: Thomas Zimmermann <tzimmermann@...e.de>
Cc: deller@....de, geert@...ux-m68k.org, javierm@...hat.com,
daniel@...ll.ch, vgupta@...nel.org, chenhuacai@...nel.org,
kernel@...0n.name, davem@...emloft.net,
James.Bottomley@...senpartnership.com, arnd@...db.de,
linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
linux-arch@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
sparclinux@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-parisc@...r.kernel.org
Subject: Re: [PATCH v2 5/5] fbdev: Define framebuffer I/O from Linux' I/O
functions
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.
Sam
Powered by blists - more mailing lists