From: Helge Deller <deller@gmx.de>
To: "Thomas Weißschuh" <linux@weissschuh.net>,
"Peter Jones" <pjones@redhat.com>,
"Daniel Vetter" <daniel@ffwll.ch>
Cc: linux-fbdev@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] fbdev/efifb: Use stack memory for screeninfo structs
Date: Wed, 28 Aug 2024 19:42:51 +0200 [thread overview]
Message-ID: <fef5bc70-3921-4562-b9d4-beccc76440a6@gmx.de> (raw)
In-Reply-To: <20240827-efifb-sysfs-v1-1-c9cc3e052180@weissschuh.net>
On 8/27/24 17:25, Thomas Weißschuh wrote:
> These variables are only used inside efifb_probe().
> Afterwards they are using memory unnecessarily.
Did you check if this change really saves some memory?
With your change, the compiler will either create a hidden
structure which it uses then, or it generates assembly
instructions to fill the struct at runtime.
Both options may not actually reduce the memory footprint...
Another option might be to mark the static struct __initdata
if you expect another card to take over before the memory is
freed at runtime. But I'm not sure if it's worth possible
implications.
Helge
> Signed-off-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> drivers/video/fbdev/efifb.c | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c
> index 8dd82afb3452..8bfe0ccbc67a 100644
> --- a/drivers/video/fbdev/efifb.c
> +++ b/drivers/video/fbdev/efifb.c
> @@ -52,24 +52,6 @@ struct efifb_par {
> resource_size_t size;
> };
>
> -static struct fb_var_screeninfo efifb_defined = {
> - .activate = FB_ACTIVATE_NOW,
> - .height = -1,
> - .width = -1,
> - .right_margin = 32,
> - .upper_margin = 16,
> - .lower_margin = 4,
> - .vsync_len = 4,
> - .vmode = FB_VMODE_NONINTERLACED,
> -};
> -
> -static struct fb_fix_screeninfo efifb_fix = {
> - .id = "EFI VGA",
> - .type = FB_TYPE_PACKED_PIXELS,
> - .accel = FB_ACCEL_NONE,
> - .visual = FB_VISUAL_TRUECOLOR,
> -};
> -
> static int efifb_setcolreg(unsigned regno, unsigned red, unsigned green,
> unsigned blue, unsigned transp,
> struct fb_info *info)
> @@ -357,6 +339,24 @@ static int efifb_probe(struct platform_device *dev)
> char *option = NULL;
> efi_memory_desc_t md;
>
> + struct fb_var_screeninfo efifb_defined = {
> + .activate = FB_ACTIVATE_NOW,
> + .height = -1,
> + .width = -1,
> + .right_margin = 32,
> + .upper_margin = 16,
> + .lower_margin = 4,
> + .vsync_len = 4,
> + .vmode = FB_VMODE_NONINTERLACED,
> + };
> +
> + struct fb_fix_screeninfo efifb_fix = {
> + .id = "EFI VGA",
> + .type = FB_TYPE_PACKED_PIXELS,
> + .accel = FB_ACCEL_NONE,
> + .visual = FB_VISUAL_TRUECOLOR,
> + };
> +
> /*
> * If we fail probing the device, the kernel might try a different
> * driver. We get a copy of the attached screen_info, so that we can
>
next prev parent reply other threads:[~2024-08-28 17:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-27 15:25 [PATCH 0/5] fbdev: devm_register_framebuffer() and some fixes for efifb Thomas Weißschuh
2024-08-27 15:25 ` [PATCH 1/5] fbdev/efifb: Use stack memory for screeninfo structs Thomas Weißschuh
2024-08-28 17:42 ` Helge Deller [this message]
2024-08-29 7:52 ` Thomas Weißschuh
2024-08-27 15:25 ` [PATCH 2/5] fbdev/efifb: Register sysfs groups through driver core Thomas Weißschuh
2024-08-28 17:50 ` Helge Deller
2024-08-27 15:25 ` [PATCH 3/5] fbdev: Introduce devm_register_framebuffer() Thomas Weißschuh
2024-08-30 7:17 ` Thomas Weißschuh
2024-08-30 8:25 ` Bert Karwatzki
2024-08-30 8:44 ` Helge Deller
2024-08-27 15:25 ` [PATCH 4/5] fbdev/efifb: Use devm_register_framebuffer() Thomas Weißschuh
2024-08-27 15:25 ` [PATCH 5/5] fbdev/efifb: Use driver-private screen_info for sysfs Thomas Weißschuh
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=fef5bc70-3921-4562-b9d4-beccc76440a6@gmx.de \
--to=deller@gmx.de \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=pjones@redhat.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox