All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Glass <sjg@chromium.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 20/22] x86: pci: Allow conditionally run VGA rom in S3
Date: Thu, 13 Apr 2017 07:32:46 -0600	[thread overview]
Message-ID: <CAPnjgZ0in2dFXmaEYWFMo=WUXBvs9SwAc-T0+u8iaK4UJCjqow@mail.gmail.com> (raw)
In-Reply-To: <CAEUhbmUzkdAp9sDeFXVaURBapMZ8G2VpS2xX5k41Ot6=30r_rw@mail.gmail.com>

Hi Bin,

On 13 April 2017 at 04:00, Bin Meng <bmeng.cn@gmail.com> wrote:
> Hi Simon,
>
> On Wed, Mar 22, 2017 at 4:07 AM, Simon Glass <sjg@chromium.org> wrote:
>> Hi,
>>
>> On 16 March 2017 at 08:26, Bin Meng <bmeng.cn@gmail.com> wrote:
>>> Introduce a new CONFIG_S3_VGA_ROM_RUN option so that U-Boot can
>>> bypass executing VGA roms in S3.
>>>
>>> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
>>> ---
>>>
>>>  arch/x86/Kconfig      | 12 ++++++++++++
>>>  drivers/pci/pci_rom.c | 14 ++++++++++++++
>>>  2 files changed, 26 insertions(+)
>>
>> Can this be handled at run-time, based on whether we have already run the ROM?
>>
>
> I am not sure if this is what you want:
>
> 1). If on previous cold boot, VGA ROM has been run. Then on next S3
> boot, VGA ROM should also be run.
> 2). If on previous cold boot, VGA ROM has not been run. Then on next
> S3 boot, VGA ROM should not be run.
>
> So this is actually controlled by the CONFIG_VIDEO_VESA driver. But
> this new Kconfig option aims to solve: even CONFIG_VIDEO_VESA driver
> is used in a normal boot, U-Boot can still bypass the driver probe
> (ROM execution) in an S3 boot to save some resume time.
>
>> At present, at least on ivybridge (non-FSP), the ROM execution happens
>> when the device comes up. So do we actually need to run the ROM in S3
>> Or can we do it later by re-probing the driver?

With ivybridge the ROM runs when the video driver starts up. If there
is no 'vidconsole' in stdout then this won't happen until someone
does:

setenv stdout vidconsole,serial

or similar. I am not sure if this is possible with FSP machines.

However in practice we are generally returning from sleep to Linux, not U-Boot.

Do we have a way to know whether the ROM needs to be run (i.e. it was
run before)?

Regards,
Simon

  reply	other threads:[~2017-04-13 13:32 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-16 14:26 [U-Boot] [PATCH 00/22] x86: Add ACPI S3 resume support Bin Meng
2017-03-16 14:26 ` [U-Boot] [PATCH 01/22] dm: rtc: Add 16-bit read/write support Bin Meng
2017-03-17  3:26   ` Simon Glass
2017-04-01  2:26     ` Bin Meng
2017-03-16 14:26 ` [U-Boot] [PATCH 02/22] x86: acpi: Add Kconfig option and header file for ACPI resume Bin Meng
2017-03-17  3:26   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 03/22] x86: baytrail: acpi: Add APIs for determining/clearing sleep state Bin Meng
2017-03-17  3:26   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 04/22] x86: Add post codes for OS resume Bin Meng
2017-03-17  3:26   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 05/22] x86: fsp: acpi: Pass different boot mode to FSP init Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 06/22] x86: Store and display previous sleep state Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 07/22] x86: baytrail: Conditionally report S3 in the ACPI table Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 08/22] x86: fsp: Mark memory used by U-Boot as reserved in the E820 table for S3 Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-04-12  8:14     ` Bin Meng
2017-03-16 14:26 ` [U-Boot] [PATCH 09/22] x86: acpi: Add wake up assembly stub Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 10/22] x86: acpi: Add one API to find OS wakeup vector Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 11/22] x86: acpi: Resume OS if resume vector is found Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-04-12  8:14     ` Bin Meng
2017-04-13 21:15       ` Simon Glass
2017-04-17  9:37       ` Stefan Roese
2017-04-24  3:38         ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 12/22] x86: Add an early CMOS access library Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-04-18  9:46     ` Bin Meng
2017-04-19  0:12       ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 13/22] x86: fsp: Save stack address to CMOS for next S3 boot Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-04-13  9:25     ` Bin Meng
2017-04-13 13:34       ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 14/22] x86: fsp: Mark the first 64K low memory as reserved Bin Meng
2017-03-21 20:06   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 15/22] x86: Adjust board_final_cleanup() order Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 16/22] x86: apci: Change PM1_CNT register access to RMW Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 17/22] x86: acpi: Make enter_acpi_mode() public Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 18/22] x86: acpi: Refactor acpi_resume() Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 19/22] x86: acpi: Turn on ACPI mode for S3 Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 20/22] x86: pci: Allow conditionally run VGA rom in S3 Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-04-13 10:00     ` Bin Meng
2017-04-13 13:32       ` Simon Glass [this message]
2017-03-16 14:26 ` [U-Boot] [PATCH 21/22] x86: minnowmax: Enable ACPI S3 resume Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-16 14:26 ` [U-Boot] [PATCH 22/22] x86: Document ACPI S3 support Bin Meng
2017-03-21 20:07   ` Simon Glass
2017-03-17  3:26 ` [U-Boot] [PATCH 00/22] x86: Add ACPI S3 resume support Simon Glass

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='CAPnjgZ0in2dFXmaEYWFMo=WUXBvs9SwAc-T0+u8iaK4UJCjqow@mail.gmail.com' \
    --to=sjg@chromium.org \
    --cc=u-boot@lists.denx.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.