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

Thomas Zimmermann tzimmermann at suse.de
Fri Sep 23 17:41:19 AEST 2022


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 <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 ;-)

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.

> 
>> --- /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 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/20220923/22deaeff/attachment.sig>


More information about the Linuxppc-dev mailing list