From: Daniel Vetter <daniel@ffwll.ch> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, Thomas Zimmermann <tzimmermann@suse.de>, David Airlie <airlied@gmail.com>, Gerd Hoffmann <kraxel@redhat.com>, dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats Date: Wed, 23 Nov 2022 18:09:16 +0100 [thread overview] Message-ID: <CAKMK7uHuwytyoxh145D1oT6-G-a0m8fDtP=da9hrfRVy3MzcXg@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdVgqwHjm8Hxms04rg6YXiQacEwKiaRV80nNA_OM9mvZpA@mail.gmail.com> On Wed, 23 Nov 2022 at 18:05, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > On Wed, Nov 23, 2022 at 5:57 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Nov 23, 2022 at 05:43:10PM +0100, Geert Uytterhoeven wrote: > > > As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken > > > bigendian drivers"), drivers must set the > > > quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() > > > compat code work correctly on big-endian machines. > > > > > > While that works fine for big-endian XRGB8888 and ARGB8888, which are > > > mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it > > > does not work for big-endian XRGB1555 and RGB565, as the latter are not > > > listed in the format database. > > > > > > Fix this by adding the missing formats. Limit this to big-endian > > > platforms, as there is currently no need to support these formats on > > > little-endian platforms. > > > > > > Fixes: 6960e6da9cec3f66 ("drm: fix drm_mode_addfb() on big endian machines.") > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > > --- > > > v2: > > > - Use "DRM_FORMAT_foo | DRM_FORMAT_BIG_ENDIAN" instead of > > > "DRM_FORMAT_HOST_foo", > > > - Turn into a lone patch, as all other patches from series > > > https://lore.kernel.org/r/cover.1657300532.git.geert@linux-m68k.org > > > were applied to drm-misc/for-linux-next. > > > > --- a/drivers/gpu/drm/drm_fourcc.c > > > +++ b/drivers/gpu/drm/drm_fourcc.c > > > @@ -190,6 +190,10 @@ const struct drm_format_info *__drm_format_info(u32 format) > > > { .format = DRM_FORMAT_BGRA5551, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true }, > > > { .format = DRM_FORMAT_RGB565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_BGR565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > +#ifdef __BIG_ENDIAN > > > > Why do we need the #ifdef here? Iirc some hw has big endian flags in the > > scanout registers, so could supprt this unconditionally if there's no > > #ifdef around the format defines. Some drivers might then also want a > > DRM_FORMAT_FOO_BE define to simplify tables and stuff, but that's more a > > bikeshed. > > "Limit this to big-endian platforms, as there is currently no need > to support these formats on little-endian platforms." > > Will anyone make use of this? In theory, all of the 16-bpp formats > can have a big-endian counterpart. > > I seem to be the first one running into this ;-) It should make testing easier, at least for drivers that can be used on both be and le platforms. But also, we can fix that whenever someone actually asks for it, same that we can add the #define since the full flag version is a bit long. I'll apply the patch to drm-misc-next. -Daniel > > > > + { .format = DRM_FORMAT_XRGB1555 | DRM_FORMAT_BIG_ENDIAN, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > + { .format = DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > +#endif > > > { .format = DRM_FORMAT_RGB888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_BGR888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_XRGB8888, .depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Geert Uytterhoeven <geert@linux-m68k.org> Cc: linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org, linux-m68k@lists.linux-m68k.org, Thomas Zimmermann <tzimmermann@suse.de>, Gerd Hoffmann <kraxel@redhat.com> Subject: Re: [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats Date: Wed, 23 Nov 2022 18:09:16 +0100 [thread overview] Message-ID: <CAKMK7uHuwytyoxh145D1oT6-G-a0m8fDtP=da9hrfRVy3MzcXg@mail.gmail.com> (raw) In-Reply-To: <CAMuHMdVgqwHjm8Hxms04rg6YXiQacEwKiaRV80nNA_OM9mvZpA@mail.gmail.com> On Wed, 23 Nov 2022 at 18:05, Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Hi Daniel, > > On Wed, Nov 23, 2022 at 5:57 PM Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Nov 23, 2022 at 05:43:10PM +0100, Geert Uytterhoeven wrote: > > > As of commit eae06120f1974e1a ("drm: refuse ADDFB2 ioctl for broken > > > bigendian drivers"), drivers must set the > > > quirk_addfb_prefer_host_byte_order quirk to make the drm_mode_addfb() > > > compat code work correctly on big-endian machines. > > > > > > While that works fine for big-endian XRGB8888 and ARGB8888, which are > > > mapped to the existing little-endian BGRX8888 and BGRA8888 formats, it > > > does not work for big-endian XRGB1555 and RGB565, as the latter are not > > > listed in the format database. > > > > > > Fix this by adding the missing formats. Limit this to big-endian > > > platforms, as there is currently no need to support these formats on > > > little-endian platforms. > > > > > > Fixes: 6960e6da9cec3f66 ("drm: fix drm_mode_addfb() on big endian machines.") > > > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> > > > --- > > > v2: > > > - Use "DRM_FORMAT_foo | DRM_FORMAT_BIG_ENDIAN" instead of > > > "DRM_FORMAT_HOST_foo", > > > - Turn into a lone patch, as all other patches from series > > > https://lore.kernel.org/r/cover.1657300532.git.geert@linux-m68k.org > > > were applied to drm-misc/for-linux-next. > > > > --- a/drivers/gpu/drm/drm_fourcc.c > > > +++ b/drivers/gpu/drm/drm_fourcc.c > > > @@ -190,6 +190,10 @@ const struct drm_format_info *__drm_format_info(u32 format) > > > { .format = DRM_FORMAT_BGRA5551, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true }, > > > { .format = DRM_FORMAT_RGB565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_BGR565, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > +#ifdef __BIG_ENDIAN > > > > Why do we need the #ifdef here? Iirc some hw has big endian flags in the > > scanout registers, so could supprt this unconditionally if there's no > > #ifdef around the format defines. Some drivers might then also want a > > DRM_FORMAT_FOO_BE define to simplify tables and stuff, but that's more a > > bikeshed. > > "Limit this to big-endian platforms, as there is currently no need > to support these formats on little-endian platforms." > > Will anyone make use of this? In theory, all of the 16-bpp formats > can have a big-endian counterpart. > > I seem to be the first one running into this ;-) It should make testing easier, at least for drivers that can be used on both be and le platforms. But also, we can fix that whenever someone actually asks for it, same that we can add the #define since the full flag version is a bit long. I'll apply the patch to drm-misc-next. -Daniel > > > > + { .format = DRM_FORMAT_XRGB1555 | DRM_FORMAT_BIG_ENDIAN, .depth = 15, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > + { .format = DRM_FORMAT_RGB565 | DRM_FORMAT_BIG_ENDIAN, .depth = 16, .num_planes = 1, .cpp = { 2, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > +#endif > > > { .format = DRM_FORMAT_RGB888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_BGR888, .depth = 24, .num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1 }, > > > { .format = DRM_FORMAT_XRGB8888, .depth = 24, .num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1 }, > > 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 -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
next prev parent reply other threads:[~2022-11-23 17:10 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-11-23 16:43 [PATCH resend v2] drm/fourcc: Add missing big-endian XRGB1555 and RGB565 formats Geert Uytterhoeven 2022-11-23 16:43 ` Geert Uytterhoeven 2022-11-23 16:57 ` Daniel Vetter 2022-11-23 16:57 ` Daniel Vetter 2022-11-23 17:05 ` Geert Uytterhoeven 2022-11-23 17:05 ` Geert Uytterhoeven 2022-11-23 17:09 ` Daniel Vetter [this message] 2022-11-23 17:09 ` Daniel Vetter 2022-11-24 6:51 ` Gerd Hoffmann 2022-11-24 6:51 ` Gerd Hoffmann 2022-11-24 8:02 ` Geert Uytterhoeven 2022-11-24 8:02 ` Geert Uytterhoeven 2022-11-24 11:17 ` Gerd Hoffmann 2022-11-24 11:17 ` Gerd Hoffmann 2022-11-24 8:46 ` Thomas Zimmermann 2022-11-24 8:55 ` Geert Uytterhoeven 2022-11-24 8:55 ` Geert Uytterhoeven 2022-11-24 9:04 ` Daniel Vetter 2022-11-24 9:04 ` Daniel Vetter 2022-11-24 9:20 ` Thomas Zimmermann 2022-11-24 9:35 ` Geert Uytterhoeven 2022-11-24 9:35 ` Geert Uytterhoeven
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAKMK7uHuwytyoxh145D1oT6-G-a0m8fDtP=da9hrfRVy3MzcXg@mail.gmail.com' \ --to=daniel@ffwll.ch \ --cc=airlied@gmail.com \ --cc=dri-devel@lists.freedesktop.org \ --cc=geert@linux-m68k.org \ --cc=kraxel@redhat.com \ --cc=linux-fbdev@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-m68k@lists.linux-m68k.org \ --cc=maarten.lankhorst@linux.intel.com \ --cc=mripard@kernel.org \ --cc=tzimmermann@suse.de \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.