| Age | Commit message (Collapse) | Author |
|---|
|
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: Bad function definition - void init_timer() should probably be void init_timer(void)
ERROR: Prefixing 0x with decimal output is defective
WARNING: Comparisons should place the constant on the right side of the test
WARNING: char * array declaration might be better as static const
TEST=Build and run on Galileo Gen2
Change-Id: I9f618eea95e1f92fa34f4f89da27c0b16ae7f4ee
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18763
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix the following errors detected by checkpatch.pl:
ERROR: open brace '{' following function declarations go on the next
line
ERROR: that open brace { should be on the previous line
ERROR: open brace '{' following struct go on the same line
ERROR: else should follow close brace '}'
TEST=Build and run on Galileo Gen2
Change-Id: I971ada9ba9ba7ce5d8029323710fee1a6166570b
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18759
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: line over 80 characters
TEST=Build and run on Galileo Gen2
Change-Id: I5fa3f8e950e2f0c60bd0e8f030342dc8c0469299
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18758
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: spaces required around that '?' (ctx:WxV)
ERROR: spaces required around that '=' (ctx:VxV)
ERROR: spaces required around that '<' (ctx:VxV)
ERROR: spaces required around that '+=' (ctx:VxV)
ERROR: space required after that ',' (ctx:VxV)
ERROR: space required before the open brace '{'
ERROR: space required after that close brace '}'
ERROR: need consistent spacing around '+' (ctx:WxV)
ERROR: need consistent spacing around '*' (ctx:WxV)
ERROR: need consistent spacing around '&' (ctx:VxW)
ERROR: spaces required around that '?' (ctx:VxW)
ERROR: spaces required around that ':' (ctx:VxW)
ERROR: trailing whitespace
ERROR: space prohibited before that '++' (ctx:WxO)
ERROR: space prohibited before that ',' (ctx:WxW)
ERROR: space prohibited after that '!' (ctx:BxW)
ERROR: spaces prohibited around that '->' (ctx:VxW)
ERROR: space prohibited after that '-' (ctx:WxW)
WARNING: space prohibited before semicolon
WARNING: unnecessary whitespace before a quoted newline
WARNING: missing space after return type
Note that lib/libgcov.c and lib/lzmadecode.c are providing false
positives for ERROR: need consistent spacing around '*' (ctx:WxV)
An example is:
void __gcov_merge_add(gcov_type *counters __attribute__ ((unused)),
unsigned int n_counters __attribute__ ((unused))) {}
TEST=Build and run on Galileo Gen2
Change-Id: I0016327a5754018eaeb25bedf42338291632c7c1
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18733
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following errors and warnings detected by checkpatch.pl:
ERROR: code indent should use tabs where possible
ERROR: switch and case should be at the same indent
WARNING: Statements should start on a tabstop
WARNING: please, no spaces at the start of a line
WARNING: please, no space before tabs
WARNING: suspect code indent for conditional statements
WARNING: labels should not be indented
TEST=Build and run on Galileo Gen2
Change-Id: Iebcff26ad41ab6eb0027b871a1c06f3b52dd207c
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18732
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: trailing statements should be on next line
The remaining error is a false positive in libgcov.c where the if
statement spans several lines with conditional compilation directives
intertwined.
TEST=Build and run on Galileo Gen2
Change-Id: I37fcef78e9323340bac1367ae1c5fde334f5ce10
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18730
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Fix the following error detected by checkpatch.pl:
ERROR: space required before the open parenthesis '('
TEST=Build and run on Galileo Gen2
Change-Id: I8953fecbe75136ff989c9e3cf6c5e155dcee3c3b
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18698
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
|
|
Fix the following warning detected by checkpatch.pl:
WARNING: braces {} are not necessary for single statement blocks
TEST=Build and run on Galileo Gen2
Change-Id: Ie4b41f6fb75142ddd75103a55e0347ed85e7e873
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18697
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Tested-by: build bot (Jenkins)
|
|
Change-Id: Id69cecb5cdd21c2d92aca74658f39c790f7b7b01
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/15211
Tested-by: build bot (Jenkins)
|
|
Our EDID code had always been aligning the framebuffer's
bytes_per_line (and x_resolution dependent on that) to 64. It turns out
that this is a controller-dependent parameter that seems to only really
be necessary for Intel chipsets, and commit 6911219cc (edid: Add helper
function to calculate bits-per-pixel dependent values) probably actually
broke this for some other controllers by applying the alignment too
widely.
This patch makes it explicitly configurable and depends the default on
ARCH_X86 (which seems to be the simplest and least intrusive way to make
it fit most cases for now... boards where this doesn't apply can still
override it manually by calling edid_set_framebuffer_bits_per_pixel()
again).
Change-Id: I1c565a72826fc5ddfbb1ae4a5db5e9063b761455
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14267
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Coreboot and most payloads support three basic pixel widths for the
framebuffer. It assumes 32 by default, but several chipsets need to
override that value with whatever else they're supporting. Our struct
edid contains multiple convenience values that are directly derived from
this (and other properties), so changing the bits per pixel always
requires recalculating all those dependents in the chipset code. This
patch provides a small convenience wrapper that can be used to
consistently update the whole struct edid with a new pixel width
instead, so we no longer need to duplicate those calculations
everywhere.
BUG=None
TEST=Booted Oak in all three pixel widths (which it conveniently all
supports), confirmed that images looked good.
Change-Id: I5376dd4e28cf107ac2fba1dc418f5e1c5a2e2de6
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/14158
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The EDID parsing code continued to update _some_ fields of the output
edid but not others if "did_detailed_timing" was already set. It also
then went on to print out this halfway mix of modes each time, despite
the fact that it didn't really update everything.
Let's fix that. We'll reduce code changes by using a temporary copy of
data in detailed_block() and then we'll copy it back if we decide we
should update.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=No more bogus printouts
Change-Id: Idbfa233e0997244c22ef21c892c4473a91621821
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4d69999cdd7ce3cd2c9332ab3f22ea8eb4b6f2e9
Original-Change-Id: Ia72cac7fda2772f26477e43237678fa30feca584
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309541
Original-Reviewed-on: https://chromium-review.googlesource.com/309609
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12444
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The hardcoded clock value for 640x480 was 25.175 MHz. That's a valid
clock to use, but is quite hard to make a non-jittery clock from PLLs.
It's much easier to make 25.200 MHz, so let's do that.
The difference between the two modes is 59.9 Hz vs. 60 Hz and it seems
better to make a non-jittery 60 Hz rather than a very jittery 59.9 Hz.
BRANCH=none
BUG=chrome-os-partner:46256
TEST=Insignia monitor works, so do others
Change-Id: I8aa124d04a90f5dcf9cfa923ed3b693fbb4a06d8
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e32ce13462101dc60cfed60b6948b7597e93525a
Original-Change-Id: Ia9804afe8011a915e4bec306e863d34ad7e27be5
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309540
Original-Reviewed-by: Stphane Marchesin <marcheu@chromium.org>
Original-(cherry picked from commit 7f32c9f460991e5e3b947117d6ae4080e630a532)
Original-Reviewed-on: https://chromium-review.googlesource.com/309576
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12443
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The set to say that a standard timing was supported was not properly in
the "if" test. That meant that even when standard timings weren't
supported, we thought that they were. That had the side effect of never
using the detailed mode.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Adafruit panel works now
Change-Id: Ide3ed6c5682840f808d854755dac58e9057e6bda
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: c99d3ee8d163fc6be207c5a7df2a7aecd7af7849
Original-Change-Id: Ib67735219fd28516857d9b63f1ba156573f1bea3
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309521
Original-(cherry picked from commit 4e4c2816e2239299bc02e3a57fb18056db62b56c)
Original-Reviewed-on: https://chromium-review.googlesource.com/309552
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12442
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
The detailed_cvt_descriptor() function takes a parameter "out" for no
good reason. Remove it.
BRANCH=none
BUG=chrome-os-partner:46998
TEST=Build and boot
Change-Id: I1042dba9ddf2b4b543bd07615013088be5055950
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5c3474c9b1f9fb73f44d64d3a0592f92339da2df
Original-Change-Id: I4d695a6dba6606d2132578ce0ab4cb612c83d0f4
Original-Signed-off-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/309598
Original-(cherry picked from commit 39122e242e808d71a4e274e8a23e9a63f4984388)
Original-Reviewed-on: https://chromium-review.googlesource.com/309496
Original-Commit-Ready: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/12441
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
HDMI driver need to know whether the monitor is DVI
or HDMI interface, so this commit just introduce a
new number 'hdmi_monitor_detected' to struct edid.
There were four bits to indicate the monitor interfaces,
it's better to take use of that. But those bits only
existed in EDID 1.4 version, but didn't persented in
the previous EDID version, so I decided to detect the
hdmi cea block.
BRANCH=none
BUG=chrome-os-partner:43789
TEST=When mickey connect with HDMI monitor, see 'hdmi_monitor_detected' is 'true'.
When mickey connect with DVI monitor, see 'hdmi_monitor_detected' is 'false'.
Change-Id: I1a4f1410e1cce1474ffae858db161a18578cac3a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 409f041805d9fdff2d49faa1a3a262cf4dc609c2
Original-Change-Id: Ife770898b0f2b4f58b8259711101a0cab4a5e4ac
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/309055
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/12345
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Based on the info by Felix Held.
Change-Id: Iab84dd8a0e3c942da20a6e21db5510e4ad16cadd
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/11857
Tested-by: build bot (Jenkins)
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
|
|
BRANCH=None
BUG=chrome-os-partner:43789
TEST=Mickey board, 640x480@60Hz display normally
Change-Id: Iea298302fe1124edbef157d1d81c12610402e9c7
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 0209422efe52c45cab3c0d787b27352f63578e76
Original-Change-Id: Idf4c8cd9f2da3c5daa589973d831a506ff549b8b
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/293994
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11397
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch will let you to choose a favourite mode to
display, while not just taking the edid detail timing.
But not all modes are able to set, only modes that
are in established or standard timing, and we only
support a few common common resolutions for now.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=tested dev mode on Mickey at 640x480@60Hz
Change-Id: I8a9dedfe08057d42d85b8ca129935a258cb26762
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: 090583f90ff720d88e5cfe69fcb2d541c716f0e6
Original-Change-Id: Iaa8c9a6fad106ee792f7cd1a0ac77e3dcbadf481
Original-Signed-off-by: Yakir Yang <ykk@rock-chips.com>
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289671
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11390
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This ensures the output buffer is initialized before exiting
decode_edid() so that if the return value is ignored in higher-level
logic (like when dealing with external displays) we don't leave
the struct filled with garbage.
BUG=chrome-os-partner:42946
BRANCH=firmware-veyron
TEST=none
Change-Id: I557e2495157458342db6d8b0b1ecb39f7267f61f
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: bb12dca133576543efa4d3bcc9aadf85d37c8b71
Original-Change-Id: I697436fffadc7dd3af239436061975165a97ec8c
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/293547
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11389
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This replaces various timing mode parameters parameters with
an edid_mode struct within the edid struct.
BUG=none
BRANCH=firmware-veyron
TEST=built and booted on Mickey, saw display come up, also
compiled for link,falco,peppy,rambi,nyan_big,rush,smaug
[pg: extended to also cover peach_pit, daisy and lenovo/t530]
Change-Id: Icd0d67bfd3c422be087976261806b9525b2b9c7e
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: abcbf25c81b25fadf71cae106e01b3e36391f5e9
Original-Change-Id: I1bfba5b06a708d042286db56b37f67302f61fff6
Original-Signed-off-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/289964
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: http://review.coreboot.org/11388
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
There are serveral members of the edid struct which are never used
outside of the EDID parsing code itself. This patch moves them to a
struct in edid.c. They might be useful some day but until then we can
just pretty print them and not pollute the more general API.
BUG=none
BRANCH=firmware-veyron
TEST=compiled for veyron_mickey, peppy, link, nyan_big, rush, smaug
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I660f28c850163e89fe1f59d6c5cfd6e63a56dda0
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Original-Commit-Id: ee8ea314a0d8f5993508f560fc24ab17604049df
Original-Change-Id: I7fb8674619c0b780cc64f3ab786286225a3fe0e2
Original-Reviewed-on: https://chromium-review.googlesource.com/290333
Original-Reviewed-by: Yakir Yang <ykk@rock-chips.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Commit-Queue: David Hendricks <dhendrix@chromium.org>
Original-Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/11387
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add native XGI Z9s framebuffer support to coreboot
XGI initialization code largely taken from Linux 3.18.5
TEST: Booted KFSN4-DRE with XGI Volari Z9s into SeaBIOS
with SeaVGABIOS enabled. Text appeared correctly on screen
and interaction with graphical comboot menu was successful.
However, Linux cleared the framebuffer on boot, rendering the
screen useless until Linux loaded its native xgifb driver.
Change-Id: I606a3892849fc578b0c4d74536aec0a0adef3be3
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8331
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
If it's a 4 byte format (as per documentation), there
are some reserved bits, so let's mark them as such...
Unfortunately undone while upstreaming changes.
Change-Id: I50f12cfff2c9bb9d082a5f3c3ac54c0d514d862c
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Originally-Reviewed-on: http://review.coreboot.org/7674
Reviewed-on: http://review.coreboot.org/7964
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Use 'd' instead of 'hhd' when printing absolute year of manufacture. This
is the correct type in this case, as the result is autoatically promoted
to int.
Change-Id: Ice4155bb1a04f206ae55c45c260089d6971b77d1
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/7885
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
The length modifiers for unsigned char were accidentally changed from
'hh' to 'h' with commit:
* 1c8ee21 edid: Change static variables to auto variables.
Change-Id: I4b3e63cbcde7635b842894f776373f7946bd0df8
Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-on: http://review.coreboot.org/4477
Tested-by: build bot (Jenkins)
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
|
|
In last clean-up commit, the detailed_blocks parsing has been merged to one
for-loop and combining return values in each iteration instead of assignment.
As a result, has_valid_detailed_blocks should now be initialized as 1.
BRANCH=none
BUG=none
TEST=Tested AUO 1080p and InnoLux 720p panels on nyan_big
Original-Change-Id: Ie4b6e25de63c0e216ae5de9bde20eed1fe3e59a6
Original-Signed-off-by: Vince Hsu <vinceh@nvidia.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/195803
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Hung-Te Lin <hungte@chromium.org>
Original-Tested-by: Hung-Te Lin <hungte@chromium.org>
(cherry picked from commit 21ac533d17c892c39532c263cc6ec15e4507ed3e)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I23111efb902c7e5994a4dbdfe77242c13ef5a70e
Reviewed-on: http://review.coreboot.org/7835
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
To support parsing multiple EDID blobs, the static "decode results" flags should
be changed to auto variables inside decode_edid.
This is done by packaging static variables into a structure inside decode_edid.
We also revised some functions (manufacturer_name, do_checksum) to avoid
accessing global variables directly. Extension (and detail block) parsing may
need to access and return all parsed context so we pass the whole structure to
it.
BRANCH=none
BUG=none
TEST=emerge-nyan coreboot chromeos-bootimage
# See EDID parsed correctly on Nyan.
Original-Change-Id: Ieca93d446bacf655c145dffdfa6cc6f5dc87ac26
Original-Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/195372
Original-Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit ed45909df24c05a0cb8b2ff662fdd2d7a39012f0)
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I17cdfa770181a6eaac9d1050d340c8e052572b4a
Reviewed-on: http://review.coreboot.org/7834
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
First, we don't want floats in our code base.
Second, the calculation of the aspect ratio was wacky,
using a value guaranteed to be 0 for aspect ratio calculation.
While at it, define the aspect_* fields to be in tenths, to
provide some additional resolution. They were like that already
but we now also commit to that.
Change-Id: I5511adf4bf76cdd6a69240491372f220ef1aa687
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: http://review.coreboot.org/7803
Reviewed-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins)
|
|
If it's a 4 byte format (as per documentation), there
are some reserved bits, so let's mark them as such...
Change-Id: I50f12cfff2c9bb9d082a5f3c3ac54c0d514d862b
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/7674
Tested-by: build bot (Jenkins)
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In E-EDID (EDID v1.3), Monitor Name (0xfc) and Monitor Range Limits (0xfd) are
always required. However, some panels do not really have these fields. As a
workaround (and since we don't really use these fields), we only print warning
messages for that case.
Change-Id: I81b1db7d7f6c6f9320a862608dec4c7be298d7db
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193742
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
(cherry picked from commit c633215ef8342664d9a4478e821fc8aad368b7f3)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/7009
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
EDID v1.4 has changed some fields (0xfc - Monitor Name, 0xfd - Monitor Range
Limits) to optional so we need to list the requirements explicitly instead of
sharing v1.3 requirements.
Change-Id: I5c7ca06893bd20e178bc35164c4ca639c881e00b
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193013
(cherry picked from commit 2ad598b8bd620117e70e13347365d74a7c6b87ef)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6998
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The detail block may contain timing descriptor, or other fields like monitor
descriptor, so we should return 1 in detailed_block function when a valid
structure is found, otherwise for any EDID containing monitor descriptor we will
see following error messages:
EDID block does not conform at all!
Detailed blocks filled with garbage
Change-Id: Ib4e91d648741e5b54a558d53a1152273c7341427
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193002
(cherry picked from commit a1f212d6aaa14d5f795beeabdb8b7b8a79578c33)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6997
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
The ASCII Data String in EDID Monitor Descriptor (3.10.3) is "Stored as ASCII,
code page #437" and may contain special characters like '-'. The isalnum check
should be removed.
Also, the "Monitor Name" (0xfc) does not need to always end with 0Ah, so the
name_descriptor_terminated should be replaced by has_valid_string_termination.
Change-Id: I12a670237e12577fc971c0fbd9b2a61c82040ad3
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193001
(cherry picked from commit 671f82fd5963e32e72d3886aa242cb3e8519f226)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6996
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
When parsing "extensions", we should skip the first EDID (main) block and start
from offset 128 (EDID may have only main block, so an EDID without any
extension is fine) because the header format for main block and extensions are
different.
Without this we will see "Unknown extension block" on all EDIDs, and seeing an
error (1) return value for EDIDs without extension.
Also, after the first "unknown" error is fixed, we can now collect all return
values from parse_extension, and return an error when any of the extensions are
wrong (not just last one).
Change-Id: I0ee029ac8ec6800687cd7749e23989399e721109
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193011
(cherry picked from commit fdf0cc2e9573c19b550fa2b5e4e06337b114f864)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6995
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Some lines in decode_edid have incorrect indent levels.
Change-Id: Icc9cb57ff8dd2e2056599b3dc733fe5ac4e41c16
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/193010
Reviewed-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 3211ac0a29a037c5414f9ed1736c8f7822ad116b)
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6994
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Peppy had some issues with FUI. We decided it was time to create
peppy-specific gma.c and i915io.c files. Using yabel and the i915tool,
we generated a replay attack, then interpolated against the slippy
i915io.c to get something working.
Also, in preparation for moving code out of the mainboard gma.c to
generic driver code, we got rid of some hardcodes in the mainboard
gma.c that have no business being there. The worst were the
computation of gmch_[m,n] and it turns out that we had some
long-standing bugs related to confusion about 'bpp'. I've killed the
word bpp everywhere I could because there are at least 3 things that
correspond to bpp. We now have framebuffer, pipe, and panel bpp. The
names are long because I want to avoid all the mistakes we've all been
making in the last year :-) Sadly, that means a lot of changes not just
peppy-related, but they are simple and in a good cause.
The test pattern generation is driven by a global variable in
mainboard/peppy/gma.c. I've found in the past that it's very useful
to have a function like this available, as one can activate it while
using a jtag debugger: halt at the right place in ramstage, set the
variable to 1, continue. It's not enough code to worry about always
including.
The last hard-codes for M and N registers are gone, and the function
to set from generic intel_dp.c code works. To avoid screen trash on a
dev mode boot, which we liked but nobody else did :-), we now take the
time to put a pleasing background color that sort of doubles as a
power LED.
Rough timing is ramstage start is at 2.2, and dev setup is done at
3.3. These new platforms are depressingly slow to boot. Rom init alone
is taking 1.9 seconds. 13 years ago it was 3 seconds from power on to bash
prompt. These CPUs are at least 10x faster and take much longer to get going.
Future work, once we get this through, is to move more functions to the
intel driver, and combine the mainboard i915io.c into the mainboard gma.c.
That separation only existed because i915io.c was generated by a tool, and it
had lots of ugliness. Most ugliness is gone.
Old-Change-Id: I6a6295b423a41e263f82cef33eacb92a14163321
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/170013
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Commit-Queue: Ronald Minnich <rminnich@chromium.org>
Tested-by: Ronald Minnich <rminnich@chromium.org>
Reviewed-by: Furquan Shaikh <furquan.m.shaikh@gmail.com>
(cherry picked from commit 8cdaf73e3602e15925859866714db4d5ec6c947d)
snow: Fix a typo in devicetree.cb that was breaking the snow build.
A typo in a recent change broke the snow build.
Old-Change-Id: I93074e68eb3d21510d974fd8e9c63b3947285afd
Signed-off-by: Gabe Black <gabeblack@google.com>
Reviewed-on: https://chromium-review.googlesource.com/171014
Reviewed-by: Ronald Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 154876c126a6690930141df178485658533096d2)
Squashed a fix into the initial patch and updated nehalem/gma.c
to have a non-static gtt_poll.
Change-Id: I2f4342c610d87335411da1d6d405171dc80c1f14
Signed-off-by: Isaac Christensen <isaac.christensen@se-eng.com>
Reviewed-on: http://review.coreboot.org/6657
Tested-by: build bot (Jenkins)
|
|
While vendor specific extension blocks are mostly opaque to us,
they're not exactly "unknown".
Change-Id: I9136c04d12045ad13ef4f942c0814c4df88bdf6b
Found-by: Coverity Scan
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/6563
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
Decoding EDID doesn't yet mean that gfx mode is used.
Change-Id: Icedd36f26877754f34dd59233cce72271d7f0b19
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/5269
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
clang complains otherwise.
Change-Id: I2ac98d7147ecd3d7064f17f8c9d214d44baedf97
Signed-off-by: Patrick Georgi <patrick@georgi-clan.de>
Reviewed-on: http://review.coreboot.org/4717
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
|
|
This includes the new dp code, which is better, and the fimd code,
which is changed and improved. We took the chance to remove un-needed
files, and also to remove some foolish u-boot habits, but not all of
them. That will take time.
With these changes we get graphics.
Since the only mainboards we have with 16 bit graphics are 5:6:5,
adjust edid.c to just use that format. If at some future time we need
4:4:4, which seems unlikely, we'll need to add a function to adjust
the lb_framebuffer. Note that you can't just divine this from the EDID,
as the graphics pipe format need not match the actual final format used.
The EDID reading works. We've been requested to support hard-coded
EDIDs and that will come in the next revision. Currently the hard-coded
EDID is ignored for testing.
Change-Id: Ib4d06dc3388ab90c834f94808a51133e5b515a4d
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64240
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/4432
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Works fine with all three panels with the change of 6 bits per color.
Change-Id: Ia47d152e62d1879150d8cf9a6657b62007ef5c0e
Reviewed-on: https://gerrit.chromium.org/gerrit/63762
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4402
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Change-Id: I9a628cec4da127a3f072d9611259dad99dfa9d29
Reviewed-on: https://gerrit.chromium.org/gerrit/63125
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4382
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
... based on the EDID detailed timing values for
pixel_clock and link_clock.
Two undocumented registers 0x6f040 and 0x6f044 correspond to link_m and link_n
respectively. Other two undocumented registers 0x6f030 and 0x6f034 correspond
to data_m and data_n respectively.
Calculations are based on the intel_link_compute_m_n from linux kernel.
Currently, the value for 0x6f030 does not come up right with our calculations.
Hence, set to hard-coded value.
Change-Id: I40ff411729d0a61759164c3c1098504973f9cf5e
Reviewed-on: https://gerrit.chromium.org/gerrit/62915
Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Commit-Queue: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: http://review.coreboot.org/4381
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <patrick@georgi-clan.de>
|
|
Now that we have horizontal display areas that are not multiples of 32 bytes,
things are more complex. We add three struct members (x, y resolution and
bytes per line) which are to be filled in by the mainboard as it sets the mode.
In future, the EDID code may take a stab at initializing these but the values are
context-dependent.
Change-Id: Ib9102d6bbf8c66931f5adb1029a04b881a982cfe
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/60514
Tested-by: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Commit-Queue: Ronald G. Minnich <rminnich@chromium.org>
Reviewed-on: http://review.coreboot.org/4336
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
We've got enough of a handle on this to realize some things:
drm_dp_helper.h is by design device and architecture independent
i915.h is common to most intel graphics chipsets going back several years
i915_reg.h is as well
Move these files to src/include/device, and adjust the .c files accordingly.
Change-Id: I07512b3695fea0b22949074b467986420783d62a
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3637
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
Add three functions to edid.c:
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr)
takes an edid and uintptr_t, and fills in a static lb_framebuffer struct
as well as setting the static vbe_valid to 1 unless some problem
is found in the edid. The intent here is that this could be called from
the native graphics setup code on both ARM and x86.
int vbe_mode_info_valid(void)
returns value of the static vbe_valid.
void fill_lb_framebuffer(struct lb_framebuffer *framebuffer)
copies the static edid_fb to lb_framebuffer.
There is now a common vbe.h in src/include, removed the two special ones.
In general, graphics in coreboot is a mess, but graphics is always a
mess. We don't have a clean way to try two different ways to turn on
a device and use the one that works. One battle at a time. Overall,
things are much better.
The best part: this code would also work for ARM, which also uses EDID.
Change-Id: Id23eb61498b331d44ab064b8fb4cb10f07cff7f3
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Gabe Black <gabeblack@chromium.org>
Reviewed-on: http://review.coreboot.org/3636
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
|
src/lib/edid.c:1177: error: ‘y’ may be used uninitialized in this function
Warning is bogus, but seems my gcc (4.4.7 as shipped by RHEL-6)
isn't clever enougth to figure this on its own. So help a bit
by explicitly initializing the variable.
Change-Id: Ia9f966c9c0a6bd92a9f41f1a4a3c8e49f258be37
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-on: http://review.coreboot.org/3501
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
|
|
This code is taken from an EDID reader written at Red Hat.
The key function is
int decode_edid(unsigned char *edid, int size, struct edid *out)
Which takes a pointer to an EDID blob, and a size, and decodes it into
a machine-independent format in out, which may be used for driving
chipsets. The EDID blob might come for IO, or a compiled-in EDID
BLOB, or CBFS.
Also included are the changes needed to use the EDID code on Link.
Change-Id: I66b275b8ed28fd77cfa5978bdec1eeef9e9425f1
Signed-off-by: Ronald G. Minnich <rminnich@google.com>
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: http://review.coreboot.org/2837
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
|
