summaryrefslogtreecommitdiff
path: root/src/lib/edid.c
AgeCommit message (Collapse)Author
2014-08-25intel/gma: Clarify code and use dedicated init for Google PeppyRonald G. Minnich
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)
2014-08-10src/lib/edid.c: missing break statementPatrick Georgi
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>
2014-02-21lib/edid: Don't set vbe_valid in decode_edid.Vladimir Serbinenko
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>
2014-02-19printk: support and use %hh prefixPatrick Georgi
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>
2013-12-21Pit: graphicsRonald G. Minnich
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>
2013-12-21Calculate transcoder flags based on pipe configFurquan Shaikh
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>
2013-12-21Added structure members x_mm and y_mm to edid decodingFurquan Shaikh
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>
2013-12-21FUI: Fill in link_m and link_n valuesFurquan Shaikh
... 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>
2013-12-12EDID: add fields specialized to the needs of framebuffersRonald G. Minnich
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>
2013-07-10FUI: reorganize include filesRonald G. Minnich
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>
2013-07-10Provide support for setting up the framebuffer from EDIDRonald G. Minnich
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>
2013-06-19edid: fix warningGerd Hoffmann
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>
2013-03-20link/graphics: Add support for EDIDRonald G. Minnich
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>