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)

3 files changed, 33 insertions, 46 deletions

diff --git a/src/drivers/intel/gma/i915.h b/src/drivers/intel/gma/i915.h
index 72301e1477..e8940a3b98 100644
--- a/src/drivers/intel/gma/i915.h
+++ b/src/drivers/intel/gma/i915.h
@@ -139,7 +139,7 @@ struct intel_dp {
 	int port;
 	int pipe;
 	int plane;
-	int bpp;
+	int pipe_bits_per_pixel;
 	/* i2c on aux is ... interesting.
 	 * Before you do an i2c cycle, you need to set the address.
 	 * This requires we remember it from one moment to the next.
@@ -272,6 +272,7 @@ int intel_dp_get_lane_align_status(struct intel_dp *intel_dp,
 void intel_prepare_ddi(void);
 void intel_ddi_set_pipe_settings(struct intel_dp *intel_dp);
 
+int gtt_poll(u32 reg, u32 mask, u32 value);
 void gtt_write(u32 reg, u32 data);
 u32 gtt_read(u32 reg);
 
diff --git a/src/drivers/intel/gma/intel_ddi.c b/src/drivers/intel/gma/intel_ddi.c
index 2b27f6eb65..e51fb9ce13 100644
--- a/src/drivers/intel/gma/intel_ddi.c
+++ b/src/drivers/intel/gma/intel_ddi.c
@@ -253,7 +253,7 @@ void intel_ddi_set_pipe_settings(struct intel_dp *intel_dp)
 {
 	u32 val = TRANS_MSA_SYNC_CLK;
 
-	switch (intel_dp->bpp) {
+	switch (intel_dp->pipe_bits_per_pixel) {
 	case 18:
 		val |= TRANS_MSA_6_BPC;
 		break;
@@ -267,7 +267,7 @@ void intel_ddi_set_pipe_settings(struct intel_dp *intel_dp)
 		val |= TRANS_MSA_12_BPC;
 		break;
 	default:
-		printk(BIOS_ERR, "Invalid bpp settings %d\n", intel_dp->bpp);
+		printk(BIOS_ERR, "Invalid bpp settings %d\n", intel_dp->pipe_bits_per_pixel);
 	}
 	gtt_write(TRANS_MSA_MISC(intel_dp->transcoder),val);
 }
diff --git a/src/drivers/intel/gma/intel_dp.c b/src/drivers/intel/gma/intel_dp.c
index 833a4d6834..393692bd04 100644
--- a/src/drivers/intel/gma/intel_dp.c
+++ b/src/drivers/intel/gma/intel_dp.c
@@ -260,7 +260,7 @@ int intel_dp_set_bw(struct intel_dp *intel_dp)
 
 int intel_dp_set_lane_count(struct intel_dp *intel_dp)
 {
-	printk(BIOS_SPEW, "DP_LANE_COUNT_SET");
+	printk(BIOS_SPEW, "DP_LANE_COUNT_SET %d ", intel_dp->lane_count);
 	return intel_dp_aux_native_write_1(intel_dp,
 					   DP_LANE_COUNT_SET,
 					   intel_dp->lane_count);
@@ -471,7 +471,24 @@ unsigned int roundup_power_of_two(unsigned int n)
 static void compute_m_n(unsigned int m, unsigned int n,
 			unsigned int *ret_m, unsigned int *ret_n)
 {
-	*ret_n = MIN(roundup_power_of_two(n), DATA_LINK_N_MAX);
+	/* We noticed in the IO operations that
+	 * the VBIOS was setting N to DATA_LINK_N_MAX.
+	 * This makes sense, actually: the bigger N is, i.e.
+	 * the bigger the denominator is, the bigger
+	 * the numerator can be, and the more
+	 * bits of numerator you get, the better the result.
+	 * So, first pick the max of the two powers of two.
+	 * And, in the (unlikely) event that you end up with
+	 * something bigger than DATA_LINK_N_MAX, catch that
+	 * case with a MIN. Note the second case is unlikely,
+	 * but we are best off being careful.
+	 */
+	/*
+	 * This code is incorrect and will always set ret_n
+	 * to DATA_LINK_N_MAX.
+	 */
+	*ret_n = MAX(roundup_power_of_two(n), DATA_LINK_N_MAX);
+	*ret_n = MIN(*ret_n, DATA_LINK_N_MAX);
 	*ret_m = ( (unsigned long long)m * *ret_n) / n;
 	intel_reduce_m_n_ratio(ret_m, ret_n);
 }
@@ -483,7 +500,6 @@ void intel_dp_compute_m_n(unsigned int bits_per_pixel,
 			  struct intel_dp_m_n *m_n)
 {
 	m_n->tu = 64;
-
 	compute_m_n(bits_per_pixel * pixel_clock,
 		    link_clock * nlanes * 8,
 		    &m_n->gmch_m, &m_n->gmch_n);
@@ -492,35 +508,6 @@ void intel_dp_compute_m_n(unsigned int bits_per_pixel,
 		    &m_n->link_m, &m_n->link_n);
 }
 
-/* not sure. */
-void intel_dp_set_m_n(struct intel_dp *intel_dp);
-
-void
-intel_dp_set_m_n(struct intel_dp *intel_dp)
-{
-	int lane_count;
-	struct intel_dp_m_n m_n;
-	int pipe = intel_dp->pipe;
-
-	lane_count = intel_dp->lane_count;
-
-	/*
-	 * Compute the GMCH and Link ratios. The '3' here is
-	 * the number of bytes_per_pixel post-LUT, which we always
-	 * set up for 8-bits of R/G/B, or 3 bytes total.
-	 */
-	intel_dp_compute_m_n(intel_dp->bpp, lane_count,
-			     intel_dp->clock, intel_dp->clock, &m_n);
-
-	{
-		gtt_write(TRANSDATA_M1(pipe),
-			  ((m_n.tu - 1) << PIPE_GMCH_DATA_M_TU_SIZE_SHIFT) |m_n.gmch_m);
-		gtt_write(TRANSDATA_N1(pipe),m_n.gmch_n);
-		gtt_write(TRANSDPLINK_M1(pipe),m_n.link_m);
-		gtt_write(TRANSDPLINK_N1(pipe),m_n.link_n);
-	}
-}
-
 static void ironlake_edp_pll_off(void);
 
 void
@@ -1791,17 +1778,13 @@ intel_dp_get_max_downspread(struct intel_dp *intel_dp, u8 *max_downspread)
 	return 1;
 }
 
-void intel_dp_set_m_n_regs(struct intel_dp *intel_dp)
+void intel_dp_set_m_n_regs(struct intel_dp *dp)
 {
-        gtt_write(PIPE_DATA_M1(intel_dp->transcoder),0x7e4a0000);
-        /* gtt_write(0x6f034,0x00800000); */
-        /* Write to 0x6f030 has to be 0x7e4ayyyy -- First four hex digits are important.
-           However, with our formula we always see values 0x7e43yyyy (1366 panel) and
-           0x7e42yyy (1280 panel) */
-        /* gtt_write(PIPE_DATA_M1(intel_dp->transcoder),TU_SIZE(intel_dp->m_n.tu) | intel_dp->m_n.gmch_m); */
-        gtt_write(PIPE_DATA_N1(intel_dp->transcoder),intel_dp->m_n.gmch_n);
-        gtt_write(PIPE_LINK_M1(intel_dp->transcoder),intel_dp->m_n.link_m);
-        gtt_write(PIPE_LINK_N1(intel_dp->transcoder),intel_dp->m_n.link_n);
+        gtt_write(PIPE_DATA_M1(dp->transcoder),
+		  TU_SIZE(dp->m_n.tu) | dp->m_n.gmch_m);
+        gtt_write(PIPE_DATA_N1(dp->transcoder),dp->m_n.gmch_n);
+        gtt_write(PIPE_LINK_M1(dp->transcoder),dp->m_n.link_m);
+        gtt_write(PIPE_LINK_N1(dp->transcoder),dp->m_n.link_n);
 }
 
 void intel_dp_set_resolution(struct intel_dp *intel_dp)
@@ -1826,10 +1809,13 @@ int intel_dp_get_training_pattern(struct intel_dp *intel_dp,
 int intel_dp_get_lane_count(struct intel_dp *intel_dp,
 			    u8 *recv)
 {
-	return intel_dp_aux_native_read_retry(intel_dp,
+	int val = intel_dp_aux_native_read_retry(intel_dp,
 					      DP_LANE_COUNT_SET,
 					      recv,
 					      0);
+	*recv &= DP_LANE_COUNT_MASK;
+	printk(BIOS_SPEW, "Lane count %s:%d\n", val < 0 ? "fail" : "ok", *recv);
+	return val;
 }
 
 int intel_dp_get_lane_align_status(struct intel_dp *intel_dp,