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

[Thomas Zimmermann]

Hi

Am 23.09.22 um 09:14 schrieb Geert Uytterhoeven:
> Hi Thomas,
> 
> On Thu, Sep 22, 2022 at 1:33 PM Thomas Zimmermann <tzimmermann at suse.de> 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?

Big thanks to Michal Suchanek, who pointed me to a Tumbleweed installer 
for big-endian PPC64. I've added code to support BE scanout buffers. 
I'll add the patch to the next iteration. But Userspace isn't really 
ready yet. Pixman mostly works on my test system, but GL rendering 
displays incorrect colors.

Best regards
Thomas

> 
> Gr{oetje,eeting}s,
> 
>                          Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20220927/a2ad5852/attachment.sig>