Most of the copies of the print_cpuinfo() call the default method.
Remove all of those in order to have only the default one when
no `cpu` command is compiled.

This also helps avoiding compiler warning, e.g.:

  arch/x86/cpu/tangier/tangier.c:23:5: warning: no previous prototype for ‘print_cpuinfo’ [-Wmissing-prototypes]

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

Use the new symbol to refer to any 'SPL' build, including TPL and VPL

Signed-off-by: Simon Glass <sjg@chromium.org>

This value is set by not used on x86 so there is no point in setting it.
Drop the assignment.

Signed-off-by: Simon Glass <sjg@chromium.org>

As part of bringing the master branch back in to next, we need to allow
for all of these changes to exist here.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay
Ethernet"' I failed to notice that b4 noticed it was based on next and
so took that as the base commit and merged that part of next to master.

This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing
changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35.

Reported-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Tom Rini <trini@konsulko.com>

Remove <common.h> from all x86 architecture files and when needed add
missing include files directly.

Signed-off-by: Tom Rini <trini@konsulko.com>

At present this uses mtrr_add_request() & mtrr_commit() combination
to program the MTRR for graphics memory. This usage has two major
issues as below:

- mtrr_commit() will re-initialize all MTRR registers from index 0,
  using the settings previously added by mtrr_add_request() and saved
  in gd->arch.mtrr_req[], which won't cause any issue but is unnecessary
- The way such combination works is based on the assumption that U-Boot
  has full control with MTRR programming (e.g.: U-Boot without any blob
  that does all low-level initialization on its own, or using FSP2 which
  does not touch MTRR), but this is not the case with FSP. FSP programs
  some MTRRs during its execution but U-Boot does not have the settings
  saved in gd->arch.mtrr_req[] and when doing mtrr_commit() it will
  corrupt what was already programmed previously.

Correct this to use mtrr_set_next_var() instead.

Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

The current vesa structure only provides a 32-bit value for the frame
buffer. Many modern machines use an address outside the range.

It is still useful to have this common struct, but add a separate
frame-buffer address as well.

Add a comment for vesa_setup_video_priv() while we are here.

Signed-off-by: Simon Glass <sjg@chromium.org>

Fix a typo in a comment.

Signed-off-by: Simon Glass <sjg@chromium.org>

This function calls rtc_write32, which has a different signature
depending on if (SPL_)DM_RTC is enabled or not. This could result in a
mismatch in SPL if DM_RTC was enabled but SPL_DM_RTC, as the non-DM
declaration would still be used in SPL even though the implementation
would be for non-DM_RTC. We are switching to the correct definitions in
the next commit, so this will become a compilation error. Since
fsp_save_s3_stack is not called from SPL, avoid compiling it if
(SPL_)DM_RTC is disabled.

Signed-off-by: Sean Anderson <sean.anderson@seco.com>