From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
pjones@redhat.com, deller@gmx.de, ardb@kernel.org
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH 1/8] video: Add helpers for decoding screen_info
Date: Mon, 29 Jan 2024 11:41:15 +0100 [thread overview]
Message-ID: <87wmrsv2us.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20240117125527.23324-2-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> The plain values as stored in struct screen_info need to be decoded
> before being used. Add helpers that decode the type of video output
> and the framebuffer I/O aperture.
>
> Old or non-x86 systems may not set the type of video directly, but
> only indicate the presence by storing 0x01 in orig_video_isVGA. The
> decoding logic in screen_info_video_type() takes this into account.
I always disliked how the orig_video_isVGA variable lost its meaning.
> It then follows similar code in vgacon's vgacon_startup() to detect
> the video type from the given values.
>
> A call to screen_info_resources() returns all known resources of the
> given screen_info. The resources' values have been taken from existing
> code in vgacon and vga16fb. These drivers can later be converted to
> use the new interfaces.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Thanks for doing this! It's quite useful to have these helpers, since as
you mention the screen_info data decoding is complex and the variables
used to store the video type and modes are confusing / misleading.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
I just have a few comments below:
> +static inline bool __screen_info_has_ega_gfx(unsigned int mode)
> +{
> + switch (mode) {
> + case 0x0d: /* 320x200-4 */
> + case 0x0e: /* 640x200-4 */
> + case 0x0f: /* 640x350-1 */
> + case 0x10: /* 640x350-4 */
I wonder if makes sense to define some constant macros for these modes? I
know that check_mode_supported() in drivers/video/fbdev/vga16fb.c also use
magic numbers but I believe that it could ease readability.
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static inline bool __screen_info_has_vga_gfx(unsigned int mode)
> +{
> + switch (mode) {
> + case 0x10: /* 640x480-1 */
> + case 0x12: /* 640x480-4 */
> + case 0x13: /* 320-200-8 */
> + case 0x6a: /* 800x600-4 (VESA) */
> + return true;
And same for these.
It can be a follow-up patch though.
[...]
> +int screen_info_resources(const struct screen_info *si, struct resource *r, size_t num)
> +{
> + struct resource *pos = r;
> + unsigned int type = screen_info_video_type(si);
> + u64 base, size;
> +
> + switch (type) {
> + case VIDEO_TYPE_MDA:
> + if (num > 0)
> + resource_init_io_named(pos++, 0x3b0, 12, "mda");
I see that drivers/video/fbdev/i740_reg.h has a #define MDA_BASE
0x3B0. Maybe move to a header in include/video along with the other
constants mentioned above ?
> + if (num > 1)
> + resource_init_io_named(pos++, 0x3bf, 0x01, "mda");
> + if (num > 2)
> + resource_init_mem_named(pos++, 0xb0000, 0x2000, "mda");
Same for these start addresses. I see that are also used by mdacon_startup()
in drivers/video/console/mdacon.c, so some constants defined somewhere might
be useful for that console driver too.
The comment also applies to all the other start addresses, since I see
that those are used by other drivers (i810, vgacon, etc).
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
WARNING: multiple messages have this Message-ID (diff)
From: Javier Martinez Canillas <javierm@redhat.com>
To: Thomas Zimmermann <tzimmermann@suse.de>,
pjones@redhat.com, deller@gmx.de, ardb@kernel.org
Cc: linux-fbdev@vger.kernel.org,
Thomas Zimmermann <tzimmermann@suse.de>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/8] video: Add helpers for decoding screen_info
Date: Mon, 29 Jan 2024 11:41:15 +0100 [thread overview]
Message-ID: <87wmrsv2us.fsf@minerva.mail-host-address-is-not-set> (raw)
In-Reply-To: <20240117125527.23324-2-tzimmermann@suse.de>
Thomas Zimmermann <tzimmermann@suse.de> writes:
Hello Thomas,
> The plain values as stored in struct screen_info need to be decoded
> before being used. Add helpers that decode the type of video output
> and the framebuffer I/O aperture.
>
> Old or non-x86 systems may not set the type of video directly, but
> only indicate the presence by storing 0x01 in orig_video_isVGA. The
> decoding logic in screen_info_video_type() takes this into account.
I always disliked how the orig_video_isVGA variable lost its meaning.
> It then follows similar code in vgacon's vgacon_startup() to detect
> the video type from the given values.
>
> A call to screen_info_resources() returns all known resources of the
> given screen_info. The resources' values have been taken from existing
> code in vgacon and vga16fb. These drivers can later be converted to
> use the new interfaces.
>
> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
> ---
Thanks for doing this! It's quite useful to have these helpers, since as
you mention the screen_info data decoding is complex and the variables
used to store the video type and modes are confusing / misleading.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
I just have a few comments below:
> +static inline bool __screen_info_has_ega_gfx(unsigned int mode)
> +{
> + switch (mode) {
> + case 0x0d: /* 320x200-4 */
> + case 0x0e: /* 640x200-4 */
> + case 0x0f: /* 640x350-1 */
> + case 0x10: /* 640x350-4 */
I wonder if makes sense to define some constant macros for these modes? I
know that check_mode_supported() in drivers/video/fbdev/vga16fb.c also use
magic numbers but I believe that it could ease readability.
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static inline bool __screen_info_has_vga_gfx(unsigned int mode)
> +{
> + switch (mode) {
> + case 0x10: /* 640x480-1 */
> + case 0x12: /* 640x480-4 */
> + case 0x13: /* 320-200-8 */
> + case 0x6a: /* 800x600-4 (VESA) */
> + return true;
And same for these.
It can be a follow-up patch though.
[...]
> +int screen_info_resources(const struct screen_info *si, struct resource *r, size_t num)
> +{
> + struct resource *pos = r;
> + unsigned int type = screen_info_video_type(si);
> + u64 base, size;
> +
> + switch (type) {
> + case VIDEO_TYPE_MDA:
> + if (num > 0)
> + resource_init_io_named(pos++, 0x3b0, 12, "mda");
I see that drivers/video/fbdev/i740_reg.h has a #define MDA_BASE
0x3B0. Maybe move to a header in include/video along with the other
constants mentioned above ?
> + if (num > 1)
> + resource_init_io_named(pos++, 0x3bf, 0x01, "mda");
> + if (num > 2)
> + resource_init_mem_named(pos++, 0xb0000, 0x2000, "mda");
Same for these start addresses. I see that are also used by mdacon_startup()
in drivers/video/console/mdacon.c, so some constants defined somewhere might
be useful for that console driver too.
The comment also applies to all the other start addresses, since I see
that those are used by other drivers (i810, vgacon, etc).
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
next prev parent reply other threads:[~2024-01-29 10:41 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-17 12:39 [PATCH 0/8] firmware/sysfb: Track parent device for screen_info Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-17 12:39 ` [PATCH 1/8] video: Add helpers for decoding screen_info Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 10:41 ` Javier Martinez Canillas [this message]
2024-01-29 10:41 ` Javier Martinez Canillas
2024-01-30 13:12 ` Thomas Zimmermann
2024-01-30 13:12 ` Thomas Zimmermann
2024-01-17 12:39 ` [PATCH 2/8] video: Provide screen_info_get_pci_dev() to find screen_info's PCI device Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:04 ` Javier Martinez Canillas
2024-01-29 11:04 ` Javier Martinez Canillas
2024-01-30 10:12 ` Thomas Zimmermann
2024-01-30 10:12 ` Thomas Zimmermann
2024-01-30 10:23 ` Javier Martinez Canillas
2024-01-30 10:23 ` Javier Martinez Canillas
2024-01-17 12:39 ` [PATCH 3/8] firmware/sysfb: Set firmware-framebuffer parent device Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:28 ` Javier Martinez Canillas
2024-01-29 11:28 ` Javier Martinez Canillas
2024-01-17 12:39 ` [PATCH 4/8] fbdev/efifb: Remove PM for " Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:30 ` Javier Martinez Canillas
2024-01-29 11:30 ` Javier Martinez Canillas
2024-01-17 12:39 ` [PATCH 5/8] firmware/sysfb: Create firmware device only for enabled PCI devices Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:36 ` Javier Martinez Canillas
2024-01-29 11:36 ` Javier Martinez Canillas
2024-01-30 12:52 ` Thomas Zimmermann
2024-01-30 12:52 ` Thomas Zimmermann
2024-01-17 12:39 ` [PATCH 6/8] fbdev/efifb: Do not track parent device status Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:38 ` Javier Martinez Canillas
2024-01-29 11:38 ` Javier Martinez Canillas
2024-01-17 12:39 ` [PATCH 7/8] firmware/sysfb: Update screen_info for relocated EFI framebuffers Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 11:52 ` Javier Martinez Canillas
2024-01-29 11:52 ` Javier Martinez Canillas
2024-01-29 12:03 ` Javier Martinez Canillas
2024-01-29 12:03 ` Javier Martinez Canillas
2024-01-17 12:39 ` [PATCH 8/8] fbdev/efifb: Remove framebuffer relocation tracking Thomas Zimmermann
2024-01-17 12:39 ` Thomas Zimmermann
2024-01-29 12:03 ` Javier Martinez Canillas
2024-01-29 12:03 ` Javier Martinez Canillas
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=87wmrsv2us.fsf@minerva.mail-host-address-is-not-set \
--to=javierm@redhat.com \
--cc=ardb@kernel.org \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=pjones@redhat.com \
--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: link
Be 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.