Hi Thomas, On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann <tzimmermann@xxxxxxx> wrote: > 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! > 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 ;-) > --- /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? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx 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