Thread (9 messages) 9 messages, 2 authors, 2022-09-27

Re: [PATCH v3 1/4] drm/ofdrm: Add ofdrm for Open Firmware framebuffers

From: Thomas Zimmermann <tzimmermann@suse.de>
Date: 2022-09-23 07:41:28
Also in: dri-devel, linuxppc-dev

Hi Geert

Am 23.09.22 um 09:14 schrieb Geert Uytterhoeven:
Hi Thomas,

On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann [off-list ref] wrote:
quoted
Open Firmware provides basic display output via the 'display' node.
DT platform code already provides a device that represents the node's
framebuffer. Add a DRM driver for the device. The display mode and
color format is pre-initialized by the system's firmware. Runtime
modesetting via DRM is not possible. The display is useful during
early boot stages or as error fallback.

Similar functionality is already provided by fbdev's offb driver,
which is insufficient for modern userspace. The old driver includes
support for BootX device tree, which can be found on old 32-bit
PowerPC Macintosh systems. If these are still in use, the
functionality can be added to ofdrm or implemented in a new
driver. As with simpledrm, the fbdev driver cannot be selected if
ofdrm is already enabled.
Thanks for your patch!
quoted
The driver has been tested on qemu's ppc64le emulation. The device
hand-over has been tested with bochs.
Oh, tested on little-endian only ;-)
I wish it was easier to test. But it's hard to find hardware and a Linux 
for PowerPC these days, so I have limited options for testing. It's just 
qemu + a compatible distribution for me. My assumption has been that 
people who what to use it on anything else would send me a patch.
quoted
--- /dev/null
+++ b/drivers/gpu/drm/tiny/ofdrm.c
+static const struct drm_format_info *display_get_validated_format(struct drm_device *dev,
+                                                                 u32 depth)
+{
+       const struct drm_format_info *info;
+       u32 format;
+
+       switch (depth) {
+       case 8:
+               format = drm_mode_legacy_fb_format(8, 8);
+               break;
+       case 15:
+       case 16:
+               format = drm_mode_legacy_fb_format(16, depth);
+               break;
+       case 32:
+               format = drm_mode_legacy_fb_format(32, 24);
Shouldn't all of these use drm_driver_legacy_fb_format() (and the
driver set drm_mode_config.quirk_addfb_prefer_host_byte_order) to have
a chance of working on traditional big-endian PPC?
That's a good point. The offb driver reads the endianess property. Ofdrm 
could do this and set the quirk bit accordingly. I won't have the option 
to test it, but the code seems easy enough to add it. I'll make an extra 
patch for this in the next iteration.

Best regards
Thomas
Gr{oetje,eeting}s,

                         Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                 -- Linus Torvalds
-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help