2013-03-13 22:35:01 +01:00
|
|
|
/*
|
|
|
|
* This file is part of the coreboot project.
|
|
|
|
*
|
|
|
|
* Copyright 2013 Google Inc.
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; version 2 of the License.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef EDID_H
|
|
|
|
#define EDID_H
|
|
|
|
|
|
|
|
/* structure for communicating EDID information from a raw EDID block to
|
|
|
|
* higher level functions.
|
|
|
|
* The size of the data types is not critical, so we leave them as
|
|
|
|
* unsigned int. We can move more into into this struct as needed.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct edid {
|
|
|
|
char manuf_name[4];
|
|
|
|
unsigned int model;
|
|
|
|
unsigned int serial;
|
|
|
|
unsigned int year;
|
|
|
|
unsigned int week;
|
|
|
|
unsigned int version[2];
|
|
|
|
unsigned int nonconformant;
|
|
|
|
unsigned int type;
|
intel/gma: Clarify code and use dedicated init for Google Peppy
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)
2013-09-20 01:45:22 +02:00
|
|
|
/* These next three things used to all be called bpp.
|
|
|
|
* Merriment ensued. The identifier
|
|
|
|
* 'bpp' is herewith banished from our
|
|
|
|
* Kingdom.
|
|
|
|
*/
|
|
|
|
/* How many bits in the framebuffer per pixel.
|
|
|
|
* Under all reasonable circumstances, it's 32.
|
|
|
|
*/
|
|
|
|
unsigned int framebuffer_bits_per_pixel;
|
|
|
|
/* On the panel, how many bits per color?
|
|
|
|
* In almost all cases, it's 6 or 8.
|
|
|
|
* The standard allows for much more!
|
|
|
|
*/
|
|
|
|
unsigned int panel_bits_per_color;
|
|
|
|
/* On the panel, how many bits per pixel.
|
|
|
|
* On Planet Earth, there are three colors
|
|
|
|
* per pixel, but this is convenient to have here
|
|
|
|
* instead of having 3*panel_bits_per_color
|
|
|
|
* all over the place.
|
|
|
|
*/
|
|
|
|
unsigned int panel_bits_per_pixel;
|
2013-04-23 19:59:11 +02:00
|
|
|
unsigned int xres;
|
|
|
|
unsigned int yres;
|
2013-03-13 22:35:01 +01:00
|
|
|
unsigned int voltage;
|
|
|
|
unsigned int sync;
|
|
|
|
unsigned int xsize_cm;
|
|
|
|
unsigned int ysize_cm;
|
|
|
|
/* used to compute timing for graphics chips. */
|
|
|
|
unsigned char phsync;
|
|
|
|
unsigned char pvsync;
|
2013-07-24 00:53:02 +02:00
|
|
|
unsigned int x_mm;
|
|
|
|
unsigned int y_mm;
|
2013-07-23 01:18:31 +02:00
|
|
|
unsigned int pixel_clock;
|
|
|
|
unsigned int link_clock;
|
2013-03-13 22:35:01 +01:00
|
|
|
unsigned int ha;
|
|
|
|
unsigned int hbl;
|
|
|
|
unsigned int hso;
|
|
|
|
unsigned int hspw;
|
|
|
|
unsigned int hborder;
|
|
|
|
unsigned int va;
|
|
|
|
unsigned int vbl;
|
|
|
|
unsigned int vso;
|
|
|
|
unsigned int vspw;
|
|
|
|
unsigned int vborder;
|
2013-06-28 23:33:30 +02:00
|
|
|
/* 3 variables needed for coreboot framebuffer.
|
|
|
|
* In most cases, they are the same as the ha
|
|
|
|
* and va variables, but not always, as in the
|
|
|
|
* case of a 1366 wide display.
|
|
|
|
*/
|
|
|
|
u32 x_resolution;
|
|
|
|
u32 y_resolution;
|
|
|
|
u32 bytes_per_line;
|
2013-03-13 22:35:01 +01:00
|
|
|
/* it is unlikely we need these things. */
|
|
|
|
/* if one of these is non-zero, use that one. */
|
2014-12-15 22:52:14 +01:00
|
|
|
/* they're aspect * 10 to provide some additional resolution */
|
2013-03-13 22:35:01 +01:00
|
|
|
unsigned int aspect_landscape;
|
|
|
|
unsigned int aspect_portrait;
|
|
|
|
const char *range_class;
|
|
|
|
const char *syncmethod;
|
|
|
|
const char *stereo;
|
|
|
|
};
|
|
|
|
|
2013-04-23 19:59:11 +02:00
|
|
|
/* Defined in src/lib/edid.c */
|
2013-03-13 22:35:01 +01:00
|
|
|
int decode_edid(unsigned char *edid, int size, struct edid *out);
|
2013-04-24 18:50:56 +02:00
|
|
|
void set_vbe_mode_info_valid(struct edid *edid, uintptr_t fb_addr);
|
2013-04-23 19:59:11 +02:00
|
|
|
|
2013-03-13 22:35:01 +01:00
|
|
|
#endif /* EDID_H */
|