All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org,
	dri-devel@lists.freedesktop.org,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
Date: Tue, 13 Feb 2018 15:27:26 +0200	[thread overview]
Message-ID: <20180213132726.GD5453@intel.com> (raw)
In-Reply-To: <20180213085030.kiksdi2a7ksae5wz@pali>

On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote:
> On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote:
> > Hi! I'm periodically getting following message in dmesg on Lenovo
> > Thinkpad X1 Carbon 3rd generation:
> > 
> > [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
> > 
> > In BIOS I already set GPU size to 512M, but this did not help. Also
> > update to last BIOS version did not help.
> > 
> > So why this message is periodically print in dmesg? And what can I do
> > with this problem?
> > 
> > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
> > can/could do that)? Is not 512MB for GPU enough?
> 
> And here is output from lspci, which clearly says that 512MB is already
> set for GPU:

The PCI BAR size has nothing to do with the size of the stolen memory.
The BAR just provides a window into the global GTT address space of the
GPU. Stolen memory is a contiguous chunk of physical memory carved out
by the BIOS. The BIOS may or may not provide a knob to change the size
of the stolen memory.

> 
> $ lspci -v -s 00:02.0
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
>         Subsystem: Lenovo HD Graphics 5500
>         Flags: bus master, fast devsel, latency 0, IRQ 46
>         Memory at e0000000 (64-bit, non-prefetchable) [size=16M]
>         Memory at c0000000 (64-bit, prefetchable) [size=512M]
>         I/O ports at 3000 [size=64]
>         [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>         Capabilities: [d0] Power Management version 2
>         Capabilities: [a4] PCI Advanced Features
>         Kernel driver in use: i915
>         Kernel modules: i915
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: "Pali Rohár" <pali.rohar@gmail.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>,
	David Airlie <airlied@linux.ie>,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-kernel@vger.kernel.org
Subject: Re: Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size
Date: Tue, 13 Feb 2018 15:27:26 +0200	[thread overview]
Message-ID: <20180213132726.GD5453@intel.com> (raw)
In-Reply-To: <20180213085030.kiksdi2a7ksae5wz@pali>

On Tue, Feb 13, 2018 at 09:50:30AM +0100, Pali Rohár wrote:
> On Tuesday 06 February 2018 16:21:43 Pali Rohár wrote:
> > Hi! I'm periodically getting following message in dmesg on Lenovo
> > Thinkpad X1 Carbon 3rd generation:
> > 
> > [drm] Reducing the compressed framebuffer size. This may lead to less power savings than a non-reduced-size. Try to increase stolen memory size if available in BIOS.
> > 
> > In BIOS I already set GPU size to 512M, but this did not help. Also
> > update to last BIOS version did not help.
> > 
> > So why this message is periodically print in dmesg? And what can I do
> > with this problem?
> > 
> > And why cannot Linux kernel allocate itself more memory for GPU (if BIOS
> > can/could do that)? Is not 512MB for GPU enough?
> 
> And here is output from lspci, which clearly says that 512MB is already
> set for GPU:

The PCI BAR size has nothing to do with the size of the stolen memory.
The BAR just provides a window into the global GTT address space of the
GPU. Stolen memory is a contiguous chunk of physical memory carved out
by the BIOS. The BIOS may or may not provide a knob to change the size
of the stolen memory.

> 
> $ lspci -v -s 00:02.0
> 00:02.0 VGA compatible controller: Intel Corporation HD Graphics 5500 (rev 09) (prog-if 00 [VGA controller])
>         Subsystem: Lenovo HD Graphics 5500
>         Flags: bus master, fast devsel, latency 0, IRQ 46
>         Memory at e0000000 (64-bit, non-prefetchable) [size=16M]
>         Memory at c0000000 (64-bit, prefetchable) [size=512M]
>         I/O ports at 3000 [size=64]
>         [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
>         Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
>         Capabilities: [d0] Power Management version 2
>         Capabilities: [a4] PCI Advanced Features
>         Kernel driver in use: i915
>         Kernel modules: i915
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Ville Syrjälä
Intel OTC

  reply	other threads:[~2018-02-13 13:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-06 15:21 Thinkpad X1 Carbon 3rd - Reducing the compressed framebuffer size Pali Rohár
2018-02-06 15:21 ` Pali Rohár
2018-02-13  8:50 ` Pali Rohár
2018-02-13  8:50   ` Pali Rohár
2018-02-13 13:27   ` Ville Syrjälä [this message]
2018-02-13 13:27     ` Ville Syrjälä
2018-02-13 13:38     ` Pali Rohár
2018-02-13 13:38       ` Pali Rohár
2018-02-13 15:36       ` Ville Syrjälä
2018-02-13 16:04         ` Pali Rohár
2018-02-13 16:04           ` Pali Rohár
2018-02-13 16:12           ` Ville Syrjälä
2018-02-13 16:12             ` Ville Syrjälä
2018-02-13 17:43             ` Pali Rohár
2018-02-13 17:45               ` Ville Syrjälä
2018-02-13 17:45                 ` Ville Syrjälä
2018-02-19  9:36                 ` Pali Rohár
2018-02-19  9:36                   ` Pali Rohár
2018-02-21 13:28                   ` Ville Syrjälä
2018-02-21 13:28                     ` Ville Syrjälä
2018-02-21 13:34                     ` Pali Rohár
2018-02-21 13:34                       ` Pali Rohár

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=20180213132726.GD5453@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=airlied@linux.ie \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pali.rohar@gmail.com \
    --cc=rodrigo.vivi@intel.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 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.