aboutsummaryrefslogtreecommitdiff
path: root/src/mainboard/intel/wtm2/i915io.h
diff options
context:
space:
mode:
authorRonald G. Minnich <rminnich@google.com>2013-04-17 16:57:30 -0700
committerStefan Reinauer <stefan.reinauer@coreboot.org>2013-07-09 22:16:37 +0200
commit4f78b187499d8e1f4a2fe3dad8e0997c91f15762 (patch)
tree26b728417cb204b80b43f3cd76b56dab7d5fad06 /src/mainboard/intel/wtm2/i915io.h
parent2a66d6b804acd22fddc2e51550ba39d2561c1234 (diff)
fox_wtm2: First step support for coreboot-based graphics startup
This code is the initial version of FUI for haswell and wtm2. The code is simplified from before in many ways. I've gotten rid of the opcode table, because it obscured meaning and I don't think it is needed any more. Register sets, mainly used for reset, are just lines of code -- not many of them. There are a bunch of not-yet-documented registers here; the VBIOS seemed to think they were necessary and testing shows they seem to be right. As a bit of added paranoia, we always include the VBIOS code as our emergency recovery path. You have to run it now anyways, so this is no regression from our current situation; and, if all goes well, in a week (or so), you'll never have to run it again, but like the Force and nose hair, it will be with you always. The code can return in three ways. The first, best way is success: panel is up and the VBIOS need not run. The second mode is that we tried to light up the panel but could not, for some reason, but will return with the panel partly up. In this case, it's ok not to power cycle the panel. The third, worst case, which will NEVER happen, ha ha, is that we have to turn the panel off and wait the required 600ms for it to cycle. Life sucks sometimes. This failure mode is in the 'hang on we're going to fix it' category now that we have ramstage in RW. The Big Goal here is to create something other coreboot ports can use as well. The guys doing the x60 report that the link FUI works, without too many mods, on that chipset, so it seems Intel is keeping things from changing too much over time. Also, again, please note: this and the next 3 versions will ALWAYS fail. The goal is to verify the correctness of the recovery path. The bizarre tab-space formatting in drm_dp_helper.h is from the original, as in i915_reg.h Change-Id: I6ecf454633029d185c29d470980b5a0f3114a8ce Signed-off-by: Ronald G. Minnich <rminnich@google.com> Signed-off-by: Gabe Black <gabeblack@chromium.org> Reviewed-on: http://review.coreboot.org/3635 Tested-by: build bot (Jenkins) Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Diffstat (limited to 'src/mainboard/intel/wtm2/i915io.h')
-rw-r--r--src/mainboard/intel/wtm2/i915io.h90
1 files changed, 39 insertions, 51 deletions
diff --git a/src/mainboard/intel/wtm2/i915io.h b/src/mainboard/intel/wtm2/i915io.h
index 2277188b6a..52842adb45 100644
--- a/src/mainboard/intel/wtm2/i915io.h
+++ b/src/mainboard/intel/wtm2/i915io.h
@@ -18,71 +18,59 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#include "i915_reg.h"
-#include "drm_dp_helper.h"
+#include <northbridge/intel/haswell/i915_reg.h>
+#include <northbridge/intel/haswell/drm_dp_helper.h>
/* things that are, strangely, not defined anywhere? */
-#define PCH_PP_UNLOCK 0xabcd0000
-#define WMx_LP_SR_EN (1<<31)
+#define PCH_PP_UNLOCK 0xabcd0000
+#define WMx_LP_SR_EN (1<<31)
+#define PRB0_TAIL 0x02030
+#define PRB0_HEAD 0x02034
+#define PRB0_START 0x02038
+#define PRB0_CTL 0x0203c
-/* Google Link-specific defines */
+
+/* mainboard-specific defines */
+/* how many bytes do we need for the framebuffer?
+ * Well, this gets messy. To get an exact answer, we have
+ * to ask the panel, but we'd rather zero the memory
+ * and set up the gtt while the panel powers up. So,
+ * we take a reasonable guess, secure in the knowledge that the
+ * MRC has to overestimate the number of bytes used.
+ * 8 MiB is a very safe guess. There may be a better way later, but
+ * fact is, the initial framebuffer is only very temporary. And taking
+ * a little long is ok; this is done much faster than the AUX
+ * channel is ready for IO.
+ */
+#define FRAME_BUFFER_BYTES (8*MiB)
/* how many 4096-byte pages do we need for the framebuffer?
- * There are 32 bits per pixel, or 4 bytes,
- * which means 1024 pixels per page.
- * HencetThere are 4250 GTTs on Link:
- * 2650 (X) * 1700 (Y) pixels / 1024 pixels per page.
+ * There are hard ways to get this, and easy ways:
+ * there are FRAME_BUFFER_BYTES/4096 pages, since pages are 4096
+ * on this chip.
*/
-#define FRAME_BUFFER_PAGES ((2560*1700)/1024)
-#define FRAME_BUFFER_BYTES (FRAME_BUFFER_PAGES*4096)
+#define FRAME_BUFFER_PAGES (FRAME_BUFFER_BYTES/(4096))
-/* One-letter commands for code not mean to be ready for humans.
- * The code was generated by a set of programs/scripts.
- * M print out a kernel message
- * R read a register. We do these mainly to ensure that if hardware wanted
- * the register read, it was read; also, in debug, we can see what was expected
- * and what was found. This has proven *very* useful to get this debugged.
- * The udelay, if non-zero, will make sure there is a
- * udelay() call with the value.
- * The count is from the kernel and tells us how many times this read was done.
- * Also useful for debugging and the state
- * machine uses the info to drive a poll.
- * W Write a register
- * V set verbosity. It's a bit mask.
- * 0 -> nothing
- * 1 -> print kernel messages
- * 2 -> print IO ops
- * 4 -> print the number of times we spin on a register in a poll
- * 8 -> restore whatever the previous verbosity level was
- * (only one deep stack)
- *
- * Again, this is not really meant for human consumption. There is not a poll
- * operator as such because, sometimes, there is a read/write/read where the
- * second read is a poll, and this chipset is so touchy I'm reluctant to move
- * things around and/or delete too many reads.
- */
-#define M 1
-#define R 2
-#define W 4
-#define V 8
-#define I 16
-#define P 32
-struct iodef {
- unsigned char op;
- unsigned int count;
- const char *msg;
- unsigned long addr;
- unsigned long data;
- unsigned long udelay;
+/* debug enums. These are for printks that, due to their place in the
+ * middle of graphics device IO, might change timing. Use with care
+ * or not at all.
+ */
+enum {
+ vio = 2, /* dump every IO */
+ vspin = 4, /* print # of times we spun on a register value */
};
/* i915.c */
unsigned long io_i915_READ32(unsigned long addr);
void io_i915_WRITE32(unsigned long val, unsigned long addr);
+int vbe_mode_info_valid(void);
+void fill_lb_framebuffer(struct lb_framebuffer *framebuffer);
/* intel_dp.c */
u32 pack_aux(u32 *src, int src_bytes);
-void unpack_aux(u32 src, u32 *dst, int dst_bytes);
+void unpack_aux(u32 src, u8 *dst, int dst_bytes);
int intel_dp_aux_ch(u32 ch_ctl, u32 ch_data, u32 *send, int send_bytes,
- u32 *recv, int recv_size);
+ u8 *recv, int recv_size);
+/* i915io.c */
+void graphics_register_reset(u32 aux_ctl, u32 aux_data, int verbose);